I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-pim-rpf-vector-07
Reviewer: Ben Campbell
Review Date: 2009-01-13
IETF LC End Date: 2009-01-19
IESG Telechat date: (if known)
Summary: This draft is very close to ready for publication as a
proposed standard. There is a minor issue that should be addressed
prior to publication, and a couple of editorial nits.
Note 1: The Gen-ART assignment was for version 06, but version 07 has
been published. This review is for 07.
Note 2: I previously reviewed 06 for publication as an informational
RFC. This review is incremental to that one. I consider any comment
from that review not mentioned here to be resolved.
Major issues: None
Minor issues:
The following issue from my previous review has not been addressed.
Email with an author indicated that they intended to fix this, but it
doesn't appear to have made it into the draft.
-- IDNITS reports that there is no RFC 2119 reference or
boilerplate, but there is at least one use of normative language
(2.3.4).
Furthermore, Section 2 is liberally sprinkled with occurrences of
lower-case "must", "should" and "may" that should be examined to
determine if they warrant normative language. I did not consider this
an issue for an informational RFC, but do consider it to so for a
proposed standard.
Nits/editorial comments:
-- IANA Considerations, last sentence (new comment)
s/propose/proposed
The following editorial comments from my previous review has not been
addressed. Email with an author indicated that they intended to fix
most of these, but the fixes don't appear to have made it into the
draft.
-- There are a number of acronyms that should be expanded on first
use. I would not worry about expanding acronyms that are well known
to the entire IETF community (e.g. TCP), but acronyms that are not
widely known outside the BGP community probably should be.
-- Section 2, first sentence:
Who is the "we" in this context? A edge router? (This is not a
complaint about 2nd person language in general so much as a concern
about the actor being obscured.) The pattern of saying "we" or
"our" referring to a network element taking some particular action
occurs a few more times in the document. It would be better to
simply name the element.
-- Section 2.3.4, first paragraph:
s/depending/dependent
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
