Brian, On Jan 17, 2011, at 2:32 PM, Brian E Carpenter wrote:
> 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? Yes, please do that. That is consistent with making the other flow label drafts 6man w.g. group documents. Thanks, Bob > > 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 --------------------------------------------------------------------
