Subject: [core] CoMI Cool draft splits

From: peter van der Stok <[email-masked]>
Date: Tue, 17 Nov 2015 10:41:05 +0100

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: [email-masked]

---

From: Rodney Cummings <[email-masked]>
Date: Tue, 17 Nov 2015 15:51:47 +0000

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:[email-masked]] On Behalf Of peter van der Stok
Sent: Tuesday, November 17, 2015 3:41 AM
To: Core <[email-masked]>
Subject: [core] CoMI Cool draft splits

Hi all,

Peter

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 17 Nov 2015 09:33:12 -0800

On Tue, Nov 17, 2015 at 7:51 AM, Rodney Cummings <[email-masked]>
wrote:

> b) Select either hash ( ii) ) or registry ( iii) ), and merge that with
> the function set ( iv) ) for a single draft
>
>

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.

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

I do not think manual management of YANG object identifiers is
a workable design.  It assumes that all modules will be registered
with some centralized naming authority.  I do not see how every module
will be registered.  This means unregistered modules cannot be used at all.
The manual numbering also has a hard-limit of 1024 objects per YANG module.
If a module ever has more than 1024 nodes, the "extra" nodes are unusable.

It can be very difficult to manually number objects:

module A {
   grouping A1 {
       leaf X { ... }
       leaf Y { ... }
    }
}

module B {
   import A { prefix A1; }

   container B1 {
     uses A:A1;
   }
   leaf B2 { ... }
}

NEXT RELEASE:

module A {
   grouping A1 {
       leaf X { ... }
       leaf Y { ... }
       leaf Z { ... }
    }
}

If the grouping A:A1 is ever extended, there is no way to number the new
objects
in module B.  All objects after the "uses A:A1" will renumber if new nodes
are
added to the external grouping (which is broken!)
Since this is a very common usage scenario in YANG, this problem will
happen a lot over time.

YANG Hash has the complexity of identifying the hash collision and reading
the rehash mapping info.  Manual numbering has the complexity of managing
the numbering space and dealing with unregistered modules.

I don't see how a client would make this hash vs. managed numbers decision
at run-time.
It is not as if the CoMI server will provide multiple ways of numbering
objects.
Giant routers do not even do that, let alone constrained devices.

Unless CoMI uses unmodified YANG modules, it does not really support YANG.

> Rodney
Andy

---

From: Michel Veillette <[email-masked]>
Date: Tue, 17 Nov 2015 19:19:19 +0000

Hi Peter

The 4 drafts you propose make lots of sense.

I propose to start by the item 'I' (The YANG to CBOR mapping), follow by item 'iv' (The Function set specification), follow by items 'II' and 'III'.
I propose this order since examples in the latter will be based on the first two deliverables.

I have extracted section 4 and 5 of the CoOL draft as starting point, see attachments.
Do you accept this contribution as strawman for this work?

Should we create a specific mailing list for this work?

Regards,

Michel Veillette
System Architecture Director
Trilliant Inc.
Tel: 450-375-0556 ext. 237
[email-masked]
www.trilliantinc.com   

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of peter van der Stok
Sent: November-17-15 4:41 AM
To: Core <[email-masked]>
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 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.

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.

Peter

---

From: Michel Veillette <[email-masked]>
Date: Tue, 17 Nov 2015 19:20:53 +0000

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

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

Thanks Peter,

Rodney

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

Hi all,

Peter

---

From: Rodney Cummings <[email-masked]>
Date: Tue, 17 Nov 2015 21:32:45 +0000

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:[email-masked]] 
Sent: Tuesday, November 17, 2015 1:21 PM
To: Rodney Cummings <[email-masked]>; peter van der Stok <[email-masked]>; Core <[email-masked]>
Cc: Somaraju Abhinav <[email-masked]>; Turner, Randy <[email-masked]>; Alexander Pelov <[email-masked]>
Subject: RE: [core] CoMI Cool draft splits

Hi Rodney

Regards,

Michel Veillette

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

Thanks Peter,

Rodney

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

Hi all,

Peter

---

From: Andy Bierman <[email-masked]>
Date: Tue, 17 Nov 2015 14:26:31 -0800

On Tue, Nov 17, 2015 at 1:32 PM, Rodney Cummings <[email-masked]>
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
>
>
> To: Rodney Cummings <[email-masked]>; peter van der Stok <
> [email-masked]>; Core <[email-masked]>
> Cc: Somaraju Abhinav <[email-masked]>; Turner, Randy <
> [email-masked]>; Alexander Pelov <
> [email-masked]>
> Would you please elaborate your item#2 "A client cannot assume that the
> YANG objects of a module are distinct from a hashing perspective."
> 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
> 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.
> CoOL, may take some time. I will be happy if in Buenos Aires we have a list
> with issues, accompanying motivation, and use cases.
>

---

From: Michel Veillette <[email-masked]>
Date: Tue, 17 Nov 2015 22:30:15 +0000

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

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

Thanks Michel,

Rodney

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

Hi Rodney

Regards,

Michel Veillette

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

Thanks Peter,

Rodney

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

Hi all,

Peter

---

From: peter van der Stok <[email-masked]>
Date: Wed, 18 Nov 2015 08:22:46 +0100

Hi Michel,

thanks for our approval. We are on the road now.
I am preparing an e_mail on the YANG to CBOR mapping to be sent 
to-morrow.
It takes some time to go through all details.

Cheerio,

Peter

Michel Veillette schreef op 2015-11-17 20:19:
> I propose to start by the item 'I' (The YANG to CBOR mapping), follow
> by item 'iv' (The Function set specification), follow by items 'II'
> and 'III'.
> 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.
> 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.
>

---

From: peter van der Stok <[email-masked]>
Date: Wed, 18 Nov 2015 08:27:37 +0100

> 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

---

From: Somaraju Abhinav <[email-masked]>
Date: Wed, 18 Nov 2015 08:31:00 +0000

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.

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

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

Abhinav

________________________________________
From: core [[email-masked]] on behalf of peter van der Stok [[email-masked]]
Sent: Wednesday, November 18, 2015 8:27 AM
To: Andy Bierman
Cc: Core
Subject: Re: [core] CoMI Cool draft splits

I agree with Andy here.

Peter

_______________________________________________
core mailing list
[email-masked]
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.

---

From: peter van der Stok <[email-masked]>
Date: Wed, 18 Nov 2015 11:23:24 +0100

Hi Abhinav,

see below.

Somaraju Abhinav schreef op 2015-11-18 09:31:
> - 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.

<peter> I agree about support for management and others (which needs a 
bit of thought) </peter>
> 
> - 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.

<peter> Again I agree. In the security considerations this should be put 
forward.
I was more thinking of referring to the drafts developed in ACE and COSE 
than on specifying security separately for CoMI/CoOL.
One of my problems is also the support of Multicast, and I don't see the 
appropriate draft being approved quickly.
</peter>

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

<peter> on the other hand there are the YANG rules as Andy pointed out;
My take-away till now is that consistent data node IDs across versions 
is VERY difficult, and probably not needed (to be checked in detail)
</peter>

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

---

From: Somaraju Abhinav <[email-masked]>
Date: Wed, 18 Nov 2015 12:49:54 +0000

Hi Peter,
About "I was more thinking of referring to the drafts developed in ACE and COSE
than on specifying security separately for CoMI/CoOL".

I don't expect that we specify the actual security protocols that will be used in CoMI/CoOL - this is clearly the domain of ACE/COSE. However, I think we should specify which ones to use in which context and how. E.g. for the discovery part, we might say reply to any message. We should also provide discovery methods of which protocol is may be used to actually secure get/put request. I do not think these types of issues will be covered in ACE/COSE but are in the domain of the management protocols.

Regards,
Abhinav
________________________________________
From: peter van der Stok [[email-masked]]
Sent: Wednesday, November 18, 2015 11:23 AM
To: Somaraju Abhinav
Cc: [email-masked]; Andy Bierman; Core
Subject: RE: [core] CoMI Cool draft splits

Hi Abhinav,

see below.

---

From: peter van der Stok <[email-masked]>
Date: Wed, 18 Nov 2015 14:40:09 +0100

Hi,

I see that we agree.
However, drafts are mostly about inter-operability. We must make 
security recommendations but I can imagine that other SDOs want to 
specify under which conditions these protocols are used.

Peter

Somaraju Abhinav schreef op 2015-11-18 13:49:
> I don't expect that we specify the actual security protocols that will
> be used in CoMI/CoOL - this is clearly the domain of ACE/COSE.
> However, I think we should specify which ones to use in which context
> and how. E.g. for the discovery part, we might say reply to any
> message. We should also provide discovery methods of which protocol is
> may be used to actually secure get/put request. I do not think these
> types of issues will be covered in ACE/COSE but are in the domain of
> the management protocols.
> 
> Regards,
> Abhinav

---

From: Somaraju Abhinav <[email-masked]>
Date: Wed, 18 Nov 2015 15:04:43 +0000

Sent: Wednesday, November 18, 2015 2:40 PM

Hi,

I see that we agree.
However, drafts are mostly about inter-operability. We must make
security recommendations but I can imagine that other SDOs want to
specify under which conditions these protocols are used.
[AS] Okay. Fair enough if we assume an SDO will specify conditions under which the protocols are used.

Peter

---

From: Andy Bierman <[email-masked]>
Date: Wed, 18 Nov 2015 08:32:57 -0800

On Wed, Nov 18, 2015 at 12:31 AM, Somaraju Abhinav <
[email-masked]> wrote:

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

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

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

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

---

From: Michel Veillette <[email-masked]>
Date: Wed, 18 Nov 2015 20:52:41 +0000

Hi Somaraju, Hi Peter

=== About "Access control"

I was assuming that this topic will be addressed later but scheduling draft(s) right now seem appropriate.

Typically, there is two approaches to access control:
- Centralized using attribute certificate (or equivalent) [RFC 5755]
- Distributed using Access Control List (ACL)

I propose to add two drafts to address these two items.

=== About "I do not understand why we need consistent numbering when a module version gets upgraded"

I thing that the protocol should support both approaches, backward compatible and non backward compatible IDs.
It's up to the developers to select the appropriate approach for each specific use case.
It's also important to note that the augment YANG statement can be used to add new functionalities (new data nodes, rpc, notifications) in a very clean way without affecting the already automatically generated IDs. I believe this should be the recommended approach to implement enhancements.

Regards,

Michel

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Somaraju Abhinav
Sent: November-18-15 3:31 AM
To: [email-masked]; Andy Bierman <[email-masked]>
Cc: Core <[email-masked]>
Subject: Re: [core] CoMI Cool draft splits

Hi Peter,

Abhinav

> 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

---

From: Rodney Cummings <[email-masked]>
Date: Wed, 18 Nov 2015 22:21:26 +0000

> to "remember" the deleted object IDs so they can never be reused.

Thanks Andy. This was my mistake. I went back and read RFC6020 section 10 (Updating a Module), and this is very clear. Now I understand why the manual mechanisms are needed.

On Tue, Nov 17, 2015 at 4:30 PM, Michel Veillette <[email-masked]> wrote:
> 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?

Oh no... I realize that the YANG files will not be exchanged. My mistake was related to an assumption that the client is required to implement the same revision that the server implements. As Andy pointed out, YANG does not require this. It is possible for a client to implement revision 2011-01-09 (original), and the server implements revision 2015-08-07 (enhanced), and everything works just fine (assuming no obsolete objects).

Rodney

---

From: Somaraju Abhinav <[email-masked]>
Date: Thu, 19 Nov 2015 10:06:37 +0000

Hi Andy,
please see inline for comments.
________________________________
From: Andy Bierman [[email-masked]]
Sent: Wednesday, November 18, 2015 5:32 PM
To: Somaraju Abhinav
Cc: [email-masked]; Core
Subject: Re: [core] CoMI Cool draft splits

On Wed, Nov 18, 2015 at 12:31 AM, Somaraju Abhinav <[email-masked]<mailto:[email-masked]>> wrote:
Hi Peter,
I like your proposal of starting with the four drafts. Just a few comments

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.

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?

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.

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 [[email-masked]<mailto:[email-masked]>] on behalf of peter van der Stok [[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 18, 2015 8:27 AM
To: Andy Bierman
Cc: Core
Subject: Re: [core] CoMI Cool draft splits

I agree with Andy here.

Peter

_______________________________________________
core mailing list
[email-masked]<mailto:[email-masked]>
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.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Nov 2015 08:19:48 -0800

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

> ------------------------------
> *From:* Andy Bierman [[email-masked]]
> *Sent:* Wednesday, November 18, 2015 5:32 PM
> *To:* Somaraju Abhinav
> *Cc:* [email-masked]; Core
> *Subject:* Re: [core] CoMI Cool draft splits
>
>
>
> [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.

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

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 19 Nov 2015 17:37:43 +0100

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

Grüße, Carsten

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Nov 2015 15:06:14 -0800

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

Andy

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 20 Nov 2015 07:35:54 +0100

Andy Bierman wrote:
> [...] IMO constrained nodes

Is that so?  Why wouldn't I use a couple of items from, say, RFC 7317
(or 7277) in my constrained node?  In the end these are just resources
that I add to my resource tree.  Of course, cherry-picking may require
some form of subsetting that may not yet be part of the NETCONF approach.

Grüße, Carsten

---

From: Somaraju Abhinav <[email-masked]>
Date: Fri, 20 Nov 2015 08:40:38 +0000

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:[email-masked]]
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 <[email-masked]<mailto:[email-masked]>> wrote:

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

---

From: Rodney Cummings <[email-masked]>
Date: Fri, 20 Nov 2015 17:36:45 +0000

I agree with Carsten on the point below.

As an example, the YANG development in progress for 802.1Q is using features, augments, and so on in order to build up modules from the basic components to more complex components (e.g. for providers). The basic components essentially represent the hardware registers of a switch. As constrained products explore integration of an 802.1Q switch in their product, the question of a constrained network management protocol comes up. IMO CoMI/CoOL provides an excellent solution for this use case, using the 802.1Q module(s) for basic components (i.e. modules not specifically targeted to constrained).

> From: core [mailto:[email-masked]] On Behalf Of Carsten Bormann
> Sent: Friday, November 20, 2015 12:36 AM
> To: Andy Bierman <[email-masked]>
> Cc: Core <[email-masked]>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 20 Nov 2015 09:49:00 -0800

Hi,

I think it will a challenge for the CORE WG to get IANA to manage
the manual number assignment of even IETF modules, let alone all
YANG modules from all vendors and all other SDOs. The cost of even 1 mistake
is rather high (like a wrong port assignment).

YANG Hash will allow any YANG module that has ever been written
or ever could be written to be used without modification or manual
number assignment.

I completely agree with you about CoMI, but not CoOL.

Andy

On Fri, Nov 20, 2015 at 9:36 AM, Rodney Cummings <[email-masked]>
wrote:

> As an example, the YANG development in progress for 802.1Q is using
> features, augments, and so on in order to build up modules from the basic
> components to more complex components (e.g. for providers). The basic
> components essentially represent the hardware registers of a switch. As
> constrained products explore integration of an 802.1Q switch in their
> product, the question of a constrained network management protocol comes
> up. IMO CoMI/CoOL provides an excellent solution for this use case, using
> the 802.1Q module(s) for basic components (i.e. modules not specifically
> targeted to constrained).
>
>

---

From: Rodney Cummings <[email-masked]>
Date: Fri, 20 Nov 2015 18:03:57 +0000

I agree that the CoMI approach is better in this respect.
From: Andy Bierman [mailto:[email-masked]]
Sent: Friday, November 20, 2015 11:49 AM
To: Rodney Cummings <[email-masked]>
Cc: Carsten Bormann <[email-masked]>; Core <[email-masked]>
Subject: Re: [core] CoMI Cool draft splits

Hi,

Andy

On Fri, Nov 20, 2015 at 9:36 AM, Rodney Cummings <[email-masked]<mailto:[email-masked]>> wrote:
I agree with Carsten on the point below.

> From: core [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Carsten Bormann
> To: Andy Bierman <[email-masked]<mailto:[email-masked]>>
> Cc: Core <[email-masked]<mailto:[email-masked]>>