Re: [Lsr] Secdir last call review of draft-ietf-isis-segment-routing-msd-16

Benjamin Kaduk <kaduk@mit.edu> Wed, 26 September 2018 23:06 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC02130DCE; Wed, 26 Sep 2018 16:06:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 1-3hamkBRr8m; Wed, 26 Sep 2018 16:06:31 -0700 (PDT)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5E84128CFD; Wed, 26 Sep 2018 16:06:30 -0700 (PDT)
X-AuditID: 12074425-e29ff700000028dd-33-5bac10f4baef
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 89.18.10461.4F01CAB5; Wed, 26 Sep 2018 19:06:29 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w8QN6Pck019013; Wed, 26 Sep 2018 19:06:26 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w8QN6LKE019089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Sep 2018 19:06:24 -0400
Date: Wed, 26 Sep 2018 18:06:21 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: David Waltermire <david.waltermire@nist.gov>, "secdir@ietf.org" <secdir@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-isis-segment-routing-msd.all@ietf.org" <draft-ietf-isis-segment-routing-msd.all@ietf.org>
Message-ID: <20180926230621.GW24695@kduck.kaduk.org>
References: <153790283647.5258.15634056350853857580@ietfa.amsl.com> <a3e1e6216dbc46db8c717d5dd2946ea0@XCH-ALN-001.cisco.com> <20180926211104.GQ24695@kduck.kaduk.org> <149d5d345afc462f9c5e5770079aaf0e@XCH-ALN-001.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <149d5d345afc462f9c5e5770079aaf0e@XCH-ALN-001.cisco.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRmVeSWpSXmKPExsUixCmqrPtVYE20wdJ7rBYbe/6xWXxfr2ix 4c9GdotnG+ezWJx4soLV4sPChywObB5Tfm9k9Viy5CeTx7WTf1kDmKO4bFJSczLLUov07RK4 MhbMncFUcFG14s+5RqYGxlWyXYwcHBICJhKH//B2MXJyCAksZpL4toGri5ELyN7IKPF8eSMr hHOVSeLYi/1MIFUsAqoSJ5ZvZgOx2QRUJBq6LzODDBIRMJJY/FwbpJ5ZYDqTxIeD09hB4sIC fhJTzoiBlPMC7Vp8uZcJYtkTRon+8yEQcUGJkzOfsIDYzALqEn/mXQIbySwgLbH8HwdEWF6i eetsZhCbU8BV4uiZFlYQW1RAWWJv3yH2CYyCs5BMmoVk0iyESbOQTFrAyLKKUTYlt0o3NzEz pzg1Wbc4OTEvL7VI10IvN7NELzWldBMjKALYXVR3MM7563WIUYCDUYmHN2L96mgh1sSy4src Q4ySHExKorwKe4FCfEn5KZUZicUZ8UWlOanFhxglOJiVRHjXbQfK8aYkVlalFuXDpKQ5WJTE eSe1LI4WEkhPLEnNTk0tSC2CycpwcChJ8B7jXxMtJFiUmp5akZaZU4KQZuLgBBnOAzScC5gw hHiLCxJzizPTIfKnGI05XszomMHMse1M5wxmIZa8/LxUKXFeNZBSAZDSjNI8uGmgJCaRvb/m FaM40HPCvEwgVTzABAg37xXQKiagVRN6VoCsKklESEk1MIZkaNREFvZx7oiWSf0RnugePeke +1mpy5tDz5S+S8kJiOTiOx1kqvr8a3TJnCRN/xOWoYumK3CbeT8tEeqVnL98Qfy5brfdG7Jy xY7qbNj+5ZhQ0oTf89mnP1dqfDplz8yTAsxnt1pmW1i7zjrdeTxpXbbZwxNxj05cnMAs+XI+ 1+XNCY/O7FBiKc5INNRiLipOBACJRRUzPQMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/bg8lHvuslXaxf90G_o87tHGUs8I>
Subject: Re: [Lsr] Secdir last call review of draft-ietf-isis-segment-routing-msd-16
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Sep 2018 23:06:33 -0000

On Wed, Sep 26, 2018 at 10:59:50PM +0000, Les Ginsberg (ginsberg) wrote:
> Benjamin -
> 
> Responses nline.
> 
> > -----Original Message-----
> > From: Benjamin Kaduk <kaduk@mit.edu>
> > Sent: Wednesday, September 26, 2018 2:11 PM
> > To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
> > Cc: David Waltermire <david.waltermire@nist.gov>ov>; secdir@ietf.org;
> > lsr@ietf.org; ietf@ietf.org; draft-ietf-isis-segment-routing-msd.all@ietf.org
> > Subject: Re: Secdir last call review of draft-ietf-isis-segment-routing-msd-16
> > 
> > On Wed, Sep 26, 2018 at 08:45:03PM +0000, Les Ginsberg (ginsberg) wrote:
> > > David -
> > >
> > > Thanx for the review.
> > > A new version of the draft (17) has been published to address your
> > comments - subject to my responses below.
> > 
> > Just in time for me to see the updated version for my IESG review; thanks.
> > 
> > > > -----Original Message-----
> > > > From: David Waltermire <david.waltermire@nist.gov>
> > > > Sent: Tuesday, September 25, 2018 12:14 PM
> > > > To: secdir@ietf.org
> > > > Cc: lsr@ietf.org; ietf@ietf.org; draft-ietf-isis-segment-routing-
> > > > msd.all@ietf.org
> > > > Subject: Secdir last call review of
> > > > draft-ietf-isis-segment-routing-msd-16
> > > >
> > > > Reviewer: David Waltermire
> > > > Review result: Has Issues
> > > >
> > > > I have reviewed this document as part of the security directorate's
> > > > ongoing effort to review all IETF documents being processed by the
> > > > IESG.  These comments were written primarily for the benefit of the
> > > > security area directors.
> > > >  Document editors and WG chairs should treat these comments just
> > > > like any other last call comments.
> > > >
> > > > The summary of the review is Ready with (minor) issues
> > > >
> > > > My apologies for the late review on this draft. Overall I found this
> > > > document to be well-written, and concise.
> > > >
> > > > General Comments:
> > > >
> > > > This document uses a mix of case around RFC2119 language (e.g., MAY
> > may).
> > > > You should use text from RFC8174 to indicate that lowercase versions
> > > > of the keywords are not normative, or adjust the case of the
> > > > lowercase words to ensure there is no confusion.
> > > >
> > > [Les:] Section 1.2 does include the standard boilerplate for RFC
> > 2119/RFC8174.
> > >
> > > I checked all the lower case uses of "may" and they are intentional.
> > > There was one instance of "should" that I changed to uppercase.
> > >
> > > > Minor nit: There is some inconsistency in the use of "MSD-Type" (the
> > > > value) and "MSD type" (the concept). Suggest cleaning this up.
> > > >
> > > [Les:] Done
> > >
> > > > Specific comments:
> > > >
> > > > Section 1:
> > > >
> > > > Para 1: s/to insure/to ensure/
> > >
> > > [Les:] Done.
> > >
> > > >
> > > > Section 4:
> > > >
> > > > The last paragraph establishes a requirement on the registration of
> > > > an MSD Type to define what the absence of a given MSD Type means.
> > > > This is an important requirement that must be addressed during
> > > > registration of new MSD Types. IMHO, this requirement should be
> > > > echoed in the registration information in section 6 to make sure it is not
> > overlooked.
> > > >
> > > [Les:] I disagree. Section 6 is defining exactly what should go into the new
> > IANA registry.
> > > The definition of "absence" is something that will have to be provided in
> > the documents which define new MSD-types, but that will NOT be captured
> > in the registry so including this in Section 6 isn’t appropriate.
> > 
> > I think a good way to think about this is as giving guidance to the Experts, that
> > they should not approve registration requests that fail to provide this
> > information along with the request.  Guidance for the Experts is appropriate
> > in the IANA Considerations section.
> > (Also, my understanding is that IANA prefers to have a more explicit
> > template for new registrations to follow, though I should not try to speak for
> > them.)
> > 
> 
> [Les:] The reason we use "experts" is because we know/expect them to be familiar with the documents which define the TLVs (unlike a "general IETF reader" whose familiarity with the subject matter may vary).
> Repeating what is said in Section 4 in Section 6 only makes sense if you think the "expert" only reads IANA sections. Such a person would not be an expert IMO. :-)

I suspect that the experts would prefer to receive a high proportion of
requests that meet the criteria the experts are going to apply, rather than
constantly telling people they need to go fix the same thing and come back.
It's best practice to be clear about what is required for a successful
registration.

-Benjamin