Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

Hi Robert,

> On Mar 31, 2017, at 12:56 PM, Robert Raszuk <robert(_at_)raszuk(_dot_)net> 
> wrote:
>
> Even if we treat encapsulation in new IPv6 header as only an option ?
There are two options listed in the draft with the “either” clause quoted 
below. Both of them are compliant. In fact, in my not so careful reading, I do 
not see any text in draft-ietf-6man-segment-routing-header-06 
<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06> that 
would be contrary to this text in RFC2460bis.

Thanks
Suresh

P.S.: I am assuming you are using the word option to mean a choice and not an 
IPv6 option. If not, please clarify.

> Thx
> R.
>
>
>
> On Mar 31, 2017 12:46, "Suresh Krishnan" 
> <suresh(_dot_)krishnan(_at_)ericsson(_dot_)com 
> <mailto:suresh(_dot_)krishnan(_at_)ericsson(_dot_)com>> wrote:
> Hi Robert,
>
> > On Mar 31, 2017, at 12:01 PM, Robert Raszuk <robert(_at_)raszuk(_dot_)net 
> > <mailto:robert(_at_)raszuk(_dot_)net>> wrote:
> >
> > Hi Suresh,
> >
> > As you requested one of many quotes from the draft which your clarification 
> > to 2460bis directly contradicts with:
> >
> > This include either:
> >
> >       A host originating an IPv6 packet.
> >
> >       An SR domain ingress router encapsulating a received IPv6 packet
> >       into an outer IPv6 header followed by an SRH.
> Excellent. Thanks for pointing out the exact text. I can confirm that this 
> text  *is compliant* with the RFC2460bis text.
>
> Thanks
> Suresh

smime.p7s
Description: S/MIME cryptographic signature