Sure, we can do that. I suggest repurposing the present draft as a rationale document, so basically what we have to do is merge its section 4 into 3697.
FYI the proposed authors for 3697bis are Shane Amante Brian Carpenter Sheng Jiang Jarno Rajahalme Since the WG adopted draft-ietf-6man-flow-update, should we post 3697bis immediately as a 6man draft? Regards Brian On 2011-01-18 10:58, Bob Hinden wrote: > 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 --------------------------------------------------------------------
