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

[Ivaylo Petrov <[e-mail]>]

Hello Jurgen,

I am sorry for the late reply and thank you for your latest review and
comments. Please find my answers below. The updated version that contains
those changes is already published as -13, therefore the diff with the
previous text can be found here [1].
Best regards,
Ivaylo

[1]:
https://www.ietf.org/rfcdiff?url1=draft-ietf-core-sid-12&url2=draft-ietf-core-sid-13

On Wed, Apr 15, 2020 at 6:20 PM Juergen Schoenwaelder <
[e-mail]> wrote:

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

[IP]: I rephrased the following text in order to prepare the future change
of meaning:
Old:

 SIDs are assigned permanently, items introduced by a new revision of a YANG
module are added to the list of SIDs already assigned.

New:

 SIDs are assigned permanently, items introduced by a new revision of a YANG
module are added to the list of SIDs already assigned. If the meaning of an
item changes, for example as a result from a non-backward compatible update
of
the YANG module, a new SID should be assigned to it.

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

[IP]: The intention was to be newer > older without any implied semantics. I
rephrased the text to capture this.
Old:
           "Optional leaf that specifies the version number of the .sid
file.
          .sid files and the version
          sequence are specific to a given YANG module revision.
          This number starts at zero when there is a YANG module update.
          This number can distinguish updates to the SID file which are the
result of
          new processing, or the result of reported errata.";
New:
           "Optional leaf that specifies the version number of the .sid
file.
          .sid files and the version sequence are specific to a given YANG
          module revision. This number starts at zero when there is a new
YANG
          module revision and increases monotonically.  This number can
          distinguish updates to the .sid file which are the result of new
          processing, or the result of reported errata.";

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

[IP]: I might be misunderstanding your statement or the text in RFC 7951,
but if I read sec 6.11. from RFC 7951 correctly,

The leftmost (top-level) data node name is always in the
namespace-qualified form.


In sec 4 of RFC 7951 the namespace-qualified form seems to only use the
module name and not the prefix. My impression seems to be supported also by
the example in this section. Due to this I believe the current text is
actually correct.

/js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
>