Subject: Re: [Gen-art] review of draft-ietf-teas-lsp-attribute-ro-02.txt

From: Cyril Margaria <[email-masked]>
Date: Mon, 2 Mar 2015 04:18:14 +0000

Hi, 

Thanks a lot for your review.

A new revision has been posted reflecting the comment in this mail.
URL:            
http://www.ietf.org/internet-drafts/draft-ietf-teas-lsp-attribute-ro-03.txt
Status:         
https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-attribute-ro/
Htmlized:       
http://tools.ietf.org/html/draft-ietf-teas-lsp-attribute-ro-03
Diff:           
http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-lsp-attribute-ro-03

Please see inline for detailed comment response.

On 16.02.15 08:58, "[email-masked]" <[email-masked]>
wrote:

>I am the assigned Gen-ART reviewer for this draft. For background on
>Gen-ART, please see the FAQ at
>
><http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
>Please resolve these comments along with any other Last Call comments
>you may receive.
>
>Document: draft-ietf-teas-lsp-attribute-ro-02.txt
>Reviewer: Francis Dupont
>Review Date: 20150213
>IETF LC End Date: 20150218
>IESG Telechat date: unknown
>
>Summary: Ready with nits
>
>Major issues: none
>
>Minor issues: none
>
>Nits/editorial comments:
> There are a heavy use of abbrevs. Note abbrevs are registered under
> http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
> and some (well known abbrevs, starred in the list) must be introduced
> at the first use.
>
> - title page 1: LSP (perhaps because this abbrev has 2 different
>  meanings?) and ERO are not well known abbrevs.

Addressed 
>
> - abstract page 1: usually explicit RFC numbers are forbidden here
>  but IMHO this document is an exception (i.e., its content will be
>  merged in the next revision of RFC 5420).

No change were made.

>
> - abstract page 1: LSP, ERO and RRO are not well known abbrevs
>  (BTW RSVP is and I give up about RSVP-TE)

Addressed
>
> - ToC page 2 and 3.2.1 title: Subobject presence rule ->
>  Subobject Presence Rule

Addressed

>  
> - 1 page 2: this document defines a mechanism to define ->
>  this document provides a mechanism to define
>  ("describes" could be fine too but it is used in the next sentence)
Addressed

- [additional nit]:  Section 2. Page 3 may -> MAY

>
> - 2.1 page 3, page 4: [Ss]ection Section -> Section
>  (IMHO this problem comes from the way the xref is rendered)

Addressed, all section references have been replaced by Section.

>
> - 2.3 page 4: lower case "must" (either "MUST", or "has to" or
>  another not-keyword synonym)
>  (and 3.1 page 6 (twice))

Addressed 

- [additional nit]:  Section 3. Page 5  lowercase optional : replaced by
OPTIONAL to follow RFC2119.

>
> - 3.1 page 5: lower case "may" (either "MAY" or can...)
>  (and 3.2.1 page 6)
Addressed 
>
> - 3.2.1 page 6: e.g. -> e.g.,
Addressed

>
> - 3.2.3 page 7: are met : -> are met:

Addressed

>
> - 4.3 page 8: registery -> registry

Addressed

>
> - 4.3 page 8: IMHO you should not have a reference in empty lines
>  (i.e., there should be one reference per defined bit)

The original content of the references are from,
http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te-parameters.xml#r
svp-te-parameters-2.
It seems the registry is not fully aligned with your comment.
To address the comment only the document defining the bit value has been
kept (RFC4920)

We received additional comments from IANA, as the document defines a new
value for each bit, we added “This Document” as a second reference to each
bit.

>
> - 4.3 page 8: another lower case keyword: shall

Addressed
>
> - 5 page 9: one should, 3 may's. IMHO you should simply promote
>  them to SHOULD and MAY's at the exception of the last one
>  (This may reveal -> This can reveal).
Addressed
>
> - 5 page 10: another "may reveal".
Addressed, changed to "can reveal²

- 5 page 10 : we have a recommended, it has been replaced by RECOMMENDED.

Best Regards.
Cyril.

>
>Regards
>
>[email-masked]

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 03 Mar 2015 17:58:13 +0000

Hi.

In the process of doing the gen-art review of 
draft-ietf-teas-rsvp-te-li-lb for IETF last call, I needed to look at  
draft-ietf-teas-lsp-attribute-ro-02 in connection with some comments 
about ordering of subobjects in the loopback draft.

I thought that the text in the first paragraph of s2.3:
>     As described in [RFC3209  <https://tools.ietf.org/html/rfc3209>] and [RFC3473  <https://tools.ietf.org/html/rfc3473>] the ERO is managed as a list
>     where each hop information starts with a subobject identifying an
>     abstract node or link.  The ERO Hop Attributes subobject MAY be
>     appended after any of the existing subobjects defined in [RFC3209  <https://tools.ietf.org/html/rfc3209>],
>     [RFC3473  <https://tools.ietf.org/html/rfc3473>], [RFC3477  <https://tools.ietf.org/html/rfc3477>], [RFC4873  <https://tools.ietf.org/html/rfc4873>], [RFC4874  <https://tools.ietf.org/html/rfc4874>], [RFC5520  <https://tools.ietf.org/html/rfc5520>] and [RFC5553  <https://tools.ietf.org/html/rfc5553>].
>     Several ERO Hop Attributes subobject MAY be present, for each hop.
was not very clear: The use of 'appended' was slightly confusing.  I 
felt it needed something a bit closer to the "Presence Rules" that are 
given for RRO subobjects in RFC 5420, s7.3.1 to make it quite clear what 
is going on.

I am not totally clear what would happen in the case of (say) an IPv4 
address subobject followed by two Label subobjects.  The wording seems 
to indicate that Hop attributes can be inserted anywhere in the sequence 
of three subobjects - but would they specifically apply to one or other 
Label if they were inserted after a Label or would they always apply 
generically to the hop terminated at the IPv4 address entity?

My suggestion for rewording, based on the assumption that the hop 
attributes apply to the hop rather than any of the labels, would be:

    As described in [RFC3209] the ERO is managed as a list of subobjects
    each identifying a specific entity, an abstract node or a link. 
Identifying
    subobjects of various types are defined in [RFC3209], [RFC3477], 
[RFC4873],
    [RFC4874], [RFC5520] and [RFC5553].  [RFC3473] modified the ERO list by
    allowing one or two Label subobjects to be interposed in the list 
after a
    subobject identifying an entity by its IP address or interface 
identifier.   One
    or more ERO Hop attributes subobjects applicable to a particular hop 
MAY
    be inserted after any of the existing identifying subobjects defined in
    [RFC3209],  [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553].
    If any Label subobjects are present for a hop, the ERO Hop attributes
    subobject(s) MUST be inserted after the Label subobjects.

The last two sentences would need to be altered if Hop attributes were 
applicable to Labels rather than just to the hop as a whole.

Regards,
Elwyn

---

From: Cyril Margaria <[email-masked]>
Date: Wed, 4 Mar 2015 01:04:36 -0500

Hi,

Thanks for your review,
Please not that a new revision addressing IANA , APS-DIR and Gen-ART
comments  on revision -02 is available.
https://tools.ietf.org/html/draft-ietf-teas-lsp-attribute-ro-03

 please see inline.

On 3 March 2015 at 12:58, Elwyn Davies <[email-masked]> wrote:

> draft-ietf-teas-lsp-attribute-ro-02 in connection with some comments about
> ordering of subobjects in the loopback draft.
>
>  was not very clear: The use of 'appended' was slightly confusing.  I felt
> it needed something a bit closer to the "Presence Rules" that are given for
> RRO subobjects in RFC 5420, s7.3.1 to make it quite clear what is going
> on.
>
> address subobject followed by two Label subobjects.  The wording seems to
> indicate that Hop attributes can be inserted anywhere in the sequence of
> three subobjects - but would they specifically apply to one or other Label
> if they were inserted after a Label or would they always apply generically
> to the hop terminated at the IPv4 address entity?
>
>
draft-ietf-teas-lsp-attribute-ro tries to leave that open to the documents
defining the TLVs. We are not excluding an Attribute that applies to a
Label or Interface. If the subobject would be inserted after a Label
Subobject, the Attribute TLVs would apply to the Labels.

This is based on the following review comment:"
I think *this* I-D needs to make it clear what the expectations are:

1. The sub-object is allowed at any point in the ERO
2. The document that specifies a TLV for the sub-object must make it
   clear where in an ERO a sub-object containing that TLV is allowed and
   not allowed."

Do you think this is reasonable or we should exclude TLVs scoped to labels?
In the latter case, I would add you suggested text.

Best Regards.
Cyril

PS: It seems there are errors with the tools.ietf.org aliases

>    allowing one or two Label subobjects to be interposed in the list after
> a
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>
>

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 04 Mar 2015 18:29:38 +0000

> https://tools.ietf.org/html/draft-ietf-teas-lsp-attribute-ro-03
Hi, Cyril.

Yes:  my comments and the new version crossed.

However -03 doesn't significantly alter para 1 of s2.3.

Firstly, I am far from expert in this area, so I have not much clue as 
to whether it would ever be useful or meaningful to associate an 
attribute with a Label rather than with the entity identified by the 
other subobject types.  However, it has just occurred to me that with 
the loopback case, one needs to  decide that if there are two labels, 
does loopback apply to both of them or just one?  Arrrgggh!

Perhaps something like the following, replacing the first two paras of 
s2.3, would cover all the bases and push the decision down to the 
document that defines the TLV(s)/flags used in the Hop attribute subobjects:

OLD:
    As described in [RFC3209] and [RFC3473] the ERO is managed as a list
    where each hop information starts with a subobject identifying an
    abstract node or link.  The ERO Hop Attributes subobject MAY be
    appended after any of the existing subobjects defined in [RFC3209],
    [RFC3473], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553].
    Several ERO Hop Attributes subobject MAY be present, for each hop.

    Document defining specific Hop attribute TLV has to describe after
    which kind of subobject they are valid and if TLV modification rules
    applies.  For instance, subobject presence rules can be defined by
    describing rules similar to [RFC4990] Section 6.1.

NEW:
    As described in [RFC3209] the ERO is managed as a list of subobjects
    each identifying a specific entity, an abstract node or a link that 
defines
    a waypoint in the ERO route.  Identifying subobjects of various 
types are
    defined in [RFC3209], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and
    [RFC5553].

    [RFC3473] modified the ERO list by allowing one or two Label subobjects
    to be interposed in the list after a subobject identifying an entity 
by its
    IP address or interface identifier.   One or more ERO Hop attributes
    subobjects applicable to a particular hop MAY be inserted directly 
after
    any of the existing identifying subobjects defined in [RFC3209], 
[RFC3477],
    [RFC4873], [RFC4874], [RFC5520] and [RFC5553].  If any Label subobjects
    are present for a hop, the ERO Hop attributes subobject(s) MAY also be
    inserted after the Label subobjects.

    The attributes specified in a ERO Hop attributes subobject apply to 
the hop
    that ends at the route waypoint identified by the immediately preceding
    identifying subobject in the ERO subobject list.

    A document defining a specific Hop attribute TLV has to describe
       -  after which kinds of subobject they are valid ,
       -  if ordering of the Hop attributes subobject and other subobjects
          associated with the same hop (e.g., Label subobjects) is 
significant,
       -  if ordering is significant, how the attribute is interpreted in
          association with the preceding subobjects, and
       -  any TLV modification rules that might apply.
    For instance, subobject presence rules can be defined by describing 
rules
    similar to [RFC4990] Section 6.1.

This might require a few words added to s2.2 to specify that the 
ordering decision for individual flags is up to the definition of the 
flag.  In turn that possibly means that the loopback draft needs to 
think about whether the loopback applies to both labels or only the one 
the loopback flag is after as mentioned above.

Regards,
Elwyn

PS
There is discussion about the .all aliases going to WG lists as well as 
relevant individuals.  The long standing position was that they didn't 
but change has recently been mooted.

/E

---

From: Cyril Margaria <[email-masked]>
Date: Wed, 4 Mar 2015 22:28:33 -0500

Hi,

Thanks for the quick feedback,
Would the following text modification address your comments .
the wording is a bit different, I tried to simplify the description of the
TLV scope.

   As described in [RFC3209] the ERO is managed as a list of subobjects
   each identifying a specific entity, an abstract node or a link that
   defines a waypoint in the network path.  Identifying subobjects of
   various types are defined in [RFC3209], [RFC3477], [RFC4873],
   [RFC4874], [RFC5520] and [RFC5553].

   [RFC3473] modified the ERO list by allowing one or two Label
   subobjects to be interposed in the list after a subobject identifying
   a link.  One or more ERO Hop Attributes subobjects applicable to a
   particular hop MAY be inserted directly after any of the existing
   identifying subobjects defined in[RFC3209], [RFC3477], [RFC4873],
   [RFC4874], [RFC5520] and [RFC5553].  If any Label subobjects are
   present for a hop, the ERO Hop Attributes subobject(s) MAY also be
   inserted after the Label subobjects.

   The attributes specified in a ERO Hop Attributes subobject apply to
   the immediately preceding subobject(s) in the ERO subobject list.

   A document defining a specific Hop Attribute TLV has to describe:

   o  after which kinds of ERO subobject they are valid ,

   o  if ordering of the Hop Attributes subobject and other ERO
      subobjects associated with the same hop (e.g., Label subobjects)
      is significant,

   o  if ordering is significant, how the attribute is interpreted in
      association with the preceding ERO subobjects, and

   o  any TLV modification rules that might apply.

   For instance, subobject presence rules can be defined by describing
   rules similar to [RFC4990] Section 6.1.

That would allow a TLV to apply to one (or more) preceding subobject, the
type of subobject being left to the TLV.

Regarding section 2.2, the following text is proposed:

   The presence and ordering rule of the Attribute Flags TLV in an ERO
   Hop Attributes Subobject is defined by each Flag.  A document
   defining a Flag to be used in a Attribute Flags TLV carried in the
   ERO Hop Attributes Subobject has to describe:

   o  after which kinds of ERO subobject the Flag is valid

   o  if ordering of the Flag and other ERO subobjects associated with
      the same hop (e.g., Label subobjects) is significant,

   o  if ordering is significant, how the Flag is interpreted in
      association with the preceding subobjects,

   o  any Flag modification rules that might apply.

If its Ok, I can post a new revision shortly.

Best Regards
Cyril

On 4 March 2015 at 13:29, Elwyn Davies <[email-masked]> wrote:

> Firstly, I am far from expert in this area, so I have not much clue as to
> whether it would ever be useful or meaningful to associate an attribute
> with a Label rather than with the entity identified by the other subobject
> types.  However, it has just occurred to me that with the loopback case,
> one needs to  decide that if there are two labels, does loopback apply to
> both of them or just one?  Arrrgggh!
>
> s2.3, would cover all the bases and push the decision down to the document
> that defines the TLV(s)/flags used in the Hop attribute subobjects:
>
> OLD:
>    a waypoint in the ERO route.  Identifying subobjects of various types
> are
>    to be interposed in the list after a subobject identifying an entity by
> its
>    subobjects applicable to a particular hop MAY be inserted directly after
>    The attributes specified in a ERO Hop attributes subobject apply to the
> hop
> This might require a few words added to s2.2 to specify that the ordering
> decision for individual flags is up to the definition of the flag.  In turn
> that possibly means that the loopback draft needs to think about whether
> the loopback applies to both labels or only the one the loopback flag is
> after as mentioned above.
>
> Regards,
> Elwyn
>
> PS
> relevant individuals.  The long standing position was that they didn't but
> change has recently been mooted.
>
> /E
>
>
>>
>>
>>
>>> about
>>>     As described in [RFC3209 <https://tools.ietf.org/html/rfc3209>] and
>>> [RFC3473 <https://tools.ietf.org/html/rfc3473>] the ERO is managed as a
>>> list
>>>     [RFC3473 <https://tools.ietf.org/html/rfc3473>], [RFC3477 <
>>> https://tools.ietf.org/html/rfc3477>], [RFC4873 <
>>> https://tools.ietf.org/html/rfc4873>], [RFC4874 <
>>> https://tools.ietf.org/html/rfc4874>], [RFC5520 <
>>> https://tools.ietf.org/html/rfc5520>] and [RFC5553 <
>>> https://tools.ietf.org/html/rfc5553>].
>>>
>>> felt

---

From: Elwyn Davies <[email-masked]>
Date: Thu, 05 Mar 2015 13:26:09 +0000

Hi, Cyril.

Yes.. That looks good.  Thanks!

Dong Jie will hopefully take this on board for the loopback flag in 
draft-ietf-teas-rsvp-te-li-lb. We have been discussing this earlier today.

Regards,
Elwyn

---

From: Cyril Margaria <[email-masked]>
Date: Thu, 5 Mar 2015 09:40:20 -0500

Hi Elwyn,

Thanks, a new revision addressing the comments have been posted
Name:        draft-ietf-teas-lsp-attribute-ro
Revision:    04
Title:        LSP Attribute in ERO
Document date:    2015-03-04
Group:        teas
Pages:        14
URL:
http://www.ietf.org/internet-drafts/draft-ietf-teas-lsp-attribute-ro-04.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-attribute-ro/
Htmlized:
http://tools.ietf.org/html/draft-ietf-teas-lsp-attribute-ro-04
Diff:
http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-lsp-attribute-ro-04

Best Regards.

On 5 March 2015 at 08:26, Elwyn Davies <[email-masked]> wrote:

>>> document
>>> subobjects
>>> by
>>> the
>>>>>      appended after any of the existing subobjects defined in [RFC3209
>>>>> <
>>>>> https://tools.ietf.org/html/rfc3209>],
>>>>> to
>>>>>   draft-ietf-teas-lsp-attribute-ro tries to leave that open to the
>>>>>
>>>> documents
>>>>>      [RFC4874], [RFC5520] and [RFC5553].  [RFC3473] modified the ERO
>>>>> list
>>>>> by
>>>>>      be inserted after any of the existing identifying subobjects
>>>>> defined
>>>>> in

---

From: Elwyn Davies <[email-masked]>
Date: Thu, 05 Mar 2015 14:48:39 +0000

Great.  Thanks!

/Elwyn

---

From: Jari Arkko <[email-masked]>
Date: Wed, 11 Mar 2015 18:26:20 +0200

Francis & Elwyn: thanks for your reviews. And thank you Cyril for the updates. I have balloted no-objection for this document on the upcoming IESG telechat.

Jari