Hi, Shane, Thanks so much for your feedback! -- Please find my comments inline...
>> Ok. Here's the text that I've included right bellow the formular: >> >> ---- cut here ---- This scheme should be used when a new flow is to >> be created (e.g., when a new TCP connection is to be created). Once >> a Flow Label value for such flow is selected, the Flow Label field >> of all the IPv6 packets corresponding to that flow would be set to >> the selected value (until the flow is terminated). ---- cut here >> ---- > > Upon further reflection, I think it would probably be best that your > draft point toward the forthcoming RFC3697bis document, where the > latter will normatively prescribe[1]: IIRC, the Brian's I-D will aim at Informational, and only then ill it be folowed by a formal revision of RFC 3697. -- that's why draft-gont references RFC 3697 (the only normative specification so far). -- I guess it could provide an Informational pointer to Brian's document to provide hints about where things are going towards, though. > a) What constitutes a "flow" > -- already in draft-carpenter-6man-flow-update-04 (Section 4); and, > b) When new flow-labels are to be created -- possibly [more than] a > bit vague in draft-carpenter; and, c) What 'uniqueness' > characteristics there are with respect to flow-labels, e.g.: a source > node SHOULD maintain unique flow-label values among a 5-tuple -- not > in draft-carpenter from what I can tell or, at best, extremely > vague. ... in order that we're not creating confusion between the > two, (or more), different drafts/specs. More specifically, I believe > it would be good to ensure the properties list above, in (a) through > (c), are (to the largest extent possible) common to avoid further > ambiguity wrt the flow-label. You mean I should also describe the "requirements" in Brian's I-D? > Specific to your draft, what would you say to replacing the text you > have with the following: ---snip--- This scheme should be used to > generate a new flow-label value at the time a new flow is created, > (for instance, when a new transport connection is about to be > established). Please refer to RFC3697bis for the conditions that > precipitate the generation of a new flow-label value. ---snip--- The only issue here is that, as mentioned above, there's no such thing as RFC3697bis, yet. -- What if, say, I simply remove the example of "e.g., when a new flow is created", and simply state that "the definition of what a flow is is out of the scope of this document", or the like? What do others think? > In addition, assuming you agree with this general direction, it would > likely mean you could further simplify your draft by [eventually] > eliminating the first few paragraphs in Section 3 > draft-gont-6man-flowlabel-security, where you quote requirements from > RFC 3697 as to a flow label's properties. Instead, when a RFC > 3697bis becomes available, you could most likely state something at > the beginning of Section 3 like "Please refer to RFC3697bis with > respect to the properties that constitute a flow-label value." You > could then continue with the existing discussion in your draft on how > flow label reqmt's are similar to TCP port numbers, etc. You I could remove the requirements summary, and include pointers to RFC 3697 and Brian's I-D? -- FWIW, I'm open to changes... just want to double-check that these changes reflect wg consensus. What do others think? Thanks! Kind regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
