Re: [Gen-art] Genart last call review of draft-ietf-nvo3-encap-10

[Donald Eastlake]

Hi Meral,

Thanks for noting the two typos you found below. I have fixed them in my
working copy so they will be fixed the next time I upload a revision.

Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com


On Fri, Nov 17, 2023 at 9:14 PM Meral Shirazipour via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Meral Shirazipour
> Review result: Ready with Nits
>
> 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
>
> .
>
> Document: draft-ietf-nvo3-encap-10
> Reviewer: Meral Shirazipour
> Review Date: 2023-11-17
> IETF LC End Date: 2023-11-18
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: This draft is almost ready to be published as Informational RFC.
>
> Major issues:
>
> Minor issues:
>
> Nits/editorial comments:
> -[Page 7], "Broadcase"-->"Broadcast"
>
> - [Page 10], "svailable"-->"available"
>
>
>
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-intarea-rfc7042bis-09

[Donald Eastlake]

Hi Dale,

Thanks for this review. See below.

On Fri, Oct 6, 2023 at 4:05 PM Dale Worley via Datatracker
 wrote:
>
> Reviewer: Dale Worley
> Review result: Ready with Nits
>
> 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
>
> .
>
> Document:  draft-ietf-intarea-rfc7042bis-09
> Reviewer:  Dale R. Worley
> Review Date:  2023-10-06
> IETF LC End Date:  2023-10-12
> IESG Telechat date:  [unknown]
>
> Summary:
>
> This draft is basically ready for publication, but has nits that
> should be fixed before publication.
>
> Nits/editorial comments:
>
> In section 3. Ethernet Protocol Parameters, it says
>
>Using this EtherType, a frame body can begin with
>
>   88-B7-yy-yy-yy-zz-zz
>
>where yy-yy-yy and zz-zz have the same meaning as in the SNAP format
>described above.
>
> Since the previous paragraph notes for another format "The five-octet
> length for such OUI-based protocol identifiers results ... in the
> preservation of 16-bit alignment.", it might be worth stating
> explicitly that the EtherType 88B7 format does not preserve 16-bit
> alignment.

Fixed in version -10.

> The largest item is the handling of the references to the various
> registries, which seem to be inconsistent.  It's possible that the
> variations in how they are referenced is based on some references
> being defining/authoritative and others not, but I did not spot any
> consistent pattern.
>
> Looking for "web page", "registry", "address family", and "table" gets
> 40+ hits, most of which are references to specific IANA registries.
> My current opinion is that these ideally should be proper references
> in the document, with the reference giving the canonical registry name
> and the full IANA URL, e.g. "SNAP Protocol Numbers,
> https://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml#ethernet-numbers-6;.

I believe the current official IANA term for a web page with one or
more registries on it is "registry group". (see
https://www.iana.org/help/protocol-registration) so I've gone through
and made this update.

> Currently, only two registries are given full references:
>
>[EthernetNum]
>   IANA, "Ethernet Numbers",
>   .
>
>[PPPNum]   IANA, "PPP Numbers",
>   .
>
> But perhaps there are too many registries mentioned to make that
> workable.

I think adding such references for every mentioned registry would be
somewhat unworkable for very little return.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

> [END]

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-eastlake-rfc6931bis-xmlsec-uris-19

[Donald Eastlake]

Hi Peter,

Thank you for your detailed review of this somewhat lengthy draft!

Sorry for my slow response, I've been on vacation at www.discon3.org.

On Tue, Dec 14, 2021 at 6:24 PM Peter Yee via Datatracker
 wrote:
>
> Reviewer: Peter Yee
> Review result: Ready with Nits
>
> 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
>
> .
>
> Document: draft-eastlake-rfc6931bis-xmlsec-uris-19
> Reviewer: Peter Yee
> Review Date: 2021-12-14
> IETF LC End Date: 2021-12-15
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: This update document corrects the IANA’s XML Security URIs registry.
> It also fixes errata in RFC 6931. There are a few nits that should be fixed
> prior to publication. [Ready with Nits]
>
> Major issues: None
>
> Minor issues: None
>
> Nits/editorial comments:
>
> General:
>
> Replace all occurrences of “US National Institute of Science and Technology”
> with “US National Institute of Standards and Technology”. While I’m sure they
> would appreciate the upgrade to their remit (along with a concomitant increase
> in funding), I suspect that the old US National Bureau of Standards still 
> wants
> to be known for being in the standards business. Sort of like the IETF. ;-)
>

OK :-)

> Specific:
>
> Page 11, section 2.2.3, 1st paragraph, 2nd sentence: change “It’s” to “Its”.
>
> Page 12, section 2.2.6, 1st paragraph, 1st sentence: append a comma after
> “stateful”.
>
> Page 13, 1st paragraph, 2nd sentence (fragment?): append a colon at the end of
> the fragment “An example of use is”. Do the same in the equivalent place in
> each of the 2.3.x sections.
>
> Page 13, 2nd paragraph, 2nd sentence: change “pre-pended” to “prepended”.
>
> Page 15, 1st paragraph, last sentence: append a comma after RIPEMD160.
>
> Page 15, 2nd paragraph, 1st sentence: append “to” after “referred”.
>
> Page 16, section 2.3.8, 1st paragraph, last fragment: append a colon after the
> fragment. For consistency and readability, add blanks lines around the “hex”
> line as was done in section 2.3.1.
>
> Page 19, section 2.3.12, 1st paragraph, 2nd sentence: change “advatages” to
> “advantages”.
>
> Page 19, section 2.3.12, 1st paragraph, 3rd sentence: change “choosen” to
> “chosen”.

OK on above.

> Page 20, end of section 2.4: there appears to be an extra blank line compared
> to other section separators. What can I say?

Sharp eyes! The idea was to have an extra blank line before each 2nd
level header in Section 2 to improve readability. The improvement may
be almost insignificant but I am inclined to leave in the extra blank
lines and have, in fact, added a couple more blank lines so as to
consistently implement my idea of such extra blank lines.

> Page 21, section 2.6.1, 1st paragraph, last sentence (fragment): append a 
> colon.
>
> Page 23, section 2.6.5, 1st paragraph, 1st sentence: change “128-bit key 
> sizes”
> to “a 128-bit key size”.
>
> Page 25, section 2.7.2, 1st paragraph, 2nd sentence: change “exacty” to
> “exactly”.
>
> Page 27, section 3: append a comma after “below”. Append a comma after “3.2”.

OK on the above.

> Page 32, section 4.1, last paragraph. This text essentially reiterates the 
> note
> from the beginning of the section about the part of the URI being omitted.
> Perhaps the text could also be omitted as repetitious?

Assuming you are talking about the last sentence, just before the 4.2
header, this is a pretty darn long table. The column headers are
repeated as column footers due to the height of that span and I think
it is reasonable to leave in this sentence just past the end of the
table.

> Page 35, last paragraph: while not harmful, the text in this paragraph almost
> completely mirrors the text in the first paragraph of the section on page 32.
> Perhaps this one can be deleted?

See answer immediately above.

> Page 36, section 5.2, 2nd paragraph, 2nd sentence: change “Criterion” to
> “Criteria”.
>
> Page 38, section 6, 3rd paragraph: the MD5 mention here is presumably subsumed
> by the 2nd paragraph’s more specific discussion of MD5 and could perhaps be
> eliminated in the 3rd paragraph.
>
> Page 40, Appendix A, 3rd item, section 2.2.6 row: change “amd” to “and”.
>
> Page 40, Appendix A, 5th item: change “approriate" to “appropriate”.
>
> Page 41, Appendix B, 1st paragraph, 2nd sentence: change “Section” to
> “Sections”. Also change the bare “Bad” to “bad”.

OK on above.

Thanks again,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-bess-evpn-oam-req-frmwk-04

[Donald Eastlake]

Hi Dave,

Thanks for the review. See below.

On Fri, Feb 5, 2021 at 4:44 PM David Schinazi via Datatracker
 wrote:
> Reviewer: David Schinazi
> Review result: Ready with Nits
>
> 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
>
> .
>
> Document: draft-ietf-bess-evpn-oam-req-frmwk-04
> Reviewer: David Schinazi
> Review Date: 2021-02-05
> IETF LC End Date: 2021-02-16
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: Thank you for a well-written document.
>   It introduces a lot of terminology I wasn't used to,
>   but does a good job of explaining it.
>
> Major issues: None
>
> Minor issues: None
>
> Nits/editorial comments:
>   - The abstract defines all the acronyms (which is great) except PBB, could 
> it define that one too?
>   - Section 2.1 doesn't really explain what a "P node" is.

Sure, we can expand PBB (Provider Backbone Bridge) in the abstract and
say in Section 2.1 that P is Provider. These should probably also be
added to the terminology section. I've made these changes in the
working copy but they are pretty minor so I think I'll wait for the
results of other reviews before uploading a new version.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-allan-5g-fmc-encapsulation-04

[Donald Eastlake]

Hi Russ,

Thanks for the review. See my responses as one co-author below.

On Fri, Jul 3, 2020 at 12:33 PM Russ Housley via Datatracker
 wrote:
>
> Reviewer: Russ Housley
> Review result: Almost Ready
>
> 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
> .
>
> Document: draft-allan-5g-fmc-encapsulation-04
> Reviewer: Russ Housley
> Review Date: 2020-07-03
> IETF LC End Date: 2020-07-27
> IESG Telechat date: Unknown
>
>
> Summary: Almost Ready
>
> Major Concerns:
>
> Section 2 says:
>
>PPPoE data packet encapsulation is indicated in an IEEE 802[8]
>Ethernet frame by an Ethertype of 0x8864.
>
> This is very odd way to introduce this section.  IEEE Std 802-2001
> covers the architecture for Project 802, not just Ethernet frames,
> which are fully specified in IEEE 802.3.  However, the MAC frame,
> MAC addresses, and Ethertypes are all described in this standard.
> Second, you need to point to RFC 2516 to talk about PPPoE.  Third,
> the Ethertype is not defined in IEEE Std 802-2001.  I suggest:
>
>The Ethernet payload [8] for PPPoE [3] is indicated by an
>Ethertype of 0x8864.

I'd be fine with that change. (I hope we don't refer to 802.3, last
time I looked that document was well over 20,000 pages everything of
relevance is in 802.)

> References:  I think that [9] needs to be a normative reference
> because the reader cannot understand the QFI field without it.

OK with me.

> Minor Concerns:
>
> Introduction: You spell out the meaning of 5G, but not BBF.  Please
> spell out BBF.  I note that 5G is on the RFC Editor "well known"
> list (https://www.rfc-editor.org/materials/abbrev.expansion.txt), but
> BBF is not, so it would be fine to not spell out 5G. Likewise, please
> spell out p2p, PPPoE, IPoE, DSLAMs, and OLTs the first time the term
> is used.
>
> Please explain the UE in the Introduction so that it is understood by
> the time it is used later.

I think most standards documents use too many acronyms and I do not
think the RFC Editor "well known" list authoritatively describes the
state of knowledge of every RFC reader. So I'm fine with spelling out
more things but would prefer not to drop any existing spelling outs.

> Please use the exact wording from RFC 8174 in the boilerplate:
>
>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
>NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
>"MAY", and "OPTIONAL" in this document are to be interpreted as
>described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
>appear in all capitals, as shown here.
>
> I assume that it is okay to use "[1] [2]" instead of
> "[RFC2119] [RFC8174]", but this is not the tradition.
>
> Section 2: Please add a reference for the IANA registry.  I think
> you are pointing to here:
>
>   https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml#ppp-numbers-2

Is IANA's URL structure and URL embedded nomenclature guaranteed to be
constant? The draft gives the precise name of the IANA registries web
page referenced: "Point-to-Point (PPP) Protocol Field Assignments". I
see no need to include a URL. I put through a number of drafts and
IANA has never asked me to add a URL to an IANA web page or registry
to one of those drafts.

> Section 5: Please add pointers to the registry that is to be updated.
> I think you are pointing here:
>
>   
> https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml#ieee-802-numbers-1

Same comment here.

> Nits:
>
> Abstract: I suggest that the Abstract say what is provided instead of
> the needs of 5G.  It is also shorter.  I suggest:
>
>As part of providing wireline access to the 5G Core (5GC), deployed
>wireline networks carry user data between 5G residential gateways
>and the 5G Access Gateway Function (AGF). The encapsulation method
>specified in this document supports the multiplexing of traffic for
>multiple PDU sessions within a VLAN delineated access circuit,
>permits legacy equipment in the data path to snoop certain packet
>fields, carries 5G QoS information associated with the packet data,
>and provides efficient encoding.

That looks OK to me.

> Section 4: s/document"s/document's/

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 33896 USA
 d3e...@gmail.com

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart telechat review of draft-ietf-trill-over-ip-15

[Donald Eastlake]

Hi Matthew,

On Thu, Mar 8, 2018 at 1:59 AM, Matthew Miller
 wrote:
> Reviewer: Matthew Miller
> Review result: Ready with Nits
>
> 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
>
> .
>
> Document: draft-ietf-trill-over-ip-15
> Reviewer: Matthew A. Miller
> Review Date: 2018-03-07
> IETF LC End Date: 2018-03-06
> IESG Telechat date: 2018-03-08
>
> Summary:  Ready with nits
>
> Major issues: NONE
>
> Minor issues: NONE
>
> Nits/editorial comments:

I find the way you have formatted your comments to be confusing. I
think there should be a clear demarkation where all the material
related to a comment ends and that for the next comment begins. You
seem to use the same unusual triple double quotation mark delimiter
between your comment and your marked up text from the draft related to
that comment.

> * In Section 4.5. "TRILL Over IP Transport IS-IS SubNetwork Point
> of Attachment", the word "of" between ""
>
> """
> The Hellos transmitted out [of] a port indicate what neighbor ports
> that port can see on the link by listing what IS-IS refers to as the
> neighbor port's SubNetwork Point of Attachment (SNPA)
> """
>
> * In Section 5.2. "Encapsulation Agreement", the first sentence is
> difficult to understand; I think it is missing the word "on" between
> "sent out" and "a TRILL over IP":
>
> """
> TRILL Hellos sent out [on] a TRILL over IP transport port indicate the
> encapsulations for which that port is offering full support through a
> mechanism initially specified in [RFC7178] and [RFC7176] that is
> hereby extended.
> """

I do not think the insertions you recommend are necessary but I'm
willing to make them.

> * In Section 5.4. "Native Encapsulation", the word "he" should be
> "the" in the sentence "Where he UDP Header is as follows".

OK

> * In Section 5.6.1. "TCP Connection Establishment", the word
> "connections" should be singular (or the leading "a" dropped) in the
> fragment "try to establish a TCP connections to each of them".

Changing "connections" to "connection" seems best.

> * In Section 5.6.1. "TCP Connection Establishment", the occurrence of
> "P!" should be changed to "P1".

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

Re: [Gen-art] Genart telechat review of draft-ietf-trill-vendor-channel-00

[Donald Eastlake]

Hi Joel,

On Mon, Feb 26, 2018 at 1:24 PM, Joel Halpern  wrote:

> Reviewer: Joel Halpern
> Review result: Ready
>
> 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 wait for direction from your
> document shepherd or AD before posting a new version of the draft.
>
> For more information, please see the FAQ at
>
> .
>
> Document: draft-ietf-trill-vendor-channel-00
> Reviewer: Joel Halpern
> Review Date: 2018-02-26
> IETF LC End Date: 2018-03-06
> IESG Telechat date: 2018-03-08
>
> Summary: This document is ready for publication as a Proposed Standard
>
> Major issues: N/A
>
> Minor issues: N/A
>
> Nits/editorial comments:
> Why does the acknowledgements say:
> "The document was prepared in raw nroff. All macros used were
> defined
> within the source file."
> ?
>

Why not? It's true. I've seen a number of draft with credit in them for MS
Word templates and the like. Shouldn't people know their are still drafts
being prepared with nroff?

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

Re: [Gen-art] Genart last call review of draft-ietf-trill-ecn-support-04

[Donald Eastlake]

Hi Dan,

Thanks for your review.

Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com


On Sun, Feb 4, 2018 at 7:01 AM, Dan Romascanu  wrote:
> Reviewer: Dan Romascanu
> Review result: Ready
>
> 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
>
> .
>
> Document: draft-ietf-trill-ecn-support-??
> Reviewer: Dan Romascanu
> Review Date: 2018-02-04
> IETF LC End Date: 2018-02-05
> IESG Telechat date: 2018-02-08
>
> Summary:
>
> This is a useful document within the TRILL context, extending ECN for networks
> built with TRILL switches. I found the document to be clear, clean and
> complete. It is READY for publication from the perspective of GenART
>
> Major issues:
>
> Minor issues:
>
> Nits/editorial comments:
>
>

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-trill-address-flush-05

[Donald Eastlake]

HI Robert,

On Fri, Jan 26, 2018 at 3:29 PM, Robert Sparks  wrote:

> Reviewer: Robert Sparks
> Review result: Ready
>
> 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
>
> .
>
> Document: draft-ietf-trill-address-flush-05
> Reviewer: Robert Sparks
> Review Date: 2018-01-26
> IETF LC End Date: 2018-02-05
> IESG Telechat date: 2018-02-08
>
> Summary: Ready for publication as a proposed standard
>
> micro-nit: Expand FGL on its first use in the introduction.
>

Thanks for the review. I've added an expansion of FGL to the Introduction
to the master sources so the next time a revision is uploaded, this will be
fixed.

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-trill-p2mp-bfd-06

[Donald Eastlake]

Hi Meral,

On Thu, Dec 21, 2017 at 7:20 PM, Meral Shirazipour
 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
> .
>
>
> Document: draft-ietf-trill-p2mp-bfd-06
> Reviewer: Meral Shirazipour
> Review Date: 2017-12-21
> IETF LC End Date:  2018-01-08
> IESG Telechat date: 2018-01-25
>
>
> Summary:
> This draft is ready to be published as Standards Track RFC but I have some
> comments.
>
>
> Major issues:
> Minor issues:
> Nits/editorial comments:
>
> -[Page 3], "It currently read:" and "Now it should read:" seem to have the
> exact same text. Is that the intent?

The difference is the insertion of "[this document]" after the
reference to [RFC7175]".

> -[Page 4], Section 6, "tacking active tails">"tracking active tails"

Thanks for pointing that out.

Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

> Best Regards,
>
> Meral
>
> ---
>
> Meral Shirazipour
>
> Ericsson Research
>
> www.ericsson.com

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] review of draft-ietf-trill-centralized-replication-10.txt

[Donald Eastlake]

Hi Francis,

Sorry, my verison numbers are all off by 1 :-(

The currently posted version is -11. I expect a -12 to be posted very soon.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

On Thu, Jan 4, 2018 at 6:13 PM, Donald Eastlake <d3e...@gmail.com> wrote:

> Hi Francis,
>
> I believe your comments are resolved in the -10 version of this draft. I
> expect a -11 version to be posted soon with a few other minor improvements.
> So, you might want to check the current -10 version or the -11 version when
> it is posted.
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 <(508)%20333-2270> (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e...@gmail.com
>
> On Mon, Dec 11, 2017 at 11:29 AM, Francis Dupont <
> francis.dup...@fdupont.fr> 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-centralized-replication-10.txt
>> Reviewer: Francis Dupont
>> Review Date: 20171209
>> IETF LC End Date: 20171212
>> IESG Telechat date: unknown
>>
>> Summary: Ready with Issues
>>
>> Major issues: None
>>
>> Minor issues: C-nickname is used before being defined
>>
>> Nits/editorial comments:
>>  - Abstract page 1: please expand the RPF abbrev
>>
>>  - Abstract page 1 and 1 page 3: Mutlicast -> Multicast
>>
>>  - ToC page 2 and 3 title page 5:
>>   Centralized Replication Solution Overview -> Centralized replication
>>   solution overview
>>   (mainly for consistency)
>>
>>  - ToC page 2 and 6 title page 8: a edge group -> an edge group
>>   (It seems both are accepted?)
>>
>>  - ToC page 2 and 9 title page 12: I have a little concern with the
>>   CMT abbrev which BTW is not in the RFC Editor list
>>   (https://www.rfc-editor.org/materials/abbrev.expansion.txt)
>>   I suggest to add "(RFC 7783)" after CMT
>>
>>  - ToC page 3 and 10 title page 13:
>>   Network Upgrade Analysis -> Network upgrade analysis
>>   (still consistency)
>>
>>  - 1 page 3: at the first read it was not obvious that RBv is just the
>>   notation for a virtual RBridge. I suggest to do the same than for RBn,
>>   i.e., to change the first occurrence from RBv to (RBv).
>>
>>  - 1 page 3: my US English spell checker does not accept learnt
>>   (it wants learned ???)
>>
>>  - 2 page 4: please move from RFC 2119 to its update RFC 8174
>>
>>  - 2 page 4: LAALP -Local -> LAALP - Local
>>
>>  - 3 page 5 title: cf ToC comment
>>
>>  - 3 page 5: " BUM packet should be..." an example of a lower case
>>   "should" which can take benefit of RFC 8174 (vs RFC 2119). Note
>>   there are two other "should"s next page and a "may" in 4 (and other
>>   lower case keywords).
>>
>>  - 3 page 6: C-nickname is used without explanation of what it is
>>   (the explanation is in 9 page 12 so far later). Some words and/or
>>   a forward reference should solve the issue.
>>
>>  - 8 page 11 (last line): nodes/ multiple -> nodes / multiple
>>
>>  - 9 page 12 title: cf ToC comment
>>
>>  - 9 page 12: CMT -> Coordinated Multicast Trees (CMT)
>>   (at the first occurrence, i.e., first line after figure 2)
>>
>>  - 9 page 12: the definition of C-nickname is here.
>>   BTW you use both C-flag and C-nickname flag, the second is not
>>   very correct from a language point of view but is very clear
>>   technically so I shan't object if you keep it.
>>
>>  - 10 page 13 title: cf ToC comment
>>
>>  - 11 page 13: psudo -> pseudo
>>
>>  - Authors' Addresses page 17 (two occurrences): China -> PR China
>>   (or you can switch all countries to ISO IS 3166 two letter codes)
>>
>> Regards
>>
>> francis.dup...@fdupont.fr
>>
>
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] review of draft-ietf-trill-centralized-replication-10.txt

[Donald Eastlake]

Hi Francis,

I believe your comments are resolved in the -10 version of this draft. I
expect a -11 version to be posted soon with a few other minor improvements.
So, you might want to check the current -10 version or the -11 version when
it is posted.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

On Mon, Dec 11, 2017 at 11:29 AM, Francis Dupont 
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
>
> .
>
> Document: draft-ietf-trill-centralized-replication-10.txt
> Reviewer: Francis Dupont
> Review Date: 20171209
> IETF LC End Date: 20171212
> IESG Telechat date: unknown
>
> Summary: Ready with Issues
>
> Major issues: None
>
> Minor issues: C-nickname is used before being defined
>
> Nits/editorial comments:
>  - Abstract page 1: please expand the RPF abbrev
>
>  - Abstract page 1 and 1 page 3: Mutlicast -> Multicast
>
>  - ToC page 2 and 3 title page 5:
>   Centralized Replication Solution Overview -> Centralized replication
>   solution overview
>   (mainly for consistency)
>
>  - ToC page 2 and 6 title page 8: a edge group -> an edge group
>   (It seems both are accepted?)
>
>  - ToC page 2 and 9 title page 12: I have a little concern with the
>   CMT abbrev which BTW is not in the RFC Editor list
>   (https://www.rfc-editor.org/materials/abbrev.expansion.txt)
>   I suggest to add "(RFC 7783)" after CMT
>
>  - ToC page 3 and 10 title page 13:
>   Network Upgrade Analysis -> Network upgrade analysis
>   (still consistency)
>
>  - 1 page 3: at the first read it was not obvious that RBv is just the
>   notation for a virtual RBridge. I suggest to do the same than for RBn,
>   i.e., to change the first occurrence from RBv to (RBv).
>
>  - 1 page 3: my US English spell checker does not accept learnt
>   (it wants learned ???)
>
>  - 2 page 4: please move from RFC 2119 to its update RFC 8174
>
>  - 2 page 4: LAALP -Local -> LAALP - Local
>
>  - 3 page 5 title: cf ToC comment
>
>  - 3 page 5: " BUM packet should be..." an example of a lower case
>   "should" which can take benefit of RFC 8174 (vs RFC 2119). Note
>   there are two other "should"s next page and a "may" in 4 (and other
>   lower case keywords).
>
>  - 3 page 6: C-nickname is used without explanation of what it is
>   (the explanation is in 9 page 12 so far later). Some words and/or
>   a forward reference should solve the issue.
>
>  - 8 page 11 (last line): nodes/ multiple -> nodes / multiple
>
>  - 9 page 12 title: cf ToC comment
>
>  - 9 page 12: CMT -> Coordinated Multicast Trees (CMT)
>   (at the first occurrence, i.e., first line after figure 2)
>
>  - 9 page 12: the definition of C-nickname is here.
>   BTW you use both C-flag and C-nickname flag, the second is not
>   very correct from a language point of view but is very clear
>   technically so I shan't object if you keep it.
>
>  - 10 page 13 title: cf ToC comment
>
>  - 11 page 13: psudo -> pseudo
>
>  - Authors' Addresses page 17 (two occurrences): China -> PR China
>   (or you can switch all countries to ISO IS 3166 two letter codes)
>
> Regards
>
> francis.dup...@fdupont.fr
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-trill-arp-optimization-08

[Donald Eastlake]

Hi Dale,

Thanks for the review. See below.

On Wed, Jun 28, 2017 at 10:35 PM, Dale Worley  wrote:
> Reviewer: Dale Worley
> Review result: Ready with Nits
>
> 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.
>
> Document:  draft-ietf-trill-arp-optimization-08
> Reviewer:  Dale R. Worley
> Review Date:  2017-06-28
> IETF LC End Date:  2017-06-29
> IESG Telechat date:  unknown
>
> Summary:
>
>This draft is basically ready for publication, but has nits
>that should be fixed before publication.
>
>Abstract
>
>This document describes mechanisms to optimize the ARP (Address
>Resolution Protocol) and ND (Neighbor Discovery) traffic in TRILL
>campus.
>
> s/in TRILL campus/in a TRILL campus/

OK.

> Perhaps summarize what the optimizations are:
>
>Each edge RBridge maintains a cache of IP/MAC address/Data Label
>bindings that are learned from ARP/ND requests and responses that
>pass through it.  This cache allows it to avoid flooding an ARP/ND
>request by either responding to it directly or by encapsulating it
>and unicasting it to the location where it is in use.

Wording along those lines sounds like a good addition.

>2 ARP/ND Optimization Requirement and Solution
>
>(including DHCP or gratuitous ARP_messages).
>
> s/_//

I think the underscore should be replaced by a space rather than the
null string.

>and should allow an end station to
>detect duplicate IP addresses.
>
> Unless this is a well-known phrase, it would be best if it was clear
> whether the end station is detecting that its own IP address is
> duplicated, or whether it is detecting that some other station's IP
> address is duplicated.

This is talking about the end station doing normal DAD by probing for
its own IP address.
"detect duplicate IP addresses" -> "detect duplication of its IP address".

>TRILL already provides an option to disable data-plane learning from
>the source MAC address of end-station frames on a per port basis (see
>Section 5.3 of [RFC6325]).
>
> Given how this section is written, shouldn't this option be considered
> an option to *enable* data-plane learning?  And in particular, doesn't
> that imply that TRILL already includes a solution to suppress ARP
> flooding?

By default RBridges learn the source MAC addresses of the Ethernet
frames they receive from attached end stations in a way similar to
such data plane learning by bridges. A change in that default, to not
learn such MAC addresses requires optional configuration. I don't
think just learning MAC addresses is useful for the types of ARP
flooding suppression talked about in this document.

> Also, what is the meaning of "learning from the source MAC address"?
> It seems like you'd want to specify what the learning is *of*, and
> then perhaps what it is learned *from*.
>
> Or is this particular learning of MAC addresses alone, and not of
> IP/MAC bindings?  If so, then isn't this feature orthogonal to ARP/ND
> optimization?

As per RFC 6325, RBridge default to data plane learning of MAC
addresses but not IP addresses. Although TRILL has ways of arbitrating
between conflicting addressing information learned through different
paths, it may be useful to disable data plane MAC address learning
when a directory is being used or the like.

> As a design matter, I'm curious why an RBridge can't learn IP/MAC
> bindings by snooping data packets, and only by snooping ARP packets.
> I suspect there are good reasons for it, but the naive reader (me) is
> left wondering...

You can get miscellaneous data packets at line speed so MAC address
learning is frequently implemented in hardware. While there is no
reason you couldn't do that for IP addresses, if you don't want to
require hardware changes from that in most existing implementations,
you would learn from ARP/ND in software which is generally practical
as they are not normally received that frequently.

>4.1 SEND Considerations
>
>Secure SEND messages require knowledge of cryptographic keys. Methods
>of communicating such keys to RBridges for use in SEND are beyond the
>scope of this document. Thus, using the optimizations in this
>document, RBridges do not attempt to construct SEND messages and are
>generally transparent to them. RBridges only construct ARP, RARP, or
>insecure ND messages, as appropriate.
>
> This doesn't flow quite correctly.  The second sentence suggests that
> there are known mechanisms for distributing keys to RBridges, but that
> this document doesn't describe them.

I disagree. Saying "X is beyond the scope of this document" means what
it says: that the topic is not further touched on in this document. I
do not think it implies that techniques to do X do or do not exist.

>

Re: [Gen-art] Genart last call review of draft-ietf-trill-rbridge-multilevel-06

[Donald Eastlake]

Hi Stewart,

Thanks for the comments. See below.

On Wed, Jun 28, 2017 at 2:06 PM, Stewart Bryant
 wrote:
> Reviewer: Stewart Bryant
> Review result: Ready
>
> 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
>
> .
>
> Document: draft-ietf-trill-rbridge-multilevel-??
> Reviewer: Stewart Bryant
> Review Date: 2017-06-28
> IETF LC End Date: 2017-06-28
> IESG Telechat date: 2017-07-06
>
> Summary:
>
> This is a well written document. I do however have a concern with the scaling
> text in section 1.2.x, as I think this could be more accessible and ought to
> include discussion of MAC Address scaling. More information below.
>
> Major issues: None
>
> Minor issues: The key justification for multi-area is scaling. The scene is 
> set
> in Section 1.2.x. However there are no references, the design size parameters
> are not articulated for each case, and the equations are not derived. I think
> that it would be helpful if the draft either provided some more explanation of
> the scaling equations and the associated input assumptions, or provided the
> assumptions and  directed the reader to an accessible text to understand the
> equations.

A reference and some further exposition of the assumptions made with
the way the equations were arrived at could be added.

> Although there is some discussion on it later there is no 
> discussion
> of the number of addresses to be learned in the single and multi-area cases 
> and
> the impact this has on the LSDB. The number of addresses to be learned will
> impact the ingress RBridge FIB and the FIB update time so this is just as
> significant in understanding the benefit of multi-level as understanding the
> link-state convergence time is.

The number of MAC (actually MAC/VLAN or MAC/FGL) addresses to be
learned by an edge TRILL switch is not affected by whether the TRILL
campus uses single or multilevel IS-IS. This number of MAC address
learned is the seventh scaling problem listed in Section 1.1 which
states that multilevel TRILL IS-IS helps only with the other six
problems. This point, that multilevel doesn't help here, could be
emphasized more but I don't think I see much point in this document in
going into details such as the scaling considerations of data plane
MAC address learning (which is the default in TRILL) or control plan
MAC address learning (which does not use the core LSDB but rather Data
Label scoped ESADI link stat databases).

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

> Nits/editorial comments: None
>
>

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-trill-mtu-negotiation-05

[Donald Eastlake]

Hi Brian,

Thanks for the comments. See below.

On Fri, Jun 23, 2017 at 9:32 PM, Brian Carpenter
 wrote:
> Reviewer: Brian Carpenter
> Review result: Ready with Issues
>
> Gen-ART Last Call review of draft-ietf-trill-mtu-negotiation-05
>
> 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
> .
>
> Document: draft-ietf-trill-mtu-negotiation-05.txt
> Reviewer: Brian Carpenter
> Review Date: 2017-06-24
> IETF LC End Date: 2017-06-28
> IESG Telechat date: 2017-07-06
>
> Summary: Ready with issues
> 
>
> Minor issues:
> -
>
>> 2. Link-Wide TRILL MTU Size
> ...
>>   ...RBridges MUST support the Extended L1 Circuit-Scoped
>>   (E-L1CS) flooding scope LSP (FS-LSP). They use that flooding to
>>   exchange their maximally supportable value of "Lz".
>
> Where does that value come from? Is it configured, derived from
> the interface in some way, or discovered?

It's somewhat similar to the originatingL1LSPBufferSize which is
talked about in Section 5 of RFC 7780, except that there is no reason
to worry about coordinating across the TRILL campus. How about adding
wording something like:

  The originatingSNPBufferSize for a port is the minimum of the
following two quantities, but not less than 1470 bytes: (1) the
maximum MTU of the port and (2) the maximum LSP size that the TRILL
IS-IS implementation can handle,

>> 2.1. Operations
>>
>>   Lz is reported using a originatingSNPBufferSize TLV that MUST occur
>>   in fragment zero of the RBridge's E-L1CS FS-LSP. An
>>   originatingSNPBufferSize APPsub-TLV occurring in any other fragment
>>   is ignored.
>
> Is that really what you mean? I thought Lz was an optional extra. So I think
> you mean:
>
> 2.1. Operations
>
>Lz MAY be reported using a originatingSNPBufferSize TLV that occurs
>in fragment zero of the RBridge's E-L1CS FS-LSP. An
>originatingSNPBufferSize APPsub-TLV occurring in any other fragment
>MUST be ignored.

Yes, the "MUST" was just in reference to being in fragment zero, not
that it has to occur, so your wording seems better.

>> 3. Link MTU Size Testing
> ...
>>   Step 0:
> ...
>>  b) Link MTU size is set to 1470, lowerBound is set to 1470,
>> upperBound is set to the link-wide Lz, linkMtuSize is set to
>> [(lowerBound + upperBound)/2] (Operation "[...]" returns the
>> fraction-rounded-up integer.).
>
> This is confusing. "linkMtuSize" was defined as a local variable.
> But what is "Link MTU size"? Is that another local variable?
> If so, how is it different from "linkMtuSize"?
> It is used again in part 2) of step 2 below.

I don't want to say anything about that before checking with the primary author.

> Also, I assume "Lz" is the value previously agreed among the nodes,
> but that should be made clear to the reader.
>
> Nits:
> -
>
>> 1. Introduction
> ...
>>   topology. While in this document, a new RECOMMENDED link-wide minimum
>>   inter-RBridge MTU size, Lz, is specified. By calculating a using Lz
>>   as specified herein, link-scoped PDUs can be formatted greater than
>>   the campus-wide Sz up to the link-wide minimum acceptable inter-
>>   RBridge MTU size potentially improving the efficiency of link
>>   utilization and speeding link state convergence.
>
> I cannot parse those two sentences. What does the "While" refer to?
> What does "By calculating a using Lz" mean?

I believe the sentences should be

"... In this document, a new RECOMMENDED link-wide minimum
inter-RBridge MTU size, Lz, is specified. By calculating and using Lz
as specified herein, ..."

>> 3. Link MTU Size Testing
> ...
>>  b) Link MTU size is set to 1470, lowerBound is set to 1470,
>> upperBound is set to the link-wide Lz, linkMtuSize is set to
>> [(lowerBound + upperBound)/2] (Operation "[...]" returns the
>> fraction-rounded-up integer.).
>
> This would be easier to understand:
>
> 3. Link MTU Size Testing
> ...
>   b) Link MTU size is set to 1470, lowerBound is set to 1470,
>  upperBound is set to the link-wide Lz, linkMtuSize is set to
>  [(lowerBound + upperBound)/2], rounded up to the nearest integer.

OK.

> Repeat this in the following two cases; a normal reader will not
> remember the rounding rule:
>
> ...
>1) If RB1 fails to receive an MTU-ack from RB2 after k tries:
>
>  upperBound is set to linkMtuSize and linkMtuSize is set to
>  [(lowerBound + upperBound)/2], rounded up to the nearest integer.
>
>2) If RB1 receives an MTU-ack to a probe of size linkMtuSize from
>   RB2:
>
>  link MTU size is set to linkMtuSize, lowerBound is set to
>  linkMtuSize and linkMtuSize is set to 

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

[Donald Eastlake]

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
 d3e...@gmail.com

On Thu, Jan 19, 2017 at 7:47 AM, Christer Holmberg <
christer.holmb...@ericsson.com> 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
>
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Donald Eastlake]

Hi Christer,

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

Re: [Gen-art] review of draft-ietf-trill-directory-assist-mechanisms-10.txt

[Donald Eastlake]

Hi Francis,

See below.

On Mon, Jan 9, 2017 at 9:05 AM, Francis Dupont
 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
>
> .
>
> Document: draft-ietf-trill-directory-assist-mechanisms-10.txt
> Reviewer: Francis Dupont
> Review Date: 20170105
> IETF LC End Date: 2017019
> IESG Telechat date: unknown
>
> Summary: Ready
>
> Major issues: None
>
> Minor issues: None

Thanks. I agree with all the below unless otherwise stated.

> Nits/editorial comments:
>  - 1.1 page 5: nomrally -> normally
>
>  - 1.2 page 6: MscSA -> MacSA
>
>  - 2.3.2 page 11: cancelled -> canceled
>
>  - 3.1 page 19: acknowledgement -> acknowledgment
>
>  - 3.2.1 page 21: AFN is from an unknown space: please add
>   a reference to where AFN is defined or to its registry (or both).

I'll add this to the Terminology section.

>  - 3.2.2.2 page 26 MacDA: in "this MAC address must be unicast"
>   as it is a requirement consider to put a MUST or to change to "has to"
>
>  - 3.3 page 27: in "A Pull Directory server may have a limit" use
>   a MAY?

"MAY" is wrong. I'll change it to "might".

>  - 3.3 page 28: you use the F, P, N, etc bits when their meanings are
>   in 3.3.1 so:
>   * please add a forward reference to 3.3.1
>   * add their names (flood, positive, negative) at first use
>
>  - 3.3.1 page 30: in "Message must have either" must -> MUST/has to
>
>  - 3.3.2 page 31: appropiately -> appropriately
>
>  - 3.5.1 page 33: knowns -> knows
>
>  - 3.5.3 page 34: Chanel -> Channel
>
>  - 3.6 page 35 (twice): [Aa]cknowledgement -> [Aa]cknowledgment
>
>  - 3.6.3 page 37: QTYPE 3 and 4 are unassigned
>
>  - 3.7 page 37: chagnes -> changes
>
>  - 7.1 page 45: only use of "IANA will assign" vs
>   "IANA is requested to assign". BTW look for what is the best and
>   use only  this one.
>
>  - 7.1 page 45: ESDADI -> ESADI and ESDAI -> ESADI
>
>  - 7.1 page 45: in the figure break the line between "for" and "expansion".
>   BTW it doesn't matter if a variable field spreads over more than one
>  line...
>
>  - Authors' Addresses page 52: (perhaps a troff macro issue):
>   please insert a comma before the country name.

OK.

>  - Authors' Addresses page 52: China -> PR China (or any variant
>   including CN (ISO IS 3166 2 letter code))

I don't see any reason to change this postal address which i have
determined by experiment to work fine, at least for mail posted in the
USA.

> Regards
>
> francis.dup...@fdupont.fr
>
> PS: I know some of you are from a country (from a list of 2) not using
> international units but millisecond abbrev is ms, not millisec...

I'll just spell it out.

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-trill-ia-appsubtlv

[Donald Eastlake]

Hi Paul,

On Wed, Jul 6, 2016 at 1:34 PM, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote:
> Donald,
>
> On 7/5/16 9:51 PM, Donald Eastlake wrote:
>>
>> Hi Paul,
>>
>> Version -09 has been uploaded with the intent that it resolve your
>> comments.
>
>
> Looks good except for one thing:
>
> Some of the new text in section 7 has me baffled:
>
>The following processes should be followed in interpreting sets of
>AFN values in an IA APPsub-TLV to synthesize addresses. These apply
>whether the AFN values came from sub-sub-TLVs or appeared within an
>Address Set or came from both sources. In general, the processing is
>applied separately to each Address Set as supplemented by any Fixed
>Address sub-sub-TLVs that are present.
> ...
>Typically, an OUI would be provided as a Fixed Address sub-sub-TLV
>(see Section 3.2) using the OUI AFN but there is no prohibition
>against one or more OUIs appearing in an Address Set.
>
>Each Address Set, after being supplemented by any Fixed Address sub-
>sub-TLVs, is processed by combining each OUI in the Address Set with
>each MAC/24 and each MAC/40 address in the address set.
>
> I get it when an OUI comes as a Fixed Address. That value is combined with
> each MAC/24 and MAC/40 in the address set, creating a new column in the
> address set. But I have no idea what it means if an OUI appears in the
> address set. In that case there will be a whole column of them, with a
> distinct value in each row. Does each one combine with MAC/*s in *every*
> row, or only with the MAC/*s in the *same* row? That latter seems like the
> more sensible interpretation, but the intent isn't clear. Frankly this kind
> of usage seems more like nonsense.

I don't see any reason to make the processing more complex with
special cases just because some uses seem very unlikely.
 You take the addresses from an Address Set and then you
supplement them from any Fixed Address sub-sub-TLVs that might be
present in the same IA APPsub-TLV. After that step, you have a set of
addresses and it no longer makes any difference where they came from.
You then perform certain processing on OUI, MAC/24, and MAC/40
addresses that are present, if any, to produce some number (possibly
zero) of 48 and/or 64 bit MAC addresses. You then perform a second
stage of processing using any IPv6/64 addresses, 48-bit MAC addresses,
and/or 64-bit addresses that are present, if any, to produce some
number (possibly zero) of IPv6 addresses.
  Why bother making the above description more complex by
prohibiting OUIs in Address Sets? (or saying they are ignored in
Address Sets or the the entire Address Set with an OUI is ignored or
..., which would probably be better to say since otherwise you would
want to say what to do about the (artificial in my opinion) "error"
condition of finding any OUI in an Address Set which implies it is in
the template for the Address Sets in that IA-APPsub-TLV.)

> But maybe it would make more sense to simply say that OUIs (and the other
> partial addresses) only make sense in special contexts such as the Fixed
> Address sub-sub-TLV.

Any OUI in an Address Set is, I admit, pretty odd. But I would expect
MAC/24 and the like to be in Address Sets. The idea is that you have,
for example, lots of end station physical Ethernet ports on links
attached to some RBridge, all from the same manufacturer with the same
OUI. So you stick that OUI in a Fixed Address sub-sub-TLV and then you
can save space by just putting a MAC/24 in the Address Set for each of
those ports in the IA APPsub-TLV originated by the RBridge.

The text already says that "typically" an OUI would be in a Fixed
Address sub-sub-TLV...

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

> Thanks,
> Paul
>
>
>> Thanks,
>> Donald
>> ===
>>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>  155 Beaver Street, Milford, MA 01757 USA
>>  d3e...@gmail.com
>>
>>
>> On Tue, Jul 5, 2016 at 9:32 AM, Paul Kyzivat <pkyzi...@alum.mit.edu>
>> wrote:
>>>
>>> On 7/4/16 11:35 PM, Donald Eastlake wrote:
>>>>
>>>>
>>>> Hi Paul,
>>>>
>>>> I believe we are generally in agreement.
>>>>
>>>> On the table in the IANA Considerations, I have read
>>>>
>>>> https://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-15#section-1.1
>>>> and I can understand why you commented as you did. But, since all the
>>>> table entries were created by IANA actions, I still think the draft is
>>>&g

Re: [Gen-art] review of draft-ietf-trill-irb-13.txt

[Donald Eastlake]

Hi,

These are all fixed in version -14 except that the last comment re
Section 7.1 to make the change "TENANT-LABEL -> TENANT-GWMAC-LABEL"
still has a tiny glitch in it. In particular, there is an extra space
just before "GWMAC" so it's "TENANT- GWMAC-LABEL". This certainly does
not seem worth a new version and can be fixed by the RFC Editor.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com


On Wed, Jun 29, 2016 at 1:02 PM, Jari Arkko  wrote:
> Francis, Donald, thank you for the review & updates.
>
> Jari
>

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-trill-ia-appsubtlv

[Donald Eastlake]

Hi Paul,

Version -09 has been uploaded with the intent that it resolve your comments.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com


On Tue, Jul 5, 2016 at 9:32 AM, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote:
> On 7/4/16 11:35 PM, Donald Eastlake wrote:
>>
>> Hi Paul,
>>
>> I believe we are generally in agreement.
>>
>> On the table in the IANA Considerations, I have read
>> https://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-15#section-1.1
>> and I can understand why you commented as you did. But, since all the
>> table entries were created by IANA actions, I still think the draft is
>> OK in having that table in the IANA Considerations Section. This is
>> not a case of including some technical specification in with the IANA
>> Considerations.  It's still all code points.
>
>
> OK. It is not a big deal.
>
> Thanks,
> Paul
>
>
>> Thanks,
>> Donald
>> ===
>>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>  155 Beaver Street, Milford, MA 01757 USA
>>  d3e...@gmail.com
>>
>>
>> On Mon, Jul 4, 2016 at 6:50 PM, Paul Kyzivat <pkyzi...@alum.mit.edu>
>> wrote:
>>>
>>> Donald,
>>>
>>> On 7/4/16 5:26 PM, Donald Eastlake wrote:
>>>>
>>>>
>>>> Hi Paul,
>>>>
>>>> Thanks for your comments. Sorry for the delay in response.
>>>> Please see below.
>>>
>>>
>>>
>>> No problem. I was just concerned that my review hadn't been received.
>>>
>>>
>>>> On Mon, Jun 27, 2016 at 6:46 PM, Paul Kyzivat <pkyzi...@alum.mit.edu>
>>>> 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>>>>
>>>>> Document: draft-ietf-trill-ia-appsubtlv
>>>>> Reviewer: Paul Kyzivat
>>>>> Review Date: 2016-06-27
>>>>> IETF LC End Date: 2016-06-28
>>>>> IESG Telechat date: 2016-07-07
>>>>>
>>>>> Summary:
>>>>>
>>>>> This draft is on the right track but has open issues, described in
>>>>> the review.
>>>>>
>>>>> This is a well written document. I was generally able to follow it
>>>>> even though I know nothing about the subject.
>>>>>
>>>>>
>>>>> Issues:
>>>>>
>>>>> Major: 0
>>>>> Minor: 7
>>>>> Nits:  2
>>>>>
>>>>> (1) MINOR: (Section 2)
>>>>>
>>>>> "Addr Sets End" is described as follows:
>>>>>
>>>>>o  Addr Sets End: The unsigned integer offset of the byte, within
>>>>>   the IA APPsub-TLV value part, of the last byte of the last
>>>>>   Address Set. This will be the byte just before the first
>>>>>   sub-sub-TLV if any sub-sub-TLVs are present ...
>>>>>
>>>>> But the remaining text of this section, and the examples, imply that
>>>>> this is really the length of the leading portion of this TLV ending
>>>>> with the last Address Set. The programmer in me says these differ by
>>>>> one, and that the implied definition is the reasonable one, while
>>>>> the action definition, and the name used to identify it, are wrong.
>>>>>
>>>>> I expect it would be difficult at this point to rename this field,
>>>>> but at least the definition can be rewritten to be consistent with
>>>>> the intended usage.
>>>>
>>>>
>>>>
>>>> Right. How about
>>>>
>>>>Addr Sets End: The unsigned integer byte number, within the IA
>>>>APPsub-TLV value part, of the last byte of the last Address Set,
>>>>where the first byte is numbered 1. This will be the number of the
>>>>byte just before ...
>>>
>>>
>>>
>>> OK. If you count starting from one. (I don't, but it 

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-trill-channel-tunnel-09

[Donald Eastlake]

Hi Peter,

Version -10 has been uploaded with the intent of resolved your GENART
review comments.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com


On Tue, Jul 5, 2016 at 4:06 PM, Peter Yee  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 wait for direction from your document shepherd or AD
> before posting a new version of the draft.  For background on Gen-ART,
> please see the FAQ at
> 
>
> Document: draft-ietf-trill-channel-tunnel-09
> Reviewer: Peter Yee
> Review Date: July 1, 2016
> IETF LC End Date: July  1, 2016
> IESG Telechat date: July 7, 2016
>
> Summary: This draft is basically ready for publication as a Proposed
> Standard, but has some nits that should be fixed before publication. [Ready
> with nits]
>
> This draft extends TRILL RBridge Channels so that they can transmit
> additional, tunneled message types.  Security services for RBridge Channel
> messages can be provisioned via RFC 5310 authentication and/or DTLS.  The
> draft is well-written and easy to understand in the larger TRILL context.
>
> The nits noted in the Last Call review will be addressed in a new version of
> the draft, as already discussed with one of the authors.  This review is
> posted in order to make the Telechat deadline, as the date for the next
> draft is not known to this reviewer.  The previous (Last Call) review can be
> found here:
> https://www.ietf.org/mail-archive/web/gen-art/current/msg13423.html
>
>

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-trill-ia-appsubtlv

[Donald Eastlake]

Hi Paul,

I believe we are generally in agreement.

On the table in the IANA Considerations, I have read
https://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-15#section-1.1
and I can understand why you commented as you did. But, since all the
table entries were created by IANA actions, I still think the draft is
OK in having that table in the IANA Considerations Section. This is
not a case of including some technical specification in with the IANA
Considerations.  It's still all code points.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com


On Mon, Jul 4, 2016 at 6:50 PM, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote:
> Donald,
>
> On 7/4/16 5:26 PM, Donald Eastlake wrote:
>>
>> Hi Paul,
>>
>> Thanks for your comments. Sorry for the delay in response.
>> Please see below.
>
>
> No problem. I was just concerned that my review hadn't been received.
>
>
>> On Mon, Jun 27, 2016 at 6:46 PM, Paul Kyzivat <pkyzi...@alum.mit.edu>
>> 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>>
>>> Document: draft-ietf-trill-ia-appsubtlv
>>> Reviewer: Paul Kyzivat
>>> Review Date: 2016-06-27
>>> IETF LC End Date: 2016-06-28
>>> IESG Telechat date: 2016-07-07
>>>
>>> Summary:
>>>
>>> This draft is on the right track but has open issues, described in
>>> the review.
>>>
>>> This is a well written document. I was generally able to follow it
>>> even though I know nothing about the subject.
>>>
>>>
>>> Issues:
>>>
>>> Major: 0
>>> Minor: 7
>>> Nits:  2
>>>
>>> (1) MINOR: (Section 2)
>>>
>>> "Addr Sets End" is described as follows:
>>>
>>>o  Addr Sets End: The unsigned integer offset of the byte, within
>>>   the IA APPsub-TLV value part, of the last byte of the last
>>>   Address Set. This will be the byte just before the first
>>>   sub-sub-TLV if any sub-sub-TLVs are present ...
>>>
>>> But the remaining text of this section, and the examples, imply that
>>> this is really the length of the leading portion of this TLV ending
>>> with the last Address Set. The programmer in me says these differ by
>>> one, and that the implied definition is the reasonable one, while
>>> the action definition, and the name used to identify it, are wrong.
>>>
>>> I expect it would be difficult at this point to rename this field,
>>> but at least the definition can be rewritten to be consistent with
>>> the intended usage.
>>
>>
>> Right. How about
>>
>>Addr Sets End: The unsigned integer byte number, within the IA
>>APPsub-TLV value part, of the last byte of the last Address Set,
>>where the first byte is numbered 1. This will be the number of the
>>byte just before ...
>
>
> OK. If you count starting from one. (I don't, but it is your draft.)
>
>>> (2) MINOR: (Section 5.1)
>>>
>>> Normally I would expect this section to request IANA to assign new
>>> values from the AFN table for OUI...RBridge Port ID. However it is
>>> worded as "IANA has allocated". Perhaps this is because they have
>>> already been (pre)allocated. I have no problem with that if IANA is
>>> OK with it.
>>
>>
>> Yup, it say "IANA has allocated" because they are already allocated. See
>>
>> http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml
>
>
> OK.
>
>>> But IMO the references to IPv4...64-bit MAC are gratuitous and
>>> inappropriate in an IANA Considerations section. If it is desired to
>>> include a list of "useful" AFN values then that belongs in some
>>> other portion of the document.
>>
>>
>> I disagree. It's "IANA Considerations", not "IANA Allocation Actions".
>> Someone looking for code points is likely look in the IANA
>> Considerations section.  All the values shown are from the same IANA
>> registry.  I can see no advantage to splitting this table between two
>> different parts of the dr

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-trill-ia-appsubtlv

[Donald Eastlake]

Hi Paul,

Thanks for your comments. Sorry for the delay in response.
Please see below.

On Mon, Jun 27, 2016 at 6:46 PM, Paul Kyzivat 
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 .
>
> Document: draft-ietf-trill-ia-appsubtlv
> Reviewer: Paul Kyzivat
> Review Date: 2016-06-27
> IETF LC End Date: 2016-06-28
> IESG Telechat date: 2016-07-07
>
> Summary:
>
> This draft is on the right track but has open issues, described in
> the review.
>
> This is a well written document. I was generally able to follow it
> even though I know nothing about the subject.
>
>
> Issues:
>
> Major: 0
> Minor: 7
> Nits:  2
>
> (1) MINOR: (Section 2)
>
> "Addr Sets End" is described as follows:
>
>o  Addr Sets End: The unsigned integer offset of the byte, within
>   the IA APPsub-TLV value part, of the last byte of the last
>   Address Set. This will be the byte just before the first
>   sub-sub-TLV if any sub-sub-TLVs are present ...
>
> But the remaining text of this section, and the examples, imply that
> this is really the length of the leading portion of this TLV ending
> with the last Address Set. The programmer in me says these differ by
> one, and that the implied definition is the reasonable one, while
> the action definition, and the name used to identify it, are wrong.
>
> I expect it would be difficult at this point to rename this field,
> but at least the definition can be rewritten to be consistent with
> the intended usage.

Right. How about

   Addr Sets End: The unsigned integer byte number, within the IA
   APPsub-TLV value part, of the last byte of the last Address Set,
   where the first byte is numbered 1. This will be the number of the
   byte just before ...

> (2) MINOR: (Section 5.1)
>
> Normally I would expect this section to request IANA to assign new
> values from the AFN table for OUI...RBridge Port ID. However it is
> worded as "IANA has allocated". Perhaps this is because they have
> already been (pre)allocated. I have no problem with that if IANA is
> OK with it.

Yup, it say "IANA has allocated" because they are already allocated. See
http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml

> But IMO the references to IPv4...64-bit MAC are gratuitous and
> inappropriate in an IANA Considerations section. If it is desired to
> include a list of "useful" AFN values then that belongs in some
> other portion of the document.

I disagree. It's "IANA Considerations", not "IANA Allocation Actions".
Someone looking for code points is likely look in the IANA
Considerations section.  All the values shown are from the same IANA
registry.  I can see no advantage to splitting this table between two
different parts of the draft.

> (3) MINOR: (Section 5.1)
>
> The "new" values here (OUI, MAC/24, MAC/40, IPv6/64) give "This
> document" as their reference. But anyone consulting the IANA
> registry and following it to this document would have difficulty
> finding any *definition* of these things.
>
> Section 6 discusses some operational issues with them, but at best
> implies a definition. (RFC7042 might be considered a definition of
> OUI, though it doesn't seem to say how big it would be.)
>
> I think what is needed are explicit definitions of all of these,
> including their widths. (In order to provide enough bits to complete
> a MAC/24 it must be at least 24 bits wide, but that would be bigger
> than needed for a MAC/40.  So I guess it must be at least 24 bits,
> and when used to expand a MAC/24 or MAC/40 an appropriate number of
> its high order bits are used.)
>
> It would be good for there to be a section, appearing in the TOC,
> for each of these so that someone coming here from the IANA registry
> will easily be able to find the definition.

This is a good point. Better definitions of these AFN types and better
references, either to within this document by explicit pointers to a
section within another document or both, are good points. Probably
Section 6 should be expanded and sub-sections added to it...

> (4) MINOR: (Section 5.2)
>
> This section defines a new registry with Expert Review as the
> procedure for approving new entries. What I don't see is any
> guidance to the expert on appropriate criteria to use to judge
> suitability of new entries. Without any guidance, relying on the
> whim of the expert can lead to variable, and perhaps biased,
> results.
>
> It would be good to give guidance on: what sorts of document
> reference are acceptable, what information needs to be included in
> the reference document, whether "special" values may be requested
> (versus just assignment in order requests are received), and the
> sorts of 

Re: [Gen-art] Gen-ART LC review of draft-ietf-trill-channel-tunnel-09

[Donald Eastlake]

Hi Peter,

Thanks for your thorough review. See below.

On Sat, Jul 2, 2016 at 2:33 AM, Peter Yee  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
> comment.  For background on Gen-ART, please see the FAQ at
> 
>
> Document: draft-ietf-trill-channel-tunnel-09
> Reviewer: Peter Yee
> Review Date: July 1, 2016
> IETF LC End Date: July  1, 2016
> IESG Telechat date: July 7, 2016
>
> Summary: This draft is basically ready for publication as a Proposed
> Standard, but has some nits that should be fixed before publication. [Ready
> with nits]
>
> This draft extends TRILL RBridge Channels so that they can transmit
> additional, tunneled message types.  Security services for RBridge Channel
> messages can be provisioned via RFC 5310 authentication and/or DTLS.  The
> draft is well-written and easy to understand in the larger TRILL context.
>
> Major issues: None
>
> Minor issues: None
>
> Nits:
>
> General:
>
> For cases of "[RFC5310] Based authentication" to "[RFC5310]-based
> authentication".  Watch for one instance of "RFC 5310 Based" as well.

OK.

(Nit-Nit: I think in the nit above, the first word should be Four.)

> Specific:

All of the following are OK unless noted otherwise right after that nit:

> Page 3, Section 1, 1st paragraph, last sentence: delete the comma following
> "link".
>
> Page 4, "HKDF" definition: Change "Hash based" to "HMAC-based".
>
> Page 4, "MTU" definition: add a period at the end of the definition for
> consistency.
>
> Page 4, "Sz" definition: change "Campus wide" to "Campus-wide".
>
> Page 6, 1st full paragraph, 1st sentence: suggest changing "RBridge Channel
> Extension Protocol" to "Extended RBridge Channel Protocol" as this is the
> usage throughout the rest of the document.
>
> Page 8, Section 3.1, 3rd sentence: insert "tunneled" before "data".  I hope
> this will help clarity when referring back to Figure 2.4 which includes
> "Tunneled Data".
>
> Page 8, Section 3.2, 1st sentence: append "(tunneled data)" after "payload".
> This is done for the same reason, although I'm not recommending doing this
> for all further occurrences of "payload" in other sections as I hope the
> connection is made by that point.
>
> Page 12, 1st paragraph, 1st sentence: change "link local" to "link-local".
>
> Page 12, 1st paragraph, 2nd sentence: change "These constructed addresses"
> to "A constructed address".

Humm. I don't really like your suggested change. How about I change it
to "Such a constructed address ..."

> Page 14, Section 4, 2nd paragraph, 1st sentence: change "use" to "used".
>
> Page 14, Section 4, 3rd paragraph, 1st sentence: change "DTLS based" to
> "DTLS-based".
>
> Page 14, Section 4, 4th paragraph, 2nd sentence: change "data accessible" to
> "data-accessible".
>
> Page 15, 1st partial paragraph, last sentence: insert "the" before
> "output-derived".
>
> Page 16, 1st bullet item: change "or" to "on".
>
> Page 17, 1st paragraph: delete the comma after "keying".
>
> Page 18, 2nd full paragraph, last sentence: change "secuirty" to "security".
>
> Page 20, Section 6.2, 1st paragraph: change "a" to "an".
>
> Page 21, Section 7, 3rd paragraph, 2nd sentence: delete "processing of".  Or
> change "processing" to "process".

Instead, change the immediately following "decapsulating" to "decapsulated".

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

Re: [Gen-art] Genart LC (and likely telechat) review : draft-ietf-trill-tree-selection-04

[Donald Eastlake]

Hi Robert,

A version -05 has been uploaded with the intent that it resolve your comments.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com


On Wed, Jun 29, 2016 at 4:09 PM, Donald Eastlake <d3e...@gmail.com> wrote:
> Hi Robert,
>
> Thanks for your thorough comments. See below.
>
> On Tue, Jun 28, 2016 at 3:33 PM, Robert Sparks <rjspa...@nostrum.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
>>
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>
>> Document: draft-ietf-trill-tree-selection-04
>> Reviewer: Robert Sparks
>> Review Date: 28 Jun 2016
>> IETF LC End Date: 1 Jul 2016
>> IESG Telechat date: 7 Jul 2016
>>
>> Summary: Ready (with nits) for publication as Proposed Standard
>>
>> This document is easy to read, even for someone not deeply steeped
>> in trill.
>>
>> I have a few questions and suggestions to consider
>>
>> 1) The essence of the idea this document provides support for is that an
>> operator will create and install a configuration that meets the one tree per
>> identifiable thing (such as VLAN) constraint.
>
> Well, it helps as long as multi-destination traffic identified by VLAN
> or whatever is carried by fewer than all trees. It need not be one.
>
>> The protocol proposed here
>> does not try to enforce that the operator supplies a configuration meeting
>> that constraint. Should the things that generate messages with the TLVs
>> defined in this document be restricted from sending messages that would map
>> the same VLAN to two trees? I understand things will still work
>> (suboptimally, as pointed out in the backwards-compatibility section), but
>> it seems this configuration error should be mitigated. Section 3.3 also
>> pulls the punch a little with it's discussion at the end of the second
>> paragraph. If you're going to leave it up to the unspecified way the
>> operator installs this configuration, you might at least point out that this
>> is something to look for and complain about. If you think the optimal
>> configuration isn't a likely thing to reach, then consider a pass through
>> the document that sets that expectation consistently.
>
> While restricting, for example, VLAN-x to one tree is optimal from the
> point of view of using up the least amount of fast path FIB
> (Forwarding Information Base) resources in some hardware
> implementations, it is not optimal from the point of view of load
> spreading. To get optimal load spreading, you would want to spread
> different multi-destination flows onto different distribution trees.
>
>> 2) There are a couple of places where you use 2119 where you appear to be
>> restating requirements from other documents. That's dangerous, from a
>> document set maintenance point of view. Please consider changing these to
>> simple prose, leaving the 2119 requirements to the protocol you're defining
>> in this document. Please look at the SHOULD in the Background Description,
>> and the SHOULD NOT in the first paragraph of the Overview. (2119 in sections
>> like backgrounds and overviews is usually a sign that somethings in the
>> wrong place.)
>
> The SHOULD in the Background Description is indeed just echoing the
> same provision from [RFC6325] and can be changed to not use a 2119 keyword.
>
> The SHOULD NOT in the first paragraph of the Overview (Section 3.1) is
> entirely due to theis draft and not inhereted from any other document.
>
>> 3) In the 3rd paragraph of 3.3, why is the requirement SHOULD strength? What
>> else would the RBridge do, and when would it be reasonable for it to do that
>> something else?
>
> The "SHOULD" requirement is to use a tree that the choosing RBridge
> has advertised it will use; however, it is not actually required to
> advertise which tree(s) it will use. Furthermore, even if it has, that
> tree(s) might just have become unavailable due to one or more
> failures.  We can probably add some words to clarify that.
>
>> Nits/editorial comments:
>>
>> * You use a lot of domain-specific acronyms in section 1 before saying what
>> they mean in section 2.
>
> Looks to me like the terminology section could be moved up.
>
>> * The first sentence in the 8th paragraph of 1.2 is very
>

Re: [Gen-art] Genart LC (and likely telechat) review : draft-ietf-trill-tree-selection-04

[Donald Eastlake]

Hi Robert,

Thanks for your thorough comments. See below.

On Tue, Jun 28, 2016 at 3:33 PM, Robert Sparks 
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
>
> .
>
> Document: draft-ietf-trill-tree-selection-04
> Reviewer: Robert Sparks
> Review Date: 28 Jun 2016
> IETF LC End Date: 1 Jul 2016
> IESG Telechat date: 7 Jul 2016
>
> Summary: Ready (with nits) for publication as Proposed Standard
>
> This document is easy to read, even for someone not deeply steeped
> in trill.
>
> I have a few questions and suggestions to consider
>
> 1) The essence of the idea this document provides support for is that an
> operator will create and install a configuration that meets the one tree per
> identifiable thing (such as VLAN) constraint.

Well, it helps as long as multi-destination traffic identified by VLAN
or whatever is carried by fewer than all trees. It need not be one.

> The protocol proposed here
> does not try to enforce that the operator supplies a configuration meeting
> that constraint. Should the things that generate messages with the TLVs
> defined in this document be restricted from sending messages that would map
> the same VLAN to two trees? I understand things will still work
> (suboptimally, as pointed out in the backwards-compatibility section), but
> it seems this configuration error should be mitigated. Section 3.3 also
> pulls the punch a little with it's discussion at the end of the second
> paragraph. If you're going to leave it up to the unspecified way the
> operator installs this configuration, you might at least point out that this
> is something to look for and complain about. If you think the optimal
> configuration isn't a likely thing to reach, then consider a pass through
> the document that sets that expectation consistently.

While restricting, for example, VLAN-x to one tree is optimal from the
point of view of using up the least amount of fast path FIB
(Forwarding Information Base) resources in some hardware
implementations, it is not optimal from the point of view of load
spreading. To get optimal load spreading, you would want to spread
different multi-destination flows onto different distribution trees.

> 2) There are a couple of places where you use 2119 where you appear to be
> restating requirements from other documents. That's dangerous, from a
> document set maintenance point of view. Please consider changing these to
> simple prose, leaving the 2119 requirements to the protocol you're defining
> in this document. Please look at the SHOULD in the Background Description,
> and the SHOULD NOT in the first paragraph of the Overview. (2119 in sections
> like backgrounds and overviews is usually a sign that somethings in the
> wrong place.)

The SHOULD in the Background Description is indeed just echoing the
same provision from [RFC6325] and can be changed to not use a 2119 keyword.

The SHOULD NOT in the first paragraph of the Overview (Section 3.1) is
entirely due to theis draft and not inhereted from any other document.

> 3) In the 3rd paragraph of 3.3, why is the requirement SHOULD strength? What
> else would the RBridge do, and when would it be reasonable for it to do that
> something else?

The "SHOULD" requirement is to use a tree that the choosing RBridge
has advertised it will use; however, it is not actually required to
advertise which tree(s) it will use. Furthermore, even if it has, that
tree(s) might just have become unavailable due to one or more
failures.  We can probably add some words to clarify that.

> Nits/editorial comments:
>
> * You use a lot of domain-specific acronyms in section 1 before saying what
> they mean in section 2.

Looks to me like the terminology section could be moved up.

> * The first sentence in the 8th paragraph of 1.2 is very
> complex. (It's the one that starts "In cases where blocks
> of"). Please consider simplifying it.

I think it can be re-worded.

> * Section 2: (I'm no fun) Do you want this alternate expansion of
> FGL to stand?

Nope... Looks like a global replace run amok or something, that should
be fixed :-)

> * Figure 2: the left table has a VLAN of 4095, which is inconsistent
> with the prose.

Shold be fixed. 4095 (0xFFF) is not a valid VLAN ID.

> * In section 3.4 you use 2119 RECOMMENDED (which is equivalent to
> SHOULD) when describing how the operator configures things. This
> isn't a constraint on the protocol defined in this document. Please
> consider rewriting the sentence without the 2119 keyword.

Humm. I think those are good operational recommendations. We can try
changing "RECOMMEND" to "suggest" and see if we get push back to
change it back :-)

> * Micronits: there's spurious 

Re: [Gen-art] review of draft-ietf-trill-irb-13.txt

[Donald Eastlake]

Hi Francis,

Thanks for the review. See some responses below.

On Wed, Jun 22, 2016 at 10:22 AM, Francis Dupont
 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
>
> .
>
> Document: draft-ietf-trill-irb-13.txt
> Reviewer: Francis Dupont
> Review Date: 20160618
> IETF LC End Date: 20160624
> IESG Telechat date: 20150630
>
> Summary: Ready
>
> Major issues: None
>
> Minor issues: None
>
> Nits/editorial comments:
>  - you have 6 (with a soft limit of 5) authors

I have have consulted with the authors and they will reduce it to 5.

>  - 1 page 3: please expand the first occurrence of the FGL abbrev
>
>   (in theory you should expand the TRILL abbrev and in the Abstract too
>but IMHO it is unlikely to get a reader of this document who does
>not know the TRILL abbrev meaning and raises a concern. BTW VLAN
>is well known (*) so doesn't need to be expanded)
>(* starred in http://www.rfc-editor.org/materials/abbrev.expansion.txt)

OK.

>  - 1 page 3: i.e. -> i.e.,

OK.

>  - 3.1 page 5: IMHO the title should be on the next page (page 6).
>   This will be fixed by the RFC Editor anyway.

I don't know how easy it will be for the authors to fix this but, as
you point out, the RFC Editor can always fix it.

>  - 3.1 pages 6 and further: congratulations, you use IP addresses
>   from blocks reserved for documentation.

Thanks.

>  - 5.2 page 12: dependant -> dependent

OK.

>  - 5.4 pages 14 and 15: I have an academic question: did you find
>   some cases of external redirects? This term is not common
>   (nor use cases :-) so I copy a definition I gave during a discussion
>   about SEND (the secure IPv6 neighbor discovery):
>- give the link-layer address of an off-link destination which is
>  in fact on-link. This "external redirect" is used for IPv6 over
>  ATM to implement NHRP short cuts for instance.

I don't think so but I'm not exactly sure what that would mean in this case.

>  - 6 page 15: another example of strange page layout that should be
>   fixed by the RFC Editor.

See response above.

>  - 7.1 page 19: TENANT-LABEL -> TENANT-GWMAC-LABEL
>   (cf 9 IANA Considerations page 22 )

OK.

Thanks,
Donald (document Shepherd)
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

> Regards
>
> francis.dup...@fdupont.fr

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC review of draft-ietf-dnsop-cookies-08

[Donald Eastlake]

Hi Peter,

On Sun, Dec 27, 2015 at 8:30 PM, Peter Yee <pe...@akayla.com> wrote:
> Hi Donald,
>
> Responses below.
>
> -Original Message-
> From: Donald Eastlake [mailto:d3e...@gmail.com]
> Sent: Sunday, December 27, 2015 4:31 PM
> To: Peter Yee
> Cc: draft-ietf-dnsop-cookies@ietf.org; gen-art@ietf.org Review Team; IETF 
> Discussion
> Subject: Re: Gen-ART LC review of draft-ietf-dnsop-cookies-08
>
>>> Minor issues:
>>>
>>> Page 14, Section 5.2.4, 1st paragraph, 1st sentence: It might be
>>> useful to mention what the examination entails as it would help in
>>> understanding the 3rd sentence in the paragraph.  There's an implied
>>> recalculation of the Server Cookie value based on the received Client
>>> Cookie and client IP address as opposed to a simple lookup of the received 
>>> value.
>
>>I'm not so sure of that. If the server wanted to, it could generate a random 
>>Server Cookie for each {Client Cookie, Client IP} and, in fact, do a look up.
>
> Section 5.2.4 is the invalid server cookie one.  Let's say just the client's 
> cookie changed, but all else remained the same.  The server wants to do a 
> lookup.  If it looks up a stored, expected server cookie based on the client 
> IP address, the server cookie looks valid.  If it just takes the received 
> client cookie and client IP address (plus server secret) and generates the 
> expected cookie value, then the received server cookie will appear invalid 
> because of the change in client cookie.

(well, presumably there is a 1 in 2**64 chance it just happens to be
valid anyway :-)

It SHOULD take the received Client Cookie into account, whether it is
doing a look-up or recalculating in a stateless manner. But it is all
potentially a bit more complex. If it is re-calculating, which is the
general assumption in this draft, it may need to try with both a
current and previous server secret. And the server could be using a
scheme such as that described in Appendix B.2, in which case the hash
portion of the server cookie can be considered an authentication code
over the other parts of the server cookie as well as over the server
secret and client cookie. In which case, after authentication, the
server might apply some restriction to the time stamp or some other
fields included in the server cookie. So determining validity could be
a bit complex.

> That's the line of thinking that led to my comment.  It appears that you're 
> expecting to do the calculation, otherwise you wouldn't have reason to notice 
> the client cookie changing since this is an examination of the server cookie. 
>  Sure, you could index off the client cookie, but that seems extreme.  And 
> you would presumably not update the server cookie value to be used in future 
> responses until you've done the initial examination, so you unless you're 
> doing an involved cookie rollover scheme, the client cookie wouldn't be used 
> until it's needed to create the updated server cookie.

Well, how about inserting a second sentence into the first paragraph
of Section 5.2.4 (keeping in mind that, based on another comment, the
existing second sentence has been deleted) something like: "This
determination normally involves re-calculating the Server Cookie (or
the hash thereof) based on the server secret (and/or the previous
server secret if it has just changed), the received Client Cookie, the
client IP address, and possibly other fields -- see Appendix B.2 for
an example."

By the way, since its Server Cookies include a nonce, I believe the
BIND implementation always sends a different Server Cookie.

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

>>> Nits:
>
>>> Page 13, Section 5.2.2, 2nd paragraph: append "bytes" after "40".
>
>>Why after 40 but not after 8 or 16? Seems like me it would be an improvement 
>>to add "bytes" after all three.
>
> That works for me too.  I just wanted to get the unit in there.  If you 
> prefer to tie the unit to each value, that's fine.
>
>>Thanks,
>>Donald
>
> My pleasure,
> -Peter
>
>
>

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC review of draft-ietf-dnsop-cookies-08

[Donald Eastlake]

Hi Peter,

Thanks for the comments, see below.

On Thu, Dec 24, 2015 at 8:27 PM, Peter Yee  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
> comment.  For background on Gen-ART, please see the FAQ at
> 
>
> (Actually, I'm tardy on this review.  It inexplicably dropped off my radar.
> So deal with these comments when you get around to handling Telechat input
> or AUTH48 or whenever it suits you!  I'm still posting this review as it
> will be needed come the Telechat.)

I don't think it has been scheduled for a Telechat yet so we might as
well resolve these comments now.

> Document: draft-ietf-dnsop-cookies-08
> Reviewer: Peter Yee
> Review Date: December 24, 2015
> IETF LC End Date: December 14, 2015
> IESG Telechat date: TBD
>
> Summary: This draft is basically ready for publication, but has nits that
> should be fixed before publication. [Ready with nits]
>
> The draft provides a lightweight means to increase the difficulty of certain
> DNS attacks by off-path attackers, but it isn't designed to be the be all
> and end all of DNS security.  It can be deployed incrementally.
>
> Major issues: None
>
> Minor issues:
>
> Page 14, Section 5.2.4, 1st paragraph, 1st sentence: It might be useful to
> mention what the examination entails as it would help in understanding the
> 3rd sentence in the paragraph.  There's an implied recalculation of the
> Server Cookie value based on the received Client Cookie and client IP
> address as opposed to a simple lookup of the received value.

I'm not so sure of that. If the server wanted to, it could generate a
random Server Cookie for each {Client Cookie, Client IP} and, in fact,
do a look up.

> Nits:
>
> Page 12, Section 5.2, 3rd paragraph, 1st sentence: change "the the" to just
> "the".

OK.

> Page 13, Section 5.2.2, 2nd paragraph: append "bytes" after "40".

Why after 40 but not after 8 or 16? Seems like me it would be an
improvement to add "bytes" after all three.

> Page 14, Section 5.2.4, 1st paragraph, 2nd sentence: delete the sentence.
> It's redundant with the 1st sentence.

OK.

> Page 15, Section 5.4, 2nd paragraph, 1st sentence: change first "a" to "an".

OK.

> Page 15, Section 5.4, 4th paragraph, 1st sentence: change first "a" to "an".

OK.

> Page 17, Section 6, 1st paragraph, 2nd sentence: change "indefinitely" to
> "indefinite".

OK.

> Page 21, Section 9, 2nd paragraph, 2nd sentence: change "WPAv2" to "WPA2"
> (the Wi-Fi Alliance's term).

OK.

> Page 23, Section 10: change "a" to "an".

OK.

> Page 27, Section A.1, 1st sentence: change "An" to "A".

OK.

> Page 29, 1st partial sentence: if you're going to drop beta earlier in the
> section, you might as well give the BIND version number here as well.  It's
> no longer apparent that a beta version was involved.

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-trill-rfc7180bis-06

[Donald Eastlake]

Hi Jari,

On Thu, Oct 22, 2015 at 8:51 AM, Jari Arkko <jari.ar...@piuha.net> wrote:
> Meral, many thanks for the review. Donald, many thanks for the changes.
>
> I have balloted no-obj.
>
> On re: conflicts, I understood the sentence as a usual if-all-else-fails 
> clause of specifying which document has precedence in case some conflicts are 
> discovered later. I think that’s fine. Is this your understanding too, Donald?

Yes, I would say that sentence is really just a back-stop as you describe.

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

> Jari
>
> On 21 Oct 2015, at 17:20, Meral Shirazipour <meral.shirazip...@ericsson.com> 
> wrote:
>
>> Hi Donald,
>>  Thank you for considering the changes. Please see in-line for a few more 
>> comments.
>>
>> Best,
>> Meral
>>
>>> -Original Message-
>>> From: Donald Eastlake [mailto:d3e...@gmail.com]
>>> Sent: Wednesday, October 21, 2015 7:54 AM
>>> To: Meral Shirazipour
>>> Cc: draft-ietf-trill-rfc7180bis@tools.ietf.org; gen-art@ietf.org
>>> Subject: Re: Gen-ART Last Call review of draft-ietf-trill-rfc7180bis-06
>>>
>>> Hi Meral,
>>>
>>> On Mon, Oct 19, 2015 at 8:02 PM, Meral Shirazipour
>>> <meral.shirazip...@ericsson.com> wrote:
>>>> I am the assigned Gen-ART reviewer for this draft. For background on
>>>> Gen-ART, please see the FAQ at
>>>> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
>>>>
>>>>
>>>> Please resolve these comments along with any other Last Call comments
>>>> you may receive.
>>>>
>>>>
>>>> Document: draft-ietf-trill-rfc7180bis-06
>>>> Reviewer: Meral Shirazipour (was originally assigned to another
>>>> gen-art) Review Date: 2015-10-19 IETF LC End Date:  2015-10-19 IESG
>>>> Telechat date: 2015-10-22
>>>>
>>>>
>>>>
>>>> Summary:
>>>>
>>>> This draft is ready to be published as Standards Track RFC but I have
>>>> some comments .
>>>
>>> Thanks. See below.
>>>
>>>> Major issues:
>>>>
>>>>
>>>> Minor issues:
>>>>
>>>> -[Page 5], Section 1.1: this section updates section 1.2 of RFC6325.
>>>> The update is about conflict resolution between sections of the RFC.
>>>>
>>>> Shouldn't this bis highlight those conflicts if any?
>>>
>>> I do not believe there are any real conflicts. RFC 6325 has some
>>> general/introductory sections and some detailed technical sections.
>>> The general sections, particularly Section 2, are written with a pedagogical
>>> goal of giving the reader the best general understanding and such general
>>> sections are not necessarily precise and do not, in general, include every
>>> corner case. During the development of RFC 6325, some reader focused on
>>> such general descriptions and claimed that the "conflicted" with the 
>>> precise,
>>> detailed technical sections.
>>> Thus Section 1.2 was added to RFC6325 to resolve this and make it clear that
>>> the later detailed sections should be followed in case of any such apparent
>>> "conflict".
>>>
>>> I don't really remember exactly what motivated making the material about
>>> precedence of sections in RFC 6325 more complete in RFC 7180 but it was
>>> probably based on some comment.
>>>
>>> The only change from Section 1.1 of RFC 7180 to this Section 1.1 draft-ietf-
>>> trill-rfc7180bis is updating of some other RFC numbers in this section.
>>>
>>
>> [MSh] Would it be possible to add a few sentences to clarify that? or maybe 
>> remove the word "conflict" ?
>>
>>
>>>> -[Page 14], Section 3.4. Should this section have a MUST sentence just
>>>> before the last sentence?
>>>>
>>>> "All RBridges in a campus MUST determine distribution trees in the
>>>> same way "
>>>
>>> I don't think so. The mandatory implementation of the distribution tree
>>> computation provisions is elsewhere. The sentence you refer to is just
>>> discussion of the consequences of failure to follow that.
>>>
>>>> -[Page 10], Section 2.4.2.1 , gives an example, then the first bullet
>>>> after the figure explains the problem with that scenar

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-trill-rfc7180bis-06

[Donald Eastlake]

Hi Meral,

On Mon, Oct 19, 2015 at 8:02 PM, Meral Shirazipour
 wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
>
>
> Please resolve these comments along with any other Last Call comments you
> may receive.
>
>
> Document: draft-ietf-trill-rfc7180bis-06
> Reviewer: Meral Shirazipour (was originally assigned to another gen-art)
> Review Date: 2015-10-19
> IETF LC End Date:  2015-10-19
> IESG Telechat date: 2015-10-22
>
>
>
> Summary:
>
> This draft is ready to be published as Standards Track RFC but I have some
> comments .

Thanks. See below.

> Major issues:
>
>
> Minor issues:
>
> -[Page 5], Section 1.1: this section updates section 1.2 of RFC6325. The
> update is about conflict resolution between sections of the RFC.
>
> Shouldn't this bis highlight those conflicts if any?

I do not believe there are any real conflicts. RFC 6325 has some
general/introductory sections and some detailed technical sections.
The general sections, particularly Section 2, are written with a
pedagogical goal of giving the reader the best general understanding
and such general sections are not necessarily precise and do not, in
general, include every corner case. During the development of RFC
6325, some reader focused on such general descriptions and claimed
that the "conflicted" with the precise, detailed technical sections.
Thus Section 1.2 was added to RFC6325 to resolve this and make it
clear that the later detailed sections should be followed in case of
any such apparent "conflict".

I don't really remember exactly what motivated making the material
about precedence of sections in RFC 6325 more complete in RFC 7180 but
it was probably based on some comment.

The only change from Section 1.1 of RFC 7180 to this Section 1.1
draft-ietf-trill-rfc7180bis is updating of some other RFC numbers in
this section.

> -[Page 14], Section 3.4. Should this section have a MUST sentence just
> before the last sentence?
>
> "All RBridges in a campus MUST determine distribution trees in the same way
> "

I don't think so. The mandatory implementation of the distribution
tree computation provisions is elsewhere. The sentence you refer to is
just discussion of the consequences of failure to follow that.

> -[Page 10], Section 2.4.2.1 , gives an example, then the first bullet after
> the figure explains the problem with that scenario and says "MUST NOT be
> locally distributed in native form ".
>
> Is it possible to clarify what should be done instead?

This section is about tunneling the frame to a neighbor that is
offering the OOMF service. It could be re-worded a little to use
"instead" rather than "before". The change would be

OLD
  The multi-destination frame MUST NOT be locally distributed in
  native form at RB2 before tunneling to a neighbor because this
  would cause the frame to be delivered twice.

NEW
  The multi-destination frame MUST NOT be locally distributed in
  native form at RB2 because this
  would cause the frame to be delivered twice. Instead it is
tunneling to a neighbor as provided in this section.

> -[Page 11], last line, "forwards the packet on that tree."
>
> Just checking if that is supposed to say "packet" or if it should say
> "frame" or "TRILL Data packet"?

It would be more consistent to say TRILL Data packet.

> Naming ("frame" or "TRILL Data packet") are used throughout,  but it would
> help to mention the convention at the beginning of the draft.

I believe the intent to is use "frame" for native frames to/from end
stations and "TRILL Data packet" or "packet" for TRILL encapsulated
packets between TRILL switches. This convention could be mentioned in
Section 1.3.

> Nits/editorial comments:
>
> -[Page 6], Section 1.3,  "RBridge - An alternative name for a TRILL Switch."
>
> To remain true to RFC7325, better to add Routing Bridge: "RBridge - Routing
> Bridge, an alternative name for a TRILL Switch."

OK.

> -[Page 15], Section 3.6 , "can implemented"--typo-->"can implement"

OK.

> -[Page 16], Section 3.6.1 , "program their hardware tables",
>
> is it assumed that TRILL fast path will only/always be HW based?

There are software implementations of TRILL. Probably better to say
"program their forwarding tables."

> -[Page 17], "RB1 is show with three ports"--typo-->"RB1 is shown with three
> ports"

OK.

> -[Page 34], "then behavior is as specified"---> "the behavior" or "then the
> behavior"

OK.

> -[Page 35], Section 10.2.2, "those capabilites"--typo-->"those capabilities"

OK.

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

> Best Regards,
>
> Meral
>
> ---
>
> Meral Shirazipour
>
> Ericsson
>
> Research
>
> www.ericsson.com

___
Gen-art mailing list
Gen-art@ietf.org

Re: [Gen-art] Gen-ART Review of draft-ietf-trill-pseudonode-nickname-05

[Donald Eastlake]

On Fri, Sep 18, 2015 at 9:49 AM, Jari Arkko  wrote:
> Donald,
>
>>> (Maybe this helps: I’m not actually sure why in a k-element set you order 
>>> them based  mod k because that would seem to produce likely 
>>> duplicates. Since your backup option in the case of duplicates is proper 
>>> numeric sort, why just not do that and only that? E.g. "RBridges are sorted 
>>> in byte string ascending order by their LAALP IDs, or if they are equal, by 
>>> their System IDs considered as unsigned integers.” But it could also be 
>>> that it is too early and I have not yet had enough Diet Coke…)
>>
>> I believe the idea is to quasi-randomize the order. The DF election is
>> per VLAN and a goal is to spread the multicast traffic across the
>> RBridges in the active-active edge group.
>
> It is a fine goal to randomise the order.
>
> My only observation of the current setup is that if you randomise a
> k-element group through "mod k” operation, you will likely have
> some number of collisions in the result. I don’t know enough
> about math to calculate the percentage. But for the sake of
> argument, if k=2 it seems that the likelihood of collision is 50%.
>
> And for every collision, your order becomes no longer random
> but simply numerical order of the identifiers. In our degenerate
> k=2 example it seems that in 50% of the cases you have a random
> order and 50% of the cases you have numerical order. I’m sure
> there would be other ways to randomise the order with less
> collisions, if avoiding numerical order is important.

Well, the way to randomize the order with quite low probability of
collisions is to sort by the hash of  (System IDj | LAALP IDi), for
example SHA-1(System IDj | LAALP IDi). Ties could still be broken by
System ID which is guaranteed to be unique but ties would be quite
rare. This seems like a minor localized change.

> Jari

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

Re: [Gen-art] Gen-ART Review of draft-ietf-trill-pseudonode-nickname-05

[Donald Eastlake]

Hi Jari,

On Thu, Sep 17, 2015 at 9:22 AM, Jari Arkko  wrote:
> Thanks for the in-depth review, Russ! Very much appreciated.
>
> I believe we still has to resolve what to do about the sort order.
>
> (Maybe this helps: I’m not actually sure why in a k-element set you order 
> them based  mod k because that would seem to produce likely 
> duplicates. Since your backup option in the case of duplicates is proper 
> numeric sort, why just not do that and only that? E.g. "RBridges are sorted 
> in byte string ascending order by their LAALP IDs, or if they are equal, by 
> their System IDs considered as unsigned integers.” But it could also be that 
> it is too early and I have not yet had enough Diet Coke…)

I believe the idea is to quasi-randomize the order. The DF election is
per VLAN and a goal is to spread the multicast traffic across the
RBridges in the active-active edge group.

> Also, I am not sure I understand this in Section 5.2:
>
>Assuming there are … k member RBridges in an RBv; ... each RBridge is
>referred to as RBj where 0 <= j < k-1
>
> Wouldn’t that mean that for 2 bridges you have RB0 only, because j=1 does not 
> satisfy 0 <= j < k-1 because 0 <= 1 < 1 is untrue. But again, it is too early 
> here and maybe I’m missing something.

It is interesting that no one else noticed this. I agree it should
either be "... j <= k=1" or "... j < k".

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

> Jari
>

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Review of draft-ietf-trill-pseudonode-nickname-05

[Donald Eastlake]

See below:

On Fri, Sep 11, 2015 at 12:17 PM, Russ Housley  wrote:
> Donald:
>
 Document: draft-ietf-trill-pseudonode-nickname-05
 Reviewer: Russ Housley
 Review Date: 2015-08-24
 IETF LC End Date: 2015-09-01
 IESG Telechat date: unknown

 Summary: Almost Ready

 Major Concerns:

 ...
>>> ...
>>>
 (2)  Also, in Section 5.2, Step 1, I think the intended sort order depends 
 on all
 of the LAALP IDi values being represented with the same number of bits.
 Since Section 9.1 provides a variable length field to carry a LAALP ID 
 value, I
 assume that they are not always the same length.  Is a step needed to
 encode the LAALP ID to a consistent length?
>>>
>>> [MZ] The sort is done in the per-LAALP base. It's not necessary to make the 
>>> LAALP ID to a constant length. Besides, the 'mod' function always returns a 
>>> value in [0, k-1] whatever the length of LAALP ID is.
>>
>> We could add "considering System ID and LAALP ID as byte strings".
>
> I am not sure that is enough unless all of the System IDs are the same length.
>
> Russ

I believe that currently all LAALP IDs are 8-byte System Identifiers
as specified in Clause 6.3.2 of IEEE Std 802.1AX-2014 used for MC-LAGs
or DRNIs; however, there could be other kinds in the future. Perhaps
the draft should say that the LAALP ID needs to be unique across the
TRILL campus, that it is a System Identifier as above if it is
8-bytes, and that the meaning for other length is reserved. But that
doesn't really answer the sort order or mod arithmetic questions.

How about just saying that they are treated as unsigned integers with
the bytes in network order?

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

Re: [Gen-art] Gen-ART Review of draft-ietf-trill-pseudonode-nickname-05

[Donald Eastlake]

Hi Sandra,

On Mon, Aug 31, 2015 at 4:20 PM, Sandra Murphy  wrote:
> On Aug 27, 2015, at 5:59 PM, Russ Housley  wrote:
>
>>
>> (3)  In Section 11, we learn that the VLAN membership of all the
>> RBridge ports in an LAALP MUST be the same.  Any inconsistencies in
>> VLAN membership may result in packet loss or non-shortest paths.
>> Is there anything that can be added to the Security Considerations
>> that can help avoid these inconsistencies?
>
> Interesting.  In the trill draft I recently reviewed for secdir 
> (draft-ietf-trill-aa-multi-attach) it makes a similar statement that VLAN 
> membership had to be consistent across all ports on all RBridges in a LAALP.  
> In that draft, the consistency meant the VLANs could be left out of the 
> protocol packet.

Did you see my response to your secdir review which I send 3 days ago?

>   All enabled VLANs MUST be consistent on all ports connected to an
>   LAALP. So the enabled VLANs need not be included in the AA-LAALP-
>   GROUP-RBRIDGES TRILL APPsub-TLV. They can be locally obtained from
>   the port attached to that LAALP.
>
> I wondered if the LAALP was responsible for ensuring the consistency.  If it 
> is left to the operator configuration, that’s tough.  Turns out there’s a 
> dynamic VLAN registration protocol (VRP), but I could not discover that it is 
> doing a consistency check.
>
> If the draft you are looking at implies inconsistency is a possibility, then 
> it must be that neither the LAALP or VRP ensures the consistency.

As per my previous response to you, as far as I know all existing
LAALPs are proprietary MC-LAG implementations and how they maintain
consistent VLAN enablement on the TRILL switch LAALP ports is out of
scope for the TRILL protocol.

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

> —Sandy

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC review of draft-ietf-trill-loss-delay-05

[Donald Eastlake]

Hi Alexey,

These changes have been made a new version -06 has been posted.

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com


On Mon, Aug 4, 2014 at 1:19 PM, Alexey Melnikov
alexey.melni...@isode.com wrote:
 On 04/08/2014 18:16, Donald Eastlake wrote:

 Hi Alexey,

 Hi Donald,

 On Sun, Aug 3, 2014 at 2:30 PM, Alexey Melnikov
 alexey.melni...@isode.com wrote:

 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq

 Please resolve these comments along with any other Last Call comments you
 may receive.

 Document: draft-ietf-trill-loss-delay-05
 Reviewer: Alexey Melnikov
 Review Date: 3 August 2014
 IETF LC End Date: 21 July 2014
 IESG Telechat date: 7 August 2014

 Summary: This draft is ready for publication as a Standards Track RFC.
 [Ready with nits]

 Major issues: None

 Minor issues:

 Section 6.4: who allocated opcodes? I.e. is there a registry?

 These OAM OpCodes were created by and originally all under the control
 of IEEE 802.1; however, 802.1 allocated the block of 32 OpCodes from
 32 to 63 to ITU-T as documented in [802.1Q]. I don't think ITU-T
 maintains an explicit registry other than the listing of assigned
 OpCodes out of their range that appears in [Y.1731] but I could be
 wrong.

 Perhaps a sentence could be added to the end of Section 6.4 such as
 These OpCodes are from the range of values that has been allocated by
 IEEE 802.1 [802.1Q] for control by ITU-T.

 I think that would be very helpful. Otherwise there is a question why there
 is no IANA registry for these and your extra sentence would address that.

 Nits:

 I think it would be better to say that all Reserved fields are set to 0
 by
 the sender and ignored by the receiver.

 I'll check with the other authors on that.

 Thank you.


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC review of draft-ietf-trill-loss-delay-05

[Donald Eastlake]

Hi Alexey,

On Sun, Aug 3, 2014 at 2:30 PM, Alexey Melnikov
alexey.melni...@isode.com wrote:
 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq

 Please resolve these comments along with any other Last Call comments you
 may receive.

 Document: draft-ietf-trill-loss-delay-05
 Reviewer: Alexey Melnikov
 Review Date: 3 August 2014
 IETF LC End Date: 21 July 2014
 IESG Telechat date: 7 August 2014

 Summary: This draft is ready for publication as a Standards Track RFC.
 [Ready with nits]

 Major issues: None

 Minor issues:

 Section 6.4: who allocated opcodes? I.e. is there a registry?

These OAM OpCodes were created by and originally all under the control
of IEEE 802.1; however, 802.1 allocated the block of 32 OpCodes from
32 to 63 to ITU-T as documented in [802.1Q]. I don't think ITU-T
maintains an explicit registry other than the listing of assigned
OpCodes out of their range that appears in [Y.1731] but I could be
wrong.

Perhaps a sentence could be added to the end of Section 6.4 such as
These OpCodes are from the range of values that has been allocated by
IEEE 802.1 [802.1Q] for control by ITU-T.

 Nits:

 I think it would be better to say that all Reserved fields are set to 0 by
 the sender and ignored by the receiver.

I'll check with the other authors on that.

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

Re: [Gen-art] Gen-ART review of draft-ietf-trill-esadi-06.txt

[Donald Eastlake]

 VLAN tag will not be present for a packet on an
 an Ethernet link that does not use VLAN tags.

 I don't think the word stripped is right, as it would not apply if
 the tag wasn't present in the first place, although I also agree with
 your comment that my suggested use of link isn't right, either.

 Here's another suggestion:

 The outer VLAN tag will not be present if it was not included
 by the Ethernet port that sent the packet.

I agree that stripped is not a very good word to use. I'm OK with
your suggested wording.

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

 Thanks,
 --David

 -Original Message-
 From: Donald Eastlake [mailto:d3e...@gmail.com]
 Sent: Saturday, April 05, 2014 11:23 AM
 To: Black, David
 Cc: zhai.hong...@zte.com.cn; hu.fang...@zte.com.cn; ra...@alum.mit.edu;
 osto...@extremenetworks.com; General Area Review Team (gen-art@ietf.org);
 tr...@ietf.org; i...@ietf.org
 Subject: Re: Gen-ART review of draft-ietf-trill-esadi-06.txt

 Hi David,

 Thanks for this very thorough review. See my responses below:

 On Sat, Mar 29, 2014 at 10:23 PM, Black, David david.bl...@emc.com wrote:
 
  I am the assigned Gen-ART reviewer for this draft. For background on
  Gen-ART, please see the FAQ at
 
  http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
 
  Please resolve these comments along with any other Last Call comments
  you may receive.
 
  Document: draft-ietf-trill-esadi-06.txt
  Reviewer: David L. Black
  Review Date: March 29, 2014
  IETF LC End Date: April 1, 2014
 
  Summary: This draft is on the right track, but has open issues
  described in the review.
 
  This draft revises the ESADI specification for TRILL from its
  original form in RFC 6325.
 
  Major issues:
 
  The draft changes ESADI in a non-backwards-compatible fashion from
  its original specification in RFC 6325, but does not explain why this
  is ok.  That explanation needs to be provided, and if implementations
  of ESADI as originally specified in RFC 6325 exist, that explanation
  needs to encompass coexistence and interoperability (or lack thereof)
  with such implementations.  That explanation probably belongs in
  Section 1.1, and could be expanded upon in Appendix A.

 This was a considered decision of the TRILL WG. At least since the -02
 version in February 2013, the ESADI WG draft has had ESADI-LSP
 provisions that were incompatible with RFC 6325 ESADI for the purpose
 of accomodating orders of magnitude more LSP fragments. This text in
 the draft, which originally used a somewhat ad hoc change from IS-IS
 LSPs to accomodate additional fragments, was posted to the list
 without objection before being incorporated. Since a standard IS-IS
 way of doing this was later in process in the ISIS WG, the ESADI draft
 was changed to follow this more standard way of providing for more LSP
 fragments and a new WG Last Call done in the TRILL WG specifically on
 this issue. See

 http://www.ietf.org/mail-archive/web/trill/current/msg06037.html
 http://www.ietf.org/mail-archive/web/trill/current/msg06009.html

 In Appendix A (Changes to [RFC6325]), how about replacing items 2 and
 3 in the list as follows (includes fixing a typo in item 3):

 OLD
2. The format of ESADI-LSP, ESADI-CSNP, and ESADI-PSNP PDU payloads
   is changed from the base IS-IS format to the Extended Level 1
   Circuit Scoped format in [FS-LSP].
 NEW
2. The format of ESADI-LSP, ESADI-CSNP, and ESADI-PSNP PDU payloads
   is changed from the base IS-IS format to the Extended Level 1
   Circuit Scoped format (E-L1CS) specified in [FS-LSP]. This
   change is not backwards compatible with [RFC6325]. It is made in
   light of (a) the very limited, if any, deployment of [RFC6325]
   ESADI, and (b) the 256 times greater information carrying
   capacity of the E-L1CS format compared with the base IS-IS
   format. It is anticipated that this greater carrying capacity
   will be needed, under some circumstances, to carry end station
   addressing information or other information that is added to
   ESADI in the future.
 OLD
3. Unicasting of ESADI PDUs is supported including replacing Section
   4.6.2.2 of [RFC6325] with the next text give in Section 4.1 of
   this document.
 NEW
3. Unicasting of ESADI PDUs is optionally supported including
   replacing Section 4.6.2.2 of [RFC6325] with the new text give in
   Section 4.1 of this document. This unicast support is backwards
   compatible because it is only used when the recipient RBridge
   signals its support.

 See possible replacement below for the first paragraph of Section 1.1
 that includes a condensed version of this additional material
 concerning backwards non-compatibility.

  Overall, this draft is not self-contained - to a significant extent,
  it is written as if it were effectively a long

Re: [Gen-art] Gen-ART review of draft-ietf-trill-esadi-06.txt

[Donald Eastlake]

Hi David,

Thanks for this very thorough review. See my responses below:

On Sat, Mar 29, 2014 at 10:23 PM, Black, David david.bl...@emc.com wrote:

 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at

 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

 Please resolve these comments along with any other Last Call comments
 you may receive.

 Document: draft-ietf-trill-esadi-06.txt
 Reviewer: David L. Black
 Review Date: March 29, 2014
 IETF LC End Date: April 1, 2014

 Summary: This draft is on the right track, but has open issues
 described in the review.

 This draft revises the ESADI specification for TRILL from its
 original form in RFC 6325.

 Major issues:

 The draft changes ESADI in a non-backwards-compatible fashion from
 its original specification in RFC 6325, but does not explain why this
 is ok.  That explanation needs to be provided, and if implementations
 of ESADI as originally specified in RFC 6325 exist, that explanation
 needs to encompass coexistence and interoperability (or lack thereof)
 with such implementations.  That explanation probably belongs in
 Section 1.1, and could be expanded upon in Appendix A.

This was a considered decision of the TRILL WG. At least since the -02
version in February 2013, the ESADI WG draft has had ESADI-LSP
provisions that were incompatible with RFC 6325 ESADI for the purpose
of accomodating orders of magnitude more LSP fragments. This text in
the draft, which originally used a somewhat ad hoc change from IS-IS
LSPs to accomodate additional fragments, was posted to the list
without objection before being incorporated. Since a standard IS-IS
way of doing this was later in process in the ISIS WG, the ESADI draft
was changed to follow this more standard way of providing for more LSP
fragments and a new WG Last Call done in the TRILL WG specifically on
this issue. See

http://www.ietf.org/mail-archive/web/trill/current/msg06037.html
http://www.ietf.org/mail-archive/web/trill/current/msg06009.html

In Appendix A (Changes to [RFC6325]), how about replacing items 2 and
3 in the list as follows (includes fixing a typo in item 3):

OLD
   2. The format of ESADI-LSP, ESADI-CSNP, and ESADI-PSNP PDU payloads
  is changed from the base IS-IS format to the Extended Level 1
  Circuit Scoped format in [FS-LSP].
NEW
   2. The format of ESADI-LSP, ESADI-CSNP, and ESADI-PSNP PDU payloads
  is changed from the base IS-IS format to the Extended Level 1
  Circuit Scoped format (E-L1CS) specified in [FS-LSP]. This
  change is not backwards compatible with [RFC6325]. It is made in
  light of (a) the very limited, if any, deployment of [RFC6325]
  ESADI, and (b) the 256 times greater information carrying
  capacity of the E-L1CS format compared with the base IS-IS
  format. It is anticipated that this greater carrying capacity
  will be needed, under some circumstances, to carry end station
  addressing information or other information that is added to
  ESADI in the future.
OLD
   3. Unicasting of ESADI PDUs is supported including replacing Section
  4.6.2.2 of [RFC6325] with the next text give in Section 4.1 of
  this document.
NEW
   3. Unicasting of ESADI PDUs is optionally supported including
  replacing Section 4.6.2.2 of [RFC6325] with the new text give in
  Section 4.1 of this document. This unicast support is backwards
  compatible because it is only used when the recipient RBridge
  signals its support.

See possible replacement below for the first paragraph of Section 1.1
that includes a condensed version of this additional material
concerning backwards non-compatibility.

 Overall, this draft is not self-contained - to a significant extent,
 it is written as if it were effectively a long collection of errata
 to the ESADI specification in RFC 6325. That makes it difficult to
 understand - it would be better if this draft completely obsoleted
 and replaced the ESADI specification in RFC 6325, describing its
 changes, instead of providing specific text changes to portions of
 the RFC 6325 text.

All of the changes to ESADI are described in Appendix A.

If the ESADI related material in RFC 6325 was entirely contained in
one contiguous area of RFC 6325, it would have been easy to write this
draft as simply obsoleting and replacing that area of RFC 6325.  The
largest such monolithic block on ESADI in RFC 6325 is Section 4.2.5
(The TRILL ESADI Protocol), including its two subsections (4.2.5.1
TRILL ESADI Participation and 4.2.5.2 TRILL ESADI Information). All
of that is obsoleted and replaced by this draft.  However, there are
other non-contiguous parts of RFC 6325 necessarily affected. For
example, Section 4.6 of RFC 6325 describes how to handle every
possible type of frame that might be received; since an ESADI PDU is
one such type of frame, it is necessary to change Section 4.6.2.2
(TRILL ESADI Frames) of RFC 6325.

There is really no 

Re: [Gen-art] Gen-ART review of draft-ietf-isis-rfc6326bis-01

[Donald Eastlake]

Hi Jari,

On Tue, Jan 21, 2014 at 5:01 PM, Jari Arkko jari.ar...@piuha.net wrote:
 Thanks for your review, Alexey! And thank you Donald for considering the 
 comments. I have placed a no-obj position on the ballot for this Thursday's 
 IESG telechat. But I do think Alexey raised valid points and I expect the 
 draft to be revised. Will you take care of that, Donald?

I have a version ready to post with some minor editorial fixes and the
like and would be happy to include the missing reference to
draft-ietf-trill-fine-labeling; however, I would prefer not to include
the somewhat hand-waving text I wrote about TRILL protocol version
number and I am not sure how long it would take to come up with a good
statement on that...

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

 Jari

 On Jan 20, 2014, at 8:11 PM, Alexey Melnikov alexey.melni...@isode.com 
 wrote:

 Hi Donald,

 On 20/01/2014 16:45, Donald Eastlake wrote:
 Hi Alexey,

 Thanks for your review, see below:

 On Mon, Jan 20, 2014 at 6:12 AM, Alexey Melnikov
 alexey.melni...@isode.com wrote:
 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

 Please resolve these comments along with any other Last Call
 comments you may receive.

 Document: draft-ietf-isis-rfc6326bis-01
 Reviewer: Alexey Melnikov
 Review Date: 2014-01-20
 IETF LC End Date: 2014-01-22
 IESG Telechat date: 2014-01-23


 Summary: This draft is nearly ready for publication as a standard track 
 RFC.

 Major issues: None

 Minor issues:

 o  Label: This carries the fine-grained label identifier for all
   subsequent MAC addresses in this sub-TLV, or the value zero if no
   label is specified.

 I fully admit ignorance of the topic, but what is exactly
 fine-grained label and where is the exact format defined? If it is
 defined later in the document, can you please add a forward
 reference. If it is defined in another document, can you please add
 a reference to that.
 Fine grained labels are specified in draft-ietf-trill-fine-labeling-07,
 which is an approved standard track draft in the RFC Editor's
 queue. Adding a reference to it here would be good.
 Sounds great. Thanks.
 In Sections 2.2.4 and 2.3.1:

 What are the requirements on backward compatibility between different
 versions of TRILL. Are TLVs formats supported for a version N also valid 
 for
 version N+M? If you have any implied assumptions, please state them in the
 document.
 There are no explicit requirements. Incremental changes and
 improvements are generally handed with capability bits or the
 presence/absence of data strucutres in control messages. A version
 change would probably indicate a pretty major modification but, since
 these version numbers are within IS-IS TLVs, I would say that
 implicitly the intent is to stay with the IS-IS PDU structure for the
 control plane.
 I think the document should state that. Also, if you want any messages to be 
 unchanged (fully or partially) irrespectively of version numbers, you should 
 state that too.

 Best Regards,
 Alexey

 ___
 Gen-art mailing list
 Gen-art@ietf.org
 https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-ietf-isis-rfc6326bis-01

[Donald Eastlake]

Hi Alexey,

Thanks for your review, see below:

On Mon, Jan 20, 2014 at 6:12 AM, Alexey Melnikov
alexey.melni...@isode.com wrote:
 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

 Please resolve these comments along with any other Last Call
 comments you may receive.

 Document: draft-ietf-isis-rfc6326bis-01
 Reviewer: Alexey Melnikov
 Review Date: 2014-01-20
 IETF LC End Date: 2014-01-22
 IESG Telechat date: 2014-01-23


 Summary: This draft is nearly ready for publication as a standard track RFC.

 Major issues: None

 Minor issues:

 o  Label: This carries the fine-grained label identifier for all
   subsequent MAC addresses in this sub-TLV, or the value zero if no
   label is specified.

 I fully admit ignorance of the topic, but what is exactly
 fine-grained label and where is the exact format defined? If it is
 defined later in the document, can you please add a forward
 reference. If it is defined in another document, can you please add
 a reference to that.

Fine grained labels are specified in draft-ietf-trill-fine-labeling-07,
which is an approved standard track draft in the RFC Editor's
queue. Adding a reference to it here would be good.

 In Sections 2.2.4 and 2.3.1:

 What are the requirements on backward compatibility between different
 versions of TRILL. Are TLVs formats supported for a version N also valid for
 version N+M? If you have any implied assumptions, please state them in the
 document.

There are no explicit requirements. Incremental changes and
improvements are generally handed with capability bits or the
presence/absence of data strucutres in control messages. A version
change would probably indicate a pretty major modification but, since
these version numbers are within IS-IS TLVs, I would say that
implicitly the intent is to stay with the IS-IS PDU structure for the
control plane.

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

 Nits/editorial comments: None
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-art Yuletide LC review of draft-ietf-trill-rfc6327bis-02.txt

[Donald Eastlake]

Hi Elwyn,

Seasons Greetings!

On Mon, Dec 23, 2013 at 5:00 PM, Elwyn Davies elw...@dial.pipex.com
wrote:
 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at

 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

 Please resolve these comments along with any other Last Call comments
 you may receive.

 Document: draft-ietf-trill-rfc6327bis-02.txt
 Reviewer: Elwyn Davies
 Review Date: 23 December 2013
 IETF LC End Date: 23 December 2012
 IESG Telechat date: (if known) -

 Summary:
 Almost ready for the IESG.  There is one minor issue that seems as
 if it needs a better way to explain how the defense against rogue
 native packets is supposed to work and a number of nits.  Apologies

It’s not actually defense “against rogue native packets” but defense
against a native packet being multiply ingressed or egressed...

 if the festive spirit got the better of a few comments.

No apologies needed...

 Major issues:
 None.

  Thanks.

 Minor issues:
 s2.2, last para:
The primary TRILL defense mechanism against such loops, which is
mandatory, is to assure that, as far as practically possible,
there is only a single RBridge that is in charge of ingressing
and egressing native frames...
 This seems to be difficult to implement: Implementing some defense
 mechanism is stated to be mandatory but the proposed defense is at
 best, best efforts.  It strikes me that given the expected
 catastrophic results of failure to have a robust defense, as
 delineated in the previous para, indicates that this either needs
 some better explanation or possibly a better defense.  I can't tell,
 but I guess we may be talking about some extraneous measure beyond
 this spec - please explain.

  The mandatory mechanism is explained in greatest detail in RFC
  6439. Perhaps the references to that RFC should be stronger and
  clearer. (It requires very peculiar and unlikely events for there to
  be a problem and, while such a problem will be bad, it will be
  transient - cleared up as soon as Hellos are exchanged on the link.)


 Nits/editorial comments:
 General: Adding titles/caption to figures and tables would be helpful.

  OK.


 General: s/byte/octet/

  I would agree that it is important for this to be consistent within
  the document. There seem to currently be 2 occurrences of octet
  and 12+ occurrences of byte. Also, byte seems to be the preferred
  term for IS-IS TLV sub-field diagrams. So, I would prefer to change
  the two occurrences of octet to byte.


 Abstract: s/IS-IS adjacency between/IS-IS adjacencies between/
 s1, para 1: multipathing?? horrid non-word!!  Suggest:
 OLD:
 support for multipathing of both unicast and multicast traffic in
multi-hop networks with arbitrary topology.
 NEW:
 support for transmission of both unicast and multicast traffic
 taking advantage of multiple paths in multi-hop networks with
 arbitrary topology.

  OK.


 s1, para 1: 'and a header that includes a hop count': A header for
 what?  Please make it clear what the header is added to.

  a header - a header in TRILL data packets


 s1, para 1, next to last sentence: Has two 'ands'
 Suggest s/and optimization/as well as optimization/

  OK.


 s1, table: Probably worth expanding BFD again (even though it is
 in the abstract and terminology).

  OK.


 s1: Definition and explanation of 'pseudonode': There is no
 explanation of the pseudonode term until s7 - and even there it is
 buried a couple of paras down in the text.  A definition/explanation
 either in s1 or s1.2 would be helpful.

  pseudonode is a fundamental concept of IS-IS and I'm really not
  sure that it should be the role of this draft to explain it. I can
  add a reference to ISO 10589 after the first occurrence of
  pseudonode in Section 1.


 s2.1, para 1, sentence 2: This sentence is difficult to parse: After
 two or three reads, I realized that the material starting at
 'devices or services' is not part of the 'includes' and ceased
 looking for an 'and'.  Suggest reversing the components of the main
 body thus:
 OLD:
Because this includes general bridged LANs
[802.1Q], devices or services that can restrict VLAN connectivity,
such as [802.1Q] bridges or carrier Ethernet services, can be part of
a link between RBridges.
 NEW:
Because this includes general bridged LANs
[802.1Q], the links between RBridges may contain devices or services that
can restrict VLAN connectivity, such as [802.1Q] bridges or carrier
Ethernet services.

  OK, I think that's an improvement.


 s2.4, para 1: s/reasonably restricted MTU/relatively restricted MTU/

  I think it really means that the restriction of MTU is reasonable,
  as opposed to unreasonable.


 s3.3, Event A4: I was initially slightly confused as to how one timer
 expiring resulted in both being expired in the broadcast case.  Maybe
 reword a bit:
 OLD:
   A4. Either (1) the Hello holding timer expires on a point-to-point
 

Re: [Gen-art] Gen-ART review of draft-ietf-trill-o-pw-03

[Donald Eastlake]

Hi Christer,

Thanks for this review. See below.

On Saturday, December 14, 2013, Christer Holmberg wrote:

  I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at 
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq

 Document: draft-ietf-trill-o-pw-03.txt

 Reviewer:   Christer Holmberg

 Review Date: 14 December 2013

 IETF LC End Date: 23 December 2013

 IETF Telechat Date: N/A



 Summary:  The document is well written, and the document is almost ready
 for publication. Below I have a minor editorial comment.



 Major Issues: None



 Minor Issues: None



 Editorial nits:



 Section 1 (Introduction):



 The first sentence begins with:



 ” The IETF has standardized…”



 I don’t think that’s needed.



 I suggest to simply say something like:



  “The TRILL (Transparent Interconnection of

  Lots of Links) protocol [RFC6325] provides
 optimal pair-wise

  data frame routing without configuration in
 multi-hop networks with

  arbitrary topology.”

 OK. I see no problem with that change.

Thanks,
Donald



-- 
Sent from Gmail Mobile
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] review of draft-ietf-trill-oam-framework-03.txt

[Donald Eastlake]

Hi,

Thanks for the review. Below are my responses. Hopefully my co-authors
will agree.

On Mon, Nov 25, 2013 at 9:25 AM, Francis Dupont
francis.dup...@fdupont.fr wrote:
 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at

 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

 Please resolve these comments along with any other Last Call comments
 you may receive.

 Document: draft-ietf-trill-oam-framework-03.txt
 Reviewer: Francis Dupont
 Review Date: 20131120
 IETF LC End Date: 20131126
 IESG Telechat date: unknown

 Summary: Ready

 Major issues: None

 Minor issues: None

 Nits/editorial comments:
  - ToC page 3 and 9 page 30: Acknowledgements - Acknowledgments

OK.

  - 1.1 page 5 (ECMP): Pathing - Path

OK.

  - 2.1 page 6 and many other places: e.g. - e.g.,
   (and i.e. - i.e., too... First at 2.4 page 12)

Actually, I don't think the RFC Editor likes Latin acronyms so it
might be better to replace e.g. with for example as well as adding
a common after it and either replace i.e. with such as or just
drop it. I think all the cases where i.e. occurs immediately after
an open parenthesis can just be dropped...

  - 2.6 page 12: ask the RFC Editor to manage to get the title not
   at the very end of the page

Yeah...

  - 6.1.5 and 6.1.6 page 26: in group item titles you put / and ,
   separators, for instance:
- VLAN / Fine grain label / Flow parameters
   and
- Target RBridge Nickname (unicast), Tree Identifier (Multicast) and
IP multicast group
   Is there a good reason? And BTW the IP multicast group is for the
   multicast case. Note my comment is only about the wording: the spec
   is very easy to understand.

I don't think there is any special reason. Probably VLAN / Fine grain
label / Flow parameters should be replaced with VLAN, Fine grain
label, and Flow parameters.

  - 6.1.7 page 27 (and 6.1.8 page 28): in Repeat Count
   For proactive monitoring this may be set to allow for infinite
monitoring.
   what is the recommended value to set the counter (or with other words
   how is encoded the infinite)?

This is an informational high level framework document. I believe that
specific encoding issues are to be addressed in the standards track
protocol documents such as draft-ietf-trill-oam-loss-delay in this
case.

  - 10.2 page 31 (TRILL-BFD): Interconnetion - Interconnection
   (Note the spelling error is in the referenced I-D itself but
it has at least one common author)

:-) we can fix that here. Hopefully the RFC Editor will fix it in the
referenced ID. I'll send them a message. I believe they have a
facility for buffering editorial comments on drafts in the RFC
Editor's queue until they get to editing them.

 Regards
 francis.dup...@fdupont.fr

 PS: my spell checker insists about congruency (the correct term is
 congruence) and IMHO it is right...

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

Re: [Gen-art] Gen-ART review of draft-ietf-trill-directory-framework-05

[Donald Eastlake]

Hi David,

Thanks for the review. See responses below.

On Wed, Jul 17, 2013 at 7:54 PM, Black, David david.bl...@emc.com wrote:
 Document: draft-ietf-trill-directory-framework-05
 Reviewer: David L. Black
 Review Date: July 17, 2013
 IETF LC End Date: July 18, 2013

 Summary:
 This draft is on the right track but has open issues, described in the review.

 This draft describes a framework for using directory servers to provide
 address mappings (address - destination RBridge) to TRILL Rbridges as an
 alternative to data plane learning and use of the TRILL ESADI protocol.

 The draft's generally well written and clear.  I found a couple of minor
 issues.

Thanks.

 Major issues: None.

 Minor issues:

 [1] The last bullet in Section 3.1 says:

- In an environment where VMs migrate, there is a higher chance
  of cached information becoming invalid, causing traffic to be
  black-holed by the ingress RBridge, that is, persistently sent
  to the wrong egress RBridge. If VMs do not flood gratuitous
  ARP/ND or VDP [802.1Qbg] messages upon arriving at new
  locations, the ingress nodes might not have MAC entries for the
  MAC of the newly arrived VMs, causing unknown address flooding.

 This is incorrect in multiple ways and should just be removed:

OK.

 - Persistent black-holing is rare in practice because all common
 VM migration implementations issue the gratuitous messages.
 - VMs don't send the gratuitous messages, hypervisors do.
 - VDP is not flooded.  The receiver's always a bridge.
 - At least one common VM migration implementation actually uses a gratuitous
 RARP, not ARP.
 - Flooding is done by the bridges and Rbridges, not the VMs.

 [2] There are some unfortunate notation problems in Section 5.1 that carry
 into the following sections, based on the logical data structure:

[{IP, MAC/VLAN, {list of attached RBridge nicknames}, {list of
interested RBridges}]

 - The first open curly brace ('{') is unmatched.
 - Subsequent text uses [IP or MAC/VLAN], IP/MAC/VLAN and MACVLAN,
 none of which appear in that structure.

We'll try to clean that up.

 Nits/editorial comments:

 Section 1 - item 1 in the numbered list does not explain why it makes
 a directory approach attractive.  This should be added, as it is
 present for the other three items .

I suggest combining point 1 with the material just before the table
and re-numbering points 2-4 to be 1-3.

 Section 2 - Say that IS-IS is a routing protocol.
 The definition of Station should say that the node or virtual node
 is on a network.  Also, please define or explain virtual node.

OK on the first two points. On virtual node, that is only used in
the definition of station which is different from the definition of
end station. However, looking through the document, there was only
one instance of station without end before it and that instance
was talking about end stations. So I propose to remove the definition
of station and to insert end before the one occurrence of
station in the body of the document not already preceded by end.

 Section 3.2 - Add the number of entries to be learned to scenario #1
 in order to parallel the scenario # 2 discussion.

OK.

 Section 4 - remove (distributed model) from first paragraph,
 as it's not explained.

OK.

 Section 5.3, top of p.13:

therefore, there needs to be some mechanism by which RBridges that
have pulled information that has not expired can be informed when
that information changes or the like.

 or the like is vague.  I suggest or becomes invalid for other
  reasons.

OK.

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

 idnits 2.12.17 didn't find any nits that need attention.

 Thanks,
 --David
 
 David L. Black, Distinguished Engineer
 EMC Corporation, 176 South St., Hopkinton, MA  01748
 +1 (508) 293-7953 FAX: +1 (508) 293-7786
 david.bl...@emc.comMobile: +1 (978) 394-7754
 
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-eastlake-rfc5342bis-03

[Donald Eastlake]

Hi David,

On Sun, Jun 9, 2013 at 1:47 PM, Black, David david.bl...@emc.com wrote:
 The -03 version of this draft resolves all of the concerns raised by
 the Gen-ART review of the -02 version.

Thanks.

 Unfortunately, a serious typo/thinko snuck into the -03 version (been
 there, done that, myself).  Section 3.2 currently says:

00-42 is a protocol number under the IANA OUI (that is,
00-00-0E-00-42) to be used for documentation purposes.

 The parenthetical expansion of the protocol number is incorrect.
 The correct expansion uses -5E- instead of -0E-:

My apologies, you are correct. However, I believe that, in context,
the typo is pretty obvious.

00-42 is a protocol number under the IANA OUI (that is,
00-00-5E-00-42) to be used for documentation purposes.

 I strongly suggest submitting a -04 version of this draft to make
 the necessary single character correction (e.g., as opposed to using
 a RFC Editor Note for that purpose).

I defer entirely to JoelJaeggli, the sponsoring AD.

I'd be happy to submit a -04 or it seems to me it could easily be
fixed with an RFC Editor Note or at AUTH48 time. (Actually, it seems
likely to me that during IESG consideration, some other change will be
decided on and this can be fixed at the same time.)

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

 Thanks,
 --David

 -Original Message-
 From: Black, David
 Sent: Wednesday, June 05, 2013 6:13 PM
 To: d3e...@gmail.com; joe.ab...@icann.org; General Area Review Team
 Cc: Black, David; joe...@bogus.com; i...@ietf.org
 Subject: Gen-ART review of draft-eastlake-rfc5342bis-02

 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at

 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

 Please resolve these comments along with any other Last Call comments
 you may receive.

 Document: draft-eastlake-rfc5342bis-02
 Reviewer: David L. Black
 Review Date: June 5, 2013
 IETF LC End Date: June 4, 2013

 Summary:
 This draft is on the right track but has open issues, described in the 
 review.

 This draft updates the IANA registered Ethernet parameters for IETF use,
 including recording values assigned for documentation.  It also makes some
 minor changes to IANA procedures.

 IANA should review this entire draft, not just its IANA Considerations
 section;
 Pearl Liang appears to have done that comprehensive review for IANA.

 Major issues: None

 Minor issues: One, the IANA review also found this issue.

 Section 3.2 states:

   IANA will assign 00-00-0E-00-42 as the protocol number under the
   IANA OUI to be used for documentation purposes.

 IANA has not made this assignment, but this assignment request is not
 recorded in the IANA Considerations section where IANA actions are
 requested and recorded by IANA after they have been performed.  This
 assignment needs to be added to the IANA Considerations section;
 see item 5 in the IANA review.

 Nits/editorial comments:

 Section 1: This document uses an IESG Ratification process for some
 assignments.  This is not the same process as the IESG Approval process
 defined in RFC 5226.  As those names could be confused by a casual reader
 who is not strongly familiar with IANA processes, I suggest adding a
 statement that the IESG Ratification process is defined in this document
 and is not the same as the IESG Approval process in RFC 5226.  This could
 be added after the sentence that cites RFC 5226.

 Section 1.4: It would be helpful to point out that there is no OUI assigned
 for documentation purposes, but there are identifiers based on the IANA OUI
 that have been assigned for documentation purposes.

 In general, the use of the acronym IAB for Individual Address Block is
 unfortunate, but unavoidable, and this is clearly pointed out in the
 definition of the IAB acronym in section 1.2.  Nothing can or should be
 done about this.

 idnits 2.12.17 did not find any nits.

 Thanks,
 --David
 
 David L. Black, Distinguished Engineer
 EMC Corporation, 176 South St., Hopkinton, MA  01748
 +1 (508) 293-7953 FAX: +1 (508) 293-7786
 david.bl...@emc.comMobile: +1 (978) 394-7754
 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Telechat Call review of draft-ietf-trill-clear-correct-04

[Donald Eastlake]

Hi Meral,

On Tue, Jul 3, 2012 at 12:18 PM, Meral Shirazipour
meral.shirazip...@ericsson.com wrote:
 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
 please see the FAQ at  
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

 Please wait for direction from your document shepherd or AD before posting a 
 new version of the draft.

 Document: draft-ietf-trill-clear-correct-04
 Reviewer: Meral Shirazipour
 Review Date: 2012-07-03
 IETF LC End Date: 2012-06-20
 IESG Telechat date: 2012-07-05

 Summary: This draft is ready for publication as a Proposed Standard but I 
 have some last editorial comments.

 Major issues:
 -none

 Minor issues:
 -none

 Nits/editorial comments:
 -Consistency with RFC6325, [Page 18], below the table, end station service 
 disable bit --missing dash-- end-station service disable bit

OK.

 -Consistency: Acronyms are usually spelled out, then followed by the acronym 
 in parenthesis [when first used]. On few occasions this has been reversed, 
 ex. check for:
 EISS (Enhanced Internal Sublayer Service), DRB (Designated RBridge) vs 
 Reverse Path Forwarding Check (RPFC)

OK. I think acronym followed by spelling out in parenthesis is
probably best for uniform format.

 -Informative References, Ref. [802], please if you get a chance verify again 
 the date of this document :)
 I checked again on the version freely available at 
 http://standards.ieee.org/about/get/802/802.html, it says 7 February, 2002. 
 I could not find anything dated 8 March, 2002.

IEEE 802 distributes a CD of all of its standards to all of its active
members (I believe to all the voting members of all of its working
groups) each year in November. (Actually, they are physically handed
out at the November 802 plenary meeting but if you qualify you can
pick it up at a later meeting if you don't attend the November meeting
or forget to pick it up there.) Under separate cover, I will send to
you the pdf for IEEE Std 802-2001 from the CD that was distributed to
me in November 2011. It says 8 March 2002 on the title page (and
Approved 6 December 2001 on the next page).

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

 Thanks,
 Meral

 ---
 Meral Shirazipour
 Ericsson
 Research
 www.ericsson.com
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Fwd: Gen-ART Last Call review of draft-ietf-trill-clear-correct-03.txt

[Donald Eastlake]

Hi Meral,

A real response this time...

Thanks for your thorough review. See below:

On Tue, Jun 19, 2012 at 11:51 AM, Meral Shirazipour
meral.shirazip...@ericsson.com wrote:
 I am the assigned Gen-ART reviewer for
 draft-ietf-trill-clear-correct-03.txt. For background on Gen-ART, please see
 the FAQ at http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html.

 Please resolve these comments along with any other Last Call comments you
 may receive.


 Document: draft-ietf-trill-clear-correct-03
 Reviewer: Meral Shirazipour
 Review Date: June-18-2012
 IETF LC End Date: June-20-2012
 IESG Telechat date: June-21-2012


 Summary:
 The document is ready for publication as a standards track RFC, however I
 have a few comments.

Thanks.

 Minor issues:

 TRILL-PORT-VER sub-TLV should be PORT-TRILL-VER sub-TLV.(there are a few
 occurrences)

Yes, thanks for spotting that.

 Nits/editorial comments:

 - Suggestion: [Page 6], line 2, spell out first occurrence LSP

OK.

 - Suggestion: [Page 6], line 5, overload bit on  overload bit set

OK.

 - Clarification:[Page 6], Section 2.1, line 5, add a comma , after
 traffic engineered frames

OK.

 - Typo:[Page 6], last word, contain --missing s-- contains

I believe the current wording is correct.

 - Suggestion: [Page 7], Section 2.2, line 2, spell out first occurrence of
 Reverse Path Forwarding Check and then use RPFC in the rest of the
 document.

It depends a little on the context but  agree that most can be changed to RPFC.

 - Clarification:[Page 10], Section 2.4.2.3, line 5, sentence starting with
 RB2 MUST advertise ...: we could omit the second occurrence of it might
 use in that sentence.

OK.

 - Clarification:[Page 10], Section 2.4.2.3, 3rd line from last, end
 stations connected to RB: a RB or RBs?

Should be end stations connected to RB3.

 - Typo: [Page 11], Section 3.1,( j, k) --remove extra space-- (j, k)

OK.

 - Suggestion: [Page 11], Section 3.2, already in flight  already in
 transmission

I think the current wording is better.

 - Typo [Page 12]:many multi-destination frame--missing s-- many
 multi-destination frames

OK.

 - Clarification:[Page 13], Point 4. , Sentence 2: suggested clarification:

 It does so by checking LSPs it receives and updating its link state
 database for any of its nicknames held with higher priority by another TRILL
 Switch that is IS-IS reachable.

I have no problem dropping in so it says ...checking LSPs...
rather than ...checking in LSPs... but I think the rest of the
change you suggest makes it slightly wrong and so would prefer to keep
the rest of the wording of that sentence.

 - Typo [Page 14]:unicast Channel message--missing s--unicast Channel
 messages

OK.

 - Typo [Page 16]: Section 5.2,Routeing  Routing

The spelling used in the ISO 10589:2002 standard's title and the
naming of this field therein includes the e.

 - Suggestion:[Page 16],last sentence, suggestion: This safety margin is
 called Margin below.

OK.

 - Typo [Page 18]:a specified in [RFC6325]--missing s--as specified in
 [RFC6325]

OK.

 - Suggestion: [Page 19], spell out first occurrence of EISS

OK.

 - Suggestion:[Page 21], Point 1, not clear what the new text becomes.
 Suggestion: refer to last paragraph of section 3.1 instead of paragraph
 before 3.2, and propose the new sentence.

OK.

 - Clarification:[Page 21], Point 2, it is not clear what the change is to
 section 3.2 of RFC6327.

OK.

 - Clarification:[Page 21], Point 3, it would be clearer to say bullet A9 is
 added (if this is an event like the rest of the bullets in section 3.3 of
 RFC6327)

Guess this does need clarification as its not an event, its a o
... type bullet item after the list of events. I'll clarify.

 - Clarification:[Page 22], section 10.1,disagreement over the Designated
 VLAN or the like. Suggestion: replace the term or the like with other
 examples or remove the term.

How about replacing ... in the face of partitioned VLANs or
disagreement over the Designated VLAN or the like in a link. with
... in the face of decreased VLAN connectivity in a link such as
partitioned VLANs, many VLANs disabled on ports, or disagreement over
the Designated VLAN.

 -Typo: [Page 22], section 10.1, each others frameseach other's
 frames

OK.

 -Typo: [Page 24], DRB SHOULD NOT appointedDRB SHOULD NOT appoint,
 an VLANa VLAN, RBridgedRBridge

OK.

 -Clarification:[Page 25], Section 11, Point 1, The previously reserved,
 reference to document.

OK. The block of nicknames from 0xFFC0 through 0xFFFE is reserved by
the TRILL base protocol document [RFC6325].

 - Clarification: [page 19/page 27], Informative References, reference [802],
 to verify which standard we want to refer to for Canonical Format Indicator:

 If it is IEEE Std 802-2001: IEEE Standard for Local and Metropolitan Area
 Networks: Overview and Architecture, then the date should be 7 February
 2001.

All copies I have seen clearly say 8 March 2001 on the cover.

 However this specific document does 

Re: [Gen-art] Gen-ART review of draft-ietf-trill-rbridge-channel-06.txt

[Donald Eastlake]

Hi Miguel,

On Tue, Jun 19, 2012 at 3:26 AM, Miguel A. Garcia
miguel.a.gar...@ericsson.com wrote:
 I have been selected as the General Area Review Team (Gen-ART)
 reviewer for this draft. For background on Gen-ART, please see the FAQ at
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq

 Please resolve these comments along with any other comments you may receive.

 Document: draft-ietf-trill-rbridge-channel-06.txt
 Reviewer: Miguel Garcia miguel.a.gar...@ericsson.com
 Review Date: 2012-06-19
 IETF LC End Date: 2012-06-20
 IESG Telechat date: 2012-06-21

 Summary: This document is ready for publication as a standards track RFC

 Major issues: none

 Minor issues: none

 Nits/editorial comments:

 The document is well written and easy to read. Congratulations to the
 authors.

Thanks.

 I have some minor editorial comments.

 - All the figures that represent bits on the wire do not follow the
 convention of numbering the bits. I would suggest to add the bit number as
 per the RFC style guide. This means adding these two lines to most figures
 in the document:


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

OK. I believe there are two figures where this should be added.

 - Also, related to figures. I would suggest to add a caption to each figure,
 for example, under the figure in Section 2.1:

      Figure 2: RBridge Channel Message inner frame

 This allows other documents to easily refer to the figure by number (e.g.,
 Figure 2 in RFC ).

OK.

 - Section 2.1.1: s/species/specifies

Thanks for spotting that.

 - Section 4. There are 5 bullet points. Something is wrong with the
 indentation of the third bullet point.

OK.

Thanks for the review,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

 /Miguel
 --
 Miguel A. Garcia
 +34-91-339-3608
 Ericsson Spain
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-trill-clear-correct-03.txt

[Donald Eastlake]

Hi Meral,

Thanks for your review. See below:

On Tue, Jun 19, 2012 at 11:51 AM, Meral Shirazipour
meral.shirazip...@ericsson.com wrote:
 I am the assigned Gen-ART reviewer for
 draft-ietf-trill-clear-correct-03.txt. For background on Gen-ART, please see
 the FAQ at http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html.

 Please resolve these comments along with any other Last Call comments you
 may receive.


 Document: draft-ietf-trill-clear-correct-03
 Reviewer: Meral Shirazipour
 Review Date: June-18-2012
 IETF LC End Date: June-20-2012
 IESG Telechat date: June-21-2012


 Summary:
 The document is ready for publication as a standards track RFC, however I
 have a few comments.



 Minor issues:

 TRILL-PORT-VER sub-TLV should be PORT-TRILL-VER sub-TLV.(there are a few
 occurrences)




 Nits/editorial comments:

 - Suggestion: [Page 6], line 2, spell out first occurrence LSP



 - Suggestion: [Page 6], line 5, overload bit on  overload bit set



 - Clarification:[Page 6], Section 2.1, line 5, add a comma , after
 traffic engineered frames



 - Typo:[Page 6], last word, contain --missing s-- contains



 - Suggestion: [Page 7], Section 2.2, line 2, spell out first occurrence of
 Reverse Path Forwarding Check and then use RPFC in the rest of the
 document.



 - Clarification:[Page 10], Section 2.4.2.3, line 5, sentence starting with
 RB2 MUST advertise ...: we could omit the second occurrence of it might
 use in that sentence.



 - Clarification:[Page 10], Section 2.4.2.3, 3rd line from last, end
 stations connected to RB: a RB or RBs?



 - Typo: [Page 11], Section 3.1,( j, k) --remove extra space-- (j, k)



 - Suggestion: [Page 11], Section 3.2, already in flight  already in
 transmission



 - Typo [Page 12]:many multi-destination frame--missing s-- many
 multi-destination frames



 - Clarification:[Page 13], Point 4. , Sentence 2: suggested clarification:

 It does so by checking LSPs it receives and updating its link state
 database for any of its nicknames held with higher priority by another TRILL
 Switch that is IS-IS reachable.



 - Typo [Page 14]:unicast Channel message--missing s--unicast Channel
 messages



 - Typo [Page 16]: Section 5.2,Routeing  Routing



 - Suggestion:[Page 16],last sentence, suggestion: This safety margin is
 called Margin below.



 - Typo [Page 18]:a specified in [RFC6325]--missing s--as specified in
 [RFC6325]



 - Suggestion: [Page 19], spell out first occurrence of EISS



 - Suggestion:[Page 21], Point 1, not clear what the new text becomes.
 Suggestion: refer to last paragraph of section 3.1 instead of paragraph
 before 3.2, and propose the new sentence.



 - Clarification:[Page 21], Point 2, it is not clear what the change is to
 section 3.2 of RFC6327.



 - Clarification:[Page 21], Point 3, it would be clearer to say bullet A9 is
 added (if this is an event like the rest of the bullets in section 3.3 of
 RFC6327)



 - Clarification:[Page 22], section 10.1,disagreement over the Designated
 VLAN or the like. Suggestion: replace the term or the like with other
 examples or remove the term.



 -Typo: [Page 22], section 10.1, each others frameseach other's
 frames



 -Typo: [Page 24], DRB SHOULD NOT appointedDRB SHOULD NOT appoint,
 an VLANa VLAN, RBridgedRBridge



 -Clarification:[Page 25], Section 11, Point 1, The previously reserved,
 reference to document.



 - Clarification: [page 19/page 27], Informative References, reference [802],
 to verify which standard we want to refer to for Canonical Format Indicator:

 If it is IEEE Std 802-2001: IEEE Standard for Local and Metropolitan Area
 Networks: Overview and Architecture, then the date should be 7 February
 2001.

 However this specific document does not define CIF. You may want to refer to
 802.1Q-2005.

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

 Thanks,
 Meral


 ---
 Meral Shirazipour
 Ericsson
 Research
 www.ericsson.com
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-trill-clear-correct-03.txt

[Donald Eastlake]

Sorry, ignore below, hit send by mistake

On Tue, Jun 19, 2012 at 2:18 PM, Donald Eastlake d3e...@gmail.com wrote:
 Hi Meral,

 Thanks for your review. See below:

 On Tue, Jun 19, 2012 at 11:51 AM, Meral Shirazipour
 meral.shirazip...@ericsson.com wrote:
 I am the assigned Gen-ART reviewer for
 draft-ietf-trill-clear-correct-03.txt. For background on Gen-ART, please see
 the FAQ at http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html.

 Please resolve these comments along with any other Last Call comments you
 may receive.


 Document: draft-ietf-trill-clear-correct-03
 Reviewer: Meral Shirazipour
 Review Date: June-18-2012
 IETF LC End Date: June-20-2012
 IESG Telechat date: June-21-2012


 Summary:
 The document is ready for publication as a standards track RFC, however I
 have a few comments.



 Minor issues:

 TRILL-PORT-VER sub-TLV should be PORT-TRILL-VER sub-TLV.(there are a few
 occurrences)




 Nits/editorial comments:

 - Suggestion: [Page 6], line 2, spell out first occurrence LSP



 - Suggestion: [Page 6], line 5, overload bit on  overload bit set



 - Clarification:[Page 6], Section 2.1, line 5, add a comma , after
 traffic engineered frames



 - Typo:[Page 6], last word, contain --missing s-- contains



 - Suggestion: [Page 7], Section 2.2, line 2, spell out first occurrence of
 Reverse Path Forwarding Check and then use RPFC in the rest of the
 document.



 - Clarification:[Page 10], Section 2.4.2.3, line 5, sentence starting with
 RB2 MUST advertise ...: we could omit the second occurrence of it might
 use in that sentence.



 - Clarification:[Page 10], Section 2.4.2.3, 3rd line from last, end
 stations connected to RB: a RB or RBs?



 - Typo: [Page 11], Section 3.1,( j, k) --remove extra space-- (j, k)



 - Suggestion: [Page 11], Section 3.2, already in flight  already in
 transmission



 - Typo [Page 12]:many multi-destination frame--missing s-- many
 multi-destination frames



 - Clarification:[Page 13], Point 4. , Sentence 2: suggested clarification:

 It does so by checking LSPs it receives and updating its link state
 database for any of its nicknames held with higher priority by another TRILL
 Switch that is IS-IS reachable.



 - Typo [Page 14]:unicast Channel message--missing s--unicast Channel
 messages



 - Typo [Page 16]: Section 5.2,Routeing  Routing



 - Suggestion:[Page 16],last sentence, suggestion: This safety margin is
 called Margin below.



 - Typo [Page 18]:a specified in [RFC6325]--missing s--as specified in
 [RFC6325]



 - Suggestion: [Page 19], spell out first occurrence of EISS



 - Suggestion:[Page 21], Point 1, not clear what the new text becomes.
 Suggestion: refer to last paragraph of section 3.1 instead of paragraph
 before 3.2, and propose the new sentence.



 - Clarification:[Page 21], Point 2, it is not clear what the change is to
 section 3.2 of RFC6327.



 - Clarification:[Page 21], Point 3, it would be clearer to say bullet A9 is
 added (if this is an event like the rest of the bullets in section 3.3 of
 RFC6327)



 - Clarification:[Page 22], section 10.1,disagreement over the Designated
 VLAN or the like. Suggestion: replace the term or the like with other
 examples or remove the term.



 -Typo: [Page 22], section 10.1, each others frameseach other's
 frames



 -Typo: [Page 24], DRB SHOULD NOT appointedDRB SHOULD NOT appoint,
 an VLANa VLAN, RBridgedRBridge



 -Clarification:[Page 25], Section 11, Point 1, The previously reserved,
 reference to document.



 - Clarification: [page 19/page 27], Informative References, reference [802],
 to verify which standard we want to refer to for Canonical Format Indicator:

 If it is IEEE Std 802-2001: IEEE Standard for Local and Metropolitan Area
 Networks: Overview and Architecture, then the date should be 7 February
 2001.

 However this specific document does not define CIF. You may want to refer to
 802.1Q-2005.

 Thanks,
 Donald
 =
  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
  155 Beaver Street, Milford, MA 01757 USA
  d3e...@gmail.com

 Thanks,
 Meral


 ---
 Meral Shirazipour
 Ericsson
 Research
 www.ericsson.com
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC/Telechat review of draft-ietf-trill-rbridge-extension-04

[Donald Eastlake]

Hi Ben,

On Fri, Jun 1, 2012 at 3:18 PM, Ben Campbell b...@nostrum.com wrote:
 Thanks for the quick response. Further comments inline. I deleted sections 
 that do not appear to need further discussion.

 Thanks!

 Ben.

 On Jun 1, 2012, at 10:45 AM, Donald Eastlake wrote:

 Hi Ben,

 Thanks for your review. See responses below.

 On Thu, May 31, 2012 at 6:08 PM, Ben Campbell b...@nostrum.com wrote:

 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
  http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

 Please wait for direction from your document shepherd
 or AD before posting a new version of the draft.

 Document: draft-ietf-trill-rbridge-extension-04
 Reviewer: Ben Campbell
 Review Date: 2012-05-31
 IETF LC End Date: 2012-06-07
 IESG Telechat date: 2012-06-07

 Note: Since this draft is on the agenda of the IESG Telechat on the
 same day that the IETF last call expires, this review is intended
 for both purposes.

 Summary:

 This draft is almost ready for publication as a proposed standard,
 but I have some clarification questions and comments that should be
 considered prior to publication.

 Major issues:

 None

 Minor issues:

 -- section 2, general:

 Do the authors assume that all TRILL extensions will follow this
 spec? Since RFC6325 already specifies an extension mechanism, what
 stops an extension from ignoring this spec and doing something
 different? Does it hurt if they do?

 I am not aware of any conflicts between this draft and RFC 6325. RFC
 6325 provides the broadest header option framework, for example
 specifying the field for the length of the options area and the
 initial two critical summary bits. This document fills in the
 structure and allocation mechanism of the remaining bits in the first
 4-byte word of the options area, consistent with and repeating some
 material from RFC 6325, but leaving specification of the remainder of
 the options area for future documents, which should be consistent with
 both RFC 6325 and this document. (For example, some future version of
 draft-ietf-trill-rbridge-options.)

 I agree there is no conflict--this draft adds details, but doesn't seem to 
 contradict anything in the RFC.


 However, neither RFC 6325 nor this document can actually actually bind
 the IETF against adopting future standards describing extensions that
 do not conform.

 Certainly. Nothing can do that. The IETF can always update a protocol to 
 change normative language, no matter how strongly it was stated originally :-)

 If future changes do not follow RFC 6325 or this
 document, for example changing the location or interpretation of the
 option length field in the TRILL Header or changing the interpretation
 of the critical summary bits in the first word of the options area,
 then this would break hardware and software implementations that
 depend on RFC 6325 and/or this document. But I trust the IETF to
 adhere to its usually high standards for backwards compatibility.

 Perhaps this draft should, in the first page header, say Updates:
 6325, not in the sense that it makes a change but in the sense that
 it fills in more details.


 Assuming the additional details in this draft comprise preferred extension 
 mechanism, then I think it makes sense to say that somewhere (perhaps a 
 SHOULD strength), and also mark it as updating 6325. Adding details is still 
 an update.

OK.

 -- section 2, 3rd paragraph from end: Non-critical extensions can
   be safely ignored.

 Is that intended to be normative? (Seems like it should be, since
 behavior for critical extensions is normative).

 I think of it as more like the definition of non-critical.

 Sure--I mainly mention it to be consistent with the text for critical 
 extensions, since it did use normative language about dropping frames.


 -- section 2.1, 1st paragraph, last sentence:

 Redundant with normative language in previous section.

 ? There is a normative requirement to discard frames with any
 unimplemented critical hop-by-hop options present, which might be
 thought to require examination of all options (something manifestly
 impossible since the format of options beyond the first word of the
 options area is not yet normatively specified). The sentence to which
 you refer just clarifies that testing the appropriate crtical summary
 bit(s) in the first word of the options area, if that word is present,
 is all that is required.

 section 2 says Any RBridge receiving a frame with a critical hop-by-hop 
 extension  that it does not implement MUST discard the frame Section 2.1 
 says If an RBridge does not implement all critical flags in a TRILL Data 
 frame, it MUST discard the frame... These really seem like the same MUST 
 (i.e, if you updated one but not the other, you would have an ambiguous 
 state). The same is true for the egress bit.

 I understand that you want to draw the connection between a critical 
 extension and critical flags, but it's

Re: [Gen-art] Gen-ART LC/Telechat review of draft-ietf-trill-rbridge-extension-04

[Donald Eastlake]

Hi Ben,

Thanks for your review. See responses below.

On Thu, May 31, 2012 at 6:08 PM, Ben Campbell b...@nostrum.com wrote:

 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
  http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

 Please wait for direction from your document shepherd
 or AD before posting a new version of the draft.

 Document: draft-ietf-trill-rbridge-extension-04
 Reviewer: Ben Campbell
 Review Date: 2012-05-31
 IETF LC End Date: 2012-06-07
 IESG Telechat date: 2012-06-07

 Note: Since this draft is on the agenda of the IESG Telechat on the
 same day that the IETF last call expires, this review is intended
 for both purposes.

 Summary:

 This draft is almost ready for publication as a proposed standard,
 but I have some clarification questions and comments that should be
 considered prior to publication.

 Major issues:

 None

 Minor issues:

 -- section 2, general:

 Do the authors assume that all TRILL extensions will follow this
 spec? Since RFC6325 already specifies an extension mechanism, what
 stops an extension from ignoring this spec and doing something
 different? Does it hurt if they do?

I am not aware of any conflicts between this draft and RFC 6325. RFC
6325 provides the broadest header option framework, for example
specifying the field for the length of the options area and the
initial two critical summary bits. This document fills in the
structure and allocation mechanism of the remaining bits in the first
4-byte word of the options area, consistent with and repeating some
material from RFC 6325, but leaving specification of the remainder of
the options area for future documents, which should be consistent with
both RFC 6325 and this document. (For example, some future version of
draft-ietf-trill-rbridge-options.)

However, neither RFC 6325 nor this document can actually actually bind
the IETF against adopting future standards describing extensions that
do not conform. If future changes do not follow RFC 6325 or this
document, for example changing the location or interpretation of the
option length field in the TRILL Header or changing the interpretation
of the critical summary bits in the first word of the options area,
then this would break hardware and software implementations that
depend on RFC 6325 and/or this document. But I trust the IETF to
adhere to its usually high standards for backwards compatibility.

Perhaps this draft should, in the first page header, say Updates:
6325, not in the sense that it makes a change but in the sense that
it fills in more details.

 -- section 2, 3rd paragraph from end: Non-critical extensions can
be safely ignored.

 Is that intended to be normative? (Seems like it should be, since
 behavior for critical extensions is normative).

I think of it as more like the definition of non-critical.

 -- section 2.1, 1st paragraph, last sentence:

 Redundant with normative language in previous section.

? There is a normative requirement to discard frames with any
unimplemented critical hop-by-hop options present, which might be
thought to require examination of all options (something manifestly
impossible since the format of options beyond the first word of the
options area is not yet normatively specified). The sentence to which
you refer just clarifies that testing the appropriate crtical summary
bit(s) in the first word of the options area, if that word is present,
is all that is required.

 -- section 2.3, first paragraph:

 Is the first sentence intended as normative?

Yes. When one is describing part of a protocol and you say that some
particular contiguous block of bits is some particular field (and then
possibly describe the sub-structure of that field) isn't that always
normative?

 -- section 6, last paragraph:

 No security implications of this are mentioned. Is it really a
 security consideration?

 Also, is this more likely to be set incorrectly than all the other
 things that some implementation might screw up, so that it warrants
 special treatment?

I tend to think that a discussion of what happens if bits are
corrupted or incorrectly set is something reasonable for the Security
Considerations section, although it could be elsewhere. The second
paragraph/sentence of this section says that security considerations
for any bits in the first word of the options area will be in the
document specifying those bits. This document specifies the critical
summary bits and the RBridge Channel Alert bits so there is text on
both of those in its Security Considerations Section.

 Nits/editorial comments:

 -- section 1:

 Please expand TRILL on first mention in the body of the document
 (i.e. not just in the Abstract.)

Sure. And all the other acronym expansions requested below are fine so
I won't respond individually to them below although I agree with them.

 -- section 2:

 Please expand RBridge and IS-IS on first mention.

 -- section 2, bullet list, 2nd bullet:  ... 

Re: [Gen-art] Gen-ART LC and Telechat Review of draft-ietf-dnsext-5395bis-02.txt

[Donald Eastlake]

Thanks. This is supposed to be a minor revision to fix a changed
mailing list and perhaps any other major problem. It does not seems
like the version to start moving sections around.,..

Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e...@gmail.com

On Mon, Jan 3, 2011 at 3:04 PM, Pete McCann mc...@petoni.org wrote:
 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
  http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

 Please wait for direction from your document shepherd
 or AD before posting a new version of the draft.

 Document: draft-ietf-dnsext-5395bis-02.txt
 Reviewer: Pete McCann
 Review Date: 2011-01-03
 IETF LC End Date: 2011-01-05
 IESG Telechat date: 2011-01-06

 Summary: Ready

 Major issues: none

 Minor issues: none

 Nits/editorial comments:

 Perhaps the Annexes (Appendices?) should be after the references.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-ietf-trill-rbridge-protocol-14

[Donald Eastlake]

Hi Peter,

Thanks for the detailed review. See below,

On Thu, Jan 7, 2010 at 3:13 PM, McCann Peter-A001034 
pete.mcc...@motorola.com wrote:

 I have been selected as the General Area Review Team (Gen-ART) reviewer
 for this draft (for background on Gen-ART, please see
 http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html
 http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ).

 Please resolve these comments along with any other Last Call comments
 you may receive.

 Document: draft-ietf-trill-rbridge-protocol-14
 Reviewer: Pete McCann
 Review Date: 2010-01-08
 IETF LC End Date: 2010-01-11
 IESG Telechat date: unknown

 Summary: Basically ready, a few minor issues  nits.

 Major issues: None.


Thanks!


 Minor issues:

 Section 4.1.4:
 This text seems to imply that the FCS of the inner, native frame is
 removed and only a single FCS covering the encapsulated frame is
 generated.  However, it is not quite clear to me which behavior
 is intended.  Could you add text to clarify?


You are correct in your interpretation. I suggest adding, after the first
sentence of the first paragarph in 4.1.4, the following: Thus, when a frame
is encapsulated, the original FCS is not included but is discarded.


 Section 4.5:
   The k trees are ordered from 1 to k, with up to k of the s trees
   advertised by RB1 given tree numbers 1 through s, respectively, and
   any remaining trees given numbers in order of priority.
 Is this worded correctly?  Should it say:
   The k trees are ordered from 1 to k, with up to s of the k trees
   advertised by RB1 given tree numbers 1 through s, respectively, and
   any remaining trees given numbers in order of priority.


The wording is certainly confusing. There are a total of k trees campus
wide. RB1 can advertise a list of trees to calculate which could be a list
of less than k, exactly k, or more than k. s is the number of trees to
calculate advertised by RB1. The numbering of a tree is significant for some
multipathing computations. There is also a priority ordering of all possible
trees, but the list of trees to calculate advertised by RB1 overrides that
priority ordering. So, if is k less than or equal to s, then the first k
trees advertised by RB1 are calculated and numbered 1 through k. If k  s,
then all trees advertised by RB1 are calculated and numbered 1 through s.
And an additional (s - k) tree are calculated and numbered s+1 ... through
k. Which trees are computed is actually explained above the text you
mention. The text you mention is just about tree numbering / ordering.

I suggest replacing the paragraph just before the 4.5.1 section heading with
the following:

The k trees calculated for a campus are ordered and numbered from 1 to k.
In addition to advertising the number k, RB1 might explicitly advertise a
set of s trees by providing a list of s nicknames that are the root of the
trees.

  -   If s == k, then the trees are numbered in the order of RB1 advertises
them.

  -   If s == 0, then the trees are numbered in order of decreasing
priority. For example, if RB1 advertises only that k=2, then the highest
priority tree is number 1 and the 2nd highest priority tree is number 2.

   -  If s  k, then those advertised by RB1 are numbered from 1 in the
order advertised. Then the remainder are chosen by priority order from among
the remaining possible trees with the numbering continuing. For example, if
RB1 advertises k=4, advertises {Tx, Ty} as the nicknames of the root of the
trees, and the campus wide priority ordering of trees in decreasing order is
Ty  Ta  Tc  Tb  Tx, the numbering will be as follows: Tx is 1 and Ty is
2 since that is the order they are advertised in by RB1. Then Ta is 3  and
Tc is 4 because they are the highest priority trees that have not already
been numbered.

Section 4.5.5:
 The bullets in this section say, forwarded onto
 adjacencies in the nickname1 tree but don't explicitly
 say that you shouldn't forward onto the adjacency on which
 the packet arrived.


Yes. Since it seems like it would be a bit verbose to add this qualification
in the many cases where there are references to adjacencies in this bulleted
list, I suggest the following. Replace the : at the end of the first
sentence in 4.5.5 with a period and add the following sentence after it:
References to adjacencies below do not include the adjacency on which a
frame was received.


 Section 7.2:
 Have you made arrangements with IEEE to get these values?  They
 normally charge a fee for new Ethertypes.


We are presently working on the applications, but they have not been
submitted. Our understanding is that it is the policy of the IEEE RAC
(Registration Authority Committee) to, on a case-by-case basis, grant code
points for standards use to standards development organizations free of
charge. For one type of allocation, a standards use multicast address, they
even have a standard form to use for this purpose:
http://standards.ieee.org/regauth/registry_stdgroupmac.html