Brian, > > There's clearly a problem (20 unused bits and enormous confusion about > how they could be used). And clearly the goal is 3697bis. The reason for > this draft, as I believe we've discussed over some months, is to set the > scene for 3697bis. Indeed we have two choices: > > 1) agree on the substance of the intended updates and publish them as a > stake in the ground, then develop 3697bis. > > 2) agree on the substance of the intended updates (by means of the > present WGLC), and then proceed directly to develop 3697bis. > > I understood that we'd agreed on 1) but the WG Chairs can tell me I'm wrong.
After a short discussion, the chairs think that it would be preferable to either have this document become an update to RFC3697 itself, or have an RFC3697bis draft be written to be considered in parallel. In the last case this draft would be the justification and background, and the RFC3697bis draft would be an implementers spec (that is, what to do, not why). I note that RFC3697 is only 9 pages long. Bob > >> >> And in looking at draft-ietf-6man-flow-ecmp-00.txt (also in WGLC), >> that document is a BCP and does not update any of the previous Flow >> Label documents. > > Correct. It doesn't need to; it is additional practice and the intention > is to ensure that it's compatible both with 3697 and the eventual 3697bis. > (I agree with your comment on that draft that the phrasing on this > point is clumsy.) > >> If we need to update the Flow Label specs, we should do so, and this >> document could be part of that or a rational for the changes. But >> absent any changes to the existing standards, I am not comfortable >> with publishing this document. > > I would be too, if it was the end of the road, but we have an author > team all set to start on 3697bis once we have a clear consensus in > the WG about the changes to be made. Can you propose text that is > clearer than the following? > > (In the Abstract) > This document describes and motivates proposed > changes to the specification in order to clarify it, making it clear > what types of usage are possible, and to introduce some additional > flexibility. It does not formally update RFC 3697. > > > (In the Introduction) > The intention of this document is to explain this in more detail and > to propose changes to RFC 3697 intended to remove the uncertainties > and encourage active usage of the flow label. It does not formally > update RFC 3697. > > Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
