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

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 7 Oct 2015 18:50:59 +0000

On 5/7/15, 8:52 AM, "Mach Chen" <[email-masked]> 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

---

From: Mach Chen <[email-masked]>
Date: Mon, 12 Oct 2015 08:55:42 +0000

Hi Alvaro,

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

Thanks,
Mach

> -----Original Message-----
> From: Alvaro Retana (aretana) [mailto:[email-masked]]
> Sent: Thursday, October 08, 2015 2:51 AM
> To: Mach Chen; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-add-path-10.txt
> 
> I just published an update that should address your comments.  Please take a
> look.
> 
> Thanks!
> 
> Alvaro.
> 
> >Hello,
> >
> >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.
> >