Re: [RTG-DIR] RtgDir review: draft-ietf-bfd-multipoint-16

[Martin Vigoureux <[e-mail]>]

Thank you Michael

Le 2018-05-13 à 1:04, Michael Richardson a écrit :
> 
> 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-draft-ietf-bfd-multipoint-16.txt
> Reviewer: Michael Richardson
> Review Date: 2018-05-12
> IETF LC End Date: unknown
> Intended Status: Standards Track
> 
> Summary:
> 
> This document is basically ready for publication, but has presentation nits
> that should be considered prior to publication.
> 
> Comments:
> 
> It seems like a well written document, with an intelligent and well-throught
> out way to extend BFD to multicast uses.
> 
> I found the document a bit too abstract as it attempted to apply itself to
> any place that BFD is used.  I would like to perhaps better
> understand how it is used in some real multicast situations (MPLS,
> PIM/IP-level multicast).
> 
> I believe that my lack of familiarity with some of those technologies might
> be keeping me in the dark.
> 
> I'm not generally happy with documents that say:
>      "The following procedure replaces section 6.8.6 of [RFC5880]."
> 
> because it's difficult to know what is going on without having the two
> documents next to eachother.  For an implementer, I'm not sure that there
> is any savings by doing this either, it seems to be solely for the
> convenience of those writing it.
> 
> I would prefer to have section 4.13 actually number the steps of the pseudo-code.
> As far as I can see, all of the pseudo-code of 5880 is being replaced, so
> this is not as much as a patch, so I don't see why not to number the
> pseudo-code.  (Like BASIC if you want, or with numbered lists)
> 
> I did not evaluate the pseudo-code to determine if it made logical sense, it
> seemed well written and understandable.
> 
> Major Issues:
> 
> No major issues found.
> 
> Minor Issues:
> 
> No minor issues found.
> 
> Nits:
> 
> "the tail declares the path to having failed."		<- s/having/have/
> 
>