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

tom petch <daedulus@btconnect.com> Tue, 24 November 2020 09:34 UTC

Return-Path: <daedulus@btconnect.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733863A1271; Tue, 24 Nov 2020 01:34:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 tYlHp6wIFlwQ; Tue, 24 Nov 2020 01:34:20 -0800 (PST)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60092.outbound.protection.outlook.com [40.107.6.92]) (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 E44513A125F; Tue, 24 Nov 2020 01:34:19 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PqqFsQY873ZOPzrvwu6XHohvlB78z0YSVwWCNWzJ325rtQK3lSMPH8ONjBC0DlAJuhlW/9r6IV2W+9AoYoJQ/ijrOsydD5ut75G3z+JYdxFw56n3bWU+KjUJjdzCGqPpcWJ7Fs19B55fslyHk3ZaQUSsgtNA9NVOaA0cAgzqlX/1GY2+kHx3c4kR4hsgjrQqsfCE8lyDjJC6RhpFl4SJqw832MynedO+Jf+s6xdedvyjbjVXZfQfXweO1gaOZkh4uM1mxYXJQmbZmejGLtOCS/p8WpAqeFXYn4AAY7AY76hszVukc7BET1zRxBrz1HXHargPL34eM/qTt+sUn3hOzQ==
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=ptLaf/+tz/KUTcrDXPzNHxzAkA+kiUSemOUqu5+R9r0=; b=g+G8aBcWbTh4f4JlIYU7DJP8lYbBMzgctJX6tJjcLac/91AeIYTCzWIiYn7FiWYmLEDcjBT01VY1dcDKQB8A65froAgCKfKGwiflvRQO4uyyBRk/5GAhYJ2Om5ZTibYW6G9RGbix2k9UzZ6cEEvctse2UToLcGZ+b4KJaPx/5Sm34xMKmB4xDA8Bmxc/4AbtiPRe8krEPsObm36FKdvhMOLx2UcBpvK5gMbSepvD3AtD+05oXjXEp5sq97NfzaYuts1UwSgNhsAOqPetT8+Lk2Ojlzk11SIYdWshj+MnlXaIxD6fqQunGb0VG68QyC4wAiaodKY1gBUHEPVsbnxovA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ptLaf/+tz/KUTcrDXPzNHxzAkA+kiUSemOUqu5+R9r0=; b=mrEO3FBR6/Jf96XK1WpF+DJ9agMTLTuidl2N8uqe1XKNyVsrNEcCot8wwSqtC3X7luxizOgDzHI6Yz0kwJ582DQdG+o/K66q81Q70iYYd8VmPpAEBRicQ1RsqtwgwmWW3OiXIxByv4BLfw6VYyKiECpqjw7FmZuXwYWMW1hwn8c=
Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com;
Received: from VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) by VI1PR0701MB7037.eurprd07.prod.outlook.com (2603:10a6:800:195::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.14; Tue, 24 Nov 2020 09:34:17 +0000
Received: from VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae]) by VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae%7]) with mapi id 15.20.3611.020; Tue, 24 Nov 2020 09:34:17 +0000
To: "Acee Lindem (acee)" <acee@cisco.com>, "last-call@ietf.org" <last-call@ietf.org>
References: <160555515848.16672.7178345983262697681@ietfa.amsl.com> <5FB515F7.1020306@btconnect.com> <FE952290-CC70-4F30-8F22-6BC20D676FAB@cisco.com>
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>
From: tom petch <daedulus@btconnect.com>
Message-ID: <5FBCD392.3050706@btconnect.com>
Date: Tue, 24 Nov 2020 09:34:10 +0000
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
In-Reply-To: <FE952290-CC70-4F30-8F22-6BC20D676FAB@cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [86.146.121.140]
X-ClientProxiedBy: LO2P265CA0093.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:8::33) To VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.1.65] (86.146.121.140) by LO2P265CA0093.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:8::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.3589.20 via Frontend Transport; Tue, 24 Nov 2020 09:34:16 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: bce85ad0-6775-40ed-bb7f-08d8905c1cdf
X-MS-TrafficTypeDiagnostic: VI1PR0701MB7037:
X-Microsoft-Antispam-PRVS: <VI1PR0701MB703705018F6F454A6D2544EAC6FB0@VI1PR0701MB7037.eurprd07.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:3513;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: lWlJljam27eQfTzBWiHvUBTpGpVFXcmv/ztPSO/NGe0edsmuJvNSsNMEA+We0S3paraVDEQ/b+/s696MLLuW0xSr5kRRDywY/VTmBNbsz3Glmk8nKUlHH115qsxOBkqp2vpCr5eCD4zw62YVBpSnW/TGniWlxL8G4Jbb9BXgTZ/t9Nezk0xK/uLGEdrunxOiW5ErXDzgq3+vlUmnzig0JNXqyVdRBKUze9d3seJLFoge+70NVAqRsL9p+WUQBoYjsqRE2fhJ9CcLgHWk64hkIYmSsU+COKSdwuBkhRa7r2zwkb10l5RlEI4znatKRR99lLMhw0ga9cp7xXVoZyOjew==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB6704.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39860400002)(376002)(366004)(346002)(396003)(83380400001)(2906002)(4326008)(478600001)(6666004)(33656002)(6486002)(5660300002)(66556008)(66476007)(66946007)(66574015)(8676002)(8936002)(26005)(2616005)(956004)(16576012)(36756003)(316002)(52116002)(53546011)(110136005)(86362001)(16526019)(186003)(87266011)(54906003); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData: qBITdvzGmTQ6pefgQqgvYye7iG26jo6m++VtY9967PyGYmmOZEoz115vByRknYm4jnJPB1ogBZYpC/1WgZVbQv7a+CsRsAuTnfS9Y6vYtsAgs8mMUkOCf4ftx1ZD47+0uXJBLASUqk9RK64Fvtz5ZDp9ZCIr4mOs654gVpbBBLwuSfkyMoeBWV9u8eM1cS52XyiI9I+ylln3z6j8c89g/BLS9iBOhuVQCJFj+HDeQ1Zt5PhNh7EBUFou/I7/uFPEW6CmXKOlqyuCNVQv6gLdxC4gNqeFNaxbZeJAbllWhyhsqeV8he84s6FrYgEYINHtWOyXIRsihUWHMM2mxqG1JU6e87l5BDJxzY2nDZcEzY2qZhshXuzTQjGLTnSxyWLWIIPhluVScPkBZT7PiHEiDZHGwRq7PaVITRxZpD9c2v2UrrIVs7iB+IJELK3hCzeqSQnAFdF9+T5LhBOEv7htEkJ0PRA/AuJgaLu2oX6sXrdIAw8zKI0K6uHG5GTmsWQkw7fjoTafv+BDnzq1zU6pAw+24Z5nfEJfrlu84h/QiU8MnVnhuEtpNJPaDZo3ToNBVPZs7TRzbgqFINLwoOXrCKxQz78F4SNzzBljrQ66XpgnbsTA5+eO3zzAIciH9wNeEDQq4dnfJ1ubWZdYIoiFKjFUILIkeKuy047I/wc+hEzX+1Jo4s9GEFvw+cNtfLvC5v6vjljsU/AFvBxVfrC1Jr3LIHjh+XUwJ9DYMcF9RhiPUTd9KkrugQ1eTK1CKKpDsn77jtOQuhGYKmVU6yqzAeOd2LD2asFfn9OEESe/WDMWZnmFV2lGNlz3LpCBqZ28V/wqs7rMvEoHiyfiDY3Gsv/AuPEaGczzXCG5u9qow1HEuwPbu2nx4JQmdEXhTT+Bg6GkDLN9cuZuh8HGRTKUkg==
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bce85ad0-6775-40ed-bb7f-08d8905c1cdf
X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6704.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Nov 2020 09:34:17.4704 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: evd5/Yd+6hoLj927n9pvpPPilu1k/cilSWcr3csnKdeOFCQ2E7EcIHfyfz1bQ079/pcDIbutN1raYz3kBk6GLA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB7037
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/DR1h8dgljWCZbgE5xmeDSQcmdHY>
Subject: Re: [spring] Last Call: <draft-ietf-spring-sr-yang-23.txt> (YANG Data Model for Segment Routing) to Proposed Standard
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Nov 2020 09:34:23 -0000

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!

>     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.


> </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
In passing, must link-msd be >= node-msd?

> </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!

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