Re: [RTG-DIR] RtgDir review: draft-ietf-idr-add-path-10.txt

["Alvaro Retana (aretana)" <[e-mail]>]

On 5/7/15, 8:52 AM, "Mach Chen" <[e-mail]> wrote:

<Wearing author hat.>

Mach:

Hi!

I just published an update that should address your comments.  Please take
a look.

Thanks!

Alvaro.

>Hello, 
>
>I have been selected as the Routing Directorate reviewer for this draft.
>The Routing Directorate seeks to review all routing or routing-related
>drafts as they pass through IETF last call and IESG review, and sometimes
>on special request. The purpose of the review is to provide assistance to
>the Routing ADs. For more information about the Routing Directorate,
>please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
>Although these comments are primarily for the use of the Routing ADs, it
>would be helpful if you could consider them along with any other IETF
>Last Call comments that you receive, and strive to resolve them through
>discussion or by updating the draft.
>
>Document: draft-ietf-idr-add-path-10.txt
>Reviewer: Mach Chen
>Review Date: 2015/05/07
>IETF LC End Date: Not known
>Intended Status: Standards Track
>
>Summary:
> This document is basically ready for publication, but has nits that
>should be considered prior to publication.
>
>Comments: 
> The document is well written and easy to read.
> 
>Major Issues: 
> No major issues found.
>
>Minor Issues: 
> No minor issues found.
>
>Nits:
>
>Abstract and Introduction
>
>s/In this document we propose/This document defines
>
>
>Introduction
>
>s/"Send-update Process"/Send-update Process, to align with the usage as
>in RFC4271.
>
>Section 4
>
>"Send/Receive:
>
>         This field indicates whether the sender is (a) able to receive
>         multiple paths from its peer (value 1), (b) able to send
>         multiple paths to its peer (value 2), or (c) both (value 3) for
>         the <AFI, SAFI>."
>
>How about other values and what's the process when received value other
>than 1, 2 and 3?
>
>
>Section 5
>
>OLD:
>" A BGP speaker MUST follow the existing procedures in generating an
>   UPDATE message for a particular <AFI, SAFI> to a peer unless the
>BGP..."
>
>NEW:
>"A BGP speaker MUST follow the procedures defined in [RFC4271] in
>generating an
>   UPDATE message for a particular <AFI, SAFI> to a peer unless the
>BGP..."
>"
>
>Best regards,
>Mach