Fernando,

Well, one point is that there is surely no rush to publish your
draft, given the current level of usage of the flow label,
so we can take the time to ensure that the normative references
are correct in the end.

I have a list of things to do on the way to 3967bis, of which
the first one is moving house next week, so there will be a little
delay before the draft is revised according to the discussion
in Beijing.

Regards
   Brian Carpenter

On 2010-11-19 19:43, Fernando Gont wrote:
> 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,
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to