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

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 27 June 2016 22:47 UTC

Return-Path: <prvs=59869d72d3=pkyzivat@alum.mit.edu>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D3D3B12DA5A; Mon, 27 Jun 2016 15:47:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.627
X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Fu5kfPGaJ_6x; Mon, 27 Jun 2016 15:47:00 -0700 (PDT)
Received: from alum-mailsec-scanner-4.mit.edu (alum-mailsec-scanner-4.mit.edu []) by ietfa.amsl.com (Postfix) with ESMTP id 6DF6712DA57; Mon, 27 Jun 2016 15:47:00 -0700 (PDT)
X-AuditID: 1207440f-5e3ff7000000093a-49-5771ace321c0
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU []) by (Symantec Messaging Gateway) with SMTP id A5.51.02362.3ECA1775; Mon, 27 Jun 2016 18:46:59 -0400 (EDT)
Received: from Paul-Kyzivats-MacBook-Pro.local (c-73-218-51-154.hsd1.ma.comcast.net []) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id u5RMkwco009297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Jun 2016 18:46:59 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
To: draft-ietf-trill-ia-appsubtlv.all@ietf.org
Message-ID: <392967e6-b056-ef84-dbe4-5adf7469a641@alum.mit.edu>
Date: Mon, 27 Jun 2016 18:46:57 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPIsWRmVeSWpSXmKPExsUixO6iqPt4TWG4wZe36hbLr81gt7j66jOL A5PHkiU/mQIYo7htkhJLyoIz0/P07RK4M0417mAvaNKs2Hb2CEsD42KFLkZODgkBE4nvL1rY uxi5OIQEtjJK/Lk/kxXCecok8fjAB2aQKjYBLYk5h/6zgNjCAj4SS6c+ALNFBPQkTl24D2Yz C+hL/H2ymKmLkYODV8Be4t1LW5Awi4CqxLGG1UwgtqhAmsTZayfARvIKCEqcnPkEqtVW4s7c 3cwQtrzE9rdzmCcw8s5CUjYLSdksJGULGJlXMcol5pTm6uYmZuYUpybrFicn5uWlFuma6OVm luilppRuYoQEFv8Oxq71MocYBTgYlXh4d9QVhguxJpYVV+YeYpTkYFIS5T01ESjEl5SfUpmR WJwRX1Sak1p8iFGCg1lJhPfXaqAcb0piZVVqUT5MSpqDRUmcV32Jup+QQHpiSWp2ampBahFM VoaDQ0mClxUYQUKCRanpqRVpmTklCGkmDk6Q4VxSIsWpeSmpRYmlJRnxoAiLLwbGGEiKB2jv UbC9xQWJuUBRiNZTjIpS4rynVwElBEASGaV5cGNh6eIVozjQl8K8/iDbeYCpBq77FdBgJqDB rNX5IINLEhFSUg2Mcu+Wtnz693N3kk72Kb6vi8XEvlp/Ol1xuW2vnK+9pKWxzrGqLqsCZQ67 Ga+ZU2pcP5rKazIWpX/h+WCkMS3d6++zB3M/WC3ZfWo1g2Ot3jeXRnXdwkPnZ8qck+O+VvxD ct7aNpvbky01n+1wkX52edeTP1k7pk+4dunT8tWLp2+L+BTyWtj8jhJLcUaioRZzUXEiADkg 1PXyAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/9UNV8YGshfU0fl5TcJ0a2zXLknU>
Cc: General Area Review Team <gen-art@ietf.org>
Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-trill-ia-appsubtlv
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jun 2016 22:47:03 -0000

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please treat these comments just like any other 
last call comments. For more information, please see the FAQ at 

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


This draft is on the right track but has open issues, described in the 

This is a well written document. I was generally able to follow it even 
though I know nothing about the subject.


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.

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

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.

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

(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 properties 
that are appropriate.

(5) MINOR: (Section 6)

This section talks about the handling of OUI and IPv6/64 when they 
appear in a Fixed Address sub-sub-TLV. It says nothing about their 
meaning if these appear elsewhere, such as in a Template. I presume this 
kind of usage is nonsense, but it would be better to explicitly state it.

(6) MINOR: (Section 6)

The description of IPv6/64 says:

    For this purpose, an 48-bit MAC address is expanded to 64
    bits as described in [RFC7042].

It wasn't entirely apparent to me what part of 7042 covers that. It 
would be helpful to provide the section where this aspect is specified. 
(After some study I guess that it is section 2.2.1.)

(7) MINOR: (Section A.2)

I believe that the values of both 'Length' and 'Address Sets End' are 
too small by 7 - presumably because they forgot to count the fixed 
fields. This also applies to the "alternative" using explict AFN encoding.

(8) NIT: (Section A.2)

Based on a very quick reading, ISTM that section 2.2.1 of 7042 suggests 
that the IPv6 addresses being constructed this way should start with 
0x02 rather than 0x20. But I'm far from sure I understand this correctly.

(9) NIT: (Section A.2)

There seems to be a typo in the following:

    The OUI would them be supplied
    by a second Fixed Address sub-sub-TLV proving the OUI.

I think "proving" should be "providing".