Re: [yang-doctors] [Teas] Yangdoctors early review of draft-ietf-teas-yang-rsvp-10

"Reshad Rahman (rrahman)" <rrahman@cisco.com> Tue, 14 May 2019 16:31 UTC

Return-Path: <rrahman@cisco.com>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7735F120104; Tue, 14 May 2019 09:31:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 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, 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=lGQ6j7HM; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=MBP2wwZ6
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 VTePagLXK0nL; Tue, 14 May 2019 09:31:52 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00AF3120045; Tue, 14 May 2019 09:31:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32715; q=dns/txt; s=iport; t=1557851511; x=1559061111; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qzsIQCWLMwZPahQXYYl5c8jdmja0NsIxGGYlzOhlMCM=; b=lGQ6j7HMmry2Ah4QDlAyctAW/QuezUqwn+rHX8UIW23lpyILrFv8Jy2D I82XE+ScZ8AYslIetizxCjy5FdGC7gLCKXAXxMl6PkHhOtL021IM8pQeu UvoutOyskDOStqkQ92hEzN+I31A/EJI3hDzDG0uxgFIcZJFjbVfDptiif 4=;
IronPort-PHdr: =?us-ascii?q?9a23=3AqHTc4Re28cp0nauwBZ7IikX6lGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGRD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/dTYzHMFLUndu/mqwNg5eH8OtL1A=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAADf7Npc/5BdJa1aChsBAQEBAwE?= =?us-ascii?q?BAQcDAQEBgVEGAQEBCwGBDi9QA2lVIAQLKIQRg0cDhFKKLIJXiT+NZoEugSQ?= =?us-ascii?q?DVAkBAQEMAQEYAQoKAgEBhEACF4IGIzQJDgEDAQEEAQECAQRtHAyFSgEBAQQ?= =?us-ascii?q?BARARHQEBLAsBDwIBCA4DAwECIQoCAgIfBgsdCAIEAQ0FIoMAAYEdTQMdAQ6?= =?us-ascii?q?gVgKBNYhfcYEvgnkBAQWFAg0Lgg8DBoEzAYoLgUMXgUA/gRABJx+CHi4+ghp?= =?us-ascii?q?HAQECAYEzQgkGgmQyggQijWCEU4gQjGE5CQKCCYYhiGcEg1IbghSKQIkajDS?= =?us-ascii?q?BIoU2gU+MYwIEAgQFAg4BAQWBTzgpgS5wFTsqAYJBgg83gziEWTuFPgFyAQu?= =?us-ascii?q?BHY9GAQE?=
X-IronPort-AV: E=Sophos;i="5.60,469,1549929600"; d="scan'208,217";a="562754768"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 May 2019 16:31:50 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x4EGVoUd026269 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 May 2019 16:31:50 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 14 May 2019 11:31:49 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 14 May 2019 11:31:48 -0500
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 14 May 2019 12:31:48 -0400
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=qzsIQCWLMwZPahQXYYl5c8jdmja0NsIxGGYlzOhlMCM=; b=MBP2wwZ6a2wRUCeakJ8fpdf2n4OFXvyw6CChyFevk18da1lLYL3oYqAgt2V0bIn6G/iCByAXelQlVYFCPS4jeETO20cE43YovYJTkR64oQgFlyVUflkKgvSq/q07WkwNffQSqYs4Wl644KqCZbqEMLEWXmdoBtby2iDBYyAu4B0=
Received: from DM5PR1101MB2105.namprd11.prod.outlook.com (10.174.104.151) by DM5PR1101MB2332.namprd11.prod.outlook.com (10.173.173.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.16; Tue, 14 May 2019 16:31:46 +0000
Received: from DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::6ce2:350d:6bed:7dde]) by DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::6ce2:350d:6bed:7dde%2]) with mapi id 15.20.1878.024; Tue, 14 May 2019 16:31:46 +0000
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
To: Tarek Saad <tsaad.net@gmail.com>, "draft-ietf-teas-yang-rsvp.all@ietf.org" <draft-ietf-teas-yang-rsvp.all@ietf.org>
CC: "yang-doctors@ietf.org" <yang-doctors@ietf.org>, "teas@ietf.org" <teas@ietf.org>, Ebben Aries <exa@arrcus.com>
Thread-Topic: [Teas] [yang-doctors] Yangdoctors early review of draft-ietf-teas-yang-rsvp-10
Thread-Index: AQHVAg3aWXDUm82pK0uCi6qbpHp+4KZpJqCAgAGcwYD//9p/gA==
Date: Tue, 14 May 2019 16:31:46 +0000
Message-ID: <9653FA2D-4C36-443F-B462-89D788B9E8FC@cisco.com>
References: <155692863223.7173.7717533907709205656@ietfa.amsl.com> <EC71AEDD-6D31-440C-A6BB-1BBE3D931702@cisco.com> <BN8PR06MB6289AC30D85BC3D22693C65CFC080@BN8PR06MB6289.namprd06.prod.outlook.com>
In-Reply-To: <BN8PR06MB6289AC30D85BC3D22693C65CFC080@BN8PR06MB6289.namprd06.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.6.190114
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com;
x-originating-ip: [2001:420:2840:1250:2421:2f0a:1dbc:638e]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6fa78b3b-0be9-427e-45f9-08d6d889a87e
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DM5PR1101MB2332;
x-ms-traffictypediagnostic: DM5PR1101MB2332:
x-ms-exchange-purlcount: 9
x-microsoft-antispam-prvs: <DM5PR1101MB23324D73A8A10742D4A71C5CAB080@DM5PR1101MB2332.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:3383;
x-forefront-prvs: 0037FD6480
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(346002)(376002)(366004)(136003)(37854004)(189003)(199004)(6486002)(316002)(7736002)(6436002)(6512007)(83716004)(14454004)(8936002)(8676002)(186003)(81166006)(81156014)(53546011)(6506007)(6246003)(6306002)(54896002)(66446008)(66476007)(9326002)(2906002)(58126008)(229853002)(54906003)(110136005)(33656002)(25786009)(4326008)(76116006)(91956017)(73956011)(66946007)(64756008)(53936002)(66556008)(256004)(99286004)(14444005)(966005)(76176011)(46003)(486006)(478600001)(2616005)(11346002)(446003)(476003)(71190400001)(71200400001)(102836004)(82746002)(2501003)(68736007)(36756003)(5660300002)(86362001)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1101MB2332; H:DM5PR1101MB2105.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: PHSZL+rzbPLmpiJNw8QYRLybPyV/HyeCmelhMVjLiklPMeyiHZJXwYA+floNDJPYJDLll7nfMeTYSHVRKk/2wERTsBQDciJoHBO6HFvi7OyDrel5z4Pl4LsXceE2Kfsuz9ZZBbpE/7GbUhLBqmdkyh3a0tVKgltFmfjBuEI+COXyOvbQTDvjanxPtr2efhsAph1fYUntr0wVWVKvzZGhbUaZzHoq7HS3yvktQ9QpnkwEHGgdYenvy/pjthR2a4UO7SQq70Im11MOSH84f+/nLpEbK0Jv2QNZWoitgtd2Yy3t3zLm9CkCEMWPiTp/M4Zm0sn5DngPd8Behm9OpJCKhxS/HbSKpWHif0nNebrBtFre8aBRYOA4tENd2QXbqo6F7B/9Ev4wjttVgMq67PpjX1KIsMmY9alRp8NnITwvVN4=
Content-Type: multipart/alternative; boundary="_000_9653FA2D4C36443FB46289D788B9E8FCciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6fa78b3b-0be9-427e-45f9-08d6d889a87e
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2019 16:31:46.6949 (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-Transport-CrossTenantHeadersStamped: DM5PR1101MB2332
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/72aGgqhKPoQCHO1No0RdfGnnXI0>
Subject: Re: [yang-doctors] [Teas] Yangdoctors early review of draft-ietf-teas-yang-rsvp-10
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 May 2019 16:31:56 -0000

Hi Tarek,

If a user wants to have information for a specific 2205 session or a 3209 session, an artificial key or no key doesn’t help for that situation: the whole list has to be read until the session is found. Why not have separate lists (under a container) for the different session types, that way you can have meaningful keys for the 2205 and 3209 sessions.

Regards,
Reshad.

From: Tarek Saad <tsaad.net@gmail.com>;
Date: Tuesday, May 14, 2019 at 10:46 AM
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>;, "draft-ietf-teas-yang-rsvp.all@ietf.org"; <draft-ietf-teas-yang-rsvp.all@ietf.org>;
Cc: "yang-doctors@ietf.org"; <yang-doctors@ietf.org>;, "teas@ietf.org"; <teas@ietf.org>;, Ebben Aries <exa@arrcus.com>;
Subject: Re: [Teas] [yang-doctors] Yangdoctors early review of draft-ietf-teas-yang-rsvp-10


Hi Reshad,



Base RSVP RFC2205 defines the session as. "An RSVP session is defined by the triple: (DestAddress, ProtocolId      [, DstPort])." RFC3209 defines a session object for RSVP-TE LSP(s) as tuple (tunnel endpoint, tunnel ID, extended tunnel ID). Since keys are mandatory leafs for lists, and to make it generic, we thought of a having an independent index key for the list.

Thinking more of it now, since the list is state/read-only, the key is optional and omitting it may be better. We can consider this in the next update to the document, thanks for pointing it out.



Regards,

Tarek





On 5/13/19, 2:09 PM, "Teas on behalf of Reshad Rahman (rrahman)" <teas-bounces@ietf.org on behalf of rrahman@cisco.com>; wrote:



    Hi,



    Question to the authors (I haven't followed this draft so apologies if I'm trying to revive a dead horse): why is there an artificial index (leaf local-index) for the sessions list, why not uniquely identify the session with destination address etc? Is it because there are different types of sessions?



    Regards,

    Reshad.





    On 2019-05-03, 8:11 PM, "yang-doctors on behalf of Ebben Aries via Datatracker" <yang-doctors-bounces@ietf.org on behalf of noreply@ietf.org>; wrote:



        Reviewer: Ebben Aries

        Review result: On the Right Track



        2 modules in this draft:

        - ietf-rsvp@2019-02-18.yang

        - ietf-rsvp-extended@2019-02-18.yang



        No YANG compiler errors or warnings (pyang 2.0, yanglint 1.1.16, confdc 6.6.1)



        Module ietf-rsvp@2019-02-18.yang:

        - Remove WG Chairs from contact information per

          https://tools.ietf.org/html/rfc8407#appendix-B

        - Use of 'state' containers.  It is stated in Section 2.3 that 'Derived state

          data is contained under a "state" container...'.  My only comments here are:

          a) Should use caution when using 'state' containers in NMDA compliant

          modules.  Rob put together a nice doc here that I won't reiterate:

          https://github.com/netmod-wg/FAQ/wiki/NMDA-Modelling-FAQ

          Using such nomenclature locks you into r/o nodes only.

          b) In some cases, the hierarchy is a bit redundant (statistics/state).

          Other NMDA compliant modules will not introduce another 'state' hierarchy

          for instance (see ietf-interfaces)

        - leaf 'packet-len' is abbreviated while most other leafs are not

        - authentication-key is of type string.  Is this leaf mean to be clear-text?

          There is nothing associated with this type that would imply special

          treatment in handling.

        - crypto-algorithm: Are all identities from ietf-key-chain supported?

        - Pluralization on counters:  e.g. 'in-error' vs. 'in-errors'. Maintain

          consistency with other modules (see ietf-interfaces)

        - Normative references are missing for some of the modules imported.  These

          must be added per https://tools.ietf.org/html/rfc8407#section-3.9



        Module ietf-rsvp-extended@2019-02-18.yang:

        - Remove WG Chairs from contact information per

          https://tools.ietf.org/html/rfc8407#appendix-B

        - Use of 'state' containers.  It is stated in Section 2.3 that 'Derived state

          data is contained under a "state" container...'.  My only comments here are:

          a) Should use caution when using 'state' containers in NMDA compliant

          modules.  Rob put together a nice doc here that I won't reiterate:

          https://github.com/netmod-wg/FAQ/wiki/NMDA-Modelling-FAQ

          Using such nomenclature locks you into r/o nodes only.

          b) In some cases, the hierarchy is a bit redundant (statistics/state).

          Other NMDA compliant modules will not introduce another 'state' hierarchy

          for instance (see ietf-interfaces)

        - Pluralization on counters:  e.g. 'in-error' vs. 'in-errors'. Maintain

          consistency with other modules (see ietf-interfaces)

        - 9 features are defined with no 'if-feature' statements.  Where are these

          feature conditions meant to be used?

        - Normative references are missing for some of the modules imported.  These

          must be added per https://tools.ietf.org/html/rfc8407#section-3.9





        General comments on the draft/modules:

        - The state container and list key designs appear very familiar to that of

          OpenConfig modules however not consistent with IETF module design.

          Consistency is key from each producing entity (e.g. IETF in this case)

        - The draft mentions RPCs and Notifications however none are defined within

          the modules

        - Section 2.3: Has examples of RPCs and Notifications that are non-existant in

          the modules

        - Abstract: s/RVSP/RSVP/

        - Abstract: s/remote procedural/remote procedure/

        - Section 2: s/extensiion/extension/

        - Section 4: Update the security considerations section to adhere to

          https://tools.ietf.org/html/rfc8407#section-3.7 and

          https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines

        - Various (missing) wording/pluralization cleanup throughout that I'll defer

          to the RFC Editor.  A once over proofread should solve this.



        _______________________________________________

        yang-doctors mailing list

        yang-doctors@ietf.org

        https://www.ietf.org/mailman/listinfo/yang-doctors





    _______________________________________________

    Teas mailing list

    Teas@ietf.org

    https://www.ietf.org/mailman/listinfo/teas