Subject: [6tisch] Reserve space for aliases

From: Michel Veillette <[email-masked]>
Date: Fri, 5 Jun 2015 15:17:41 +0000

Hi Alexander

In your presentation at 6TiSCH, you propose the following data node ID structure.

*       32 bits YANG ID
-      20 bits for module ID (assigned by IETF)
-      10 bits for data node ID (generated deterministically)

Based on this structure, we can reserve module ID zero for aliases.

If we want to minimize both the network an node resources require by this alias mechanism, we can map an entire module to this space.
This can be implemented by a single integer resource (e.g. leaf alliassedModule { type uint32 } )
This approach require 4 bytes per CoMI server accessed.

If we want a more complex but more flexible aliases mechanism, your proposed map of (allias, YANG ID) seem the solution.
However, we have to consider that this structure can be as large as 1250 bytes per CoMI server accessed if limited to 256 aliases.

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

---

From: Alexander Pelov <[email-masked]>
Date: Fri, 5 Jun 2015 18:02:30 +0200

Hi Michel,

> Le 5 juin 2015 à 17:17, Michel Veillette <[email-masked]> a écrit :
> 
> Hi Alexander
>  
> •       32 bits YANG ID
> –      20 bits for module ID (assigned by IETF)
> –      10 bits for data node ID (generated deterministically)
>  

I was just summarizing what was discussed on the discussion in CoMI. Actually, it is 30 bits YANG ID, but that’s for purposes to be consistent with the YANG hash and I don’t mind keeping it 30 bits.

> This approach require 4 bytes per CoMI server accessed.

It is possible to map an entire module to the alias space and this is up to the operator. However, if you load two modules which redefine the same alias you will loose the benefit from it. Maybe it would be interesting to be able to specify that you want the aliases from THIS specific module to be used.

If the /mg/0 alias is reserved for managing the aliases, this could be simply saying:
POST /mg/0
{
 "source_uri" : "/mg/BAA"
}

where /mg/BAA is the YANG id of the module (20 bits module ID + 10 bits set to 0). This way, the server will know: OK, get the alias mapping from the YANG scheme of module with ID = B (as defined by the IETF). 

Or, you can dynamically configure the mapping:
POST /mg/0
{
  YANG_id : alias,
  YANG_id : alias,
  YANG_id : alias
}

> However, we have to consider that this structure can be as large as 1250 bytes per CoMI server accessed if limited to 256 aliases.

This is assuming you need a separate mapping for each server. I would suppose that in a network you’ll have a single alias mapping (maybe two?) - after all, you’re trying to optimize the management of your devices (servers). So, typically you’d map all 6tisch devices with aliases 1-10 (channel, slot, etc.) and use that on them, and on all other you’d access the full ID. 

Best,
Alexander

> [email-masked] <mailto:[email-masked]>
> www.trilliantinc.com <http://www.trilliantinc.com/>

---

From: Michel Veillette <[email-masked]>
Date: Fri, 5 Jun 2015 18:41:26 +0000

Hi Alexander

I have some concerns about allowing CoMI client(s) the control of the list of aliases.
This approach work fine for the first CoMI application (e.g. 6TiSCH) but what do we do with the subsequent CoMI application?

One possible solution is that each CoMI client send a list of (alias, data node ID) to the CoMI server. In this case, the CoMI client might receive an error if one or multiple of these aliases are already reserved.

A second possible solution is that each CoMI client send a list of (data node ID) and get a list of (alias, data node ID) from the CoMI server. In this case, CoMI clients will have to deal with a mix population of aliases.

The proposed solution need to scale to a multi-vendors, multiple applications environment.
With this is mind, do you have any alternative solutions to propose?

Michel Veillette

From: Alexander Pelov [mailto:[email-masked]]
Sent: 5 juin 2015 12:03
To: Michel Veillette
Cc: Andy Bierman; [email-masked]; [email-masked]
Subject: Re: Reserve space for aliases

Hi Michel,

Le 5 juin 2015 à 17:17, Michel Veillette <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Alexander

•       32 bits YANG ID

Best,
Alexander

Michel Veillette

---

From: Andy Bierman <[email-masked]>
Date: Fri, 5 Jun 2015 11:55:10 -0700

On Fri, Jun 5, 2015 at 11:41 AM, Michel Veillette <
[email-masked]> wrote:

> This approach work fine for the first CoMI application (e.g. 6TiSCH) but
> what do we do with the subsequent CoMI application?
>
>
>
> One possible solution is that each CoMI client send a list of (alias, data
> node ID) to the CoMI server. In this case, the CoMI client might receive an
> error if one or multiple of these aliases are already reserved.
>
>
>
> A second possible solution is that each CoMI client send a list of (data
> node ID) and get a list of (alias, data node ID) from the CoMI server. In
> this case, CoMI clients will have to deal with a mix population of aliases.
>
>
>

Does this approach allow each client to have a different set of aliases,
so the server has to maintain a configured mapping for each client?
This seems like a lot of overhead and NV-storage requirements
on the server.

Changing the schema identifiers based on which client is
sending the request seems like a complicated design change
from RESTCONF, NETCONF, or SNMP, where there is only
1 schema tree which is not dependent on the client identity.

Andy

> [email-masked]
>
> www.trilliantinc.com
>
>
>
>
>
> *From:* Alexander Pelov [mailto:[email-masked]]
> *Sent:* 5 juin 2015 12:03
> *To:* Michel Veillette
> *Cc:* Andy Bierman; [email-masked]; [email-masked]
> *Subject:* Re: Reserve space for aliases
>
>
>
> Hi Michel,
>
>
>
>
>
>  Le 5 juin 2015 à 17:17, Michel Veillette <
> [email-masked]> a écrit :
>
>
>
> Hi Alexander
>
>
>
> I was just summarizing what was discussed on the discussion in CoMI.
> Actually, it is 30 bits YANG ID, but that’s for purposes to be consistent
> with the YANG hash and I don’t mind keeping it 30 bits.
>
>
>
>
>
>   If we want to minimize both the network an node resources require by
> this alias mechanism, we can map an entire module to this space.
>
> It is possible to map an entire module to the alias space and this is up
> to the operator. However, if you load two modules which redefine the same
> alias you will loose the benefit from it. Maybe it would be interesting to
> be able to specify that you want the aliases from THIS specific module to
> be used.
>
>
>
> where /mg/BAA is the YANG id of the module (20 bits module ID + 10 bits
> set to 0). This way, the server will know: OK, get the alias mapping from
> the YANG scheme of module with ID = B (as defined by the IETF).
>
>
>
>   If we want a more complex but more flexible aliases mechanism, your
> proposed map of (allias, YANG ID) seem the solution.
>
> However, we have to consider that this structure can be as large as *1250
> bytes per CoMI server accessed* if limited to 256 aliases.
>
>
>
> This is assuming you need a separate mapping for each server. I would
> suppose that in a network you’ll have a single alias mapping (maybe two?) -
> after all, you’re trying to optimize the management of your devices
> (servers). So, typically you’d map all 6tisch devices with aliases 1-10
> (channel, slot, etc.) and use that on them, and on all other you’d access
> the full ID.
>
>
>
> Best,
>
> Alexander
>
>
>
>
>
>
> Michel Veillette
> [email-masked]
>
> www.trilliantinc.com
>
>
>

---

From: Alexander Pelov <[email-masked]>
Date: Fri, 5 Jun 2015 22:10:06 +0200

Hi Andy,

You are right that if we start considering multiple clients, each of which trying to use its aliases the things become.. les optimal. And if no caution is taken - can spell trouble.

The point is, your default behavior should be to use the normal ID. However, in some cases, you may decide that you’re going to be having quite a lot of exchanges with the same ID, so yes, you can redefine the alias mapping. 

However, you are right that we need to take care of eventual race conditions. Indeed, in 6TiSCH and other managed networks it may not happen (which alone is sufficient for me to have this « golden » IDs be left out of the « randomly allocated », or « eternally locked to a specific ID » resources).

Having the /mg/A resource provide the meta-information can help solve a lot (all?) of the problems. (in my past mails I referred this as /mg/0 but I meant /mg/A, sorry)

The first requirement for a client is to query the /mg/A resource. 
There, you can get the meta-data concerning the aliases, including the hash of the alias mapping, the mapping itself (if necessary), and the updater (identified by a token). I’m wondering if there could be added a validity of the mapping. A client can change the mapping ONLY if it is the last updater (hash+token match), or if the validity has expired. If the server has a way of keeping time it can track the validity itself. Otherwise, it can be a constant datetime after which the resource is considered expired and any client can update the resource. 

Just to be sure, I’m talking about clients, which are capable enough to keep track of some context about the servers it controls OR a client in a particular kind of network, which knows that some things are just expected to be there and there is no way for them to happer otherwise. 

*****************
** The default way of doing things should always be to use the normal IDs.** If you want to be optimal (in some way), get /mg/A, and if you understand it - use it. If there’s nothing, POST whatever you like, but be sure that you have enough resources to remember what you’re doing. 
* 
* If you want to set a different configuration in each of your 10M nodes, then well you should have the storage to remember all of them.
*****************

By the way, I was thinking of something quite interesting, which can come supplement the node ID aliasing. Actually, I think that the 20 bits + 10 bits YANG id really opens a lot of perspectives (will try to write that up tomorrow).

The major point is that when the data node ID = 0, the module ID can be used as a resource to obtain meta-information on the module. For example, its version. This way, if you update a YANG module with a new one, which only appends elements, you will not need to request a new managed ID. GET /mg/moduleID?keys=version (with data node ID=0) and you know what is your module really capable of. 

Also, the special place of /mg/A can actually become an entry point for most of the information related to CoMI (to be discussed.. I have no strong feelings on this). It can, for example, provide the mod.uri, and other information. The only information that remains truly necessary to be fixed in /.well-known/core is the entry point to the CoMI interface (e.g. /mg). Afterwards, everything can be determined from /mg/A with queries (/mg/A?keys=mod.uri+alias.uri)

Best,
Alexander

PS.
As if data node aliasing is not enough… module ID aliasing (this one is really very low in my priorities and I’m mentioning it only for completeness):

The first 12 bits take 2 URI characters and 2 bytes in CBOR. Having 10 bits for the data node ID leaves 2 interesting bits in the module ID part… So we can have module aliases as well (albeit only 3).

That is, in URI encoding, 
0x00000000-0x000003FF -> data node aliasing
0x00000400-0x000007FF -> aliased module 1
0x00000800-0x00000BFF -> aliased module 2
0x00000C00-0x00000BFF-> aliased module 3

Implementation-wise, its really easy: upon request, if the module ID = aliased module ID 1, replace the module ID part, so no need to map the entire module ID / data node ID space. 

But really, that much optimization? Even if it seems straightforward, I would like to see use cases that could benefit from this before actually considering it.

> Le 5 juin 2015 à 20:55, Andy Bierman <[email-masked]> a écrit :
> 
> 
> 
> On Fri, Jun 5, 2015 at 11:41 AM, Michel Veillette <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Alexander
> 
>  
> 
> From: Alexander Pelov [mailto:[email-masked] <mailto:[email-masked]>] 
> Sent: 5 juin 2015 12:03
> To: Michel Veillette
> Cc: Andy Bierman; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> Le 5 juin 2015 à 17:17, Michel Veillette <[email-masked] <mailto:[email-masked]>> a écrit :
> 
>  
> 
> Hi Alexander
> 
>  
>

---

From: Michel Veillette <[email-masked]>
Date: Fri, 5 Jun 2015 21:43:42 +0000

Hi Alexander and Hi Andy

I thinks we can avoid the support of a complex aliases mechanism and still archive the same level of message compression.
The solution consists of supporting two forms of data node identifier, the same way as RESTconf. (e.g. ietf-system:current-datetime vs. current-datetime)

The long form will consist of the ID format proposed by Alexander  (2 reserved bits, 20 bits module ID, 10 bits data node ID).
The short form will carry only the data node ID  (10 bits data node ID).
The long form will be used only when needed.

Let assume we have these two modules:

module a {

  container containerA {
    leaf leafA1 { type string},
    leaf leafA2 { type string}
  }
}

module b {
  import a { prefix a; }

  augment "/a:containerA" {
    leaf leafA3 { type string}
  }
}

Let assume we have these assigned IDs:

ID

Full ID

Base64

module a

25

container containerA

1

110010000000001 = 25601

GQB

leaf leafA1

2

110010000000010 = 25602

GQC

leaf leafA2

3

110010000000011 = 25602

GQD

module b

26

leaf leafA3

1

110100000000001 = 26625

GgB

A GET can be implemented as follow:

REQ: GET example.com/mg/GQB

RES: 2.05 Content (Content-Format: application/cbor)
{
  1 : {
    2 : " leafA1 value",
    3 : " leafA2 value "
    26625 : " leafA3 value "
  }
}

A PUT can be implemented as follow:

REQ: PUT example.com/mg
{
  25601 : {
    2 : " leafA1 value",
    3 : " leafA2 value "
    26625 : " leafA3 value "
  }
}

RES: 2.05 Ok

Michel Veillette

From: Alexander Pelov [mailto:[email-masked]]
Sent: 5 juin 2015 16:10
To: Andy Bierman
Cc: Michel Veillette; [email-masked]; [email-masked]
Subject: Re: Reserve space for aliases

Hi Andy,

*****************

Best,
Alexander

PS.

Le 5 juin 2015 à 20:55, Andy Bierman <[email-masked]<mailto:[email-masked]>> a écrit :

On Fri, Jun 5, 2015 at 11:41 AM, Michel Veillette <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alexander

Andy

Michel Veillette

From: Alexander Pelov [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 5 juin 2015 12:03
To: Michel Veillette
Cc: Andy Bierman; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Reserve space for aliases

Hi Michel,

Hi Alexander

•       32 bits YANG ID

Best,
Alexander

Michel Veillette

---

From: Alexander Pelov <[email-masked]>
Date: Sun, 7 Jun 2015 11:21:06 +0200

Hi Michel,

That sound great! Having the short form (10 bits data node ID) and long form (20 bits module ID + 10 bits data node ID), can save quite a lot when dealing with more than isolated data items, as you point in your example. 

As I mentioned earlier, having your moduleID+0000000000 can be used as YANG id for the module, which can provide meta-information on the loaded module. For example, if you issue a request against that ID and receive Resource not found, then the module is not loaded (but this of course should not be the way to discover it). Is this useful? If there is need for module versioning, the YANG module ID can be used to obtain the versioning information. Having deterministic data node IDs can be used to have versions of the same module (e.g. adding new leafs, new containers, etc.) - removing things out will require new module ID.

In addition to having reduced data requirements (in URIs and CBOR), having the fixed YANG module IDs helps locate some special resources.
E.g. module ID:
   aliasing : 18 bits = 0 + 00
      full YANG module ID = AAAA (compressed to A)
   YANG meta-data module: 18 bits = 0 + 01
      full YANG module ID= AAAg0 (compressed to g0)
   Reserved for future use: 18 bits = 0 + 10 and 18 bits = 0 + 11
 
The YANG meta-data module can provide all necessary meta-information, e.g. mod.uri, the loaded modules, their versions, and so forth. This keeps the separation between aliasing and meta-information. Note, that the meta-module YANG scheme will be published with a normal assigned YANG module ID, which will be mapped to the /mg/g0, e.g. changing the meta-data a couple of years down the road is possible with or without versioning.

I also don’t think it would be a good idea to have complex aliasing mechanisms, and this should be further discussed. It will be very useful for managed networks. The /mg/A resource should be kept as light as possible. For the moment I think there are only two necessary pieces of information that need to be given by it: hash-value of the contents of the mapping and URI to extract the full mapping. The mapping can be obtained from the meta-data (/mg/g0 or .well-known/core).  The simplest mechanism to be used is the following: 

1) If no aliases are defined, then the client can POST a new alias mapping
   1.a) the alias mapping expires after a timer (default value = 1h, which can be overridden by the client)
   1.b) upon timer expiry, the alias mapping is deleted
   1.c) the timer can be extended with a keep-alive POST from any client
2) An alias mapping cannot be altered or deleted by a client. 

The reasoning behind this is the following: A node becomes ‘managed’ by a client, and the client registers this. If a different client tries to POST new configuration it will receive a 4.03 Forbidden. 

This actually makes configuring and implementing aliases really straightforward. Upon discovery of a node, a client can directly POST to /mg/A, and if it receives:
   - "4.04 Not Found", then aliasing is not supported
   - "4.03 Forbidden", the alias mapping is already defined (by someone else)
   - "2.01 Created" - alias defined
   - "2.04 Changed" - alias timer updated

If the /mg/g0 is accepted as YANG meta-data module pointer, then the actual alias mapping can be retrieved from there. 

Best,
Alexander

> Le 5 juin 2015 à 23:43, Michel Veillette <[email-masked]> a écrit :
> 
> Hi Alexander and Hi Andy
>  
> REQ: GET example.com/mg/GQB <http://example.com/mg/GQB>
>  
> REQ: PUT example.com/mg <http://example.com/mg>
> {
>   25601 : {
>     2 : " leafA1 value",
>     3 : " leafA2 value "
>     26625 : " leafA3 value "
>   }
> }
>  
> RES: 2.05 Ok
>  
>  
> Michel Veillette
> Cc: Michel Veillette; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> Le 5 juin 2015 à 20:55, Andy Bierman <[email-masked] <mailto:[email-masked]>> a écrit :
>  
> 
>

---

From: Michel Veillette <[email-masked]>
Date: Mon, 8 Jun 2015 14:35:56 +0000

Hi Alexander

The proposed “long form, short form” is incompatible with the concept of aliases since the short form ID space is the same as the proposed aliases ID space. We will have to choose one or the other. In the following example, IDs 1, 2, 3 is the short form within the module ID 25, not alias 1, 2, 3. “long form, short form” add some extra overhead compared to aliases, however this approach have multiple advantages:

·         Allows compression of all modules, not just a small subset of IDs (20 or 256 IDs)

·         Do not require an initial handshake for aliases discovery or configuration

·         Can be implemented using the same simple rules as RESTconf

About the meta information such as the list of modules and the list for streams. This should be implemented using YANG modules , “ietf-yang-library” and “ietf-restconf-monitoring” or equivalent. We don’t need to create special behaviours or special query parameters to implement this meta data.

http://www.netconfcentral.org/modules/ietf-yang-library/2014-09-26

ietf-yang-library:modules/module/name
ietf-yang-library:modules/module/revision
ietf-yang-library:modules/module/schema
ietf-yang-library:modules/module/namespace
ietf-yang-library:modules/module/feature
ietf-yang-library:modules/module/conformance
ietf-yang-library:modules/module/submodule/name
ietf-yang-library:modules/module/submodule/revision
ietf-yang-library:modules/module/submodule/schema

http://www.netconfcentral.org/modulereport/ietf-restconf-monitoring

ietf-restconf-monitoring:restconf-state/capabilities/capability
ietf-restconf-monitoring:restconf-state/streams/stream/name
ietf-restconf-monitoring:restconf-state/streams/stream/description
ietf-restconf-monitoring:restconf-state/streams/stream/replay-support
ietf-restconf-monitoring:restconf-state/streams/stream/replay-log-creation-time
ietf-restconf-monitoring:restconf-state/streams/stream/encoding/type
ietf-restconf-monitoring:restconf-state/streams/stream/encoding/events

Michel Veillette

Sent: 7 juin 2015 05:21

Hi Michel,

Best,
Alexander

Le 5 juin 2015 à 23:43, Michel Veillette <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Alexander and Hi Andy

module a {

  container containerA {

module b {
  import a { prefix a; }

ID

Full ID

Base64

module a

25

container containerA

1

110010000000001 = 25601

GQB

leaf leafA1

2

110010000000010 = 25602

GQC

leaf leafA2

3

110010000000011 = 25602

GQD

module b

26

leaf leafA3

1

110100000000001 = 26625

GgB

REQ: GET example.com/mg/GQB<http://example.com/mg/GQB>

REQ: PUT example.com/mg<http://example.com/mg>
{
  25601 : {
    2 : " leafA1 value",
    3 : " leafA2 value "
    26625 : " leafA3 value "
  }
}

RES: 2.05 Ok

Michel Veillette

From: Alexander Pelov [mailto:[email-masked]]
Sent: 5 juin 2015 16:10
To: Andy Bierman
Cc: Michel Veillette; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Reserve space for aliases

Hi Andy,

*****************

Best,
Alexander

PS.

Andy

Michel Veillette

Hi Michel,

Hi Alexander

•       32 bits YANG ID

Best,
Alexander

Michel Veillette

---

From: Alexander Pelov <[email-masked]>
Date: Mon, 8 Jun 2015 17:59:58 +0200

Hi Michel,

> Le 8 juin 2015 à 16:35, Michel Veillette <[email-masked]> a écrit :
> 
> Hi Alexander
>  

Ok, I see what you mean. Indeed, there could be a way to have both aliases and the long form, short form, but maybe it becomes a little bit clumsy, and the goal is to avoid complexity.

In your proposal, the module ID = 0 is reserved for the compression prefix, and I agree that this will be more generic than simply leaving it for the aliases. 

However, I would still consider that there are interesting cases where aliasing can be applied. There are two possibilities to reconcile them:
1) reserve data node ID < 24. Module ID=0 + data node IDs < 24 can then be used for the aliasing (if needed). The specification of this can be out of CoMI or with the simple mechanism I described in the previous mail. 
2) reserve module ID = 1 (or /mg/g0) for aliasing. Maybe this would be the best solution, as it only increases the alias URI with 1 character compared to the initial proposal. 

I would go with 2), as it has the same merits of the aliases (can be standardized very simply, at no cost for devices), and is only based on reserving a module ID for this purpose. It keeps the possibility to use the compressed YANG id + long form / short form. 

> http://www.netconfcentral.org/modules/ietf-yang-library/2014-09-26 <http://www.netconfcentral.org/modules/ietf-yang-library/2014-09-26>
>  
> http://www.netconfcentral.org/modulereport/ietf-restconf-monitoring <http://www.netconfcentral.org/modulereport/ietf-restconf-monitoring>
>  

Ok, great! Thanks for pointing this out - there is no need to reinvent the wheel.

Best,
Alexander

> Le 5 juin 2015 à 23:43, Michel Veillette <[email-masked] <mailto:[email-masked]>> a écrit :
>  
> Hi Alexander and Hi Andy
>

---

From: Michel Veillette <[email-masked]>
Date: Mon, 8 Jun 2015 18:26:22 +0000

Hi Alexander

We had some discussions lately about using the “select” query parameter with a CBOR content instead of a URI with a base64 data node ID.
Did I understand correctly, Andy?

I see multiple advantages to this approach:

·         we can select a list of data nodes instead of a single data node

·         we can use the full 32 bits of the data node ID (instead of 30 bits)

·         we don’t need to support two different representation of the data node IDs

For example: (Using the IDs introduced earlier in the thread)

To select leafA1:

   REQ: GET example.com/mg?select(25602)

     2 : " leafA1 value"
   }

To select leafA1, leafA2 and leafA3:

   REQ: GET example.com/mg?select( [ 25602, 3, 26625 ] )

     2 : " leafA1 value"
     3 : " leafA2 value ",
     26625 : " leafA3 value "
   }

Notes:

·         In the first example, the select query parameter contains  0x196402

·         In the second example, the select query parameter contains  0x8319640203196801

·         Data node IDs within the list encoded using the short form inherit the module ID of the previous item.

·         Module ID 1 to 63 are more compact (2 octets) and should be reserved to standardized modules.

Michel Veillette

Sent: 8 juin 2015 12:00

Hi Michel,

Le 8 juin 2015 à 16:35, Michel Veillette <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Alexander

The proposed “long form, short form” is incompatible with the concept of aliases since the short form ID space is the same as the proposed aliases ID space. We will have to choose one or the other. In the following example, IDs 1, 2, 3 is the short form within the module ID 25, not alias 1, 2, 3. “long form, short form” add some extra overhead compared to aliases, however this approach have multiple advantages:
•         Allows compression of all modules, not just a small subset of IDs (20 or 256 IDs)
•         Do not require an initial handshake for aliases discovery or configuration
•         Can be implemented using the same simple rules as RESTconf

    2 : " leafA1 value",,
    3 : " leafA2 value ",
    26625 : " leafA3 value "
  }
}

Best,
Alexander

Michel Veillette

Hi Michel,

Best,
Alexander

Hi Alexander and Hi Andy

module a {

  container containerA {

module b {
  import a { prefix a; }

ID

Full ID

Base64

module a

25

container containerA

1

110010000000001 = 25601

GQB

leaf leafA1

2

110010000000010 = 25602

GQC

leaf leafA2

3

110010000000011 = 25602

GQD

module b

26

leaf leafA3

1

110100000000001 = 26625

GgB

RES: 2.05 Ok

Michel Veillette

Hi Andy,

*****************

Best,
Alexander

PS.

Andy

Michel Veillette

Hi Michel,

Hi Alexander

•       32 bits YANG ID

Best,
Alexander

Michel Veillette

---

From: Alexander Pelov <[email-masked]>
Date: Tue, 9 Jun 2015 08:19:37 +0200

Hi Michel,

The goal of aliases is to be as compact as possible. Adding query parameter seems to me to counter the whole point. However, the select query parameter may have sense in other contexts.

> Module ID 1 to 63 are more compact (2 octets) and should be reserved to standardized modules.

Completely agree that module ID < 64 are special and should be treated as such. How do you chose the standard modules, which will have the privilege to be always compact, whereas all future modules will be taking 4 octets in the CBOR representation? Moreover, module ID < 4 are even MORE special, as they take 2 characters in the URI, and all the rest take 3+ characters.

Thats, you have module ID = 1, 2 and 3 are also quite special, and reserving one of them for an optimization mechanism (instead of allocating it to a specific module) doesn’t seem far fetched to me. What do you think?

Keeping the logic where module ID = 1, data node ID = 0 will provide the alias fast detection / configuration, module ID = 1, data node ID = 1023 (YANG id = 2047, URI = /mg/__) could be a meta-parent node for all aliases. This will work like a charm with your proposed long form / short form, e.g. if I have the following mapping:
{
  1 : 25601,
  2 : 25602,
  3 : 26225,
  4 : 50001
}

Then, you could get all these values in one go:

REQ: GET example.com/mg/ <http://example.com/mg/gB>__       (module ID = 1 / data node ID = 1023)

     1 : 'leafA1 value’
     2 : 'leafA2 value',
     3 : 'leafA3 value’,
     4 : 'leafB value’
}

When taking your example into account, you could also update selected leafs as in your example:

REQ: PUT example.com/mg
{
  2047 : {
    1 : 'leafA1 value',
    3 : 'leafA2 value’, 
    4 : 'leafB value'
  }
}
 
RES: 2.05 Ok

As always, it is sufficient to say that module ID = 1 is reserved for aliases and leave the specification to an external document, which seems to me the simplest solution. 

Actually, due to the special nature of module ID = 1..3, I would expect them to be all reserved for some special modules, but of course I would not be the right person to decide which are these. 

I feel that the structured YANG form (20 bits + 10 bits) + YANG id URI compression + ID long form / short form really allowed us to advance quite a lot from the YANG hash. Adding a reserved module ID would not shock me, and can cover interesting use cases. What do you think?

Best,
Alexander

> Le 8 juin 2015 à 20:26, Michel Veillette <[email-masked]> a écrit :
> 
> Hi Alexander
>  
>    REQ: GET example.com/mg?select <http://example.com/mg?select>(25602)
>  
>    REQ: GET example.com/mg?select <http://example.com/mg?select>( [ 25602, 3, 26625 ] )
>  
> Le 8 juin 2015 à 16:35, Michel Veillette <[email-masked] <mailto:[email-masked]>> a écrit :
>  
> Hi Alexander
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 10 Jun 2015 13:25:56 +0000

Dear all:

This looks like the problem of local namespaces,  which is the reason why MPLS switches labels.
The user may access a limited set of resources from a number of servers, and servers are read by many users.
You cannot ensure that you have a single alias space that satisfies them all.

So ,what if the user had its own set of aliases and the server also had its own set of aliases?

The aliases could be mapped in a table like a uSAP and a pSAP are mapped across layers. Broadly:
- First time a user requests a resource in a server, it comes with a tuple (userid, useralias, fullname)
- The server responds with (serverid, serveralias, userid, useralias).

After that,  if the server is a constrained device then the user talks to the server with (serverid, serveralias) and the user maintains a switching table for the resource it uses on various servers.
If the user is the constrained device and the server is not, the user could talk with (userid, useralias) and the server maintains a switching table.

For large servers, the server may allocate aliases dynamically based on what it is being asked. We’d then need to talk about alias update or revocation, probably in terms of session and lifetime.

Does that look usable?

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: vendredi 5 juin 2015 20:55
To: Michel Veillette
Cc: [email-masked]; Alexander Pelov; [email-masked]
Subject: Re: [6tisch] Reserve space for aliases

Andy

Michel Veillette

Hi Michel,

Hi Alexander

•       32 bits YANG ID

Best,
Alexander

Michel Veillette

---

From: Michel Veillette <[email-masked]>
Date: Wed, 10 Jun 2015 17:04:26 +0000

Hi Pascal.

If we move ahead with the solution discussed between myself and Alexander, aliases won’t save much space and are not worth it.

The solution is based on the following principles:

·         Data nodes are identified using a 20 bits registered module identifier and a 10 bits assigned YANG ID, 2 bits are reserved for future use.

·         Similarly as RESTconf, data nodes can be identified using a long form (module identifier, YANG ID) or a short form (YANG ID). Long form is used only when needed.

Note: Module ID zero is invalid since it occupy the same ID space as the short form.

·         Data node(s) selected by a GET statement are listed in a query parameter and encoded in CBOR.

·         Meta data (e.g. list of modules, module version) are provided using standard YANG modules

The solution have the following characteristics:

·         No hash, no clashes, no re-hash table

·         No initial handshake required

·         No base64 encoding

For example

·         Assuming module ID 25, YANG ID 2 to 5

·         Assuming that module ID 25, YANG  ID 2 is encoded using the long form as 11001 0000000010 or 25602

REQ: GET example.com/mg?select( [ 25602, 3 ] )

 2 : "value",
  3 : {
    4 : "value",
    5 : "value",
  }
}

REQ: PUT example.com (Content-Format: application/cbor)
{
  25603 : {
    4 : "value",
    5 : "value",
  }
}

RES: 2.05 Ok

Michel Veillette

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: 10 juin 2015 09:26
To: Andy Bierman; Michel Veillette
Cc: [email-masked]; Alexander Pelov; [email-masked]
Subject: RE: [6tisch] Reserve space for aliases

Dear all:

Does that look usable?

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: vendredi 5 juin 2015 20:55
To: Michel Veillette
Cc: [email-masked]<mailto:[email-masked]>; Alexander Pelov; [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] Reserve space for aliases

Andy

Michel Veillette

Hi Michel,

Hi Alexander

•       32 bits YANG ID

Best,
Alexander

Michel Veillette

---

From: Alexander Pelov <[email-masked]>
Date: Thu, 11 Jun 2015 23:06:24 +0200

Hi Pascal,

> Le 10 juin 2015 à 15:25, Pascal Thubert (pthubert) <[email-masked]> a écrit :
> 
> Dear all:
>  

Great analogy! And yes, sadly you cannot satisfy them all, at least not with all devices.

> - The server responds with (serverid, serveralias, userid, user alias).

Actually, I think that this could be worked out in CoMI also. Instead of fullname you could provide the YANG id (module ID + data node ID) and do the mapping. User alias would be the special aliased YANG id. User ID, however, could be a little bit more tricky - how do we ensure that it is consistent? Use the IP address of the client could be doable, but we’ll have to include the UDP port just in case someone runs two clients on the same machine.

> For large servers, the server may allocate aliases dynamically based on what it is being asked. We’d then need to talk about alias update or revocation, probably in terms of session and lifetime.

You are pointing out an interesting question. I would think (but maybe I’m mistaken), that the client should have the leading role in figuring out what’s happening. The idea is the following:

The client checks if the server supports aliasing, with the possible options:
S1) no aliasing
S2) static/server-defined aliasing
S3) dynamic/single alias mapping 
  S3.1) mapping already defined
  S3.2) no mapping defined
S4) dynamic/per client alias mapping

Then, the client can take action, depending on its own capabilities and the response of the server. E.g. a unconstrained client could obtain the alias mapping if it is static (or if there is a single alias mapping in place) and cache it locally. So, there will be the following correspondence :

Given:
C1) constrained client
C2) unconstrained client

We have:
C1 + S1) no aliasing, nothing to do
C1 + S2) and C1 + S3.1) if the alias mapping is known, use it. otherwise, ignore
C1 + S3.2) and C1 + S4) define alias mapping

C2 + S1) no aliasing, nothing to do
C2 + S2) and C2 + S3.1) if the alias mapping is known, use it. otherwise, learn it
C2 + S3.2) and C2 + S4) define alias mapping

I would say that the analogy you made with MPLS corresponds quite a lot to the C2+S4 case. Personally, I would be most interested into having one client configure one alias mapping to all servers in the network (e.g. the managing entity), which will profit most from saving several bytes on each message exchange. Everyone else could use the standard IDs, which we’ve already managed to shrink significantly.

Indeed, with structured module ID + data node ID (20 bits + 10 bits), YANG URI compression, and long form/short form, we’ll have quite a lot of gain. Reserving module ID = 1 for aliases and maybe writing a short draft on how the aliasing is implemented seems feasible, where we can cover the exact mechanism of alias definition, and client/server interaction.

Alexander

---

From: Michel Veillette <[email-masked]>
Date: Fri, 12 Jun 2015 16:57:37 +0000

Hi Alexander, hi Pascal

I want to emphases the following points

·         The use of the select query parameter encoded in CBOR support of 63 modules with optimized message size instead of only 3 for the base64 URI.

If the 6TiSCH module ID is allocated within these 63 IDs, there will be no message size optimization provided by the aliases mechanism.

This make the introduction of aliases less urgent.

·         The message size of the select query parameter encoded in CBOR should be equal or smaller compared to the base64 URI.

However, the select query parameter encoded in CBOR support a wider range of values without size penalty (16 bits instead of 12, 32 bits instead of 30)

Furthermore, CoMI devices won’t have to support two type of encoding depending if IDs are part of the command vs. payload.

For example:

Assuming module ID 2

Assuming data node ID 1, 2, 3, 4 (long form 2049, 2050, 2051)

Assuming “,” separator to select multiple data nodes

Base64 approach:

REQ: GET example.com/mg/gB         (3 bytes; 1 byte for the “/”, 2 bytes for “gB”)

CBOR approach:

REQ: GET example.com/mg?select(2049)         (4 bytes; one byte for the CoAP option, 3 for 2049 encoded using CBOR)

Base64 approach:

REQ: GET example.com/mg/gB,C,D,E         (9 bytes; 1 byte for the “/”, 8 bytes for “gB,C,D,E”)

CBOR approach:

REQ: GET example.com/mg?select( [2049,2,3,4] )      (8 bytes; 1 byte for the CoAP option, 1 for the CBOR array, 3+1+1+1 bytes for the IDs)

Michel Veillette

From: Alexander Pelov [mailto:[email-masked]]
Sent: 11 juin 2015 17:06
To: Pascal Thubert (pthubert)
Cc: Andy Bierman; Michel Veillette; [email-masked]; [email-masked]
Subject: Re: [6tisch] Reserve space for aliases

Hi Pascal,

Le 10 juin 2015 à 15:25, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> a écrit :

Dear all:

Does that look usable?

Given:
C1) constrained client
C2) unconstrained client

We have:

Alexander

Pascal

Andy

Michel Veillette

Hi Michel,

Hi Alexander

•       32 bits YANG ID

Best,
Alexander

Michel Veillette

---

From: Alexander Pelov <[email-masked]>
Date: Fri, 12 Jun 2015 21:25:45 +0200

Hi Michel,

You’re right. As I mentioned in my previous mails, I’m pretty happy with the compression of IDs we’ve achieved until now, so aliases are not as a pressing issue. 

The thing is, if they can be implemented at (almost) zero cost, then some of the use-cases become quite interesting.

You actually provide a very good case with the select option. I’ve not thought if it will present some other difficulties, but I actually think it facilitates the use of aliases (and I mention this only because it will help me also understand the semantics of your proposal of the select option).

If I take the example you provide:
> REQ: GET example.com/mg?select <http://example.com/mg?select>( [2049,2,3,4] ) 

The parameters 2,3,4 are actually relative to the module ID of the first one. So, if I try to generalize this (please correct me if I’m wrong), I would imagine something like:
> REQ: GET example.com/mg?select <http://example.com/mg?select>( [2049,2,3,4, 4097,2,3,4] ) 
To resolve to getting module ID=1, relative node IDs=1,2,3 and 4, and module ID=2 and relative node IDs =1,2,3 and 4.

This means, that specifying a GET example.com/mg?select(1) should resolve to module ID=0 and relative node ID=1. This requires absolutely no additional processing from the node. 

So, this leaves us back to the initial idea of the aliases. All short node IDs are relative to a module ID (so that the long form ID can be interpreted). Module ID=0 is reserved, and can be used for aliasing if the device wishes to support it. 

Does this break some of the things along the way? 

Best,
Alex

> Le 12 juin 2015 à 18:57, Michel Veillette <[email-masked]> a écrit :
> 
> Hi Alexander, hi Pascal
>  
> REQ: GET example.com/mg/gB <http://example.com/mg/gB>         (3 bytes; 1 byte for the “/”, 2 bytes for “gB”)
>  
> CBOR approach:
> REQ: GET example.com/mg?select <http://example.com/mg?select>(2049)         (4 bytes; one byte for the CoAP option, 3 for 2049 encoded using CBOR)
>  
> Base64 approach:
> REQ: GET example.com/mg/gB,C,D,E <http://example.com/mg/gB,C,D,E>         (9 bytes; 1 byte for the “/”, 8 bytes for “gB,C,D,E”)
>  
> CBOR approach:
> REQ: GET example.com/mg?select <http://example.com/mg?select>( [2049,2,3,4] )      (8 bytes; 1 byte for the CoAP option, 1 for the CBOR array, 3+1+1+1 bytes for the IDs)
>  
>  
> Michel Veillette
> Le 10 juin 2015 à 15:25, Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>> a écrit :
>  
> Dear all:
>  
> From: 6tisch [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Andy Bierman
> Cc: [email-masked] <mailto:[email-masked]>; Alexander Pelov; [email-masked] <mailto:[email-masked]>

---

From: Michel Veillette <[email-masked]>
Date: Fri, 12 Jun 2015 21:10:13 +0000

I Alexander

I don’t see any issues with your proposal of using module ID 0 as aliases.
The only constrain is that aliases need to be at the start of the select for a GET and at the start of the payload for a PUT.

The last things we need to sort out, is the instance selector (keys) in the context of a select query parameter containing multiple data nodes.

Let assume the following:

·         A CoMI client need to select 3 data nodes (Data node ID 2049, 2 and 3)

·         For the first data node, three values need to be provided as keys (e.g. 1, "ipv4", "10.0.0.51 "), see draft-vanderstok-core-comi-06 page 22.

·         For the third data node, one integer value need to be provided as keys (e.g. 22).

If we include these keys in the select query parameter encoded in CBOR, the result might look as follow:

REQ: GET example.com/mg?select( [[20491,"ipv4","10.0.0.51",2], 2, [3,22]] )

In the current draft, the CoMI server need to support two encoding for each selector, CBOR encoding in the payload and text in the keys query parameter.
With this proposal, both use cases are encoded using CBOR.

What do you things?

Michel Veillette

From: Alexander Pelov [mailto:[email-masked]]
Sent: 12 juin 2015 15:26
To: Michel Veillette
Cc: Pascal Thubert (pthubert); Andy Bierman; [email-masked]; [email-masked]
Subject: Re: [6tisch] Reserve space for aliases

Hi Michel,

If I take the example you provide:
REQ: GET example.com/mg?select<http://example.com/mg?select>( [2049,2,3,4] )

The parameters 2,3,4 are actually relative to the module ID of the first one. So, if I try to generalize this (please correct me if I’m wrong), I would imagine something like:
REQ: GET example.com/mg?select<http://example.com/mg?select>( [2049,2,3,4, 4097,2,3,4] )
To resolve to getting module ID=1, relative node IDs=1,2,3 and 4, and module ID=2 and relative node IDs =1,2,3 and 4.

This means, that specifying a GET example.com/mg?select<http://example.com/mg?select>(1) should resolve to module ID=0 and relative node ID=1. This requires absolutely no additional processing from the node.

Best,
Alex

Le 12 juin 2015 à 18:57, Michel Veillette <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Alexander, hi Pascal

•         The use of the select query parameter encoded in CBOR support of 63 modules with optimized message size instead of only 3 for the base64 URI.
If the 6TiSCH module ID is allocated within these 63 IDs, there will be no message size optimization provided by the aliases mechanism.
This make the introduction of aliases less urgent.

•         The message size of the select query parameter encoded in CBOR should be equal or smaller compared to the base64 URI.
However, the select query parameter encoded in CBOR support a wider range of values without size penalty (16 bits instead of 12, 32 bits instead of 30)
Furthermore, CoMI devices won’t have to support two type of encoding depending if IDs are part of the command vs. payload.

For example:

Assuming module ID 2

Base64 approach:
REQ: GET example.com/mg/gB<http://example.com/mg/gB>         (3 bytes; 1 byte for the “/”, 2 bytes for “gB”)

CBOR approach:
REQ: GET example.com/mg?select<http://example.com/mg?select>(2049)         (4 bytes; one byte for the CoAP option, 3 for 2049 encoded using CBOR)

Base64 approach:
REQ: GET example.com/mg/gB,C,D,E<http://example.com/mg/gB,C,D,E>         (9 bytes; 1 byte for the “/”, 8 bytes for “gB,C,D,E”)

CBOR approach:
REQ: GET example.com/mg?select<http://example.com/mg?select>( [2049,2,3,4] )      (8 bytes; 1 byte for the CoAP option, 1 for the CBOR array, 3+1+1+1 bytes for the IDs)

Michel Veillette

From: Alexander Pelov [mailto:[email-masked]]
Sent: 11 juin 2015 17:06
To: Pascal Thubert (pthubert)
Cc: Andy Bierman; Michel Veillette; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] Reserve space for aliases

Hi Pascal,

Dear all:

Does that look usable?

Given:
C1) constrained client
C2) unconstrained client

We have:

Alexander

Pascal

Andy

Michel Veillette

Hi Michel,

Hi Alexander

•       32 bits YANG ID

Best,
Alexander

Michel Veillette

---

From: Alexander Pelov <[email-masked]>
Date: Fri, 12 Jun 2015 23:42:25 +0200

Michel,

> Le 12 juin 2015 à 23:10, Michel Veillette <[email-masked]> a écrit :
> 
> I Alexander
>  

Yes, I suppose you should always start with aliases, but that doesn’t sound like a strong constraint to me, so it’s seems like the perfect solution.

> REQ: GET example.com/mg?select <http://example.com/mg?select>( [[20491,"ipv4","10.0.0.51",2], 2, [3,22]] )

Just a small typo (missed a coma after 2049, right?):
> REQ: GET example.com/mg?select <http://example.com/mg?select>( [[2049, 1,"ipv4","10.0.0.51",2], 2, [3,22]] )

And yes, seems quite straightforward and reasonable to me. If I understand correctly, the format you use is the following:
The select parameter accepts a single integer (long form data ID) or an array. In the latter case, each element of the array may be either an integer (e.g. data ID), or an array in the form [data ID, key1, key2, …, keyN]. The data ID may be absolute (e.g. long form), or relative to the module of the previous data ID. 

This seems quite expressive, simple and compact. I wonder if we’re missing something, as it really does seem to have quite a lot of nice characteristics. 

Best,
Alexander

> This means, that specifying a GET example.com/mg?select <http://example.com/mg?select>(1) should resolve to module ID=0 and relative node ID=1. This requires absolutely no additional processing from the node. 
>  
> Le 12 juin 2015 à 18:57, Michel Veillette <[email-masked] <mailto:[email-masked]>> a écrit :
>  
> Hi Alexander, hi Pascal
>  
> Cc: Andy Bierman; Michel Veillette; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 12 Jun 2015 14:57:14 -0700

Hi,

Here is the "JSON for YANG" draft:
https://www.ietf.org/id/draft-ietf-netmod-yang-json-04.txt

The long form (module-name:local-name) is only used
at the top of a sub-tree and where the module namespace changes
(due to an augment from another module).

The data is hierarchical and the parser is required to maintain
the current module scope. It should be possible to omit the module
identifier is nested data, except for nodes that start a new
module scope.

Is this what you have in mind?
For YANG Hash (that has no module identifier)
every nested node ID needs the full 30 bits,
but this is not required for managed IDs.

Andy

On Fri, Jun 12, 2015 at 2:42 PM, Alexander Pelov <
[email-masked]> wrote:

> Michel,
>
>
> Le 12 juin 2015 à 23:10, Michel Veillette <
> The only constrain is that aliases need to be at the start of the select
> for a GET and at the start of the payload for a PUT.
>
>
> Yes, I suppose you should always start with aliases, but that doesn’t
> sound like a strong constraint to me, so it’s seems like the perfect
> solution.
>
>
> The last things we need to sort out, is the instance selector (keys) in
> the context of a select query parameter containing multiple data nodes.
>
> ·         For the first data node, three values need to be provided as
> keys (e.g. 1, "ipv4", "10.0.0.51 "), see draft-vanderstok-core-comi-06
> page 22.
> REQ: GET example.com/mg?select( [[2049, 1,"ipv4","10.0.0.51",2], 2,
> [3,22]] )
>
>
> And yes, seems quite straightforward and reasonable to me. If I understand
> correctly, the format you use is the following:
> The select parameter accepts a single integer (long form data ID) or an
> array. In the latter case, each element of the array may be either an
> integer (e.g. data ID), or an array in the form [data ID, key1, key2, …,
> keyN]. The data ID may be absolute (e.g. long form), or relative to the
> module of the previous data ID.
>
> This seems quite expressive, simple and compact. I wonder if we’re missing
> something, as it really does seem to have quite a lot of nice
> characteristics.
>
> Best,
> Alexander
>
>
>
> In the current draft, the CoMI server need to support two encoding for
> each selector, CBOR encoding in the payload and text in the keys query
> parameter.
> *From:* Alexander Pelov [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* 12 juin 2015 15:26
> *To:* Michel Veillette
> *Cc:* Pascal Thubert (pthubert); Andy Bierman; [email-masked];
> [email-masked]
> *Subject:* Re: [6tisch] Reserve space for aliases
>
> Hi Michel,
>
> You’re right. As I mentioned in my previous mails, I’m pretty happy with
> the compression of IDs we’ve achieved until now, so aliases are not as a
> pressing issue.
>
> The thing is, if they can be implemented at (almost) zero cost, then some
> of the use-cases become quite interesting.
>
> You actually provide a very good case with the select option. I’ve not
> thought if it will present some other difficulties, but I actually think it
> facilitates the use of aliases (and I mention this only because it will
> help me also understand the semantics of your proposal of the select
> option).
>
> REQ: GET example.com/mg?select( [2049,2,3,4] )
>
>
> The parameters 2,3,4 are actually relative to the module ID of the first
> one. So, if I try to generalize this (please correct me if I’m wrong), I
> would imagine something like:
>
> REQ: GET example.com/mg?select( [2049,2,3,4, 4097,2,3,4] )
>
> To resolve to getting module ID=1, relative node IDs=1,2,3 and 4, and
> module ID=2 and relative node IDs =1,2,3 and 4.
>
> This means, that specifying a GET example.com/mg?select(1) should resolve
> to module ID=0 and relative node ID=1. This requires absolutely no
> additional processing from the node.
>
> So, this leaves us back to the initial idea of the aliases. All short node
> IDs are relative to a module ID (so that the long form ID can be
> interpreted). Module ID=0 is reserved, and can be used for aliasing if the
> device wishes to support it.
>
> Le 12 juin 2015 à 18:57, Michel Veillette <
> ·         The use of the select query parameter encoded in CBOR support
> of 63 modules with optimized message size instead of only 3 for the base64
> URI.
> If the 6TiSCH module ID is allocated within these 63 IDs, there will be no
> message size optimization provided by the aliases mechanism.
> ·         The message size of the select query parameter encoded in CBOR
> should be equal or smaller compared to the base64 URI.
> However, the select query parameter encoded in CBOR support a wider range
> of values without size penalty (16 bits instead of 12, 32 bits instead of
> 30)
> Furthermore, CoMI devices won’t have to support two type of encoding
> depending if IDs are part of the command vs. payload.
>
> For example:
>
> Assuming module ID 2
> REQ: GET example.com/mg?select(2049)         (4 bytes; one byte for the
> CoAP option, 3 for 2049 encoded using CBOR)
>
> Base64 approach:
> REQ: GET example.com/mg?select( [2049,2,3,4] )      (8 bytes; 1 byte for
> the CoAP option, 1 for the CBOR array, 3+1+1+1 bytes for the IDs)
>
>
> Michel Veillette
> *From:* Alexander Pelov [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* 11 juin 2015 17:06
> *To:* Pascal Thubert (pthubert)
> *Cc:* Andy Bierman; Michel Veillette; [email-masked]; [email-masked]
> *Subject:* Re: [6tisch] Reserve space for aliases
>
> Hi Pascal,
>
>
> Actually, I think that this could be worked out in CoMI also. Instead of
> fullname you could provide the YANG id (module ID + data node ID) and do
> the mapping. User alias would be the special aliased YANG id. User ID,
> however, could be a little bit more tricky - how do we ensure that it is
> consistent? Use the IP address of the client could be doable, but we’ll
> have to include the UDP port just in case someone runs two clients on the
> same machine.
>
>
>
>
>
> After that,  if the server is a constrained device then the user talks to
> the server with (serverid, serveralias) and the user maintains a switching
> table for the resource it uses on various servers.
> If the user is the constrained device and the server is not, the user
> could talk with (userid, useralias) and the server maintains a switching
> table.
>
> For large servers, the server may allocate aliases dynamically based on
> what it is being asked. We’d then need to talk about alias update or
> revocation, probably in terms of session and lifetime.
>
> Does that look usable?
>
>
> You are pointing out an interesting question. I would think (but maybe I’m
> mistaken), that the client should have the leading role in figuring out
> what’s happening. The idea is the following:
>
> Then, the client can take action, depending on its own capabilities and
> the response of the server. E.g. a unconstrained client could obtain the
> alias mapping if it is static (or if there is a single alias mapping in
> place) and cache it locally. So, there will be the following correspondence
> :
>
> Given:
> C1) constrained client
> C2) unconstrained client
>
> We have:
> I would say that the analogy you made with MPLS corresponds quite a lot to
> the C2+S4 case. Personally, I would be most interested into having one
> client configure one alias mapping to all servers in the network (e.g. the
> managing entity), which will profit most from saving several bytes on each
> message exchange. Everyone else could use the standard IDs, which we’ve
> already managed to shrink significantly.
>
> Indeed, with structured module ID + data node ID (20 bits + 10 bits), YANG
> URI compression, and long form/short form, we’ll have quite a lot of gain.
> Reserving module ID = 1 for aliases and maybe writing a short draft on how
> the aliasing is implemented seems feasible, where we can cover the exact
> mechanism of alias definition, and client/server interaction.
>
> Alexander
>
>
>
> Pascal
>
> *From:* 6tisch [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Andy Bierman
> *Sent:* vendredi 5 juin 2015 20:55
> *To:* Michel Veillette
> *Cc:* [email-masked]; Alexander Pelov; [email-masked]
> *Subject:* Re: [6tisch] Reserve space for aliases
>
>
>
> If we want to minimize both the network an node resources require by this
> alias mechanism, we can map an entire module to this space.

---

From: Alexander Pelov <[email-masked]>
Date: Sat, 13 Jun 2015 00:25:09 +0200

Hi Andy,

Not sure if you were referring to the example/explanation I tried to provide (maybe Michel had something else in mind), but here I go.

> Le 12 juin 2015 à 23:57, Andy Bierman <[email-masked]> a écrit :
> 
> Hi,
> 
> https://www.ietf.org/id/draft-ietf-netmod-yang-json-04.txt <https://www.ietf.org/id/draft-ietf-netmod-yang-json-04.txt>
> 

Ok, that sounds perfectly in line with the module ID/data node ID and the long form/short form we’ve been discussing with Michel.

> but this is not required for managed IDs.

If you have your YANG hash ID behave in a structured way (e.g. stop being a hash..), then you don’t need to send the full 30 bits. 

If I take the following example (which is a strange case just for the sake of it):
REQ: GET example.com/mg?select <http://example.com/mg?select>( [5, 2049, 2, 3, 4, 4097, 2, 3, 4, 2053, 2055, 6] )

That would resolve to requesting the following YANG IDs:
long form = module ID / short form
5 = 0 / 5
2049 = 1 / 1
2050 = 1 / 2
2051 = 1 / 3
2052 = 1 / 4
4097 = 2 / 1
4098 = 2 / 2
4099 = 2 / 3
4099 = 2 / 4
2053 = 1 / 5
2055 = 1 / 7
2054 = 1 / 6

Of course, that is not (directly) related to the way the YANG parser processes the YANG modules. It is a way to parse the select option, and is straightforward. Consecutively, element by element apply something of the form:

if (full_id & 0x3FFFFC00) > 0) {
   current_module_ID = full_id >> 10;
}
else {
  full_id = (current_module_ID << 10) & full_id;
}

Of course, that could be optimized, but for the sake of clarity we can leave it like this for the moment.

Best,
Alexander

> 
> 
> Andy
> 
> 
> 
> 
> 
> On Fri, Jun 12, 2015 at 2:42 PM, Alexander Pelov <[email-masked] <mailto:[email-masked]>> wrote:
> Michel,
> 
> 
>> Le 12 juin 2015 à 23:10, Michel Veillette <[email-masked] <mailto:[email-masked]>> a écrit :
>> 
>> I Alexander
>>  
>> Cc: Pascal Thubert (pthubert); Andy Bierman; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 12 Jun 2015 15:58:43 -0700

Hi,

I am not convinced that aliases are worth all the effort
because most (95%?) of the IDs in the payload will only
need 10 bits.

Andy

On Fri, Jun 12, 2015 at 3:25 PM, Alexander Pelov <
[email-masked]> wrote:

> Hi Andy,
>
> Not sure if you were referring to the example/explanation I tried to
> provide (maybe Michel had something else in mind), but here I go.
>
> Ok, that sounds perfectly in line with the module ID/data node ID and the
> long form/short form we’ve been discussing with Michel.
>
>
> If you have your YANG hash ID behave in a structured way (e.g. stop being
> a hash..), then you don’t need to send the full 30 bits.
>
> REQ: GET example.com/mg?select( [5, 2049, 2, 3, 4, 4097, 2, 3, 4, 2053,
> 2055, 6] )
>
> Of course, that is not (directly) related to the way the YANG parser
> processes the YANG modules. It is a way to parse the select option, and is
> straightforward. Consecutively, element by element apply something of the
> form:
>
>> And yes, seems quite straightforward and reasonable to me. If I
>> understand correctly, the format you use is the following:
>> This seems quite expressive, simple and compact. I wonder if we’re
>> missing something, as it really does seem to have quite a lot of nice
>> characteristics.
>>
>> Best,
>> Alexander
>>
>>
>>
>> This means, that specifying a GET example.com/mg?select(1) should
>> resolve to module ID=0 and relative node ID=1. This requires absolutely no
>> So, this leaves us back to the initial idea of the aliases. All short
>> node IDs are relative to a module ID (so that the long form ID can be
>> If the 6TiSCH module ID is allocated within these 63 IDs, there will be
>> no message size optimization provided by the aliases mechanism.
>> You are pointing out an interesting question. I would think (but maybe
>> I’m mistaken), that the client should have the leading role in figuring out
>> I would say that the analogy you made with MPLS corresponds quite a lot
>> to the C2+S4 case. Personally, I would be most interested into having one
>> Indeed, with structured module ID + data node ID (20 bits + 10 bits),
>> YANG URI compression, and long form/short form, we’ll have quite a lot of
>> gain. Reserving module ID = 1 for aliases and maybe writing a short draft
>> on how the aliasing is implemented seems feasible, where we can cover the
>> exact mechanism of alias definition, and client/server interaction.
>>
>> Alexander
>>
>>
>>
>> Pascal
>>
>> *From:* 6tisch [mailto:[email-masked] <[email-masked]>]
>>  *On Behalf Of *Andy Bierman
>> One possible solution is that each CoMI client send a list of (alias,
>> data node ID) to the CoMI server. In this case, the CoMI client might
>> receive an error if one or multiple of these aliases are already reserved.
>>

---

From: Alexander Pelov <[email-masked]>
Date: Sat, 13 Jun 2015 01:26:50 +0200

Hi Andy,

> Le 13 juin 2015 à 00:58, Andy Bierman <[email-masked]> a écrit :
> 
> Hi,
> 

Yes, I must say that in the discussions in the past couple of days really cover many of the cases I was thinking about, so I would tend to agree with you that in most cases aliases can be an overkill. 

However, you always need to provide at least one long id, which could be avoided, and could be very beneficial for some networks. 

So, to sum up, if the proposal of YANG ID structure (20 bits module ID + 10 bits data node ID), long form/short form, and ‘select’ option with CBOR encoding is accepted, then 95% of the work is done (and I would be happy with that).

I feel that adding a short statement - module ID = 0 is reserved for aliases - and address this in another draft would be the simplest solution (we have to figure out what to do with that module ID = 0 anyways). I’ve already described a pretty straightforward way of managing aliases, the simplest being - static allocation by the server (e.g. upon provisioning / firmware update / etc.). 

Alexander

> 
> 
> Andy
> 
> 
> 
> 
> On Fri, Jun 12, 2015 at 3:25 PM, Alexander Pelov <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Andy,
> 
>> Le 12 juin 2015 à 23:57, Andy Bierman <[email-masked] <mailto:[email-masked]>> a écrit :
>> 
>> Hi,
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 12 Jun 2015 23:37:33 +0000

I agree

If an app keeps reading the same data from a device literally for years, compression makes sense...

Pascal

Le 12 juin 2015 à 19:26, Alexander Pelov <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Andy,

Le 13 juin 2015 à 00:58, Andy Bierman <[email-masked]<mailto:[email-masked]>> a écrit :

Hi,

Alexander

Andy

On Fri, Jun 12, 2015 at 3:25 PM, Alexander Pelov <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andy,

Le 12 juin 2015 à 23:57, Andy Bierman <[email-masked]<mailto:[email-masked]>> a écrit :

Hi,

If I take the following example (which is a strange case just for the sake of it):
REQ: GET example.com/mg?select<http://example.com/mg?select>( [5, 2049, 2, 3, 4, 4097, 2, 3, 4, 2053, 2055, 6] )

Best,
Alexander

Andy

On Fri, Jun 12, 2015 at 2:42 PM, Alexander Pelov <[email-masked]<mailto:[email-masked]>> wrote:
Michel,

Le 12 juin 2015 à 23:10, Michel Veillette <[email-masked]<mailto:[email-masked]>> a écrit :

I Alexander

Let assume the following:
•         A CoMI client need to select 3 data nodes (Data node ID 2049, 2 and 3)
•         For the first data node, three values need to be provided as keys (e.g. 1, "ipv4", "10.0.0.51 "), see draft-vanderstok-core-comi-06 page 22.
•         For the third data node, one integer value need to be provided as keys (e.g. 22).

REQ: GET example.com/mg?select<http://example.com/mg?select>( [[20491,"ipv4","10.0.0.51",2], 2, [3,22]] )

Just a small typo (missed a coma after 2049, right?):
REQ: GET example.com/mg?select<http://example.com/mg?select>( [[2049, 1,"ipv4","10.0.0.51",2], 2, [3,22]] )

Best,
Alexander

What do you things?

Michel Veillette

From: Alexander Pelov [mailto:[email-masked]]
Sent: 12 juin 2015 15:26
To: Michel Veillette
Cc: Pascal Thubert (pthubert); Andy Bierman; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] Reserve space for aliases

Hi Michel,

Best,
Alex

Hi Alexander, hi Pascal

For example:

Assuming module ID 2

Base64 approach:

CBOR approach:

Base64 approach:

CBOR approach:

Michel Veillette

Hi Pascal,

Dear all:

Does that look usable?

Given:
C1) constrained client
C2) unconstrained client

We have:

Alexander

Pascal

Andy

Michel Veillette

Hi Michel,

Hi Alexander

•       32 bits YANG ID

Best,
Alexander

Michel Veillette

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 13 Jun 2015 01:11:28 +0000

Hello Michel:

I’m not so worried for 6TiSCH’s ID than for the IDs used to collect data from sensors. Because that is the operation that will happen all the time an suck batteries.
I understand that any sensor vendor will want to have its own module IDs, correct? And soon enough that vendor will come with variants of his products, and will want more module IDs, is that right?

If I’m correct, this pleads for aliases; but maybe not as we thought them. I have missed the trick of 63 module IDs that are optimally encoded, but I trust you on that – I figure that it is because it takes 2 bits to encoded the coap option?

If so: maybe we should alias the module IDs so that the 63 IDs that benefit from the optimal cbor compression should be the aliases of any of the thousands of IDs that will soon exist in the registries.

Also note that device makers will want the vendor specific range that they use to play with before something is registered. Aliases could also be a way to play with module IDs that have not yet been registered to IANA.

I’m not sure the above makes sense since it is based on a partial understanding of your work so far…

Pascal

From: Michel Veillette [mailto:[email-masked]]
Sent: vendredi 12 juin 2015 09:58
To: Alexander Pelov; Pascal Thubert (pthubert)
Cc: Andy Bierman; [email-masked]; [email-masked]
Subject: RE: [6tisch] Reserve space for aliases

Hi Alexander, hi Pascal

For example:

Assuming module ID 2

Base64 approach:

CBOR approach:

Base64 approach:

CBOR approach:

Michel Veillette

Hi Pascal,

Dear all:

Does that look usable?

Given:
C1) constrained client
C2) unconstrained client

We have:

Alexander

Pascal

Andy

Michel Veillette

Hi Michel,

Hi Alexander

•       32 bits YANG ID

Best,
Alexander

Michel Veillette

---

From: Michel Veillette <[email-masked]>
Date: Sat, 13 Jun 2015 03:53:47 +0000

Hi Alexander

About “Yes, I suppose you should always start with aliases, but that doesn’t sound like a strong constraint to me”

If I take the following example:
GET example.com/mg?select(1, 2, 2049, 3)

Data node ID 1 and 2 can be associated with module ID 0 (aliases) but data node ID 2049 and 3 are associated with module ID 1.
I don’t understand how aliases can be added at the end of this list without been processed as short form.
Please confirm my understanding.

Hi Andy

About “The data is hierarchical and the parser is required to maintain the current module scope. It should be possible to omit the module identifier for nested data, except for nodes that start a new module scope. Is this what you have in mind?”

Yes
I’m proposing to use the same model as JSON with a long form consisting of a 20 bits module ID/10 bits YANG ID and the short form consisting of a 10 bits YANG ID.

About “I am not convinced that aliases are worth all the effort because most (95%?) of the IDs in the payload will only need 10 bits.”

Agree
In most cases, the message size compression will same just a couple of bytes.
As mentioned by Alexander, we can simply reserve a range for aliases (e.g. module ID 0) but defer the resolution to a different draft.

Hi Pascal

About “I understand that any sensor vendor will want to have its own module IDs, correct?”

Correct, with 20 bits, we can allocate 1 000 000 module ID.
This can be done one by one or by small bundle of module IDs (e.g. 4, 8, 16 IDs).

About “I have missed the trick of 63 module IDs that are optimally encoded”

When using the long form (20 bits module ID, 10 bits YANG ID), data node ID small enough to fit on 16 bits are encoded using CBOR in 3 bytes. Since the YAND ID takes 10 bits, we have 6 bits left for the module ID (64 IDs minus ID 0 reserved for the short form). Module ID greater than 63 require the use of the 5 bytes CBOR encoding.

About “If so: maybe we should alias the module IDs so that the 63 IDs that benefit from the optimal CBOR compression should be the aliases of any of the thousands of IDs that will soon exist in the registries.”

A possible solution is to reserve module ID 0, 1, 2 and 3 for aliases which will leave 60 “more optimal” module IDs.
The specific use of the reserved module IDs can be addressed in one of multiple subsequence drafts.
What is important for now is the establishment of a consensus around the core concepts discussed:

·         registered 20 bits module ID

·         10 bits assigned YANG ID

·         long form / short form data node ID

·         select encoded in CBOR

Michel Veillette

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: 12 juin 2015 21:11
To: Michel Veillette; Alexander Pelov
Cc: Andy Bierman; [email-masked]; [email-masked]
Subject: RE: [6tisch] Reserve space for aliases

Hello Michel:

Pascal

Hi Alexander, hi Pascal

For example:

Assuming module ID 2

Base64 approach:

CBOR approach:

Base64 approach:

CBOR approach:

Michel Veillette

Hi Pascal,

Dear all:

Does that look usable?

Given:
C1) constrained client
C2) unconstrained client

We have:

Alexander

Pascal

Andy

Michel Veillette

Hi Michel,

Hi Alexander

•       32 bits YANG ID

Best,
Alexander

Michel Veillette

---

From: Andy Bierman <[email-masked]>
Date: Fri, 12 Jun 2015 22:24:14 -0700

On Fri, Jun 12, 2015 at 8:53 PM, Michel Veillette <
[email-masked]> wrote:

>  *Hi Alexander*
>
>
>
> About “Yes, I suppose you should always start with aliases, but that
> doesn’t sound like a strong constraint to me”
>
>
>
> Data node ID 1 and 2 can be associated with module ID 0 (aliases) but data
> node ID 2049 and 3 are associated with module ID 1.
>
> *Hi Andy*
> About “The data is hierarchical and the parser is required to maintain the
> current module scope. It should be possible to omit the module identifier
> for nested data, except for nodes that start a new module scope. Is this
> what you have in mind?”
>
>
>
> Yes
>
> I’m proposing to use the same model as JSON with a long form consisting of
> a 20 bits module ID/10 bits YANG ID and the short form consisting of a 10
> bits YANG ID.
>
>
>

I like your proposal to allow support for numbered objects.

 About “I am not convinced that aliases are worth all the effort because
> most (95%?) of the IDs in the payload will only need 10 bits.”
>
>
>
> Agree
>
> As mentioned by Alexander, we can simply reserve a range for aliases (e.g.
> module ID 0) but defer the resolution to a different draft.
>
>
>

I think reserving module ID zero is OK for that

>  *Hi Pascal*
> When using the long form (20 bits module ID, 10 bits YANG ID), data node
> ID small enough to fit on 16 bits are encoded using CBOR in 3 bytes. Since
> the YAND ID takes 10 bits, we have 6 bits left for the module ID (64 IDs
> minus ID 0 reserved for the short form). Module ID greater than 63 require
> the use of the 5 bytes CBOR encoding.
>

I think CoMI should support "replaceable" numbering schemes, which
should be identified in the server capabilities somehow.  I prefer if
the server used 1 numbering scheme, not 1 per node.

I proposed a conformance "package" in a now expired draft
called YANG Conformance.  A conformance profile can include
multiple modules, and specify the required revisions and
features as well.

The point is that an arbitrarily large set of modules can be
reduced to a single identifier.  The profile could be extended
to support ad-hoc numbering of all the objects in the package.
This works best for lots of the similar devices which all
implement the same set of modules, so there are a small number
of packages to manage.

The server would advertise its 1 (or more) package IDs.
There is no need to use the 20 bit module ID at all if the server
supports only 1 conformance package. 10 bits
might be tight for numbering all the protocol accessible objects
in the YANG modules in each package. I think 12 bits would be
needed.

This would also allow YANG modules to be numbered
without a centralized authority. A CoMI package could
even define the "standard" aliases, if that was supported.

Do you think something like this would be useful for CoMI?

Andy

>
> About “If so: maybe we should alias the module IDs so that the 63 IDs that
> benefit from the optimal CBOR compression should be the aliases of any of
> the thousands of IDs that will soon exist in the registries.”
>
>
>
> A possible solution is to reserve module ID 0, 1, 2 and 3 for aliases
> which will leave 60 “more optimal” module IDs.
>
> *From:* Pascal Thubert (pthubert) [mailto:[email-masked]]
> *Sent:* 12 juin 2015 21:11
> *To:* Michel Veillette; Alexander Pelov
> *Subject:* RE: [6tisch] Reserve space for aliases
>
>
>
> Hello Michel:
>
>
>
> I’m not so worried for 6TiSCH’s ID than for the IDs used to collect data
> from sensors. Because that is the operation that will happen all the time
> an suck batteries.
>
> I understand that any sensor vendor will want to have its own module IDs,
> correct? And soon enough that vendor will come with variants of his
> products, and will want more module IDs, is that right?
>
>
>
> If I’m correct, this pleads for aliases; but maybe not as we thought them.
> I have missed the trick of 63 module IDs that are optimally encoded, but I
> trust you on that – I figure that it is because it takes 2 bits to encoded
> the coap option?
>
>
>
> If so: maybe we should alias the module IDs so that the 63 IDs that
> benefit from the optimal cbor compression should be the aliases of any of
> the thousands of IDs that will soon exist in the registries.
>
>
>
> Also note that device makers will want the vendor specific range that they
> use to play with before something is registered. Aliases could also be a
> way to play with module IDs that have not yet been registered to IANA.
>
>
>
> *From:* Michel Veillette [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* vendredi 12 juin 2015 09:58
> *To:* Alexander Pelov; Pascal Thubert (pthubert)
> *Subject:* RE: [6tisch] Reserve space for aliases
>
>
>
> Hi Alexander, hi Pascal
>
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 13 Jun 2015 10:16:54 +0000

Hello Michel:

Got you! Thanks for all !

For the last point I was in fact suggesting that we could also alias module IDs as opposed to leaves in the model. How many modules in one sensor? If that's less than 63 then they can all be aliased.
Concatenation of all ideas give:

0 for short forms
1...3 for aliasing full data node IDs long forms
4..60 for aliasing module IDs meaning that the short form must be provided
61...63 reserved for experimentation

Client and server would negotiate if the alias is take from server alias space or client alias space depending on which is constrained, default being server.

This negotiation would work even if the module I'd is not yet allocated since it could be negotiated by name into a reserved alias 61..63.

Makes sense?
Pascal

Le 12 juin 2015 à 23:53, Michel Veillette <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Alexander

If I take the following example:
GET example.com/mg?select<http://example.com/mg?select>(1, 2, 2049, 3)

Hi Andy

Yes

Agree

Hi Pascal

·         select encoded in CBOR

Michel Veillette

Hello Michel:

Pascal

Hi Alexander, hi Pascal

For example:

Assuming module ID 2

Base64 approach:

CBOR approach:

Base64 approach:

CBOR approach:

Michel Veillette

Hi Pascal,

Dear all:

Does that look usable?

Given:
C1) constrained client
C2) unconstrained client

We have:

Alexander

Pascal

Andy

Michel Veillette

Hi Michel,

Hi Alexander

•       32 bits YANG ID

Best,
Alexander

Michel Veillette

---

From: Michel Veillette <[email-masked]>
Date: Sat, 13 Jun 2015 15:55:06 +0000

Hi Pascal

If I understand correctly your proposal

·         the range 1 to 3 is used to alias a data nodes based on a mapping table containing (module name or ID, YANG ID, alias ID).
If this is the case, a single ID might be sufficient since it will allow aliasing of up to 1000 data nodes.

·         If I understand correctly, the range 4 to 60 is used to alias complete modules based on a mapping table containing (module name or ID, alias ID).

Is it correct?

Michel Veillette

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: 13 juin 2015 06:17
To: Michel Veillette
Cc: Alexander Pelov; Andy Bierman; [email-masked]; [email-masked]
Subject: Re: [6tisch] Reserve space for aliases

Hello Michel:

0 for short forms

Makes sense?
Pascal

About "Yes, I suppose you should always start with aliases, but that doesn't sound like a strong constraint to me"

Data node ID 1 and 2 can be associated with module ID 0 (aliases) but data node ID 2049 and 3 are associated with module ID 1.
I don't understand how aliases can be added at the end of this list without been processed as short form.
Please confirm my understanding.

Hi Andy

About "The data is hierarchical and the parser is required to maintain the current module scope. It should be possible to omit the module identifier for nested data, except for nodes that start a new module scope. Is this what you have in mind?"

Yes
I'm proposing to use the same model as JSON with a long form consisting of a 20 bits module ID/10 bits YANG ID and the short form consisting of a 10 bits YANG ID.

About "I am not convinced that aliases are worth all the effort because most (95%?) of the IDs in the payload will only need 10 bits."

Agree

Hi Pascal

About "I understand that any sensor vendor will want to have its own module IDs, correct?"

About "I have missed the trick of 63 module IDs that are optimally encoded"

About "If so: maybe we should alias the module IDs so that the 63 IDs that benefit from the optimal CBOR compression should be the aliases of any of the thousands of IDs that will soon exist in the registries."

A possible solution is to reserve module ID 0, 1, 2 and 3 for aliases which will leave 60 "more optimal" module IDs.
The specific use of the reserved module IDs can be addressed in one of multiple subsequence drafts.
What is important for now is the establishment of a consensus around the core concepts discussed:

?         registered 20 bits module ID

?         10 bits assigned YANG ID

?         long form / short form data node ID

?         select encoded in CBOR

Michel Veillette

Hello Michel:

I'm not so worried for 6TiSCH's ID than for the IDs used to collect data from sensors. Because that is the operation that will happen all the time an suck batteries.
I understand that any sensor vendor will want to have its own module IDs, correct? And soon enough that vendor will come with variants of his products, and will want more module IDs, is that right?

If I'm correct, this pleads for aliases; but maybe not as we thought them. I have missed the trick of 63 module IDs that are optimally encoded, but I trust you on that - I figure that it is because it takes 2 bits to encoded the coap option?

I'm not sure the above makes sense since it is based on a partial understanding of your work so far...

Pascal

Hi Alexander, hi Pascal

*         The use of the select query parameter encoded in CBOR support of 63 modules with optimized message size instead of only 3 for the base64 URI.

*         The message size of the select query parameter encoded in CBOR should be equal or smaller compared to the base64 URI.

Furthermore, CoMI devices won't have to support two type of encoding depending if IDs are part of the command vs. payload.

For example:

Assuming module ID 2

Assuming "," separator to select multiple data nodes

Base64 approach:

REQ: GET example.com/mg/gB<http://example.com/mg/gB>         (3 bytes; 1 byte for the "/", 2 bytes for "gB")

CBOR approach:

Base64 approach:

REQ: GET example.com/mg/gB,C,D,E<http://example.com/mg/gB,C,D,E>         (9 bytes; 1 byte for the "/", 8 bytes for "gB,C,D,E")

CBOR approach:

Michel Veillette

Hi Pascal,

Dear all:

Actually, I think that this could be worked out in CoMI also. Instead of fullname you could provide the YANG id (module ID + data node ID) and do the mapping. User alias would be the special aliased YANG id. User ID, however, could be a little bit more tricky - how do we ensure that it is consistent? Use the IP address of the client could be doable, but we'll have to include the UDP port just in case someone runs two clients on the same machine.

For large servers, the server may allocate aliases dynamically based on what it is being asked. We'd then need to talk about alias update or revocation, probably in terms of session and lifetime.

Does that look usable?

You are pointing out an interesting question. I would think (but maybe I'm mistaken), that the client should have the leading role in figuring out what's happening. The idea is the following:

Given:
C1) constrained client
C2) unconstrained client

We have:

I would say that the analogy you made with MPLS corresponds quite a lot to the C2+S4 case. Personally, I would be most interested into having one client configure one alias mapping to all servers in the network (e.g. the managing entity), which will profit most from saving several bytes on each message exchange. Everyone else could use the standard IDs, which we've already managed to shrink significantly.

Indeed, with structured module ID + data node ID (20 bits + 10 bits), YANG URI compression, and long form/short form, we'll have quite a lot of gain. Reserving module ID = 1 for aliases and maybe writing a short draft on how the aliasing is implemented seems feasible, where we can cover the exact mechanism of alias definition, and client/server interaction.

Alexander

Pascal

Andy

Michel Veillette

Hi Michel,

Hi Alexander

*       32 bits YANG ID

I was just summarizing what was discussed on the discussion in CoMI. Actually, it is 30 bits YANG ID, but that's for purposes to be consistent with the YANG hash and I don't mind keeping it 30 bits.

This is assuming you need a separate mapping for each server. I would suppose that in a network you'll have a single alias mapping (maybe two?) - after all, you're trying to optimize the management of your devices (servers). So, typically you'd map all 6tisch devices with aliases 1-10 (channel, slot, etc.) and use that on them, and on all other you'd access the full ID.

Best,
Alexander

Michel Veillette

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 13 Jun 2015 18:30:43 +0000

Yes!

With the intent that the alias may be in fact that of the peer.
For instance if the server is a constrained node, the (fat) client would have an additional index to that table that is the deviceID or the groupID of the server.
The server would indicate in the handshake that it is not capable to handle someone else's aliases. It could indicate its aliases in the first responses and from then on the client would use the server's aliases.

Cheers,

Pascal

Sent: samedi 13 juin 2015 08:55

Hi Pascal

*         the range 1 to 3 is used to alias a data nodes based on a mapping table containing (module name or ID, YANG ID, alias ID).
If this is the case, a single ID might be sufficient since it will allow aliasing of up to 1000 data nodes.

*         If I understand correctly, the range 4 to 60 is used to alias complete modules based on a mapping table containing (module name or ID, alias ID).

Is it correct?

Michel Veillette

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: 13 juin 2015 06:17
To: Michel Veillette
Cc: Alexander Pelov; Andy Bierman; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] Reserve space for aliases

Hello Michel:

0 for short forms

Makes sense?
Pascal

Hi Andy

Yes

Agree

Hi Pascal

*         registered 20 bits module ID

*         10 bits assigned YANG ID

*         long form / short form data node ID

*         select encoded in CBOR

Michel Veillette

Hello Michel:

Pascal

Hi Alexander, hi Pascal

For example:

Assuming module ID 2

Base64 approach:

CBOR approach:

Base64 approach:

CBOR approach:

Michel Veillette

Hi Pascal,

Dear all:

Does that look usable?

Given:
C1) constrained client
C2) unconstrained client

We have:

Alexander

Pascal

Andy

Michel Veillette

Hi Michel,

Hi Alexander

*       32 bits YANG ID

Best,
Alexander

Michel Veillette

---

From: Michel Veillette <[email-masked]>
Date: Sat, 13 Jun 2015 22:01:56 +0000

Hi Pascal

The discussion about aliases is interesting but we should not be distracted to much by it until we have resolved to initial and core problem, how modules and data nodes are identified. Unless the concept of registered Module ID (20 bits) and assigned Data node ID (10 bits) are accepted, the only reliable identifiers are the module name and the data node path, both are considered too heavy weight.

In summary:

With the current draft, we can advertise of setup data node aliases only using:
                (module name, data node path -> alias ID) which represent ~100 octets.

If Module ID and Data node ID are supported, we can advertise of setup data node aliases using:
                (module ID, data node ID -> alias ID) which represent ~ 5 octets.

Michel Veillette

Sent: 13 juin 2015 14:31

Yes!

Cheers,

Pascal

Hi Pascal

Is it correct?

Michel Veillette