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

[Cyril Margaria <[e-mail]>]

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, "[e-mail]" <[e-mail]>
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
>
>[e-mail]