Re: [core] CoMI Cool draft splits

[Andy Bierman <[e-mail]>]

On Tue, Nov 17, 2015 at 1:32 PM, Rodney Cummings <[e-mail]>
wrote:

> 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).
>
>
YANG does not actually allow objects to be removed.
The status is allowed to change to "obsolete".
YANG hash and automatic numbering will both be able
to "remember" the deleted object IDs so they can never be reused.

The "automatic" numbering only works for the first version of a module.
Manual numbering will almost certainly be required after that.
The YANG extensions for numbering are confusing to me.
Why would I want to hard-wire the numbers to start at N?
How does this fix the "uses from an expanded grouping" problem
I mentioned before, that changes the automatic number assignments?





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


I agree that the client needs to be able to handle future rehashes in order
to work.  A new server revision can have a clash for an object that did
not clash in the previous version.  This code is rather simple
and also generic. The code to read the rehash and replace the bad hashes
with the rehashes does not need to know any data-model specific info to
work.

I am quite concerned about the comment that was made in the meeting that
there will be some modules that never get registered.  The entire premise
of CooL is that every module MUST and therefore will get registered.



Andy




>
> 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
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core
>