Re: [netmod] [core] js review of draft-ietf-core-sid-12

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Wed, 15 April 2020 16:21 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 C78863A0A8F; Wed, 15 Apr 2020 09:21:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1CqzYoN0-m_a; Wed, 15 Apr 2020 09:20:59 -0700 (PDT)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2064.outbound.protection.outlook.com [40.107.22.64]) (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 274783A0A3A; Wed, 15 Apr 2020 09:20:58 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xp5gHw52R1w+aE1P+vXHlSTwkeVSkip1WhZmRa4ky8OQb/k8cDA2EYxW39JOFTB0VWbd2mazKori4yRkOZ1TyInsVTFKzDB8UGA136wwj+XP4VqhewRuhXsqpkxY5IpvBpIjf14/8/60FiMN0efyfEpoDJmaQW6zoSLYyzskvCCmsxfIET7ZtvQ67RtjWOb2vUq9/3B+UR8q2XxiC/ppVv7CIgH95v88TQj1i7CEjPfSvhPEvhRUugYo/2MFriglfTWdq1m41CnKJmNFk8rhgXgH40yb1cd5QM+N1R/mnD9BJUT7kHqmE2ebS4TFa231vMSYDw2bJvDCDN0/xdT4xg==
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=HQysCgPSbG8FnpVNa+p+Z0FTFHPaO4kx7Dz1BsWcooY=; b=N356Ok9m/1msrKuJvvX4/sM6NL7zUlLSvorXozXiK4f9yvy6bSKGzvvqnHm4ZlZQea82XS1NV4hXUCl+MbrmhJsRx4WdsP7Y7Omf/8u4xCimRXhFHDUbo/12qwuKGbnybAf7H82++WNgxiWUAsGq6S4jgd5USvcXxbBjN8BRx4n66qw4Cgnk48TrV2VDUgBsjFwLmmtOBO2xxiJ+CzwwvXel+ZNgbZIw6wL82UjD7YPnOhVy9IKORRl1J7qD8s2NHZWIaFEE9wniUk7l38wYBQV2bzr3pu6LPH1czIh7VtozxMD4oG6wpg2JHiWQedzEeMgXM3p09birtU7juG+u5A==
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=HQysCgPSbG8FnpVNa+p+Z0FTFHPaO4kx7Dz1BsWcooY=; b=nXG1sJkCxbOwAnfNVGliE8aN8jg5jeSoPo7fofwJGBNdqR3GjvCOJfzd1rtMoudU6UQ8WaqCzADokkl6qzeW3h0apVPnk5NaP+2qgOdU0L/62Wj2/GZutJHgNHJJqB1qIJ8pvS+OEg2v2EhfS8h+YBmYIRSLfl3EgX9/hmY3UzI=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de;
Received: from AM0P190MB0707.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:196::24) by AM0P190MB0626.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:193::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.24; Wed, 15 Apr 2020 16:20:56 +0000
Received: from AM0P190MB0707.EURP190.PROD.OUTLOOK.COM ([fe80::dc34:2067:88d1:c483]) by AM0P190MB0707.EURP190.PROD.OUTLOOK.COM ([fe80::dc34:2067:88d1:c483%5]) with mapi id 15.20.2921.024; Wed, 15 Apr 2020 16:20:55 +0000
Date: Wed, 15 Apr 2020 18:20:54 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Ivaylo Petrov <ivaylo@ackl.io>
Cc: core <core@ietf.org>, NetMod WG <netmod@ietf.org>
Message-ID: <20200415162054.s4bjcrienqvrytfz@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Ivaylo Petrov <ivaylo@ackl.io>, core <core@ietf.org>, NetMod WG <netmod@ietf.org>
References: <20200330213129.m2azrbeaxrtgivfc@anna.jacobs.jacobs-university.de> <CAJFkdRz445b4n86ug=v1ruYYWbDjwnEJwUNCZvEzENu_gMV0bg@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAJFkdRz445b4n86ug=v1ruYYWbDjwnEJwUNCZvEzENu_gMV0bg@mail.gmail.com>
X-ClientProxiedBy: AM0P190CA0004.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:190::14) To AM0P190MB0707.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:196::24)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from localhost (2001:638:709:5::7) by AM0P190CA0004.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:190::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.25 via Frontend Transport; Wed, 15 Apr 2020 16:20:55 +0000
X-Originating-IP: [2001:638:709:5::7]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 2a14954d-cab0-419e-a63b-08d7e158f96a
X-MS-TrafficTypeDiagnostic: AM0P190MB0626:
X-MS-Exchange-Transport-Forked: True
X-Microsoft-Antispam-PRVS: <AM0P190MB0626C099541820CF762E70CDDEDB0@AM0P190MB0626.EURP190.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-Forefront-PRVS: 0374433C81
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0707.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(136003)(376002)(39850400004)(396003)(366004)(346002)(8936002)(66476007)(52116002)(1076003)(2906002)(8676002)(5660300002)(66946007)(6916009)(3450700001)(6496006)(81156014)(66556008)(86362001)(54906003)(6486002)(478600001)(186003)(4326008)(786003)(316002)(16526019)(83080400001); 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: gOSlABOvkpHT96L3QSk9mu89pi8pBfOLoP3cqioQzwM35zECqLh0QgUZnuh9cRutXQMKswA7/9ri6t0yT4gfqr8xCxgGnNp8ppEZegZYa3nA7my2y++gRs4IS0i4jYgEkKnpcu/39ncZn+BUTcKITWX0FpEhV9Or+v+80wBslRBrwvI7eeyshr2VN1yf6UgZzv3zfGX+/ltWtjBFclsEGUm61Jd/Bw5zYdpCC+E8LH59acFYRtKFh4YskMrYYdM75qQHRBep3xTL38/8Hhg1zJBuR5HzADHCfRE79s1lAO3rfs+BFAPCmn0PlzSdwhoV6v1hKqEJXOVbTaJVAbo6RUxJEk9EUI5R2TXg5y5JfZzcdob3owlV+N/vvkGwq6QH9ch5NfV7YaeqPeEWF5OQHyqvfPY9ml/oOIYXHAulmHTtnUv21SxqSIGGRBBHv7XuE8rgidZ7JnJ92bPL8MCXWc9h+O+t0DIjMm/D52g+AANp34M/F3mu+mH9HYhMqRnko9IunPgtEXLcc0nnQr9S/w==
X-MS-Exchange-AntiSpam-MessageData: y8cX+aTi3Go/cYcpb/ITPFt9d9kc731DI7+SX1ELPlx8KhwcEIq/Gd/z3aD5lkFZxG3scGnnoZw9MM4gwmJTAWrLLiilVToaxz541e6PJw/bOHZdM/U05vqfRiQoRBBWEV1N56sGY5CMaJ/kX5QYIXiIMmdpUnAiu+9vg9AFcnk=
X-OriginatorOrg: jacobs-university.de
X-MS-Exchange-CrossTenant-Network-Message-Id: 2a14954d-cab0-419e-a63b-08d7e158f96a
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Apr 2020 16:20:55.7945 (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: nH+JDmzwUOsfnz2amhNGeCR3EYcb8sBfEFLUHeCNvLx+MwmRSqZGIvFnSGgm9NN0VqBnSxuS1v4qf0Ch74Ys5W8TWPQc8SGdAGR0WKirO1c=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0626
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/iHZFByHNKdwnnf8j-fjMjFG1TQ4>
Subject: Re: [netmod] [core] 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: Wed, 15 Apr 2020 16:21:02 -0000

On Wed, Apr 15, 2020 at 03:27:21PM +0200, Ivaylo Petrov wrote:

> - 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...
> >
> 
> [IP]: We will not be able to clearly answer this before there is more
> information how the YANG items semantics can change. For now it looks like
> assigning new range would be a good solution, but maybe there will be some
> other solutions that will be even more optimal. What looks logical is that
> at least every semantic of an item should have a separate SID.

Yes and this will impact the SID document since SIDs are going to be
specific to a (module, path, version) triple.

> - 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.
> >
> 
> [IP]: Currently this is indeed somewhat confusing. The proposed change from
> Michael Richardson was to at least have CORECONF in the title of the CoMI
> document. I am wondering if that might still leave some of the confusion.
> For me the simple solution is in this document to refer to CoMI, not
> CORECONF and let CoMI draft define what CORECONF actually is. Unless you
> think this will still not resolve the issue, this is going to be my way
> forward.

Avoiding CORECONF in this document helps to limit the problem. If CoMI
is the name of the protocol, I would hope we do not need CORECONF at
all. But then CORECONF is all over the place in
draft-ietf-core-comi-09.txt, it actually looks like the protocol is
called CORECONF and not CoMI. I really believe this terminology
confusion needs to be resolved in the WG so the WG actually knows and
agrees on the name of the technology they standardize.
 
> - 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.)
> >
> 
> [IP]: I believe now it should be more clear.

Yes. I wonder though, is this a simple linear counter? Or can it be
anything as long as newer > older is satisfied? Or is this just a tag
that needs to match and it does not imply any order semantics?

>   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?
> >
> 
> [IP]: I might have misunderstood something, but my understanding is that
> the prefix related to a module could be changed during an import, whereas
> here we really want to use the module name as a more stable identifier. The
> difference between absolute schema node identifier and schema-node path is
> that we mandate the use of module name and not prefix as defined in RFC
> 7950.

Well, what you model here is an absolute schema node path, except that
prefixes are replaced by module names. Note that refering to
instance-identifier as defined in RFC 7951 has the problem, the RFC
7951 definition of an instance-identifier also includes prefixes
instead of module names.

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