Re: [core] CoMI Cool draft splits

[Somaraju Abhinav <[e-mail]>]

Hi Andy,

About “OK. So that means the scope includes constrained networks, not just constrained nodes. I am interested in using CoMI as a replacement for RESTCONF in constrained networks where TCP doesn't really work.”
[AS] I was hoping to use CoMI as much more than a replacement for RESTConf in constrained network. In the CoMI draft, you make a point of comparing CoMI to LWM2M and point out the advantages. As far as I am aware, LWM2M has nothing to do with network management and/or restconf. LWM2M is used to really manage constrained devices and applications that constrained devices use. So, this comparision of CoMI with LWM2M is very misleading. I personally want to use CoMI/CoOL to replace instead of LWM2M and I see great benefits in doing so. Like it or not, YANG looks like a data modelling tool that can be used for several different purposes.

Maybe we can build 2 separate protocols out the parts that have been proposed.
[AS] Maybe this makes sense but we should try to merge the two if possible.

About “I don't see managed IDs as a general solution, but IMO constrained nodes”
[AS] I partly agree about this assessment. I think that having a central registry for all managed IDs is indeed unrealistic and will not work in the long run. However, I see that CoMI/CoOL, if used for application management, will be a tool that other SDOs such as OMA or IPSO can reuse. I expect that if we provide standard methods for an SDO (e.g. use resource type to indicate the type of YANG module) then these SDOs can manage IDs that are relevant to the SDO.

About “but IMO constrained nodes will never be using the same modules that are written for networking equipment.”
[AS] Maybe constrained nodes will not use all the modules written for networking equipment. However, I am sure some of them could be and will be used.

About “We plan to just use NACM to configure what a client is authorized to access wrt/ management data and operations.  Again, how much value is there in reinventing stuff?”
[AS] I am not saying that NACM should not be used. I am just saying that we should think about it and if NACM works as it is then sure we can reuse it.

About “This describes what is allowed to change in a new revision of a module. Notice how "rename object" is not in the list?”
[AS] The cool module identifier is not the same thing as the name of the YANG module. It is an extension and there are no rules as far as I know in YANG that says this cannot change.

About “Stable identifiers are useful because old clients can continue to work with new servers.”
[AS] Okay, I can live with this explanation. Maybe we can think of automated numbering schemes where data nodes in newer versions are automatically assigned IDs higher than all previous versions in the module.


From: Andy Bierman [mailto:[e-mail]]
Sent: Freitag, 20. November 2015 00:06
To: Carsten Bormann
Cc: Somaraju Abhinav; Core
Subject: Re: [core] CoMI Cool draft splits



On Thu, Nov 19, 2015 at 8:37 AM, Carsten Bormann <[e-mail]<mailto:[e-mail]>> wrote:
Andy Bierman wrote:
> I think the term "constrained" is not widely agreed upon in the IETF.

No.  But we are using it in the sense of RFC 7228 here.

OK. So that means the scope includes constrained networks, not just
constrained nodes. I am interested in using CoMI as a replacement
for RESTCONF in constrained networks where TCP doesn't really work.

I want to use the same "content layer" and code for that content across the board.
That means the exact same YANG data models, without exception, and the translation
from RESTCONF features to CoMI features must be loss-less.  The protocol,
messaging, and transport layers can all change as needed.

I realize this is not what might work best for a constrained node.
Maybe we can build 2 separate protocols out the parts that have been proposed.
I don't see managed IDs as a general solution, but IMO constrained nodes
will never be using the same modules that are written for networking equipment.



Grüße, Carsten


Andy

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