Re: [Last-Call] Last Call: <draft-ietf-spring-sr-yang-23.txt> (YANG Data Model for Segment Routing) to Proposed Standard

"Acee Lindem (acee)" <acee@cisco.com> Tue, 24 November 2020 14:48 UTC

Return-Path: <acee@cisco.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755993A0EF6; Tue, 24 Nov 2020 06:48:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.72
X-Spam-Level:
X-Spam-Status: No, score=-7.72 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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 header.b=kxAaO69A; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BX9shoJ1
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 JpP8W5hBFVDS; Tue, 24 Nov 2020 06:48:40 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBB83A0EF5; Tue, 24 Nov 2020 06:48:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7940; q=dns/txt; s=iport; t=1606229320; x=1607438920; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Xknix4adZ+PbKg39dDZVwYrxDck2nAqLtQqdzoFgS+g=; b=kxAaO69AZWQDLb7nYD2UoanTMMgtnX3TtdYOsH9CmGhj9KZkbC5OydNn MnMBXXOkSLqxm84K8VQ9hdtGGoJn11yTR3cNlug7RqR4mcwBjc0jm+B0I /LWW7xgk/0Gn+J+m8LU4hvDT2qwIVg/XHCmVm7Byj+WdS3jHtuw12nEqX E=;
X-IPAS-Result: =?us-ascii?q?A0BUEACqGr1f/5JdJa1iHgEBCxIMQIMhTgMHdFkvLgqEM?= =?us-ascii?q?4NJA401JpkEglMDVAsBAQENAQEtAgQBAYRKAheCFQIlOBMCAwEBAQMCAwEBA?= =?us-ascii?q?QEFAQEBAgEGBHGFYQyFcgEBAQECARIREQwBATcBDwIBCBgCAh8HAgICMBUQA?= =?us-ascii?q?gQBDQUigwQBglUDDiABozICgTyIaHaBMoMEAQEFhRsYghAJgQ4qgnODdoZXG?= =?us-ascii?q?4IAgREnDBCCTz6DeB4/gwAzgiyTcYdJnRMKgm6bIAMfogYdk0CgYwIEAgQFA?= =?us-ascii?q?g4BAQWBayOBV3AVGiEqAYI+UBcCDY4fDBcUgzqKWHQ3AgYBCQEBAwl8jQWBN?= =?us-ascii?q?AGBEAEB?=
IronPort-PHdr: =?us-ascii?q?9a23=3A9vaAFxQV7Y0ufZN7l9zHnRGqdNpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQB9+J4e5PjOzQvqv8H2cH5MXJvHMDdclKUB?= =?us-ascii?q?kIwYUTkhc7CcGIQUv8MLbxbiM8EcgDMT0t/3yyPUVPXsqrYVrUry648TUVHB?= =?us-ascii?q?PyPhYzLePwScbeis2t3LW0/JveKwxDmDu6Z+Z0KxO75QXcv8Ubm81sMKE0nx?= =?us-ascii?q?DIuXBPPe9RwDBl?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.78,366,1599523200"; d="scan'208";a="591932035"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Nov 2020 14:48:38 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AOEmcF9016488 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 Nov 2020 14:48:38 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 24 Nov 2020 08:48:38 -0600
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 24 Nov 2020 08:48:37 -0600
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 24 Nov 2020 09:48:37 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=le/w6c41KJcfJ0eujp36NR0xFDvM0eDf4Zr6yOyFGtN3rYvSc3CT9+w+HX5ruQMnBGej+AaOg1IC7FD7g8MHVZa16MfvJpLunbIPNwwpyqBKJEmjS87wiZlauItAslXhMOiOIeWzYWhzU9SwTQyaTpYfguPfLBPYDocCB4Xd4Rf45pnK5VkiXFporyENXndNEigiUJT1HGH7I00nsgjZSeRI6AhVPndryT/M//Ixn7zVl58Bl0/tJMatcsEkFm4fIPfxEu175ErdADnVmUTlJBlfRxrwhOzibI8DyMI1MZoBsNdy1Oi+bkS69mTTJ3MNnzKfkmUK3/8unSpDiUFBJw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Xknix4adZ+PbKg39dDZVwYrxDck2nAqLtQqdzoFgS+g=; b=ZD3TlM3uVOX0CwL+GPx1Y7I/a5Z1Lv4SxuxstF2om5/NsGDFlaPNEtYjJCAO/Hdze7R8Vr7OdoKXfuD7T6xHim9O2R/vNIWJtqwtmGWBLrAwsLXA9hpRT9BhzrNFQva9cqWWBUEyeTSIDzuCww0PzVzT98j4MOZJrGIG7wKxau6WvPDxED1zXI0TkJOvYNQxErEpxlwZkHwdHnrlQ6E7TDS9HrOw4PIIoKEFUMLBKRxcT06MDckoBXW8USHXcWJLIrxpzqoEXOtlzQjQupsfWEdVUg1S51MfgEajsaheZ9hac2WsupNmq4Vfloqcl39xJyJ8dp4bUhkRtxAFSBbERg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Xknix4adZ+PbKg39dDZVwYrxDck2nAqLtQqdzoFgS+g=; b=BX9shoJ128u2bU+9QHyzBOLAI0fBERupxzCVeSMDPkeJVZbUffSCQkP/XKFDXiEu4aaCenDwlt0JkZxCKs107OOJ5iUVfLnrXVzzhVLGMH7BgUyZz5vuOwDXgTUyz7cilrX/X3i5e70IHO+mSBgzne3lnKYWI/XUBKW/fJaLTlk=
Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BY5PR11MB4483.namprd11.prod.outlook.com (2603:10b6:a03:1bc::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.25; Tue, 24 Nov 2020 14:48:36 +0000
Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078%3]) with mapi id 15.20.3589.025; Tue, 24 Nov 2020 14:48:36 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: tom petch <daedulus@btconnect.com>, "last-call@ietf.org" <last-call@ietf.org>
CC: "spring-chairs@ietf.org" <spring-chairs@ietf.org>, "spring@ietf.org" <spring@ietf.org>, Joel Halpern <jmh@joelhalpern.com>, "draft-ietf-spring-sr-yang@ietf.org" <draft-ietf-spring-sr-yang@ietf.org>
Thread-Topic: Last Call: <draft-ietf-spring-sr-yang-23.txt> (YANG Data Model for Segment Routing) to Proposed Standard
Thread-Index: AQHWvE9TnHz4xC0KAECDY9QT1Wf1oanN1wuAgAfYZQCAAWHdAIAABAYA
Date: Tue, 24 Nov 2020 14:48:36 +0000
Message-ID: <88A25442-527C-4558-95F4-0E9DE0A79C63@cisco.com>
References: <160555515848.16672.7178345983262697681@ietfa.amsl.com> <5FB515F7.1020306@btconnect.com> <FE952290-CC70-4F30-8F22-6BC20D676FAB@cisco.com> <5FBCD392.3050706@btconnect.com>
In-Reply-To: <5FBCD392.3050706@btconnect.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.43.20110804
authentication-results: btconnect.com; dkim=none (message not signed) header.d=none;btconnect.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [136.56.133.70]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6ae3dbbd-0e7f-4aa8-31e5-08d890880643
x-ms-traffictypediagnostic: BY5PR11MB4483:
x-microsoft-antispam-prvs: <BY5PR11MB4483C0BEC0F58CBF5E035A13C2FB0@BY5PR11MB4483.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:4714;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 3QqR/6G3FYYWBjJRgb4obzkNkWyEBz6HJaVx0J2yg/4bl7L411biE0DjUVjCVFmHsUNyiY3Tb25+q+hvz053Hux4CDi6jPyzLe9k3vtaCwY0vufN4nIPdN51A9FO0CRSoBJ3MLawRkOSwIT9TLMWhJmAIYRA0JO5OwkFp6xDVRWl+wQpVkYL7ITJUhibwRDGm3fMXnAzOUo0ThEa+e6f7HxixT/48tMSEJ7VkkqRBZsqV/PXNI9wO+zwEpJjsopmEx5rktQvlxscWOcdar9gsmg6WKC9eutco4W07GIsBpwPCDcgG2ZqmHBZiu1LOT0RGlnt50ykNK/MpgTmVzZelQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(376002)(346002)(136003)(366004)(39860400002)(5660300002)(54906003)(83380400001)(33656002)(66574015)(6486002)(316002)(2616005)(110136005)(186003)(4326008)(26005)(296002)(6506007)(53546011)(66446008)(64756008)(66556008)(71200400001)(66476007)(478600001)(8936002)(2906002)(66946007)(86362001)(76116006)(36756003)(8676002)(6512007); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: h3crXKkl+r3jcrQDAQ2QV5zy7OrY2y6peshKDW2Lx6FzLQXpiKIxZ+5PrX9YpDa6qrDwDapFjPIwvyM4VdBMJ5/oqggFoLzsaA5l+xwVZ2N0LmQqcfsMzExOWvZ8fGsqL3FLCCab/M79A/VOKLxA+9nrlF4qFAuiQLiDXSbiFjZmikJVSsPXVAjaQUf7s8IArBwOaPyRdwquNbEHrT092DlqToMSos9+c+cGYnqXmP03SODkZKkve6YjuChMbqnf9SKW/yfkiAz/1dFmCARPTrnBpeXvDDR68ArB1vcTDSYVoilTOjr1ZWZF196vtf0IhJUFox7hS29gdSXI1bO4yOu0yw4lzlHnyZmQwnxyvpkINt906y1W/K0fYt2mAjIkUEFq3xERir8wvYoimAbuNdLzo5VQ/kIVWAuRNRhpgjVmyaR6U2rlgBcuRXLowO6CEqn1V+46//UqOlhVzRUzKunJLcJLNlKzsHtS3YLTH1q+hnJC3uGYGTYaUaJBSCqyTvd8PzpJeVRCeNYXD06tyl+RR50Ii4RvwvKRVSiOl/pIluRQaKIhD0ej8F8vZEiQ8sRskstTQmeENs47Lv//PBD5NtlJJyINFrItQWeGeo7gWM/ShzpZyBuZ8j178VTsaV8O+t2wy4ZIx2oAkXubKPA5K+FksgbJJKAgmm3yu2OeFbvYWZLUBV1S0p1HfMZ1HCsAL2ivtjoZKR9DVX41rbQHeGLAdUbAP0xDmyCR90p8umlSbdUCHtY8MhgOc4CaEVXWuMRpfBoSykaSi+StgzSPOdlYyjy31TIvuY+l8m7bIsaYi6D2ufkpafX3b+LHiitsqWu9iN2chY4R/sYerpb+k37X9lsjBXNSst6IAVpZeFNdEB6L97zbyElx/OyyvWCp1fSFjWrzljD2bfZWww==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <10043C1763DEA743A8558AC52DC826D5@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6ae3dbbd-0e7f-4aa8-31e5-08d890880643
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2020 14:48:36.5405 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: xxzkDr5D5wQpyRaVwWfFseCFo7Ize1KrL0dT/qhXaJ0JmETO50JVyn+fpNXu1LFm
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4483
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/VtqyH9K-4flgPl-WHaMbNlsqCm8>
Subject: Re: [Last-Call] Last Call: <draft-ietf-spring-sr-yang-23.txt> (YANG Data Model for Segment Routing) to Proposed Standard
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Nov 2020 14:48:43 -0000

Hi Tom, 

On 11/24/20, 4:34 AM, "tom petch" <daedulus@btconnect.com> wrote:

    On 23/11/2020 17:27, Acee Lindem (acee) wrote:
    > Hi Tom,
    >
    > See a couple responses inline enclosed in <acee> and </acee>. We are addressing the rest of your comments.
    >
    > On 11/18/20, 7:39 AM, "tom petch" <daedulus@btconnect.com> wrote:
    >
    >      IANA Considerations does not register the module names used in the modules
    >
    > <acee>
    > This is in the IANA considerations...

    <tp>
    Indeed; I do not see a registration of ietf-segment-routing-mpls!

Yes - I see the typo now that you pointed out which one. 

    >     This document registers a YANG module in the YANG Module Names
    >     registry [RFC6020].
    >
    >        name: ietf-segment-routing-common
    >        namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-common
    >        prefix: sr-cmn
    >        reference: RFC XXXX
    >
    >        name: ietf-segment-routing
    >        namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing
    >        prefix: sr
    >        reference: RFC XXXX
    >
    >        name: ietf-segment-routing
    >        namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls
    >        prefix: sr-mpls
    >        reference: RFC XXXX
    > </acee>
    >
    >      Examples are IPv4 only, IPv6 would be good
    >
    >      BGP is included when it comes to defining a router-id but is ignored
    >      everywhere else, such as signalling MSD, protocol extensions etc
    >
    >      reference "RFC XXXX" would be improved by including the title in all
    >      cases not just some
    >
    >      the scheme http: appears in many places.  It would be lovely if this
    >      really was the scheme but I fear that it is not
    > <acee>
    > This is directly from the RFC 8407 template in Appendix B. What would you suggest?

    <tp>
    Many I-D do now specify https: since that is now the only option 
    supported by the IETF; I have seen this called for by an AD.

As long as the URLs work, I don't see a problem with either. 


    > </acee>
    >
    >      module srcmn
    >        the upper bound must be larger
    >        the value must be greater
    >      consistency is good - I think greater is better
    >
    >      8.3
    >      operation states
    >      usually operational
    >
    >      two imports lack references
    >
    >      typedef router-id
    >      this is a well known type from RFC8394; it seems likely to confuse to
    >      redefine it with a related but different meaning
    >
    >      leaf enabled
    >      enables protocol extensions
    >      which protocols?
    >
    >      leaf protected
    >      it is used to protect
    >      how does it do that:-)
    >
    >      enum dual
    >      ... In this case will be advertised with backup flag set
    >      What is the backup flag?  It does not feature in RFC8660.  Needs an
    >      explanation and reference
    >
    >      container link-msd
    >        list link-msds
    >          leaf msd
    >      The usual YANG convention is for a list to be plural and the leaf
    >      singular.  You have the plural list but not the leaf.
    > <acee>
    > So you are asking for a change from "leaf msd" to "leaf link-msd"?

    <tp>
    Yes I would especially given node-msd.  I wish that YANG Guidelines said 
    more about container names.  I think that having the same identifier for 
    container, for list, for leaf (which I have seen in another I-D)
    will lead to mistakes so having a convention for list and leaf will 
    reduce mistakes but having another for container would be even better. 
    That said, I have yet to think of a good convention
Like you said, this would be the third time for link-msd(s). I'll see what my co-authors think. 


    In passing, must link-msd be >= node-msd?
Yes - this is clear in the associated MSD protocol drafts. 

    > </acee>
    >
    >
    >   And who needs the
    >      container?  This is mpls not a common module that might be augmented so
    >      what does the container give apart from complexity?
    >
    >      list policy
    >        leaf string
    >      YANG string caters for very large items of very complex character sets.
    >        Is that desirable?
    > <acee>
    > IETF models normally do not limit identifiers. An individual implementation could do this with a deviation.

    <tp>
    I know - I did see an AD challenge that, I think in IESG review, not 
    long ago.  SMI was better at this!

Since we have standardized on a maximum length for identifiers or even policy identifiers, I'm not going to pick one specific to this draft. It goes without saying that implementations will have a limit. 

Thanks,
Acee

    Tom Petch

    > </acee>
    >
    > Thanks,
    > Acee
    >
    >      leaf used
    >      will used plus free equal size?
    >
    >      Indicates if the binding is /instal/installed/
    >
    >      notification-segment-routing-global-srgb-collision
    >      a mix of conflict and collision;  consistency is good and I prefer the
    >      latter which is the name of the notification
    >
    >      containing /s/a/ mapping
    >
    >      ... sid collision
    >      again consistency good, prefer collision to conflicting
    >
    >      s.9
    >      I would have thought the srgb worthy of mention under sensitive nodes
    >
    >      Tom Petch
    >
    >
    >      On 16/11/2020 19:32, The IESG wrote:
    >      >
    >      > The IESG has received a request from the Source Packet Routing in Networking