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 protected]> 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/> >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
