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. - 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". Regards Francis.Dupont at fdupont.fr