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

[Juergen Schoenwaelder <[e-mail]>]

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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>