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

From: Ivaylo Petrov <[email-masked]>
Date: Wed, 10 Jun 2020 11:16:47 +0200

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 <
[email-masked]> 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: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 23 Jun 2020 18:59:38 +0200

> > agrees on the name of the technology they standardize.

I am not sure whether this got resolved...

>           processing, or the result of reported errata.";

The YANG versioning aims at supporting version histories that are more
complex than just a simple linear history. Hence, a simple linear
order of the sid version number may have limitations.

> the example in this section. Due to this I believe the current text is

In an ideal world, the definitions in this document would depend on
the YANG specification and not on some other encoding rules. And I
think what you are dealing with are absolute-schema-nodeid with the
additional rule that prefix values in the node-identifier production
are module names.

The way the instance-identifier type has been defined is a bit
problematic since it is rather XML encoding specific. Hence to get
what you want, you have to import the JSON specific solution. If we
ever do YANG 2.0 and factor out the XML specific things from the core
language, this will likely be addressed. Note that the instance
identifier includes predicates in square brackets, which I think your
schema-node-path does not need.

/js

---

From: Ivaylo Petrov <[email-masked]>
Date: Wed, 24 Jun 2020 09:56:11 +0200

Hi Juergen,

Thank you very much for your new comments! Please find my answers below.

> I am not sure whether this got resolved...

[IP]: You are right - I realized that omission and I have started a
discussion (so far not many opinions on it though) here [1] focusing mostly
on this point. I have proposed 3 options for a way forward - use only
CORECONF, use only CoMI or find good enough reason to have the clearly CoAP
part have a name (CoMI) and CoMI + Content format to be called CORECONF. I
currently don't see a reason for having both CoMI and CORECONF as names, so
I would rather go with one of the other two options. I will try to see if
in the past people were more in favour of one or the other. I believe
Carsten would prefer CORECONF and at the top of my head I don't remember
anyone voicing any preferences, but I will check that and propose it as the
default way forward if there are no replies in the next 6-7 days.

[1]: https://mailarchive.ietf.org/arch/msg/core/x9RJkfnQgW0Rp3LmHd2CkbOA4DY/

> order of the sid version number may have limitations.

[IP]: The .sid file history is linked to a YANG file version and is
supposed to mostly/only fix errors in the generation. Any change in the
YANG file version (be it linear or nonlinear) is expected to reset the .sid
file version to 0. Please let me know if you believe that this is still not
going to work well in some cases or if you think that the text is not clear
enough.

> schema-node-path does not need.

[IP]: I believe I see your point. My understanding is that you would prefer
this document to not depend on the JSON encoding, but rather define that
encoding in this document using as a basis the YANG specification. That
would be fine for me, simply let me know if I understood you correctly.

/js

Thanks again!

Best regards,
Ivaylo Petrov

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 24 Jun 2020 12:08:14 +0200

> > > > > >   Interface" and a management protocol?) I am not sure whether I
)> > > > > >   to review comi, hence I mention my confusion here as I hit it
> > while

Something like this

  | protocol | model. lang. | data encoding   |
  |----------+--------------+-----------------|
  | NETCONF  | YANG         | XML             |
  | RESTCONF | YANG         | XML, JSON, CBOR |
  | CORECONF | YANG         | CBOR            |

I can easily explain to others. So far we have managed without
creating additional names for the rows. If we talk about data models,
we talk about 'YANG models' and they are ideally for a large part
agnostic to the protocol(s) and encoding(s) used. If we talk about
protocol specifics, well we have a name for it. Data encoding (or
representation) aspects ideally are protocol agnostic as well - at
least for protocols that can deal with different encodings. One could
add a naming dimension (path vs SIDs) but as long SIDs are only used
as an optimization by the CBOR encoding, this may not be necessary.

> going to work well in some cases or if you think that the text is not clear

OK. If the sid number space is scoped by the YANG module version, then
there does not seem to be a problem (i.e., if I update a YANG module,
then the sid number space for that version of the YANG module resets
to 0).

> would be fine for me, simply let me know if I understood you correctly.

Yes, this is what I wanted to say in much more complicated words. ;-)

/js