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

"Reshad Rahman (rrahman)" <rrahman@cisco.com> Mon, 13 May 2019 18:08 UTC

Return-Path: <rrahman@cisco.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96D61201BB; Mon, 13 May 2019 11:08:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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=SRZ+6xOc; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=cQIk61Iq
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 KIw_PdqQHg_z; Mon, 13 May 2019 11:08:46 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5DA1200D6; Mon, 13 May 2019 11:08:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6228; q=dns/txt; s=iport; t=1557770926; x=1558980526; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pb0arSpmOtlsLVhN9zXqdvU+ux9G0Jgx8kEcMBAYu8M=; b=SRZ+6xOcDe2LDOE+idkCKCBLOcx2Lk1Yo2EPeIIEDRWpHBQ2WzgobRuz 9TZRPvPuL4+n9Foke59ABJDnB2w1M4Yu5l8MripHGYg5x+iIzptd+geQz eA8K0pg2Ogv5zn9bePkj/mlYRI+kQHAZ0TgyDCBjfL1JhttpYYWYSHifu Q=;
IronPort-PHdr: =?us-ascii?q?9a23=3AKTO+gRMX2W3O0i4k0m8l6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjhNvfqaiU8NM9DT1RiuXq8NBsdFQ=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BsAABjsdlc/5hdJa1aCh0BAQUBBwU?= =?us-ascii?q?BgVEIAQsBgT1QA2lVIAQLKIQRg0cDhFKKLJl8gS6BJANUCQEBAQwBARgLCgI?= =?us-ascii?q?BAYRAAheBfCM0CQ4BAwEBBAEBAgEEbRwBC4VLAgQBARAREQwBASwLAQ8CAQg?= =?us-ascii?q?aAiYCAgIlCxUQAgQOBSKDAAGBagMdAQ6hBgKBNYhfcYEvgnkBAQWFBhiCDwM?= =?us-ascii?q?GgQsoAYoLgUMXgUA/gREnH4JMPoJhAQECAYEzKxeCczKCBCKLMYItmXsJAoI?= =?us-ascii?q?JhiCIaoNSFAeCE5NZjDKBIoU0jjACBAIEBQIOAQEFgU84KYEucBU7KgGCQYI?= =?us-ascii?q?Pg2+FFIU+AXIBC4EdjmYBAQ?=
X-IronPort-AV: E=Sophos;i="5.60,465,1549929600"; d="scan'208";a="272523722"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 May 2019 18:08:45 +0000
Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x4DI8jRK028965 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 13 May 2019 18:08:45 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 13 May 2019 13:08:44 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 13 May 2019 13:08:43 -0500
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 13 May 2019 13:08:44 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pb0arSpmOtlsLVhN9zXqdvU+ux9G0Jgx8kEcMBAYu8M=; b=cQIk61IqESkyHs6J2kYzTbe2qEnaQ74peXDG+wFaKePE8XmeymzNyzmeCPBIkSeBink4T4ZIAS686ANlJfkjch+ebFKIsSvj9qkhH23gljWAPZQCcwi68ff10RhAXF74JMuAA/ZZkTI6dcpZ8XkURMuX3ldeXd4g95A/fU95YCY=
Received: from DM5PR1101MB2105.namprd11.prod.outlook.com (10.174.104.151) by DM5PR1101MB2265.namprd11.prod.outlook.com (10.174.104.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.21; Mon, 13 May 2019 18:08:43 +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; Mon, 13 May 2019 18:08:43 +0000
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
To: "draft-ietf-teas-yang-rsvp.all@ietf.org" <draft-ietf-teas-yang-rsvp.all@ietf.org>
CC: "teas@ietf.org" <teas@ietf.org>, Ebben Aries <exa@arrcus.com>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>
Thread-Topic: [yang-doctors] Yangdoctors early review of draft-ietf-teas-yang-rsvp-10
Thread-Index: AQHVAg3aWXDUm82pK0uCi6qbpHp+4KZpJqCA
Date: Mon, 13 May 2019 18:08:42 +0000
Message-ID: <EC71AEDD-6D31-440C-A6BB-1BBE3D931702@cisco.com>
References: <155692863223.7173.7717533907709205656@ietfa.amsl.com>
In-Reply-To: <155692863223.7173.7717533907709205656@ietfa.amsl.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: 96eeb46b-f9d8-43ed-011f-08d6d7ce08c9
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DM5PR1101MB2265;
x-ms-traffictypediagnostic: DM5PR1101MB2265:
x-ms-exchange-purlcount: 6
x-microsoft-antispam-prvs: <DM5PR1101MB22654C945A987E82EE4DF28DAB0F0@DM5PR1101MB2265.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:4125;
x-forefront-prvs: 0036736630
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(346002)(39860400002)(366004)(136003)(37854004)(199004)(189003)(86362001)(68736007)(446003)(486006)(186003)(2351001)(7736002)(91956017)(46003)(11346002)(81156014)(73956011)(81166006)(966005)(99286004)(2501003)(102836004)(25786009)(58126008)(54906003)(6486002)(316002)(305945005)(5640700003)(6512007)(6306002)(66446008)(14444005)(256004)(64756008)(76176011)(476003)(66476007)(66556008)(2906002)(82746002)(2616005)(6506007)(76116006)(6436002)(4326008)(229853002)(6116002)(53936002)(66946007)(6916009)(36756003)(71200400001)(83716004)(8936002)(8676002)(71190400001)(33656002)(478600001)(6246003)(5660300002)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1101MB2265; H:DM5PR1101MB2105.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: pt16uIk2wEpPj5UUj44thd3lU/iPvv6GTm86JSOHP1z23KoTAEWy9UO7PCtEyBu7n1J0I2UCE4zi3vi6tPgKHjvq4A2msRnvqovSyxyglOM75Sp4mPPTdE8uBDPdpTNL816kizGTxuRM5q5V7bW4R05NX1wnUN+CGekqan6MtrJrclNxr1RaWlVJY1Q/KiMSUvELfj8QhJj87NwTnTuqO4p9Wq/aIZ/79tf0N0jNh7XO29E5hvnq1Y9Lg+SkIH73M5pV+Mv4ZwZaiyPTHnrnER0hCVg3BO+GCU8xorlH93BnIPpi3gwbHhHfBaFZo01Ha1C7oVMBF7gYubwonESt54FGJHrlbHXCS2AFK6/jBWPAzl3401XM5ZRj8VXtxp1u421KhHhdjpVbARRnEcS/jTdGU4lixj9rl/tfsapnQTY=
Content-Type: text/plain; charset="utf-8"
Content-ID: <07A8AB526AC97442BB02F1F6B91B3C41@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 96eeb46b-f9d8-43ed-011f-08d6d7ce08c9
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2019 18:08:42.8458 (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: DM5PR1101MB2265
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.28, xch-aln-018.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/E1CwwftEGufGH8sHIW2mqn4lBDk>
Subject: Re: [Teas] [yang-doctors] Yangdoctors early review of draft-ietf-teas-yang-rsvp-10
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 May 2019 18:08:57 -0000

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