Re: [core] CoMI Cool draft splits

[Michel Veillette <[e-mail]>]

Hi Rodney

Would you please elaborate your item#2 "A client cannot assume that the YANG objects of a module are distinct from a hashing perspective."
I'm not sure I fully understand the implications of this statement.

The CoOL draft propose to prefix all objects (data nodes, rpc and notifications) defined by a module & associated sub-modules with a common identifier. What is the impacts of item 2 on this approach?

Regards,

Michel Veillette
System Architecture Director
Trilliant Inc.
Tel: [phone] ext. 237
[e-mail]
www.trilliantinc.com   



-----Original Message-----
From: core [mailto:[e-mail]] On Behalf Of Rodney Cummings
Sent: November-17-15 10:52 AM
To: peter van der Stok <[e-mail]>; Core <[e-mail]>
Subject: Re: [core] CoMI Cool draft splits

Thanks Peter,

At this time, proceeding with 4 drafts sounds good to me.

Nevertheless, as we get closer to progressing these in a WG, I think we should transition to 2 drafts:
a) YANG to CBOR mapping ( i) )
b) Select either hash ( ii) ) or registry ( iii) ), and merge that with the function set ( iv) ) for a single draft

As for the motivation and use cases, I wonder if it might be helpful to state our assumptions for the client side. I would claim that:
1. A client cannot assume that the YANG modules implemented by the server have been enhanced specifically for CoMI/CoOL.
2. A client cannot assume that the YANG objects of a module are distinct from a hashing perspective.
3. A client cannot assume that a new revision of a module is backward compatible to an older revision of that module (i.e. old is proper subset).
If these assumptions are correct, then the client must perform some processing of the server's YANG modules prior to using CoMI/CoOL, and that may help to decide between hash/registry.
If these assumptions are incorrect, it might be useful to discuss it in the draft, to provide some background rationale.

Rodney

-----Original Message-----
From: core [mailto:[e-mail]] On Behalf Of peter van der Stok
Sent: Tuesday, November 17, 2015 3:41 AM
To: Core <[e-mail]>
Subject: [core] CoMI Cool draft splits

Hi all,

During the Yokohama meeting I proposed to split the CoMI/CoOl drafts into three parts as suggested by Juergen Schoenwalder in a separate earlier communication.
This e_mail sets out in more detail why the proposed split is a good one.

The proposed three parts are:
1) The Function Set (sections 2, 3, 4 in CoMI; sections 2, 3, 7 in CoOL)
2) The YANG to CBOR mapping (section 6 in CoMI; section 5 in CoOL)
3) The YANG name compression (section 5 in CoMI; section 6 in CoOL)

The split has two advantages:
- the parts 2 and 3 can be used in other contexts, e.g. RESTCONF
- It separates out the issues which need to be solved to merge CoOL and CoMI.

I come to the generation of 4 drafts:
i) The YANG to CBOR mapping.
ii) Hashing of YANG names
iii) Managed identifier assignment to YANG names
iv) The Function set specification

Ad i) I don't expect a long list of issues for the merging. However, it may be advisable to submit the draft to the netmod WG, where much of the YANG expertise exists and the draft can be aligned with the YANG to JSON draft.
Ad ii and iii) These approaches are very different and merit independent drafts. The CoRE WG can decide to adopt 1, 2, or none of the two drafts. 
It is also possible that drafts get submitted to other WGs.
Ad iv) In my view the alignment of the two existing approaches, CoMI and CoOL, may take some time. I will be happy if in Buenos Aires we have a list with issues, accompanying motivation, and use cases.

Is this a valid approach? Comments are solicited.

Peter

--
Peter van der Stok
vanderstok consultancy
mailto: [e-mail]

_______________________________________________
core mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/core