Thanks for the review, Christer, and responses, Donald! There’s some discussion to be had here I guess with acronyms etc but I have posted a no-objection position for today’s IESG telechat.
Jari On 19 Jan 2017, at 06:27, Donald Eastlake <d3e...@gmail.com> wrote: > Hi Christer, > > On Wed, Jan 18, 2017 at 6:07 PM, Christer Holmberg > <christer.holmb...@ericsson.com> wrote: >> I am the assigned Gen-ART reviewer for this draft. The General Area Review >> Team (Gen-ART) reviews all IETF documents being processed by the IESG for >> the IETF Chair. Please treat these comments just like any other last call >> comments. >> >> For more information, please see the FAQ at >> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. >> >> >> Document: >> draft-ietf-trill-rfc6439bis-04.txt >> >> Reviewer: Christer Holmberg >> Review Date: 18.01.2017 >> IETF LC End Date: 10.01.2017 >> IESG Telechat date: (if known) 19.01.2017 >> >> >> Summary: The document is almost ready >> for publication, but there are some editorial nit that I’d like the authors >> to address. >> >> >> Major issues: None >> >> >> Minor issues: None >> >> >> Nits/editorial comments: >> >> >> Q1: In the Abstract and Introduction, please expand “TRILL” on first >> occurrence. > > OK. > >> 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? > >> Q2: Related to Q1. In section 1.2, you do expand TRILL, but it is >> different than in RFC 6439. Is the intention really to change the meaning of >> “TRILL”? > > It seems misleading to just say that it expands it differently when it > expands it exactly the same way. It's just that is also provides a > second equally good or, in the opinion of some people, better > expansion. There has been some effort to change the name of the TRILL > working group to the second version, which should not be too big a > deal as the acronym is the same. And I don't see how it hurts anything > to have both in this document. > >> Q3: In the Abstract and Introduction, I think it would be good to >> have a reference to “Appointed Forwarder”. > > OK. > >> 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. > >> 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. > >> Q6: In the Security Considerations, please use “This document” >> instead of “This memo”, in order to have consistent terminology. > > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
