Hi, Thanks for the review. Below are my responses. Hopefully my co-authors will agree.
On Mon, Nov 25, 2013 at 9:25 AM, Francis Dupont <francis.dup...@fdupont.fr> wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-trill-oam-framework-03.txt > Reviewer: Francis Dupont > Review Date: 20131120 > IETF LC End Date: 20131126 > IESG Telechat date: unknown > > Summary: Ready > > Major issues: None > > Minor issues: None > > Nits/editorial comments: > - ToC page 3 and 9 page 30: Acknowledgements -> Acknowledgments OK. > - 1.1 page 5 (ECMP): Pathing -> Path OK. > - 2.1 page 6 and many other places: e.g. -> e.g., > (and i.e. -> i.e., too... First at 2.4 page 12) Actually, I don't think the RFC Editor likes Latin acronyms so it might be better to replace "e.g." with "for example" as well as adding a common after it and either replace "i.e." with "such as" or just drop it. I think all the cases where "i.e." occurs immediately after an open parenthesis can just be dropped... > - 2.6 page 12: ask the RFC Editor to manage to get the title not > at the very end of the page Yeah... > - 6.1.5 and 6.1.6 page 26: in group item titles you put "/" and "," > separators, for instance: > - VLAN / Fine grain label / Flow parameters > and > - Target RBridge Nickname (unicast), Tree Identifier (Multicast) and > IP multicast group > Is there a good reason? And BTW the IP multicast group is for the > multicast case. Note my comment is only about the wording: the spec > is very easy to understand. I don't think there is any special reason. Probably "VLAN / Fine grain label / Flow parameters" should be replaced with "VLAN, Fine grain label, and Flow parameters". > - 6.1.7 page 27 (and 6.1.8 page 28): in Repeat Count > "For proactive monitoring this may be set to allow for infinite > monitoring." > what is the recommended value to set the counter (or with other words > how is encoded the infinite)? This is an informational high level framework document. I believe that specific encoding issues are to be addressed in the standards track protocol documents such as draft-ietf-trill-oam-loss-delay in this case. > - 10.2 page 31 (TRILL-BFD): Interconnetion -> Interconnection > (Note the spelling error is in the referenced I-D itself but > it has at least one common author) :-) we can fix that here. Hopefully the RFC Editor will fix it in the referenced ID. I'll send them a message. I believe they have a facility for buffering editorial comments on drafts in the RFC Editor's queue until they get to editing them. > Regards > francis.dup...@fdupont.fr > > PS: my spell checker insists about congruency (the correct term is > congruence) and IMHO it is right... OK. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
