Subject: [Gen-art] Gen-ART review of draft-ietf-pim-ecmp-03.txt

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 11 Jun 2012 09:30:41 +0200

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 <[email-masked]>
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]".

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

/Miguel
-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Liming Wei <[email-masked]>
Date: Tue, 19 Jun 2012 18:08:36 -0700

Hi Miguel,

Response to your comments inline..

On 6/11/12 12:30 AM, Miguel A. Garcia wrote:
> Reviewer: Miguel Garcia<[email-masked]>
> Review Date: 2012-06-11

Will remove "[RFC4601]".

> and 3.2, because the procedures needs to explain what to do with all

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