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

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 Jan 2017 23:07:49 +0000

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.

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?

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"?

Q3:        In the Abstract and Introduction, I think it would be good to have a reference to "Appointed Forwarder".

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.

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.

Q6:        In the Security Considerations, please use "This document" instead of "This memo", in order to have consistent terminology.

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 18 Jan 2017 23:27:00 -0500

Hi Christer,

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

> “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.

> “It also includes reference implementation details.
>               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-masked]

---

From: Jari Arkko <[email-masked]>
Date: Thu, 19 Jan 2017 09:42:26 +0200

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 <[email-masked]> wrote:

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 19 Jan 2017 12:47:36 +0000

Hi Donald,

Please see inline.

>> the acronyms NOT expanded so called ³well known² acronyms?
>

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.

...

>> ³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

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.

>> ³It also includes reference implementation details.
>>               permitted.²
>> Is the last sentence really needed? I don¹t think an RFC can mandate the

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