Re: [Teas] Alvaro Retana's No Objection on draft-ietf-teas-rsvp-te-srlg-collect-06: (with COMMENT)

["Alvaro Retana (aretana)" <[e-mail]>]

On 6/15/16, 6:39 PM, "Matt Hartley (mhartley)" <[e-mail]> wrote:

Matt:

Hi!

>> My comments are relatively minor but I would like to see them addressed
>> before publication.
>>
>> 1. Section 4.1. (SRLG Collection Flag): "Šthis document defines a new
>>flag
>> in the Attribute Flags TLVŠwhich MAY be carriedŠ"  I think a clearer
>> description would be something worded more along the lines of "Šwhich
>>MUST
>> be set inŠto indicate that SRLG information SHOULD be reportedŠ"
>
>I see what you're getting at, but I don't want to give the impression
>that an implementation is obliged to request SRLG recording.
>
>How about:
>
>This document defines a new SRLG collection flag in the Attribute Flags
>TLV (see RFC 5420 [RFC5420]). A node that wishes to indicate that SRLG
>collection is desired MUST set this flag in an Attribute Flags TLV in an
>LSP_REQUIRED_ATTRIBUTES or LSP_ATTRIBUTES Object to indicate that SRLG
>information SHOULD be reported.

That looks fine.


>> It would also be good if in this section the difference between
>> LSP_REQUIRED_ATTRIBUTES  and LSP_ATTRIBUTES is also explained.
>
>Given that RFC 5420 (where these are defined) is a normative reference,
>can we not assume that the reader has read it? If not, would it be better
>to add this here in 4.1, or in 3.1?

There's some text already in 5.1: "...carried either in an
LSP_REQUIRED_ATTRIBUTES Object when the collection is mandatory, or in an
LSP_ATTRIBUTES Object when the collection is desired, but not mandatory."

Moving/copying something like that towards the front would help.  I would
prefer 4.1 simply because that's where the flag is defined..


>
>> 2. Section 4.2. (RRO SRLG sub-object): "ŠThe SRLG sub-object SHOULD be
>> pushedŠbefore the node IP addressŠSHOULD be pushed after the Attribute
>> sub-object, if present, and after the LABEL sub-object, if requested."
>> Knowing that it is a stack, does it really make a difference where the
>> SRLG sub-object is pushed?  Put another way, why are you using "SHOULD"
>> and not "MUST"?
>
>First one should be a MUST. As for the others... IIRC this was
>semi-plagiarized from RFC 5420, which also uses SHOULD in a similar
>context.

My point was that "MUST" makes it so that the sub-object has to be put in
a specific place...but "SHOULD" doesn't absolutely mandate it.  If
"SHOULD" is used then the ordering doesn't matter, so we should get rid of
the normative language...

Thanks!!

Alvaro.