On 31/03/2017 07:19, 神明達哉 wrote:
At Thu, 30 Mar 2017 11:52:41 -0500,
Robert Raszuk <robert(_at_)raszuk(_dot_)net> wrote:
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.
I don't get the logic...an "update" can start immediately once such a
draft new proposal is available. The update won't be formally
completed until it gets some formal state like a standard track RFC,
and it will take time, but that wouldn't necessarily mean a further
work is "frozen";
Exactly. At this time the *quickest* way forward is to get 2460bis through
the IESG, progress the -extension-header-insertion draft ASAP, and in due
time do an early assignment request for draft-ietf-6man-segment-routing-header
If you try that early assignment request today, it seems likely to fail.
Brian
it's not very clear to me what this term means in
this context, but it's quite common development takes place while the
spec is being discussed as a draft, and it's also not uncommon some
commercial operators even start deploying it. On the other hand, even
if we now agreed that rfc2460bis should explicitly allow such "further
work", the discussion itself would take long and wouldn't be completed
soon.
But IMO it's irresponsible to leave the text ambiguous and let some
other people misunderstand it, possibly even more casually and/or in
the global Internet, for the comfort of some particular future work.
I think we're now trying to help avoid the latest clarification in
rfc2460bis to be interpreted as an "outright ban" of future updates
while still trying to be responsible for the soundness of the global
Internet. In my understanding Brian's additional text is one such
attempt (I also proposed text in that sense at the time of WGLC,
although it wasn't adopted in the end). If that text is still not
enough we can discuss how to phrase it. And, while I suspect people
who wanted to keep the ambiguity will never be satisfied with the
result as long as the added clarification remains, I believe that's a
reasonable compromise to achieve a balance between being responsible
and not (unintentionally) discouraging future updates.
--
JINMEI, Tatuya
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6(_at_)ietf(_dot_)org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------