Re: RtgDir review: draft-ietf-bmwg-bgp-basic-convergence-01.txt

Terry,
Thanks for your review and feedback. Apologies for the delay, we 
incorporated the changes in the latest version of the draft 
(draft-ietf-bmwg-bgp-basic-convergence-02.txt) published couple of weeks 
ago.
Please see inline for details on each of the comments:



On 4/22/14 7:50 PM, Terry Manderson wrote:
> 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-bmwg-bgp-basic-convergence-01
> http://tools.ietf.org/id/draft-ietf-bmwg-bgp-basic-convergence-01.txt
> Reviewer: Terry Manderson
> Review Date: 18/04/2014
> IETF LC End Date: N/A - WG requested Routing Area Directorate review
> Intended Status: Standards Track
>
> Summary:
>
> I have some minor concerns about this document that I think should be
> resolved before publication.
>
> Comments:
>
> This document is clearly written and for the most part easy to understand.
> The steps are
> enumerated, which is very helpful. I would have prefered to see the
> reference topology figures repeated closer to the test case where they are
> used, but this is a matter of style.
>
>
> Major Issues:
>
> No major issues found
>
> Minor Issues:
>
> Section 3 (figures 1-4): please define The Helper node (HLP) before its
> use. It is first defined in section 5.1.2
<<BP>> Fixed this in Sec.3
>
> Section 4.5: Please clarify if the interface media types and throughput
> must all be exactly the same for all devices in all the test cases, or
> that the media types and throughput are to be the same for iterations of
> the test cases. I re-read that Para several times and could infer either
> situation.
<<BP>> thanks, clarified this. It should be for all iterations of test cases
>
> Section 4.10: Can you please highlight the impact on the tests for where
> routing processor redundancy cannot be disabled, or if unwilling to do
> that suggest that the impacts or assessment of impacts are out of scope of
> this draft.
<<BP>> yes clarified this and added the scope/impact in the section
>
> Section 5.: Point B. I assume you mean Hard Reset here. For understanding
> purposes you may like to consider adding the term in parenthesis.
<<BP>>thanks, another reviewer also pointed to the same. So we reworded 
and clarified the sentence
>
> Section 5.1.1: Pont B introduces "peer x of Emulator". I find this wording
> terse, can you please clarify what this is as I couldn't see in the text
> of section 3.
>
> 	Point D: "peer-x" is used here. Is this the same term as point B?
>
> 	It appears as I read through the points, that Peer-X (possibly otherwise
> known as 'SOME_ASN-X) is the test case nomenclature representation of the
> emulator function. It may be worth stating that up front to be pragmatic
> and help the reader.
<<BP>>good catch, fixed this and used the same representation now in 
both Sec.3 and 5.1.1
>
>
> Section 5.1.2:
>
> 	This section introduces a NTP time source to the test case, that isn't
> described in "Section 3. Test Topologies". While not a critical concern to
> someone implementing the topologies, it may help them by highlighting the
> necessity of NTP in section 3.
<<BP>> added the text in Sec.3
>
> Section 5.1.5
>
> 	Is the omission of normative language in the points, specifically A,B,
> and C intentional?
<<BP>> fixed these
>
> Section 5.5, Point B. The language here surrounding the time source is
> different than in earlier text, is that intentional?
<<BP>> thanks, fixed this
>
> Nits:
>
> Section 1.1, Para 3: s/functional/functions/
> Section 4.2, Para 1: s/or through neighbor/or through a neighbor/
> Section 4.4, Para 3: s/a)default/a) default/
> 		s/b)platform-specific/b) platform-specific/
> 		s/c)values/c) values/
> Section 4.6, Para 3: s/)is/) is/
>
> Section 5.1.1, second last para: s/Stand Deviation/Standard Deviation/
>
> Section 5.2.1,
> 	Point C. "Tx1", do you simply mean "Tx" as described in Figure 1?
> 	Point C. s/(Tx1)Interface/(Tx1) Interface/
> 	Point E. s/Trr2/Tr2/
> 	Point F. "(Drr1)" Can you clarify this is the intended nomenclature for
> this egress interface on the DUT?
>
> Section 5.3, Point E s/route say/route, say/ - I'd expect the RFC editor
> may suggest using "e.g".
>
> Section 5.6, Point B(6) s/(e.g. route A)/(e.g. routeA)/ - "RouteA" appears
> to be the selected form from earlier parts of the draft.
> 	(same for other occurrences in the remainder of the Draft (eg S5.8 point
> N,Q, .)
>
>
> Section 5.8. point F. s/Autonomous System.s/Autonomous Systems/
> Section 5.8. Point S. s/Node -1/Node-1/
<<BP>> thanks for pointing all these variations. Fixed them in the newer 
version of the draft


Once again thanks for the review.

regards,
Bhavani


>
>
> Cheers
> Terry

_______________________________________________
bmwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bmwg