Hi Miguel,
Response to your comments inline..
On 6/11/12 12:30 AM, Miguel A. Garcia wrote:
I have been selected as the General Area Review Team (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 comments you may receive.
Document: draft-ietf-pim-ecmp-03.txt
Reviewer: Miguel Garcia<miguel.a.gar...@ericsson.com>
Review Date: 2012-06-11
IETF LC End Date: 2012-06-12
IESG Telechat date: 2012-06-21
Summary: The document is ready for publication as a standards track RFC.
Major issues: none
Minor issues: none
Nits/editorial comments:
- The Abstract should not include references. Just delete "[RFC4601]".
Will remove "[RFC4601]".
- Perhaps this is a matter of personal taste... but Section 3.5.2 is
devoted to describe the format of the PIM ECMP Redirect message. I think
this is a section where you should describe the format, but you shouldn't
write normative statements as for what to do with those fields. For
example, I am referring to statements like:
Address of desired upstream
neighbor where the downstream receiver SHOULD redirect PIM
Joins
the receiving
router of this message MUST use the "Interface ID", instead of
"Neighbor Address", to identify the new RPF neighbor
an ECMP
Redirect message MUST be discarded if the "Interface ID" field...
I think all these sentences including a normative MUST, SHOULD, etc.
should be written in Sections 3.1. or 3.2 (Procedures). This means that
the format (current section 3.5) should be moved to a place prior to 3.1
and 3.2, because the procedures needs to explain what to do with all
these fields.
Good point. Our original consideration was that when a protocol
implementer refers to the packet format and the fields,
it is more convenient for them to see that type of explanation
in the same place, as opposed to scattered in other parts of the spec.
On the
other hand, doing what you suggested makes the spec look "cleaner", as the
format does not explain the protocol behavior, and the explanations occur in
places they are supposed to be explained.
So, we will move the explanation for the "Neighbor Address", and the
"Interface
ID" to the end of section 3.1.
Thanks,
-Liming Wei
/Miguel
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
