Hi Juergen,
Thanks for those clarifications :) For the CORECONF vs CoMI point, I saw no
opposition to only using CORECONF, therefore my plan is to use [1] and
rename CoMI to CORECONF everywhere except for the draft name, which I do
not intend to change.
I tried to rephrase the text about instance-identifiers. Now the
terminology section contains a definition of namespace-qualified form that
works for any usable schema node and the schema-node-path uses that one
now. The latest version can be seen here [2]. The text in the YANG module
reads:
```
description
"A schema-node path string for use in the
YANG SID registry. This string additionally follows the following
rules:
o The leftmost (top-level) data node name is always in the
namespace-qualified form.
o Any subsequent schema node name is in the namespace-qualified form
if the node is defined in a module other than its parent node, and
the simple form is used otherwise. No predicates are allowed.
This format is intended to support the YANG 1.1 ABNF
for a schema node identifier, except module names
are used instead of prefixes.";
reference
"RFC 7950, The YANG 1.1 Data Modeling Language;
Section 6.5: Schema Node Identifier;";
```
I plan to submit the new version tomorrow or the day after.
Best regards,
Ivaylo
[1]: https://github.com/core-wg/comi/compare/coreconf-only
[2]:
https://tools.ietf.org/rfcdiff?url1=draft-ietf-core-sid&url2=http://core-wg.github.io/yang-cbor/draft-ietf-core-sid-latest.txt
On Wed, Jun 24, 2020 at 1:08 PM Juergen Schoenwaelder <
[email protected]> wrote:
> On Wed, Jun 24, 2020 at 09:56:11AM +0200, Ivaylo Petrov wrote:
> > Hi Juergen,
> >
> > Thank you very much for your new comments! Please find my answers below.
> >
> > On Tue, Jun 23, 2020 at 6:59 PM Juergen Schoenwaelder <
> > [email protected]> wrote:
> >
> > > On Wed, Jun 10, 2020 at 11:16:47AM +0200, Ivaylo Petrov wrote:
> > >
> > > > > - 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.
> > >
> > > 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/
>
> 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.
>
> > > > > - 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.";
> > >
> > > 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.
> > >
> >
> > [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.
>
> 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).
>
> > > > 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.
> > >
> > > 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.
> > >
> >
> > [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.
> >
>
> Yes, this is what I wanted to say in much more complicated words. ;-)
>
> /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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
