Telechat Review of draft-ietf-teas-lsp-attribute-ro-04

Request Review of draft-ietf-teas-lsp-attribute-ro
Requested rev. no specific revision (document currently at 05)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-03-10
Requested 2015-03-04
Authors Cyril Margaria, Giovanni Martinelli, Steve Balls, Ben Wright
Draft last updated 2015-03-09
Completed reviews Genart Last Call review of -02 by Francis Dupont (diff)
Genart Telechat review of -04 by Francis Dupont (diff)
Opsdir Last Call review of -02 by Kiran Chittimaneni (diff)
Assignment Reviewer Francis Dupont
State Completed
Review review-ietf-teas-lsp-attribute-ro-04-genart-telechat-dupont-2015-03-09
Reviewed rev. 04 (document currently at 05)
Review result Ready
Review completed: 2015-03-09


I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


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

 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.

 - 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).

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

 - ToC page 2 and 3.2.1 title: Subobject presence rule ->
  Subobject Presence Rule
 - 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)

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

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

 - 3.1 page 5: lower case "may" (either "MAY" or can...)
  (and 3.2.1 page 6)

 - 3.2.1 page 6: e.g. -> e.g.,

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

 - 4.3 page 8: registery -> registry

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

 - 4.3 page 8: another lower case keyword: shall

 - 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).

 - 5 page 10: another "may reveal".


Francis.Dupont at