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

[Mach Chen <[e-mail]>]

Hi Alvaro,

I have reviewed the latest version, it addresses my comments.

Thanks,
Mach

> -----Original Message-----
> From: Alvaro Retana (aretana) [mailto:[e-mail]]
> Sent: Thursday, October 08, 2015 2:51 AM
> To: Mach Chen; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-add-path-10.txt
> 
> 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