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

From: Donald Eastlake <[email-masked]>
Date: Tue, 21 Feb 2017 14:32:43 -0500

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

On Thu, Jan 19, 2017 at 7:47 AM, Christer Holmberg <
[email-masked]> 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
>
>