Hi Christer, Version -05 of the draft, which was just posted, is intended to resolve your comments.
Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Thu, Jan 19, 2017 at 7:47 AM, Christer Holmberg < christer.holmb...@ericsson.com> wrote: > Hi Donald, > > Please see inline. > > >> Also, in general, the document does expand some acronyms on first > >> occurrence, while it does not expand others. Can the authors verify > >>that all > >> the acronyms NOT expanded so called ³well known² acronyms? > > > >Can you point to one that isn't well known? > > I didn¹t check - it was more a generic question whether you have checked > the non-expanded acronyms. > > But, looking in the Introduction: > > 1) I see that you have expanded LAN, but not VLAN. Both are well-known, so > they do not need to be enhanced. > > 2) LSP IS a well known acronym, and LSP actually have multiple meanings > (perhaps they all mean the same thing). > > LSP - Label Switched Path (LSP) or > - Label Switching Path (LSP) -- RARELY USED > - Link State Packet (LSP) or > - Link State PDU (LSP) (or Link State Protocol Data Unit) > > > 3) FGL is not a well known acronym. > > 4) In the case of DRB you use the following format: 'enhanced (acronym)'. > In other cases you use 'acronym (enhanced)¹. Please be consistent whenever > you do write both the acronym and the enhanced name. > > Having said that, DRB is a well known acronym, so I don¹t think you need > to enhance it. Still, as it may be a "less known well known², a reference > would still be useful. > > ... > > >> Q4: The end of the introduction contains the following text: > >> > >> ³This documents obsoletes [RFC6439], updates [RFC6325], and updates > >> [RFC7177], as described in Appendix B.² > >> > >> That¹s all good, but I think it would be good to have a few words also > >>in > >> the Introduction, explaining exactly what is obsoleted and updated. > > > >OK, especially as it is more like it incorporates RFC 6439 to simplify > >things and reduce the number of documents that implementers have to > >look at. > > > That is also very good information. The details can be in Appendix B, but > I think it would be good to have a high-level description in the > Introduction. > > > >> Q5: The end of the introduction contains the following text: > >> > >> ³It also includes reference implementation details. > >> Alternative implementations that interoperate on the wire > >>are > >> permitted.² > >> > >> Is the last sentence really needed? I don¹t think an RFC can mandate the > >> usage of one specific implementation of the RFC. > > > >Well, I think the TRILL WG likes wording similar to that. It also > >occurs in at least RFC 6325, the TRILL base protocol specification. > > Ok. I won¹t argue against it, I just think it sounds a little strange :) > > But, could you then add a reference to the section describing the > reference implementation details, because I don¹t think it is explicit > anywhere. > > Also, if the reference implementation details are different from the ones > in 6325 I think it would be useful to point out. > > Regards, > > Christer > >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
