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

[Liming Wei <[e-mail]>]

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<[e-mail]>
> 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