[netmod] js review of draft-ietf-core-sid-12
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Mon, 30 March 2020 21:31 UTC
Return-Path: <J.Schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7F93A137A; Mon, 30 Mar 2020 14:31:43 -0700 (PDT)
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, 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=jacobsuniversity.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 uBVikBb2EDGx; Mon, 30 Mar 2020 14:31:40 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0618.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::618]) (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 25C313A137B; Mon, 30 Mar 2020 14:31:39 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UMzbwSyzMfM3kGbQJnMMvMCe5Mb02CNNI9q3ROAe4R2RvUwRyEXnpUYpjWsS03LZPer+h61nJ9JhBcRQwx0foHErB/FYvaHGGQ4nrMy0szf5ETraIxByswC3rjLpYp4e66zKB8NY/cUlURaouMDQqtHth/3/z/z71jv2Kqke0BF9EnFb2pMP71LVRffWiY1omd67yDPRihWhlxzBgNJowCvKBg5wED4qY40RKrI/lZuI/nmb/8aTg4RkiRgy5zqJamu77VQ39hlPv5xEgGAYJc5Oc2oTSWNTpIYarC67i7ucp1o7sRbEH0go8FSNxPc82ypHmq8UaPL3EgbxXHZjLw==
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=G6ZSHLPKH0kQ3aMzdF4Axils08PyKYk/ErNJuFfl/6Y=; b=FQpFsNI0HzPCLFD4CpDpu94HdJihJekDFwyIHdanLN4+eFe5E+83L9jrdpawsfgALogptleuzwHcM3oLTBQ0hWxQBywNjPx/swLC9BMLjN/rLDbQLxjNDbe1w4CcU6A2ri7fmGd9O7OqFNwmSqksBbw3B4pS9FrKKZfkOhTv+Jr3g1sXTHxeJXkMXYPts+wF5QISre9/UYRBCtqIShHV++e4SrBgTxeM4TilnziHcccxyn0ZCvO7U2ZZF/0frG050tqxBU144N5P009OOAUu+hRVcdiOeAwi0sfHXOdg/OBuT8Zs4R1DuCDQo1MpA5pMuzIy+U18fS9NCTNbHC+97Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G6ZSHLPKH0kQ3aMzdF4Axils08PyKYk/ErNJuFfl/6Y=; b=ecqaGIVLctgo4KzNsRux0Yo9948i2OYGPxoeJud6iMJlBKKUFw21h/pORLvCwJkqQymUdxYRzpiLLZQsAd/YHSpmAmceBM8SdZLAwsA1/oiqtb4S9/8kJ0qCQcJEPStd/80kvX2pj9AIjAAQZQ9BFODM1M8WR4v+/L9YTyu+RyM=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de;
Received: from DB6P190MB0310.EURP190.PROD.OUTLOOK.COM (10.165.186.141) by DB6P190MB0376.EURP190.PROD.OUTLOOK.COM (10.175.241.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Mon, 30 Mar 2020 21:31:36 +0000
Received: from DB6P190MB0310.EURP190.PROD.OUTLOOK.COM ([fe80::b999:3826:8a06:8653]) by DB6P190MB0310.EURP190.PROD.OUTLOOK.COM ([fe80::b999:3826:8a06:8653%6]) with mapi id 15.20.2856.019; Mon, 30 Mar 2020 21:31:36 +0000
Date: Mon, 30 Mar 2020 23:31:29 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: core@ietf.org
Cc: netmod@ietf.org
Message-ID: <20200330213129.m2azrbeaxrtgivfc@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: core@ietf.org, netmod@ietf.org
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
X-ClientProxiedBy: FR2P281CA0036.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:14::23) To DB6P190MB0310.EURP190.PROD.OUTLOOK.COM (2603:10a6:6:3e::13)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from localhost (2001:638:709:5::7) by FR2P281CA0036.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:14::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20 via Frontend Transport; Mon, 30 Mar 2020 21:31:36 +0000
X-Originating-IP: [2001:638:709:5::7]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: ffe754de-bb93-4c5e-6d4a-08d7d4f1b9e9
X-MS-TrafficTypeDiagnostic: DB6P190MB0376:
X-MS-Exchange-Transport-Forked: True
X-Microsoft-Antispam-PRVS: <DB6P190MB037603A38134239A2632DFBCDECB0@DB6P190MB0376.EURP190.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:8273;
X-Forefront-PRVS: 0358535363
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB6P190MB0310.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(136003)(376002)(346002)(366004)(39850400004)(396003)(186003)(66556008)(16526019)(8936002)(8676002)(81156014)(86362001)(6486002)(6916009)(5660300002)(66946007)(66476007)(4326008)(478600001)(1076003)(6666004)(81166006)(3450700001)(6496006)(450100002)(316002)(52116002)(2906002)(786003); DIR:OUT; SFP:1101;
Received-SPF: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: agPc9yLVCCj0CgV9ug8qXiijIatLaG3+tgnj5p2dwpzcaWiEHUaPq1N7svsIFhovCNIbkRgAmmKS7bQesm61Ge0KSBYljmo97bCUV+u5+QfX81wFEkcarXpN2RgO9tVp+HbHIh7s7DKrGeB6b4131besglT5GiQd7CTbsAKjXAiiZo/45LEXttTzsX+wOcUAfaym+slicC9rFDi+x3HnEFqrHWM9E0SkiCyEbi9/xjZsPbO+jJWIlYMoyQ1a999y3ZttK/dWP1Sp0YuCn2h97QClwiKFmOQfC6carQ6IUEBr8QpkennRu4b+KaiDAsZA1kMdCRyfHJGvNyoJE5h4qzVHB8IztLVS6fwHuer1HYCe20wO2RRXY1ZHF0IpA3zos7sPmwO8/ohLL/RLszDCvIuG1iLknjvJzuxLDCOa5NrA1Kh/6KMnkrZfyV5E48OdEsEM3IJZw1NawfzFZfJZpq4rALEq9LDCizPnLSxMUMB2Iunsxqp8+IRuVig5ElO5Ox/Gv5Xefnx9php3ynP1DQ==
X-MS-Exchange-AntiSpam-MessageData: 2s4p4CFBrdiaVAtQ+YmTEwP+Dqb837X/ixqpPt9yy2kiva98PUMB1X58RsRnVYo//20kSdA+d2tGGXjzFbXABJlbUFU24t8gnuOOEyxgmdrHdKBxYnsVC8I0wVRcGX1Y0GCWNvPSK+EwOJtML5dormeaR8tXT10OUX21QiHrywg=
X-OriginatorOrg: jacobs-university.de
X-MS-Exchange-CrossTenant-Network-Message-Id: ffe754de-bb93-4c5e-6d4a-08d7d4f1b9e9
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Mar 2020 21:31:36.8743 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: f8/OQipR6kPCHql1OTW0FyLN9bi2MH63ynvDVsRWKdy4TqQEORXmo7gXfkGrOJuM9t7+twp/FRSFHOUt0zKdjSW/NKrnr0GTRr7AES/9kF0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0376
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/SMw0cJ_t-NcV6hfDNtf9lYqMp6U>
Subject: [netmod] js review of draft-ietf-core-sid-12
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Mar 2020 21:31:43 -0000
Hi, I have reviewed draft-ietf-core-sid-12. I will try to review yang-cbor tomorrow as well. (I am probably more interested in CBOR encoding for RESTCONF than the usage of CoAP itself, hence my priority on these two IDs under last call.) - Avoid the use of the word 'template', which is not a well defined term and may be used with varying interpretations. o data nodes (Note: including those parts of a YANG template as defined by the 'yang-data' extension.) It is not clear to me what is meant with "those parts of a YANG template as defined by the 'yang-data' extension." I think this could benefit from a rewording. - The ID seems to assume that semantics of yang items never change. This is true so far but NETMOD has chartered work that might change this property. So what happens if the semantics of a YANG item changes? SIDs are assigned permanently, items introduced by a new revision of a YANG module are added to the list of SIDs already assigned. If a YANG module changes in a non-backwards compatible way, I assume a new sid range must be allocated? Strictly speaking, this question does not have to be answered today but it very likely needs an answer in the future... - The definition of 'path' is not very precise, i.e., it does not spell out how module namespaces work, only by example.. I do not know whether a definition can be imported from somewhere. - s/RESCONF/RESTCONF/ - Is it CoRECONF or CORECONF? And I find the term CORECONF confusing. We have two protocols called NETCONF and RESTCONF and now we add another protocol called CoMI and we call CoMI together with YANG CBOR and SIDs CORECONF? 1) NETCONF + YANG + XML serialization + path naming -> ? 2) RESTCONF + YANG + XML|JSON serialization + path naming -> ? 3) CoMI + YANG + CBOR serialization + SID naming -> CORECONF We do not have a term for 1) and 2) and then we have a term for 3) which, however, looks more like the protocol names used in 1) and 2). This comment is not specific to this ID, but the asymmetry showed up while reading the SID document, I had to look at other IDs to understand how things are named. And the SID document says YANG is a language designed to model data accessed using one of the compatible protocols (e.g. NETCONF [RFC6241], RESCONF [RFC8040] and CoRECONF [I-D.ietf-core-comi]). Then I read the CoMI abstract. It first says CoMI is "a CoAP Management Interface", it then says "The complete solution composed of CoMI, [I-D.ietf-core-yang-cbor] and [I-D.ietf-core-sid] is called CORECONF." and finally it states that "CORECONF extends the set of YANG based protocols, NETCONF and RESTCONF, with the capability to manage constrained devices and networks.". So I am confused, is CORECONF a protocol as stated in this document? Or is CoMI a protocol? (What is then the difference between a "Management Interface" and a management protocol?) I am not sure whether I get to review comi, hence I mention my confusion here as I hit it while reviewing the sid document. - This description makes little sense to me: typedef sid-file-version-identifier { type uint64; description "Optional attribute that gives information about the .sid file version."; } This is a type definition. Why does the description talk about an optional attribute? The type should not state whether something using the type is optional or not. (And I would prefer to avoid 'attribute', better use YANG defined terms or just describe that this type represents a version number for a SID file.) - sid range - was it not said before that it is 63 bits? Is the idea that sids with the highest bit set are legal but undefined or reserved? Or should there be a range restriction? typedef sid { type uint64; description "YANG Schema Item iDentifier"; reference "[I-D.ietf-core-sid] YANG Schema Item iDentifier (SID)"; } - schema-node-path "Identifies a schema-node path string for use in the SID registry. This string format follows the rules for an instance-identifier, as defined in RFC 7959, except that no predicates are allowed. RFC 7959 seems to be a typo, I assume you mean RFC 7951 s/Identifies a schema-node path string/A schema-node path" It is a bit confusing to define a schema-node path by way of reference to an instance identifier. I understand that you borrow the namespace encoding from the way JSON encode instance identifiers but this type really represents what RFC 7950 calls an absolute schema node identifier, no? Is the term schema-node path actually needed or is it the same as absolute schema node identifier? Or is the difference between the two how namespaces are represented? - dependency-revision list dependency-revision { key "module-name"; description "Information about the revision of each YANG module that the module in 'module-name' includes used during the .sid file generation."; The sentence can probably be rewritten to make it clearer. Are the SIDs assigned to a module dependent on the modules listed in the 'dependency-revision'? (Is this a good name for the list?) Why is it necessary to know which revisions were used to resolve imports without revision? - Please avoid wrapped entry point numbers in the table in 6.3.3. - The handling of early allocations sounds complex, I have some doubts this process will work in practice... - Incomplete sentence: RFC7120] also says Or is the following paragraph a quote? In that case, add a colon. - There are likely more normative references, e.g., RFC 6991 and RFC 8040. - Why does the example in appendix A not have / need dependency-revisions? - I have not run any tools to validate things. I just read the I-D. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
- [netmod] js review of draft-ietf-core-sid-12 Juergen Schoenwaelder
- Re: [netmod] [core] js review of draft-ietf-core-… Ivaylo Petrov
- Re: [netmod] [core] js review of draft-ietf-core-… Juergen Schoenwaelder
- Re: [netmod] [core] js review of draft-ietf-core-… Ivaylo Petrov
- Re: [netmod] [core] js review of draft-ietf-core-… Juergen Schoenwaelder
- Re: [netmod] [core] js review of draft-ietf-core-… Ivaylo Petrov
- Re: [netmod] [core] js review of draft-ietf-core-… Juergen Schoenwaelder
- Re: [netmod] [core] js review of draft-ietf-core-… Ivaylo Petrov
- Re: [netmod] [core] js review of draft-ietf-core-… Juergen Schoenwaelder
- Re: [netmod] [core] js review of draft-ietf-core-… Ivaylo Petrov