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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Wed, 26 September 2018 23:24 UTC

Return-Path: <ginsberg@cisco.com>
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 28A3C130DC4; Wed, 26 Sep 2018 16:24:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.49
X-Spam-Level:
X-Spam-Status: No, score=-14.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 dXLLEnp3ic_0; Wed, 26 Sep 2018 16:24:37 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499AC130DCE; Wed, 26 Sep 2018 16:24:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30136; q=dns/txt; s=iport; t=1538004277; x=1539213877; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dS5eyhCWRTLDalgX2R8URlBBE6JpQ49EaHUynXOdJkE=; b=Fov/5zZuayAiwnEtkCNPohgC8nbSheuApbxbjusDrfEMmU8Bd1o5MG7a BN9kQnHCF2x9fTlU7e3+Ys5THU8zwRMrdAgaif0un39wBT/0V2XZfSU2J 5nxLnBd77XgmsBYvE7yy7qPIoTxkuGBYvzWpJU0GxJsdT5Hfdc8cVEkVc w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAADHFKxb/4UNJK1aDgsBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVGBF3dlfygKg2qIFYwwgg2WT4F6CyOESQIXg2YhNBg?= =?us-ascii?q?BAwEBAgEBAm0cDIU4AQEBAQIBIwo+DgUHBAIBBgIRBAEBKAMCAgIwFAkIAgQ?= =?us-ascii?q?OBQiDGoEdXAgPiCqbTYEuihEFinsXgUE/gRKDEoMbAQECAYF1H4JLglcCjWy?= =?us-ascii?q?Fd4kkCQKGQYliH4FGhFKHfoEei3uIbwIRFIElHTiBVXAVgyeCJReIWoUEOm8?= =?us-ascii?q?BjDCBHgEB?=
X-IronPort-AV: E=Sophos;i="5.54,308,1534809600"; d="scan'208,217";a="457926589"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2018 23:24:33 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id w8QNOXXd001246 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Sep 2018 23:24:33 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 26 Sep 2018 18:24:32 -0500
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1395.000; Wed, 26 Sep 2018 18:24:32 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Benjamin Kaduk <kaduk@mit.edu>
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>
Thread-Topic: Secdir last call review of draft-ietf-isis-segment-routing-msd-16
Thread-Index: AQHUVQPqnQ0QGOOP8EOqsf/gazaoC6UC9FjAgABwTwD//8fJ0IAAWG2A//+wjNA=
Date: Wed, 26 Sep 2018 23:24:31 +0000
Message-ID: <31f78bd59e874b18b7ab5d91a7db4aa8@XCH-ALN-001.cisco.com>
References: <153790283647.5258.15634056350853857580@ietfa.amsl.com> <a3e1e6216dbc46db8c717d5dd2946ea0@XCH-ALN-001.cisco.com> <20180926211104.GQ24695@kduck.kaduk.org> <149d5d345afc462f9c5e5770079aaf0e@XCH-ALN-001.cisco.com> <20180926230621.GW24695@kduck.kaduk.org>
In-Reply-To: <20180926230621.GW24695@kduck.kaduk.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.8.175]
Content-Type: multipart/alternative; boundary="_000_31f78bd59e874b18b7ab5d91a7db4aa8XCHALN001ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/E4XAcMzQWEEWW38wryA-aMiv9CU>
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:24:40 -0000

Benjamin -



Please review https://tools.ietf.org/html/rfc8126#section-1.1



In particular (emphasis added):



" The purpose of having a dedicated IANA Considerations section is to

   provide a single place to collect clear and concise information and

   instructions for IANA.  Technical documentation should reside in

   other parts of the document…”



I think what you propose is not consistent with the intent of the IANA section.



Thanx.



    Les





> -----Original Message-----

> From: Benjamin Kaduk <kaduk@mit.edu>;

> Sent: Wednesday, September 26, 2018 4:06 PM

> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>;

> Cc: David Waltermire <david.waltermire@nist.gov>;; 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 10:59:50PM +0000, Les Ginsberg (ginsberg) wrote:

> > Benjamin -

> >

> > Responses nline.

> >

> > > -----Original Message-----

> > > From: Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>>

> > > Sent: Wednesday, September 26, 2018 2:11 PM

> > > To: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>

> > > Cc: David Waltermire <david.waltermire@nist.gov<mailto:david.waltermire@nist.gov>>; secdir@ietf.org<mailto:secdir@ietf.org>;

> > > lsr@ietf.org<mailto:lsr@ietf.org>; ietf@ietf.org<mailto:ietf@ietf.org>;

> > > draft-ietf-isis-segment-routing-msd.all@ietf.org<mailto: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<mailto:david.waltermire@nist.gov>>

> > > > > Sent: Tuesday, September 25, 2018 12:14 PM

> > > > > To: secdir@ietf.org<mailto:secdir@ietf.org>

> > > > > Cc: lsr@ietf.org<mailto:lsr@ietf.org>; ietf@ietf.org<mailto:ietf@ietf.org>;

> > > > > draft-ietf-isis-segment-routing- msd.all@ietf.org<mailto: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