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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ok so till a new document updates 2460bis any further work on EHs is frozen as it would reference 2460bis with new text. That was my main point.

And what current EH implementations are supposed to do in the mean time ? Would IANA allocate codepoints for EH work before 2460bis is formally updated which in the current IETF speed is easy 2+years ?

Note that without the proposed clarification none of the above obstacles exist.

Thx
R.

On Mar 30, 2017 10:47, "Suresh Krishnan" <suresh.krishnan@xxxxxxxxxxxx> wrote:
Hi Robert,

> On Mar 30, 2017, at 10:31 AM, Robert Raszuk <robert@xxxxxxxxxx> wrote:
>
> Hi Brian,
>
> Could you elaborate a bit on the definition of "accidentally escaping packets" ?
>
> The fundamental issue with original Suresh suggestion I see is that his proposed text kills ability to have 2460bis as normative reference in any other draft describing or defining extension headers. And effectively stops any work which needs to be based on 2460bis till 2460bis is updated.

This is not true. The *new draft* will update RFC2460bis. We do not need a new (RFC2460bis)bis to do this. I can understand that this would be bad, but that is not the intent.

Thanks
Suresh

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]