Re: [core] CoMI Cool draft splits

[Somaraju Abhinav <[e-mail]>]

Hi Andy,
please see inline for comments.
________________________________
From: Andy Bierman [[e-mail]]
Sent: Wednesday, November 18, 2015 5:32 PM
To: Somaraju Abhinav
Cc: [e-mail]; Core
Subject: Re: [core] CoMI Cool draft splits



On Wed, Nov 18, 2015 at 12:31 AM, Somaraju Abhinav <[e-mail]<mailto:[e-mail]>> wrote:
Hi Peter,
I like your proposal of starting with the four drafts. Just a few comments

- Before working through iv) function set, I think it makes a little bit of time working out what use cases we want to support. In particular, I think we should decide if we are only going to address Netconf/Restconf support or if we expect to support Yang application layer module management. In my opinion, in constrained networks we will not support two management protocols one for networking and one for application layer. Therefore, we should support both in the function set.


We don't know this term "YANG application layer module management" in the NETMOD WG.
The semantics of the YANG module can be anything.  The same language is used for devices
and controllers, as well as application and server code generation by many tools.
[AS] Agreed. But we understanding this explains what function set we want to support. One example was the argument to include RPC/operations. I think CoMI currently does not support RPCs because the need to do so was not clear from a network management point of view. However, for applications, I can provide clear reasons to do so. Same thing for "actions" from the Yang 1.1 draft.

- Access control. I think for iv) function set, we should also think about how access control is going to work while we look at the function set. I don't know if this is a separate draft in a different WG (e.g. ACE). But from the perspective of being able to use a device management protocol, unless we also get interoperability for access control/security mechanisms, the drafts will not be usable in the field.


Would this be a replacement for NACM, which is how authorization is handled
for YANG data.
[AS] Yes. I think CoMI/CoOL should recommend something similar to NACM. Whether it is based on NACM or something new that is coming from ACE/COSE is up for discussion. This also relates to the previous point about use cases. Will we also use the same access control methods also for application layer CoAP resources?


- Regarding Versions of YANG modules: I do not understand why we need consistent numbering when a module version gets upgraded. As Rodney already mentioned, we can not assume that new versions of a module are supersets of old versions. I think it is also important to keep using the automated numbering scheme as far as possible. So, my questions is the following: do we need data node IDs consistent across versions of YANG modules.



YANG is just like SMIv2 wrt/ permanent identifiers.
[AS] I did not realise that all YANG modules MUST have permanent module identifiers. Could you please point me to the right reference where I can read about this? Anyways, the permanent identifiers need not be the same as the identifiers that should be used withing the API to access the modules themselves (i.e the identifiers used withing CoOL to access data). Therefore, my questions still stays the same, do data node IDs need to be the same across multiple versions of the same module.

Once an ID is assigned it is never removed.
The 'status' statement is used to manage lifecycle issues like obsolete objects.
So you can assume revision N+1 is a superset of N (at least for the purpose
of object identification).

When a module is updated in the server, we usually attempt to minimize the change
such that existing client code will continue to work without an upgrade.
This is how YANG Hash works.  If the Cool numbers are version-specific, then
a client needs to store multiple sets of IDs to work with each version, and also
needs to be updated anytime a server it manages is updated.


Abhinav

Andy


________________________________________
From: core [[e-mail]<mailto:[e-mail]>] on behalf of peter van der Stok [[e-mail]<mailto:[e-mail]>]
Sent: Wednesday, November 18, 2015 8:27 AM
To: Andy Bierman
Cc: Core
Subject: Re: [core] CoMI Cool draft splits

>
> I think the YANG Hash draft should be separate from the protocol.
> We want to use it with RESTCONF, as well as the YANG/CBOR encoding.
>

I agree with Andy here.
Although I sympathize with Rodney, that once the four drafts are
reality, the WG should decide about adoption and a recombination of
documents.

Peter

_______________________________________________
core mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/core
________________________________________________________ The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.

________________________________________________________ The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.