Re: [core] CoMI Cool draft splits

[Andy Bierman <[e-mail]>]

On Thu, Nov 19, 2015 at 2:06 AM, Somaraju Abhinav <
[e-mail]> wrote:

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



I think the term "constrained" is not widely agreed upon in the IETF.
Why not just use RESTCONF and not bother with CoMI?
At some point, the value of re-inventing everything becomes unclear.



>
>> - 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?
>
>
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?  E.g., CooL copies ietf-yang-library inline just to
change
a string to a number. Same thing with ietf-yang-patch. IMO the savings from
using CBOR
are good enough.  If the data models and protocol operations are altered,
then supporting
CoMI is a separate development effort for every data model.  This does not
scale well.
I prefer to use the same code but with more efficient plumbing down in the
transport.





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



Look at section 10 in RFC 6020.
This describes what is allowed to change in a new revision of a module.
Notice how "rename object" is not in the list?  Sec. 10 is normative.
YANG modules that do not follow these rules are invalid modules.

Stable identifiers are useful because old clients can continue to
work with new servers.  YANG allows old data to be extended with
optional nodes.  A new set of identifiers per revision requires
the clients to store all versions of each identifier in order to
maintain backward compatibility with old servers.


Andy



>
> 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]] on behalf of peter van der Stok [
>> [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]
>> 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.
>