Re: [Teas] [yang-doctors] Yangdoctors early review of draft-ietf-teas-yang-rsvp-10
Tarek Saad <tsaad.net@gmail.com> Tue, 14 May 2019 14:46 UTC
Return-Path: <tsaad.net@gmail.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 5950E12006F; Tue, 14 May 2019 07:46:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 4VoJhyjYxG9w; Tue, 14 May 2019 07:46:19 -0700 (PDT)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B101120135; Tue, 14 May 2019 07:46:02 -0700 (PDT)
Received: by mail-qk1-x735.google.com with SMTP id n68so7854388qka.1; Tue, 14 May 2019 07:46:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=XwxjEGDkIswOg0LRpovjnzZmc0Q1vYbsSykuKw5qfeI=; b=FSud/klVFlx1fLoFtvsNubJ/5ZxMa5ec4U32fDuNSflh8s/jZQIXUY++NU9UOQ6yx5 GOUHrNBm+t+P/ggfSFZfWgzdDWnzzXDwhbuWjfH8k3chhdN25/0qY7hORKruZNvtfEcR EDvgG+NKYLIwVoM55NVvHb9+Vsm8Aj4veQzCAszQSGU9aGMLMHOPHLQLUJyCuL1183FC nkOcfHXj9UeJWHX7w2Q1152HRjRBK5Nqdb+cRBKST8gQXKRz1lY6Ub03RglUdwRDHvYk MpNKpyQR358QG6GI9/6H9zSTX20u2zrRrVpyv3mhWHj5fjC0LE5IJDos3k0NudSpRRm2 7ZNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=XwxjEGDkIswOg0LRpovjnzZmc0Q1vYbsSykuKw5qfeI=; b=qH3Xg2EahYQUrr6u77LU/nK5Kma3sviFXcSVDtIfWzywiUIz/vw/53EOxl/kf/KntI kT64VU31XeSrfqziykpmLJnUe2jzm9sVjvFHcaU8dRFs4ZzkdxHPnARNowPcw57aHpkp Bsh2EnXWWEq+uSKVyDj4wbitRzkLArBWg2IYUmKCl9W3C1RW5d6FVbkzdprrWoCm6FlE TSj2zmF0/QxKet2TMw+o9MS+k5rqrIsbP+RBZCrahuXocWnOzlMRQsgiort2OuyxQdnx PAeMYnLGOxrTPzKgOQH8QkEYMNuBgkutUJTPhpLosGTyFABkwAG00dChKQ4V9XIXnBvc M58w==
X-Gm-Message-State: APjAAAUzUDp5dslIbF+kPsMLhNKZ88H/ptozElQwynKWZw8bfoVPbVS8 HGCE9yrhMZmLeva5/B6LKqShxIxVwX4=
X-Google-Smtp-Source: APXvYqx1O0d8BZNJn0yhJHvQWvZumNiHqy61QErtdN13L+8U6t69/BcNvXOc6qpX8Mss4HTcY9sbVQ==
X-Received: by 2002:a37:a28c:: with SMTP id l134mr25233205qke.43.1557845161280; Tue, 14 May 2019 07:46:01 -0700 (PDT)
Received: from BN8PR06MB6289.namprd06.prod.outlook.com ([52.96.29.13]) by smtp.gmail.com with ESMTPSA id m19sm935517qtk.52.2019.05.14.07.46.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 May 2019 07:46:00 -0700 (PDT)
From: Tarek Saad <tsaad.net@gmail.com>
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>
Thread-Topic: [Teas] [yang-doctors] Yangdoctors early review of draft-ietf-teas-yang-rsvp-10
Thread-Index: AQHVCbb3VaZZva/8i0WZe49LJoH6sqZqtA85
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Tue, 14 May 2019 14:45:59 +0000
Message-ID: <BN8PR06MB6289AC30D85BC3D22693C65CFC080@BN8PR06MB6289.namprd06.prod.outlook.com>
References: <155692863223.7173.7717533907709205656@ietfa.amsl.com> <EC71AEDD-6D31-440C-A6BB-1BBE3D931702@cisco.com>
In-Reply-To: <EC71AEDD-6D31-440C-A6BB-1BBE3D931702@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_BN8PR06MB6289AC30D85BC3D22693C65CFC080BN8PR06MB6289namp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/qPUUKGWYgXOvY0xh2PWQQK56aZo>
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: Tue, 14 May 2019 14:46:25 -0000
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
- [Teas] Yangdoctors early review of draft-ietf-tea… Ebben Aries via Datatracker
- Re: [Teas] [yang-doctors] Yangdoctors early revie… Reshad Rahman (rrahman)
- Re: [Teas] [yang-doctors] Yangdoctors early revie… Tarek Saad
- Re: [Teas] [yang-doctors] Yangdoctors early revie… Reshad Rahman (rrahman)
- Re: [Teas] [yang-doctors] Yangdoctors early revie… Reshad Rahman (rrahman)
- Re: [Teas] [yang-doctors] Yangdoctors early revie… Jan Lindblad
- Re: [Teas] Yangdoctors early review of draft-ietf… Tarek Saad