On 31/03/2017 07:19, 神明達哉 wrote: > At Thu, 30 Mar 2017 11:52:41 -0500, > Robert Raszuk <robert@xxxxxxxxxx> 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@xxxxxxxx > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >