Re: [Gen-art] Gen-ART review of draft-ietf-trill-rfc6439bis-04

[Jari Arkko <[e-mail]>]

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 <[e-mail]> wrote:

> Hi Christer,
> 
> On Wed, Jan 18, 2017 at 6:07 PM, Christer Holmberg
> <[e-mail]> 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   [phone] (cell)
> 155 Beaver Street, Milford, MA 01757 USA
> [e-mail]
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art