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

Donald Eastlake <d3e3e3@gmail.com> Wed, 06 July 2016 01:51 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070471288B8; Tue, 5 Jul 2016 18:51:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vokZBqgBo1TU; Tue, 5 Jul 2016 18:51:28 -0700 (PDT)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0603B12B025; Tue, 5 Jul 2016 18:51:28 -0700 (PDT)
Received: by mail-oi0-x22a.google.com with SMTP id s66so253439461oif.1; Tue, 05 Jul 2016 18:51:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i4aEQTctwNpw3l+TckgQcGxrb56ZqdK/lIaZydP5/FA=; b=zS13IamV4qVTNFq+fCwzRKMmvf0JVeHpVf93kcDDVxU0oOLDA7HJQjfpP9vkJBDoHp 3ZXoIdbGv+rFG0ZtlkXrjaNRXCcLog9NhUuo/3JxV24qb2CA2AgpYpHRl7wgc1kq2VBo XOqi/5Q2HklgGoymNyIP1CSl+ijWwSKogVzcMbkk24Cv9clmvVtgDobNo3V1ax1lSMjF 6BzR4KYhngJwddlZgmzCZ4LZufaIjKol/nlU5HFrNeS3F/t8U0nC4a2oIbEKQqegMH6S N1xXV7d/SqSP8EaHzDgV+UKqzk8mNSWqb9ggptikvxYag/coaeyjmNc0UzZutmUhvags FK9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=i4aEQTctwNpw3l+TckgQcGxrb56ZqdK/lIaZydP5/FA=; b=YWg/iuPqNUO/d+KS8y4YbJt8lIx1VaxZShpQeXeLPimxKxJi9LA7G4f5owdHvtVA6b 32S4V19KYPDWZ499QypoXB16Usak3aizKYJGYegqPd+T6ML5kYiQzE/pWIFvOHwrxHEG qNPAwApYyLJGedjst0T51FksHNsC/SPcUVFMpwLswhJVrvtcvrOPf+YUKR1cuTCeQO21 AvIkKoRNB2HoMKnN/Yj/PvmH7tPtKj1lgxDxpl6Bq4wPZrmzxsIMrn+7HoN1SLlGcn2Z ZKVfRsNRjtbPj1NJ0iTHNqn09UFK55xZ+2On0cVzmizhJO6LFMz3nmD/aB1KujPNh/EB 4nOA==
X-Gm-Message-State: ALyK8tKbJelv3qiz37r9OIqjvmEUskNGFnCKKUwnvvcd42//cIwhY+eEUMk3wnLLeOss/WNIlV3vkKsymDJlpg==
X-Received: by 10.202.183.139 with SMTP id h133mr10510886oif.6.1467769887083; Tue, 05 Jul 2016 18:51:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.52.242 with HTTP; Tue, 5 Jul 2016 18:51:12 -0700 (PDT)
In-Reply-To: <2cff626f-8f5e-19ce-704a-c0f1990c0569@alum.mit.edu>
References: <392967e6-b056-ef84-dbe4-5adf7469a641@alum.mit.edu> <CAF4+nEFNUZA6gGA0P3v-CjABYG8gUdW0mqRt13LzQ47-mgSG6A@mail.gmail.com> <3840099b-5151-5be6-c164-91ac8362ea57@alum.mit.edu> <CAF4+nEFF7w_5YW9Mcn-=NrjAz0eFXPH+mkbmm0KgBDhoJLu95Q@mail.gmail.com> <2cff626f-8f5e-19ce-704a-c0f1990c0569@alum.mit.edu>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Tue, 5 Jul 2016 21:51:12 -0400
Message-ID: <CAF4+nEGn27KFLLg924Xv_fabZx2BXfqiCkROckRjYc0o3gEPXg@mail.gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/uUmdZXB4FeUdk9vu0Jc0BupAGiI>
Cc: General Area Review Team <gen-art@ietf.org>, draft-ietf-trill-ia-appsubtlv.all@ietf.org
Subject: Re: [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: Wed, 06 Jul 2016 01:51:37 -0000

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


On Tue, Jul 5, 2016 at 9:32 AM, Paul Kyzivat <pkyzivat@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
>>  d3e3e3@gmail.com
>>
>>
>> On Mon, Jul 4, 2016 at 6:50 PM, Paul Kyzivat <pkyzivat@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 <pkyzivat@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 draft.
>>>
>>>
>>>
>>> When I wrote this comment I had in mind the following that I recently
>>> read:
>>>
>>>
>>> https://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-15#section-1.1
>>>
>>>>> (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...
>>>
>>>
>>>
>>> WFM
>>>
>>>
>>>>> (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.
>>>>
>>>>
>>>>
>>>> OK. Some guidance can be added.
>>>>
>>>>> (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.
>>>>
>>>>
>>>>
>>>> OK, the draft should explain their processing wherever they occur.
>>>>
>>>>> (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.)
>>>>
>>>>
>>>>
>>>> OK.
>>>>
>>>>> (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.
>>>>
>>>>
>>>>
>>>> Thanks for catching that there is an error here.
>>>>
>>>> Length should be the size everything after the 2-byte length
>>>> field. That's
>>>>   7  fixed fields
>>>>  36  three address sets, each 12 bytes
>>>>   7  sub-sub-tlv one
>>>>  14  sub-sub-tlv two
>>>> for a total of 64 so the value is off by 10.
>>>>
>>>> Address Sets End should be the above less the sub-sub-tlvs, so that
>>>> would be 43 and the value shown is also off by 10.
>>>
>>>
>>>
>>> I guess I also got it wrong.
>>>
>>> But it was obvious to me that the examples weren't all done the same way.
>>>
>>>>> (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.
>>>>
>>>>
>>>>
>>>> Ahhh, there is indeed an error here but it is in the bottom 64 bits,
>>>> which should be a Modified EUI-64 identifier, as described in Section
>>>> 2.2.1 of RFC 7042. Thus the top byte of the bottom 64 bits of the
>>>> resulting IPv6 addresses should be 0x02. The top byte of the entire
>>>> IPv6 128-bit address should be 0x20 as shown.
>>>
>>>
>>>
>>> OK. Like I said, I didn't really understand the details.
>>>
>>>         Thanks,
>>>         Paul
>>>
>>>
>>>>> (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".
>>>>
>>>>
>>>>
>>>> OK.
>>>>
>>>> Thanks,
>>>> Donald
>>>> ===============================
>>>>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>>>  155 Beaver Street, Milford, MA 01757 USA
>>>>  d3e3e3@gmail.com
>>>>
>>>
>>
>