Document: draft-ietf-pim-rpf-vector-07  (Note: -06 review follows the -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


===============================================================================

Document: draft-ietf-pim-rpf-vector-06
Reviewer: Ben Campbell
Review Date:  2008-11-05
IETF LC End Date: 2008-11-13

Summary:

This draft is almost ready for publication. I have a few fairly minor concerns that I think should be addressed prior to publication, and some editorial nits.

Substantive Comments:

-- It is not clear to me why this is to be an informational RFC. It seems to be defining protocol. If that protocol is not intended to be a standard, then it would help to have an applicability statement to that effect.

-- Section 4:

The IANA considerations section needs a little more information. Is this attribute to be added to an existing registry? Is a new registry needed?

-- Section 5:

The security considerations section implies that adding this new Vector creates no new security considerations beyond those in RFC4601.  
I am not qualified to hold an opinion whether this is true or not--has the working group explicitly thought about it?

Editorial Comments:

-- IDNITS reports that there is no RFC 2119 reference or boilerplate, but there is at least one use of normative language (2.3.4).

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

-- IDNITS reports that the reference to draft-ietf-pim-join-
attributes-03 is outdated. There is an 06 as of the time of this review.