Re: [trill] RtgDir review: TRILL: Interface Addresses APPsub-TLV <draft-ietf-trill-ia-appsubtlv-07.txt>

Alia Atlas <akatlas@gmail.com> Thu, 02 June 2016 02:49 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F5412D0FF; Wed, 1 Jun 2016 19:49:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.699
X-Spam-Level:
X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no 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 81JA6aTf7TOs; Wed, 1 Jun 2016 19:49:44 -0700 (PDT)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 3EC5812D0B2; Wed, 1 Jun 2016 19:49:44 -0700 (PDT)
Received: by mail-yw0-x231.google.com with SMTP id h19so37536040ywc.0; Wed, 01 Jun 2016 19:49:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=8bz+VoXAVhIFZNfAU4030ExEemENrHJCwq+vwsLY1lg=; b=fKHDG4Tu1xLaGSFSKiAMZ+u78X04z/hIF5TNBJFylUDCZ+0nqg0DrlBFwE2EdqtE+e DB6Vy2IeMFBZ5v/vk5r2SH5SHgGOv+0Oodp8Z/GGadgfmADuLnrxvAkr1ZoEuF/4v+d9 c1Yjl7olPoiIMg9YiRm6PgIak40gIcZmRH4TdvfnDlaKqZ+ilhBIJvNwFmlw3HkIm9WB t0fqWGAgHetfMe+YYgdQLL2SqFBY3eF4Nu5cERCmSrj/Y81ApfAr/40KLB3/vnAhkKaa q+zvJ/ZqCIvy/yHi6MLHhd2auau3Q/Kk7lB4+dMbENVlZ3lyyBKfI48pvETga1Bbc68F 9xEQ==
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:date :message-id:subject:from:to:cc; bh=8bz+VoXAVhIFZNfAU4030ExEemENrHJCwq+vwsLY1lg=; b=ODVcinAzZG229uzQ6RInybXb/LnL8mVV1bkJdOr3x/ToM3izSVW/yOkc2VYbGfW//l dGzfTV3oUkxeSZ2SiyJUvIzXNa63ZSJfdjmizb1NNVUvcfR6T7+fSRhjtlgJBIxdNk4H tBnjwJJfOs+SjHR3a9LkbWJnBhr5lGK4bW82aQ70Z6UcSCsh/iAoHYPJf5ew3yHqmPy6 at619C2H4Tyty6dhzQdcgCoaTK2weIvIEMYX71tqaiyunvzwpjzBBCb7hKpOXBiEaEw2 8lzvVpb4Ga5BD1PYkUyBSj0seSDSVQaA2t0PhjRyev00mDh+b+U5SoqG3JyMq0nLjE22 fTOA==
X-Gm-Message-State: ALyK8tIuQWlUsSYJBgeBmnAauV3DQcnAfB1XKxkBbjtbkKs+9dUU/YQOmvtX4FM76YqM+NeDkyUEsYh+vaBriQ==
MIME-Version: 1.0
X-Received: by 10.37.201.71 with SMTP id z68mr4171604ybf.124.1464835783508; Wed, 01 Jun 2016 19:49:43 -0700 (PDT)
Received: by 10.13.221.74 with HTTP; Wed, 1 Jun 2016 19:49:43 -0700 (PDT)
In-Reply-To: <B7B03C88-1B0E-4C83-8EC1-8DF4BEEB301D@verisign.com>
References: <C4E48021-CFBA-458A-AD3E-6B73A55FFEC8@verisign.com> <CAF4+nEHRNL60DK9asQ_ekadDP9fwj2UJP7HQuLXP0zMXpV9+5w@mail.gmail.com> <B7B03C88-1B0E-4C83-8EC1-8DF4BEEB301D@verisign.com>
Date: Wed, 1 Jun 2016 22:49:43 -0400
Message-ID: <CAG4d1rc1SPzoVDtP1Z3Ykaqoxb_5ssAFy+fBYhjaaxv1D6jY-g@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: "McPherson, Danny" <dmcpherson@verisign.com>
Content-Type: multipart/alternative; boundary=001a114d74f887cab3053442a8a5
Archived-At: <http://mailarchive.ietf.org/arch/msg/trill/mO_1n9M3GYeJ69E1h_acQUmvans>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "all@ietf.org" <all@ietf.org>, "rtg-ads@ietf.org" <rtg-ads@ietf.org>, "draft-ietf-trill-ia-appsubtlv@ietf.org" <draft-ietf-trill-ia-appsubtlv@ietf.org>, "trill@ietf.org" <trill@ietf.org>, Donald Eastlake <d3e3e3@gmail.com>
Subject: Re: [trill] RtgDir review: TRILL: Interface Addresses APPsub-TLV <draft-ietf-trill-ia-appsubtlv-07.txt>
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jun 2016 02:49:46 -0000

Danny,

Thank you very much for your review.

Regards,
Alia

On Thu, May 5, 2016 at 2:41 PM, McPherson, Danny <dmcpherson@verisign.com>
wrote:

>
> I’m comfortable with your stated intentions here Donald.
>
> Thanks for the prompt response,
>
>
> -danny
>
>
>
>
> On 5/5/16, 12:02 PM, "Donald Eastlake" <d3e3e3@gmail.com> wrote:
>
> >Hi Danny,
> >
> >Thanks for your comments. See below.
> >
> >On Wed, May 4, 2016 at 10:27 AM, McPherson, Danny
> ><dmcpherson@verisign.com> wrote:
> >>
> >> Hello,
> >>
> >> I have been selected as the Routing Directorate reviewer for this
> >> draft. The Routing Directorate seeks to review all routing or
> >> routing-related drafts as they pass through IETF last call and IESG
> >> review, and sometimes on special request. The purpose of the review
> >> is to provide assistance to the Routing ADs. For more information
> >> about the Routing Directorate, please see
> >> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> >>
> >> Although these comments are primarily for the use of the Routing
> >> ADs, it would be helpful if you could consider them along with any
> >> other IETF Last Call comments that you receive, and strive to
> >> resolve them through discussion or by updating the draft.
> >>
> >> Document: draft-ietf-trill-ia-appsubtlv-07.txt
> >> Reviewer: Danny McPherson
> >> Review Date: May 4, 2016
> >> Intended Status: Proposed Standard
> >>
> >>
> >> Summary:
> >>
> >>  I have some minor concerns about this document that I think should
> >>  be resolved before publication.
> >>
> >>
> >> Comments:
> >>
> >> I believe the draft is technically sound, however, the quality and
> >> readability needs a bit more work, particularly as it relates to
> >> introduction of new terms, and consistent application and use of all
> >> terms.  There are also some general error handling and encoding
> >> issues that need to be given consideration.
> >>
> >>
> >> Major Issues:
> >>
> >> I have no “Major” issues with this I-D.
> >
> >Thanks.
> >
> >> Minor Issues:
> >>
> >> 1. ERROR HANDLING: There are a number of places in the document
> >> where it discusses the receipt of malformed, badly encoded,
> >> non-matching, or corrupt messages, and the advice is to either
> >> [silently] discard or ignore the messages.  Some general guidance
> >> should be given here to enable operational diagnosis of any issues
> >> that may result in temporal or persistent problems, where logging
> >> and other actions should occur.  Some aspects of this might leverage
> >> the OAM Framework efforts, although it appears much of the TRILL
> >> work leaves this to the implementer.
> >
> >In the IETF context "silently discard" means that there is no
> >on-the-wire message sent. It says nothing about whether or not
> >counters are kept of such condition or errors are logged. A suggestion
> >to log such events and/or keep such counters can be added.
> >
> >> 2. When using “Nickname” it would be useful to define the encoding
> >> as an unsigned 16-bit integer, or just reference "as specified in S
> >> 3.7 of RFC6325”.
> >
> >OK. Will add the reference.
> >
> >> 3. The inclusion of the “TLV” acronym in the "APPsub-TLV” TLV name
> >> seems loose and redundant to me, as opposed to “APPsub TLV” or
> >> similar.
> >
> >This comes from RFC 6823, Section 3.2, which says that sub-TLVs that
> >go inside the GENAPP TLV "are refrred to as APPsub-TLVs".
> >
> >> 4. Inconsistent use of “Interface Address APPsub-TLV”, “IA
> >> APPSub-TLV”, “Interface Address APP-subTLV”, and “AppsubTLV” makes
> >> it seem like you’re talking about different things.
> >
> >OK - that should be made more consistent, probably standardizing on
> >"IA APPsub-TLV".
> >
> >> 5. The use of “sub-sub-TLV” seems a bit loose and sloppy to me as
> >> well, and should be cleaned up.  E.g., S 5.2 “IA Appsub-TLV
> >> Sub-Sub-TLVs SubRegistry"
> >
> >You don't like "sub-sub-TLV"?
> >
> >Seems like, strictly speaking, you have IS-IS PDUs which contain
> >TLVs. Then some TLVs can contain sub-TLVs. (The GENAPP TLV is the only
> >one that occurs to me with a special name for its sub-TLVs, namely
> >APPsub-TLVs.) and some sub-TLVs can contain a further nested level,
> >which it seems to me to be precise and logical to call sub-sub-TLVs.
> >(I am not aware of any requirement for any more deeper nesting in a
> >use of IS-IS.) So, would you prefer that what are called sub-sub-TLVs
> >in this document just be called "sub-TLVs" (which I agree they are)
> >resulting in two different levels with the same name? While there
> >might be some errors in their use in this draft, the mere use of
> >APPsub-TLV and sub-sub-TLV for the two levels does not seem "loose and
> >sloppy" to me...
> >
> >> 6. Only one of the “Figures” is labeled / captioned
> >
> >OK. All the principal figures should be labeled. (I don't think cases
> >where there is a small, indented figure that just expands part of a
> >principal figure and appears shortly after the principal figure need
> >to be captioned.) So, the initial figures in Sections 3.1, 3.2, 3.3,
> >and 3.4 would have Figures numbers and captions added.
> >
> >> 7. The use of “Address Sets” and “Address Sets Ends” makes it a bit
> >> hard to read when used in sentences.  Perhaps an acronym for each,
> >> or hyphenating/underscoring them would make it more readable.
> >
> >OK - I'll see what I can do.
> >
> >> 8. S 3.4 the 2-byte “Type” value in the diagram should be
> >> “TOPOLOGY”, not “DATALEN”.
> >
> >Thanks for noticing this error.
> >
> >> 9. I noticed that Radia was a co-author until the last revision, and
> >> now she doesn’t even exist in the Acknowledgements section.  While
> >> no explanation is required here, I did find this a bit odd.
> >
> >I think her listing as an author was in error.
> >
> >> 10. IANA Considerations: Some guidance from the IANA folks on the
> >> formatting of this section might be in order.  It’s not as clear as
> >> it could be about what their instructions are here.
> >
> >There are some improvements that could be made. In inverse order,
> >Section 5.3 looks fine. In Section 5.2, "Available" should be changed
> >to "Unassigned" as that is the preferred IANA term. Section 5.1 is
> >talking about assignments that have already happened and looks OK as
> >far as the table of values goes; however, the material after the first
> >sentence after that table seems inappropriate in an "IANA
> >Considerations" section and should, perhpas, be in a new "Processing
> >Address Sets" section.
> >
> >> 11. S 2: It’s unclear to me if the “Confidence” value of 255 “being
> >> treated as if it was 254” is inline with RFC6325 S 4.8.1 guidance?
> >
> >The idea is that local configuration or learning should be able to
> >override address reachability received through network messages.  Thus
> >such information, when manually configured, defaults to have confidence
> >255.
> >
> >RFC 6325 Section 4.8.1 just says that information learned via ESADI
> >will have a confidence of from 0 to 254 but don't actually say what to
> >do if it is recreived as 255. This is updated by Section 6.2 RFC 7357,
> >1st paragraph, that makes it clear that a received value of 255 is
> >just treated as if it was 254. Thus it is consistent with these prior
> >RFCs to the IA APPsub-TLV draft to give this rule for handling the
> >value 255 in the Confidence field of IP APPsub-TLVs.
> >
> >> 12. In general, I agree there appear to be no new Security
> >> Considerations here.  I do not believe Asymmetry will be an issue
> >> with the forged packet discard issue although some consideration of
> >> this might be in order (or perhaps simply a reference to SAVI or
> >> other work here).  I wonder if some consideration should be given to
> >> broader disclosure of reachable layer 2 addresses here, but that
> >> seems a bit reaching as well.
> >>
> >>
> >> Nits:
> >>
> >> 1. Abstract & Introduction: s/by-pass/bypass/
> >
> >OK.
> >
> >> 2. S.2: s/Data Label is reachable from /Data Label are reachable/
> >
> >"... inteface ... is reachable ...", so I think "is" is correct but
> >I'll see if I can re-word this sentence.
> >
> >> 3. A reference for the first use of AFN would be useful, perhaps to
> >> the IANA registry.
> >
> >OK.
> >
> >> 4. Expressing TBD code points in [ ] brackets might help with
> >> readability as well
> >
> >OK.
> >
> >> 5. S 3.2 “if the Length is 0 or 1 or less” — not sure the “or less"
> >> is necessary?
> >
> >OK, the "or less" should be removed.
> >
> >Thanks,
> >Donald
> >===============================
> > Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
> > 155 Beaver Street, Milford, MA 01757 USA
> > d3e3e3@gmail.com
>