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

Thanks Terry. Your posts to the list will no longer be moderated.

This concludes the WGLC.  The authors have many comments to address,
including the list below.

A revised draft is requested, and we'll proceed from there.

Al
bmwg co-chair

> -----Original Message-----
> From: bmwg [mailto:[email protected]] On Behalf Of Terry Manderson
> Sent: Tuesday, April 22, 2014 7:51 PM
> To: [email protected]
> Cc: [email protected]; draft-ietf-bmwg-bgp-basic-
> [email protected]; [email protected]
> Subject: [bmwg] RtgDir review: draft-ietf-bmwg-bgp-basic-convergence-
> 01.txt
> 
> 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
> 
> 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.
> 
> 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.
> 
> Section 5.: Point B. I assume you mean Hard Reset here. For understanding
> purposes you may like to consider adding the term in parenthesis.
> 
> 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.
> 
> 
> 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.
> 
> Section 5.1.5
> 
> 	Is the omission of normative language in the points, specifically
> A,B,
> and C intentional?
> 
> Section 5.5, Point B. The language here surrounding the time source is
> different than in earlier text, is that intentional?
> 
> 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/
> 
> 
> Cheers
> Terry
_______________________________________________
bmwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bmwg