Re: [CCAMP] AD review of draft-ietf-ccamp-assoc-ext

[Lou Berger <[e-mail]>]

Adrian,

See below.

On 8/9/2012 9:46 PM, Adrian Farrel wrote:
> Hi,
> 
> Nearly there. See in line.
> 
> Thanks or the work.
> 
> Adrian
> 
>>> To start with, a key question:
>>>
>>> Why does the working group want to publish this as an RFC when there
>>> is no immediate intention to implement for any of the many scenarios
>>> described in the document?
>>>
>>> Will this become just another Standards Track RFC that gathers dust
>>> and obfuscates the real protocol specs, or is there good reason to
>>> publish it?
>>>
>>
>> The document was motivated to support applications such as defined in
>> draft-ietf-ccamp-rsvp-resource-sharing (whose authors say they intend to
>> revive this work now that the foundation work has reach maturity.)
> 
> OK. I think that this and the other responses probably tip it towards
> publication. It feels a little premature, but not overly.
> 
>>> I can see how this updates 4872.
>>>
>>> I am not convinced about this being an update to 2205, 3209 and 3473.
> 
> [snip]
> 
> The bottom line here appears to be:
> - leave updates 4872 

> - remove updates 2205, 3209, 3473

Are you sure about this?  Other RFCs that provide incremental functions
that are not required by all implementations identify the base protocol
in the Updates field. For example, take a look at rfc5151 it says both
3209 and 3473 are updated.

> - retain text in Section 3
> - don't add updates 4873
> 

...

> 
>>> 3.1.1 vs 3.2.1
>>>
>>> In 3.1.1 you have...
>>>    Relative ordering of ASSOCIATION objects of the same
>>>    type SHOULD be preserved by transit nodes.
>>
>> note this is path processing,
>>
>>> In 3.2.1 you have...
>>>    Relative ordering of ASSOCIATION objects of the same
>>>    type MUST be preserved by transit nodes.  Association type specific
>>>    ordering requirements MAY be defined in the future.
>>
>> Note this is resv processing.
>>
>>> 1. Why is 3.1.1 SHOULD and 3.1.2 MUST?
>>
>> I'm not sure, other than 3.1.2 is new so there's no chance of placing a
>> new requirement on implementations of 4872&3 (which only use association
>> objects in Path messages.)
>>
>> I'm fine with should for both.
>>
>> Co-authors?
> 
> Francois seems to indicate SHOULD and SHOULD is OK.

done, although this means that we have to drop the following sentence.

> 
>>> 2. Why does 3.2.1 consider association type-specific rules, but these
>>>    are not in 3.1.1?
>>
>> 3.1.1 relates to path messages and we didn't want to impose new
>> requirements on implementations of 4872&3.
>>
>>> 3. s/type specific/Type-specific/
>>
>> sure.
>>
>>> 4. Why "MAY" not "may"?
>>
>> over zealousness.  i.e., your right!
>>
>>> 3.2.2
>>>
>>> s/This section apply/This section applies/
>>
>> Thanks.
>>
>>> 3.3.1
>>>
>>>    Once an association is identified, resources SHOULD be shared across
>>>    the identified sessions.
>>>
>>> This use of "SHOULD" begs the question: under what circumstances MAY
>>> resource sharing not be applied?
>>
>> actual resource allocation is really an implementation choice and
>> different internal implementation choices.  We didn't want to overly
>> constrain an implementation. "is expected" is really what we mean, but
>> how do you say this in 2119 language?
> 
> I think you are fine using SHOULD in this case. But you need to add
> ...although implementations MAY vary this according to local policy and
> resource-sharing capabilities.
> 
> (Note that Francois proposed to promote this to a MUST, which would be OK, but
> doesn't seem to be the original intent.)
> 
>>> Globally...
>>>
>>> Please be consistent with:
>>> - Association ID
>>> - association-id
>>
>> okay.
>>
>>> Section 4.1
>>>
>>> Global Association Source: 4 bytes
>>>
>>>       This field contains a value that is a unique global identifier.
>>>       This field MAY contain the 2-octet or 4-octet value of the
>>>       provider's Autonomous System Number (ASN).  It is expected that
>>>       the global identifier will be derived from the globally unique ASN
>>>       of the autonomous system hosting the Association Source.  The
>>>       special value of zero (0) indicates that no global identifier is
>>>       present. Note that a Global Association Source of zero SHOULD be
>>>       limited to entities contained within a single operator.
>>>
>>> Given the statement that the content is globally unique, I don't think
>>> there is room for you to pontificate about how this field might be
>>> filled. You need to make a definitive statement. Otherwise the content
>>> cannot be guaranteed to be globally unique (unless you envisage a
>>> central registration system!).
>>
>> Humm this text is actually lifted from 6370 which says:
>>
>>    Quoting from RFC 5003, Section 3.2:
>>       The global ID can contain the 2-octet or 4-octet value of the
>>       provider's Autonomous System Number (ASN).  It is expected that
>>       the global ID will be derived from the globally unique ASN of the
>>       autonomous system hosting the PEs containing the actual AIIs.  The
>>       presence of a global ID based on the operator's ASN ensures that
>>       the AII will be globally unique.
>>
>> How about:
>>
>>     This field contains a value that is a unique global identifier.
>>     This field MAY contain the Global_ID as defined in [RFC6370].
>>     The special value of zero (0) indicates that no global identifier
>>     is present. Note that a Global Association Source of zero SHOULD be
>>     limited to entities contained within a single operator.
> 
> Notwithstanding the problems of ambiguity introduced in RFC 5003 (the text you
> quote is poor, but section 3.2 is clearer about the actual content of the
> identifier) *this* document must not be ambiguous. Noting also that RFC 5003
> allows a provider to decide to not bother with global uniqueness.
> 
> So, I would prefer you to write...
> 
>      This field contains a value that is a unique global identifier
>      using the Global_ID as defined in [RFC6370] or the value zero (0).
>      The special value of zero indicates that no global identifier is
>      present. Note that a Global Association Source of zero SHOULD be
>      limited to entities contained within a single operator.

The old text allowed for TP Global_ID while you are now requiring it's use.

How about:

  This field contains a value that is a unique global identifier or the
  special value zero (0).  When non-zero and not overridden by local
  policy, the Global_ID as defined in [RFC6370] SHALL be used.
  The special value of zero indicates that no global identifier is
  present. Note that a Global Association Source of zero SHOULD be
  limited to entities contained within a single operator.

> 
>>> Section 4.1
>>>
>>>    Extended Association ID: variable, 4-byte aligned
>>>
>>>       This field contains data that is additional information to support
>>>       unique identification.  The length and contents of this field is
>>>       determined by the Association Source.  This field MAY be omitted,
>>>       i.e., have a zero length.  This field MUST be padded with zeros
>>>       (0s) to ensure 32-bit alignment.
>>>
>>> This is confusing. I think that the length of the field is chosen by the
>>> Association source and determined by the Length field of the Association
>>> object.
>>>
>>> But your text implies that the contents of the field may be different
>>> from a four octet quantity. Since you have not included a separate
>>> length indicator, this cannot be. The object length must always be a
>>> multiple of 4 (says RFC 2205) and so there is no difference between a
>>> zero padded field and a field where the zeros have meaning.
>>>
>>> You *could* say that the length of this field is Association Type-
>>> specific, but that would be ugly.
>>
>> How about:
>>    Extended Association ID: variable, 4-byte aligned
>>
>>       This field contains data that is additional information to support
>>       unique identification.  The length and contents of this field is
>>       determined by the Association Source.  The length of this field
>>       is derive from the object Length field and as such MUST have a
>>       zero length or be 4-byte aligned.  A zero length indicates that
>>       this field is omitted.
> 
> Still having trouble with "determined by".  Try "dependent on".

how about "scoped by"

> s/derive/derived/

k

...

Thanks,
Lou