Hi Christer,

On Wed, Jan 18, 2017 at 6:07 PM, Christer Holmberg
<[email protected]> 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
 [email protected]

_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to