Re: [core] CoMI Cool draft splits

[Michel Veillette <[e-mail]>]

Hi Rodney

If I understand correctly, you propose to automatically generate IDs based on the YANG definition files of the modules implemented by each  CoMI/CoOL server. Is this correct?

If this is the case, I don't things we can assume that the targeted constrained networks have enough bandwidth to transfer these files, neither the nodes have enough resources to process these files.

CoMI / CoOL server are implemented with a simple map of ID vs. values.
On the client side, the right ID need to be used in function of the version / rehash.

The goal is to maintain the network and resources footprint as low as possible.

Regard,

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


-----Original Message-----
From: Rodney Cummings [mailto:[e-mail]] 
Sent: November-17-15 4:33 PM
To: Michel Veillette <[e-mail]>; peter van der Stok <[e-mail]>; Core <[e-mail]>
Cc: Somaraju Abhinav <[e-mail]>; Turner, Randy <[e-mail]>; Alexander Pelov <[e-mail]>
Subject: RE: [core] CoMI Cool draft splits

Thanks Michel,

To back up a bit, I think I may be misunderstanding a fundamental assumption in the design of both CoMI and CoOL. Please forgive my ignorance.

Of my three points, I think the fundamental point is #3, and #1 and #2 are just symptoms. To elaborate on #3 with an example, let's say I have a module "foo", with two revisions:
- 2011-01-09: original
- 2015-08-07: enhanced

Both CoMI and CoOL seem to be designed under the assumption that the original revision is a proper subset of the enhanced revision (i.e. objects were added, but none removed). 

For CoMI, this is why the client must read the ietf-yang-hash module to obtain re-hash mapping. The server presumably promises to leave the hashes of the original unchanged in the enhanced. Therefore, only the server knows the re-hash values, which must be queried by the client.

For CoOL, the algorithm for the client to find an automatic DNID is clear. Nevertheless, the manual DNID (YANG "id" extension) is provided so that the module author can manually ensure that DNIDs of the original remain the same in the enhanced.

As I think through this for the client side, I don't think it is valid for my client to assume that the enhanced is a proper subset of the original (item #3). I realize that a proper subset is common in practice, but it is not guaranteed. From my reading of RFC6020bis, the enhanced module can completely remove all objects from original.

Therefore, on the client side, it would be easier for me to assume the "automatic" implementation in the server. 

In the context of Cool, "automatic" means the automatic DNID algorithm. I would prefer to avoid the "manual" mechanism entirely (my item #1). Rather than create CoOL-specific YANG modules, just force the client to process the normal YANG module assuming that all DNID are automatic.

In the context for CoMI, specify an "automatic" algorithm for resolving hash collisions, similar to CoOL's automatic DNID. This enables a client and server to use the same re-hash, and it avoids the need to query the ietf-yang-hash module.

Overall, it seems like the most challenging aspects of CoMI and CoOL are the "manual" extensions to help with backward compatibility (item #3). To a naive reader such as myself, these "manual" extensions make the draft far more complex, and it would be simpler to use the "automatic" technique in both client and server.

Rodney


-----Original Message-----
From: Michel Veillette [mailto:[e-mail]] 
Sent: Tuesday, November 17, 2015 1:21 PM
To: Rodney Cummings <[e-mail]>; peter van der Stok <[e-mail]>; Core <[e-mail]>
Cc: Somaraju Abhinav <[e-mail]>; Turner, Randy <[e-mail]>; Alexander Pelov <[e-mail]>
Subject: RE: [core] CoMI Cool draft splits

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