Re: [6tisch] Finally !!

[Alexander Pelov]

Wonderful! Congrats to all the authors, the chairs and the contributors to
this amazing work!

Cheers,
Alexander


On Tue, Jun 1, 2021 at 4:56 PM Pascal Thubert (pthubert)  wrote:

> Dear all
>
>
>
> It is our greatest pleasure to announce that the following RFCs were just
> published on the IETF data tracker:
>
>
>
>
>
> RFC 9030  *(was
> draft-ietf-6tisch-architecture)*
> *An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of
> IEEE 802.15.4 (6TiSCH)*
>
> 2021-05
> 57 pages
>
> New
>
> Informational RFC
>
>
>
> RFC 9031  *(was
> draft-ietf-6tisch-minimal-security)*
> *Constrained Join Protocol (CoJP) for 6TiSCH*
>
> 2021-05
> 41 pages
>
> New
>
> Proposed Standard RFC
>
>
>
> RFC 9032  *(was
> draft-ietf-6tisch-enrollment-enhanced-beacon)*
> *Encapsulation of 6TiSCH Join and Enrollment Information Elements*
>
> 2021-05
> 10 pages
>
> New
>
> Proposed Standard RFC
>
>
>
> RFC 9033  *(was
> draft-ietf-6tisch-msf)*
> *6TiSCH Minimal Scheduling Function (MSF)*
>
> 2021-05
> 20 pages
>
> New
>
> Proposed Standard RFC
>
>
>
> This concludes the work items that this working group had on its plate.
>
>
>
> Many thanks to you all for years of hard work, in standards, open source
> implementation, and interop testing.
>
>
>
> Keep safe!
>
>
>
> The chairs
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] [IoT-DIR] Iotdir early review of draft-ietf-6tisch-6top-protocol-09

[Alexander Pelov]

Dear Xavi,

Thanks a lot for the prompt reply and the detailed address of the points I’ve 
outlined. 

For completeness, see inline.


> Le 1 mars 2018 à 12:50, Xavi Vilajosana Guillen  a écrit 
> :
> 
> Dear Alex,
> 
> Thanks so much for your constructive review. Let us answer inline your 
> comments (XV:). We are taking them into account in the new draft version that 
> will be published before the cut-off date.
> 
> regards
> Xavi
> 
> Reviewer: Alexander Pelov
> Review result: Ready with Issues
> 
> Hello all,
> 
> This is the review for the IoT Directorate.
> 
> Document: draft-ietf-6tisch-6top-protocol-09
> Reviewer: Alexander Pelov
> Date: 22 February 2018
> 
> The general feeling of the reviewer is that the document is a solid work.
> Multiple examples are given and the document is easy to understand as a whole.
> There are some nits, and some text that need to be clarifier.
> 
> The general feeling of the reviewer is that the document relies heavily on the
> definition of an external Scheduling Function (SF). The recommended values 
> seem
> very reasonable to the reviewer and it is not clear what is the benefit of
> anticipating that an SF can override the semantics of most of the fields. For
> example, most of the fields are opaque to the 6P sublayer and only make sense
> to the SF : CellOptions, Metadata, CellList. For one, in Wireshark, there will
> be the need for separate disector for each SF.
> 
> XV: we aimed to support particular needs of an SF. For example the Metadata 
> field can be used to indicate to what Slotframe Handle the 6P operation 
> should be applied. However we think as well that a large set of SFs will use 
> the fields as defined by 6P (celllist) for example.

Ok. Thanks for the example with the Metadata field; 

> 
> A final point here is that there seem to be no readily available polished SF
> that would help in the understanding of the concepts beyond what is already on
> the 6P draft. 
> 
> XV: We think the MSF (https://tools.ietf.org/html/draft-chang-6tisch-msf-00 
> <https://tools.ietf.org/html/draft-chang-6tisch-msf-00>) clearly maps to the 
> requirements from 6P.

Thanks for clearing this out. If MSF becomes a WG item I would find it useful 
to add it to the text as a reference (that’s a very minor edit and shouldn’t 
interfere with the closing of the WGLC).

> 
> 
>  For example, the SF0 draft (draft-ietf-6tisch-6top-sfx-00)
> redefines quite heavily the behavior of CellList introducing notion of
> WhiteList and BlackList of cells. The reviewer is aware that these are 
> distinct
> works, but it feels that there should be a minimum level of interoperability,
> where an upper layer does not completely redefine what is happening on lower
> layers. Having extension mechanisms may seem like a better way to solve
> richness of proposals if this is necessary.
> 
> XV: We agree on that. We think however that most SFs can be developed without 
> redefining the 6P fields. Note also that the SIGNAL command is designed to 
> that aim. i.e., an SF issues SIGNALS which are opaque to 6P internals in 
> order to transmit information to the other Node SF.

Ok.

> 
> One point which remained unclear is how do the Minimal 6TiSCH and 6P interact?
> It could be useful to provide a description on the bootstrap of 6P interaction
> (how does a sender A initiate the first 6P Request - over Minimal
> 6TiSCH-managed cell?).
> 
> XV: This is detailed in the MSF draft for example. 6P defines the messaging 
> structure and protocol interaction but does not define a particular behaviour.
> The SF is the responsible of defining the behaviour at boot, what cells are 
> used and how new cells are added. 6P Provides the l2 transport semantics for 
> the 
> SF to operate. 

Ok, thanks. One more reason to add reference to MSF.

> 
>  
> How do they enter in play in case of de-synchronisation
> ? (e.g. A rescheduling all 6P cells, but B not getting the final L2 ACK, which
> puts A's 6P cells on a completely different schedule than B's.. so B can't
> signal back transaction rollback / CLEAR). Is this solved by 6TiSCH minimal or
> through a different mechanism?

I think that independently of MSF, this is a situation that could apply to any 
SF. It may then be of interest to describe in the text of 6P how is this 
situation handled. (even if MSF handles this gracefully, other SFs may benefit 
from guidance how to handle such situation).

> 
> The Security section could be enriched. A notable example is the handling of
> resource reservation, which could lead to DOS attacks.
> 
> XV: this has been clarified thanks to another reviewer comment. 

Ok, thanks.

> - - - - - - - - - - - - - - -
> 
> Section 3.2.3:

[6tisch] Iotdir early review of draft-ietf-6tisch-6top-protocol-09

[Alexander Pelov]

Reviewer: Alexander Pelov
Review result: Ready with Issues

Hello all,

This is the review for the IoT Directorate.

Document: draft-ietf-6tisch-6top-protocol-09
Reviewer: Alexander Pelov
Date: 22 February 2018

The general feeling of the reviewer is that the document is a solid work.
Multiple examples are given and the document is easy to understand as a whole.
There are some nits, and some text that need to be clarifier.

The general feeling of the reviewer is that the document relies heavily on the
definition of an external Scheduling Function (SF). The recommended values seem
very reasonable to the reviewer and it is not clear what is the benefit of
anticipating that an SF can override the semantics of most of the fields. For
example, most of the fields are opaque to the 6P sublayer and only make sense
to the SF : CellOptions, Metadata, CellList. For one, in Wireshark, there will
be the need for separate disector for each SF.

A final point here is that there seem to be no readily available polished SF
that would help in the understanding of the concepts beyond what is already on
the 6P draft.  For example, the SF0 draft (draft-ietf-6tisch-6top-sfx-00)
redefines quite heavily the behavior of CellList introducing notion of
WhiteList and BlackList of cells. The reviewer is aware that these are distinct
works, but it feels that there should be a minimum level of interoperability,
where an upper layer does not completely redefine what is happening on lower
layers. Having extension mechanisms may seem like a better way to solve
richness of proposals if this is necessary.

One point which remained unclear is how do the Minimal 6TiSCH and 6P interact?
It could be useful to provide a description on the bootstrap of 6P interaction
(how does a sender A initiate the first 6P Request - over Minimal
6TiSCH-managed cell?). How do they enter in play in case of de-synchronisation
? (e.g. A rescheduling all 6P cells, but B not getting the final L2 ACK, which
puts A's 6P cells on a completely different schedule than B's.. so B can't
signal back transaction rollback / CLEAR). Is this solved by 6TiSCH minimal or
through a different mechanism?

The Security section could be enriched. A notable example is the handling of
resource reservation, which could lead to DOS attacks.

- - - - - - - - - - - - - - -

Section 3.2.3:
6P CellOptions - ends with the statement that it is an "Opaque set of bits",
which MAY be redefined by the SF (format, meaning). As pointed out earlier, if
there is a need to redefine this for each SF, maybe there are other ways of
defining such flexibility (e.g. TLVs).

The table in Figure 7 provides the recommended meaning of the bitmap for 6P
COUNT and 6P LIST. What is the recommended meaning for 6P ADD/DELETE/RELOCATE?

Nits: there seems to be errors in Figure 7: examples of "all cells are marked
as RX" and "all cells are marked as TX" seem inverted (same for TX=1,RX=0,S=1
and TX=0,RX=1,S=1).

- - - - - - - - - - - - - - -

Section 3.3.1:
How does the sender/receiver know the size of CellList? (infer from packet
size?)

The candidate cells (a total of NumCandidate) are presumably provided by the
SF. However, it is up to 6P to handle the case when they do not fit in the
packet size. The text specifies that this should be handled in more than one 6P
ADD requests - which is OK on the conceptual level, but seems underspecified
for an implementation. What if NumCells is smaller than the number of candidate
cells that can fit in a single transaction - should they be also split in two
transactions? What happens if the first 6P ADD is successful, but the second
one fails? Should the sender 6P DELETE the successfully added first batch of
cells?

Can allocation of 0 cells be considered as partial success?

NOALLOC return code is not defined.

- - - - - - - - - - - - - - -

Section 3.3.3.
Figure 17 - it seems counterintuitive to have RC_SUCCESS on failed relocation.
Could NOALLOC be used in this case?

In both Relocation and Allocation 3-step 6P transaction there is the risk of a
security attack. If a malicious node constantly renews 3-step requests and
never acknowledges, the neighboring node will be keeping the proposed cells as
"reserved" and not allocate them to other nodes, thus provoding a DOS attack.
Probably a way to limit repeated requests could be useful for this case.

- - - - - - - - - - - - - - -

Section 3.3.5.
"To retrieve the list of scheduled cells at B" - all cells scheduled at B? Or
the cells scheduled for A? (could be clarified)

Nits: Node B MAY returns -> Node B MAY return

- - - - - - - - - - - - - - -

Section 3.3.6.
There may be two parallel transactions: 1) A->B and 2) B->A. If a 6P CLEAR is
issued on one, how does this affect the other? (presumably clear both?)

How does this affect separate SF? If there is a state kept by each SF, are all
SFs cleared? Are statistics also cleared for SFs? (probably SF-dependent, 

[6tisch] CoOL initial version - management interface for constrained devices and networks

[Alexander Pelov]

Dear all,

In preparation for the presentation this Friday in CORE you can find the 
first version of the CoOL (Constrained Objects Language) draft at the 
following address:

https://datatracker.ietf.org/doc/draft-veillette-core-cool/

Best,
Alexander

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] [Ace] Optimizing EAP-over-CoAP payload

[Alexander Pelov]

Hi Carsten,

yes, you are right about this! Thanks for pointing it out.

Indeed, the wording should be carefully selected, and I think in some 
(most?) cases the token can be zero-length. However, as you correctly 
state, this should not be a MUST. If the requester includes a token, 
then the responder must conform to the CoAP specification.


Best,
Alexander


Le 12/10/2015 21:01, Carsten Bormann a écrit :

Rafa Marin Lopez wrote:

I would say that using zero-length token is possible. What I am not sure is 
whether make it mandatory or not. I mean we could say that if the client sends 
a zero-length token the server can consider it OK as per the text above. If 
there is a non-zero length token value should be also fine.

There is never a reason to discuss token values -- these are chosen by
the requester based on its needs, and there is never a reason for a
responder to question that choice.

Grüße, Carsten

___
Ace mailing list
a...@ietf.org
https://www.ietf.org/mailman/listinfo/ace


___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] [Ace] Optimizing EAP-over-CoAP payload

[Alexander Pelov]

Hi Abhijan,

Thanks for pointing your draft - very interesting work.

However, it seems to me that it solves only a subset of the problems at 
which EAP-over-CoAP is aimed. Most notably, it is limited to a specific 
authentication method (DTLS-PSK), whereas EAP is an extensible 
framework. Maybe there could be some kind of cooperation between the 
two, e.g. you could specify an EAP method like EAP-DTLS-PSK-short?


Best,
Alexander


Le 13/10/2015 14:48, Abhijan Bhattacharyya a écrit :

Hi Rafa,
The application layer driven approach is really interesting in the 
constrained environment context. We had a similar approach for secure 
session establishment (assuming that boot-strapping is already done) 
which performs the session establishment in CoAP but uses the DTLS 
encryption and header-structure for secure exchange of the 
application-layer message. Coincidentally we have also defined an 
option called "Auth" .


Here is the link to the draft: 
https://tools.ietf.org/html/draft-bhattacharyya-dice-less-on-coap-00(Had 
an older work in progress: 
https://tools.ietf.org/html/draft-bhattacharyya-core-coap-lite-auth-00. But 
this one did not provide channel security).
I submitted this draft to dice, however, dice was not really the place 
to discuss this. Our draft is due to expire in about 4 days.




Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: abhijan.bhattachar...@tcs.com
Website: http://www.tcs.com <http://www.tcs.com/>

Experience certainty.IT Services
   Business Solutions
   Consulting



"Ace"  wrote on 10/13/2015 12:11:46 AM:

> From: Rafa Marin Lopez 
> To: Alexander Pelov 
> Cc: 6tisch@ietf.org, Dan Garcia , Rafa Marin Lopez
> , a...@ietf.org
> Date: 10/13/2015 12:16 AM
> Subject: Re: [Ace] Optimizing EAP-over-CoAP payload
> Sent by: "Ace" 
>
> Dear Alexander:
>
> Thanks for your comments
>
> > El 8 oct 2015, a las 10:53, Alexander Pelov  escribió:
> >
> > Dear Rafa,
> >
> > I've been reading the latest version of your draft ( draft-marin-
> ace-wg-coap-eap-01.txt ), and I have a couple of questions regarding
> some of the payload options, which could be optimized even further:
> >
> > 1) Use shorter name for the /auth resource
> > 2) Mandate the use of zero-length CoAP token
> >
> > The first, and the more simple one, is - would it be possible to
> change the name of the authentication resource from /auth to a
> shorter one (like /a)? Maybe it could be an option to change the
> name of this resource, based on the underlaying architecture, e.g.
> an RFC could mandate that in a specific network the resource could
> be named /a, whereas the default value could remain /auth?
>
> [Rafa] I do not see any problem to shorten the resource name.
>
> >
> > The second, which is a little bit more subtle. Tokens are used to
> match responses to requests, but during the authentication/
> authorization phase a single peer (endpoint) would communicate with
> a single authenticator. Moreover, the communication happens in a
> serial fashion, and responses are piggybacked. This falls in the
> case when zero-length token is also advised by RFC7252. Do you think
> that it would be appropriate to make the use of zero-length token
> mandatory for EAP-over-CoAP?
>
> [Rafa] I guess you are referring to this text:
>
> "An empty token value is appropriate e.g., when
>no other tokens are in use to a destination, "or when requests are
>made serially per destination and receive piggybacked responses.”
>
> I would say that using zero-length token is possible. What I am not
> sure is whether make it mandatory or not. I mean we could say that
> if the client sends a zero-length token the server can consider it
> OK as per the text above. If there is a non-zero length token value
> should be also fine.
>
> What do you think?
>
> Best Regards.
>
> >
> > Best,
> > Alexander
> >
> > ___
> > Ace mailing list
> > a...@ietf.org
> > https://www.ietf.org/mailman/listinfo/ace
>
> ---
> Rafael Marin Lopez, PhD
> Dept. Information and Communications Engineering (DIIC)
> Faculty of Computer Science-University of Murcia
> 30100 Murcia - Spain
> Telf: +3486501 Fax: +34868884151 e-mail: r...@um.es
> ---
>
>
>
>
> ___
> Ace mailing list
> a...@ietf.org
> https://www.ietf.org/mailman/listinfo/ace

=-==

[6tisch] Optimizing EAP-over-CoAP payload

[Alexander Pelov]

Dear Rafa,

I've been reading the latest version of your draft ( 
draft-marin-ace-wg-coap-eap-01.txt ), and I have a couple of questions 
regarding some of the payload options, which could be optimized even 
further:


1) Use shorter name for the /auth resource
2) Mandate the use of zero-length CoAP token

The first, and the more simple one, is - would it be possible to change 
the name of the authentication resource from /auth to a shorter one 
(like /a)? Maybe it could be an option to change the name of this 
resource, based on the underlaying architecture, e.g. an RFC could 
mandate that in a specific network the resource could be named /a, 
whereas the default value could remain /auth?


The second, which is a little bit more subtle. Tokens are used to match 
responses to requests, but during the authentication/authorization phase 
a single peer (endpoint) would communicate with a single authenticator. 
Moreover, the communication happens in a serial fashion, and responses 
are piggybacked. This falls in the case when zero-length token is also 
advised by RFC7252. Do you think that it would be appropriate to make 
the use of zero-length token mandatory for EAP-over-CoAP?


Best,
Alexander

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] an idea about 1X and 6tisch

[Alexander Pelov]

Dear Michael, dear Rafa, dear all,

Thanks for getting back the discussion on using EAP over CoAP for AAA in 
6TiSCH. This will also make it cross-compatible with long-range radio 
AAA, which will also use EAP-over-CoAP.


I would say that we have the chance that the EAP over CoAP is still a 
(advanced) draft, so there could be exchanges to make sure that the two 
are well-adapted to each other.


For example, we could use CoAP block transfer for EAP message 
fragmentation (as suggested by the CoAP IE draft). There are some other 
ways in which we could use CoAP-only based fragmentation, but I would 
first like to see if there is any problem related to the block transfer 
(e.g. DOS?) as it would be my favorite.


I would also think that we could borrow some ideas from LTE key 
derivation, where with a single MSK (provided by the EAP process) we 
could derive as many keys as we want, and also have seamless roaming 
(keeping the perfect forward security property) of the communications.


Best,
Alexander


Le 29/09/2015 11:31, Rafa Marin Lopez a écrit :

Hi Michael:

Regarding EAP-over-CoAP, we will update our draft before Yokohama.

Best Regards.
El 26/09/2015, a las 21:10, Michael Richardson  escribió:


Alexander Pelov suggested something interesting.
1. CoAPie gives us CoAP across link-layer constructs.
2. EAP-over-CoAP [such as: marin-ace-wg-coap-eap] lets us move EAP using CoAP.

The result is that one could, conceptually use this to build a 1X-like
enrollment system.  I'm not sure which layer does
fragmentation/fraglettation; or even if there is enough bytes left over to
make this useful at all.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

---
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +3486501 Fax: +34868884151 e-mail: r...@um.es
---




___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch


___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Comment to draft-wang-6tisch-6top-coapie-01.txt

[Alexander Pelov]

Dear all,

For me the ideal solution would be if one of the 16 payload types could 
be allocated to CoAP. This way, we could use it for 6TiSCH and 
long-range, low-rate WANs. However, this would provide for a generic, 
extensible mechanism of operating these networks. Adding too much 
overhead (not sure how many bytes 802.15.9 takes) would make it 
impractical for LR-WANs.


On the packet fragmentation, I like the approach taken by the 802.15.4k 
LECIM group, which introduces a new type of frame - 110 Fragment Frame - 
and sends the full 802.15.4 MAC header only in the first frame (context 
establishment - some other info is added also). Afterwards, the set of 
fragments is identified only through a 7 bit identifier assigned by the 
sender. In each consecutive fragment, only a 2 byte MAC header is 
included (3 bits frame type (= 110), 7 bits frame ID, 6 bits frame 
counter). Extremely efficient in terms of overhead (e.g. MAC addresses 
are sent only during the context establishment), and particularly well 
adapted to infrastructure networks. Not sure if it would fit all 6TiSCH 
scenarios though.


Best,
Alexander


Le 25/09/2015 12:31, Thomas Watteyne a écrit :
We need to discuss this point urgently, and do the work to ask the 
IEEE for carve out some IE space for IETF/6TISCH if applicable.


On Thu, Jul 23, 2015 at 4:28 PM, Qin Wang > wrote:


Hi Pat,

Since there are two approaches mentioned in the discussion, i.e.
(1) containing 6top-to-6top message in a specific payload IE
(coapie), (2) using the mechanism provided by IEEE802.15.9 to
convey the 6top-to-6top message, I would like to do more
evaluation. I couldn't find the IEEE802.15.9 spec on IEEE802
website. Can you tell me how to get it?

Thanks
Qin



On Tuesday, July 21, 2015 8:59 PM, Tero Kivinen mailto:kivi...@iki.fi>> wrote:


This draft plans to put the coap messages directly on the payload IEs
in the 802.15.4. The problem is that we only have 16 payload IE types
in total for 802.15.4, so reserving one number for coap might be hard.

On the other hand IEEE 802.15.9 needed to have solution to this same
problem, i.e how to multiplex upper layer data packet over 802.15.4
frames and how to fragment them so they can fit on the 802.15.4
frames.

The 802.15.9 is split in two layers, first one is the multiplexed data
service, which takes 16-bit MultiplexId and the data packet to be sent
to the other end, and it will fragment and deliver it to the other
end. The MultiplexId is used to separate different protocols using
this mechanism. One of those protocols is the key management protocols
providing KMP for 802.15.4, which is the second part of the 802.15.9.

Instead putting the coap messages in the payload IEs, it would
possible to allocate one MultiplexId for coap messages, and then coap
messages could be transmitted using multiplexing layer of 802.15.9.
This would also take care of fragmentting the messages (with PHY using
127 octet PSDU, the maximum size of the data packet is around 24kB).

The 802.15.9 recommended practice is already past the working group
letter ballots, and is starting its sponsor ballot soon. It is
expected to come out around the end of year. The draft will be
available on the ieee document store after the sponsor ballot starts,
i.e. very soon.
-- 
kivi...@iki.fi 


___
6tisch mailing list
6tisch@ietf.org 
https://www.ietf.org/mailman/listinfo/6tisch



___
6tisch mailing list
6tisch@ietf.org 
https://www.ietf.org/mailman/listinfo/6tisch




___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch


___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] about the secure join process

[Alexander Pelov]

Dear Michael,

> Le 8 sept. 2015 à 03:14, Michael Richardson  a écrit :
> 
> 
> Alexander Pelov  wrote:
>> In our proposal for managing long-range radio networks with CoAP (
>> https://tools.ietf.org/html/draft-pelov-core-cosol-00 ) we’re using
>> EAP-over-CoAP. The use of CoAP as signaling protocol, makes it natural
>> to go to this solution, as this way we can reuse the whole EAP
>> framework that’s already in place.
> 
> EAP-over-CoAP is probably a better choice than over PANA :-)
> 
> But, it seems to me that it ought to be EAP-over-DTLS-over-CoAP,
> with the result being creation of a CoAPS context.

I think that you don’t really need DTLS, just the same way you don’t have 
encryption in 802.1X. 

You’re only transporting the EAP messages. If you want, you could do EAP-TLS, 
but I would be more interested in EAP-PSK and EAP-AKA.


> 
> In either case, if you are really doing EAP-TLS, then you wind up with
> a ridiculous number of layers.
> 
> One can then run EST or something similar over it.
> 
> Your document seems to intersect with a bunch of other work, I hope to get
> back to you with some additional comments.
> 

I would be happy to discuss the different points on which we can collaborate 
and discuss.

Best,
Alexander


> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works| network architect  [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
> 

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] about the secure join process

[Alexander Pelov]

Dear all,

In our proposal for managing long-range radio networks with CoAP ( 
https://tools.ietf.org/html/draft-pelov-core-cosol-00 
 ) we’re using 
EAP-over-CoAP. The use of CoAP as signaling protocol, makes it natural to go to 
this solution, as this way we can reuse the whole EAP framework that’s already 
in place. 

Afterwards, you could use of your choosing either EAP-PSK or any other 
mechanism which would be deemed fit (e.g. certificates, USIM cards, …).

EAP is already used for authentication and authorization in WiFI with WPA/WPA2, 
WiMax (maybe not the best example..), UMTS, LTE, … and for me is one of the few 
truly extensible ways for doing it (I’m still looking at OAuth for that, but 
for me the two are complementary solutions).

I’m sorry to have been absent in the last conf call, but if you want we can 
discuss this in the next one.

Best,
Alexander


> Le 7 sept. 2015 à 09:41, Giuseppe Piro  a écrit :
> 
> Dear all, 
> 
> I'm trying to capture assumptions and goals related to the join process, as 
> discussed during the latest conf call. It is just to verify that everything 
> is clear in my mind :-) 
> 
> Please, reply and correct me if I'm wrong. 
> 
> 
> Initial assumptions:
> - all nodes known K1.
> - each node shares a PSK with the JCE. It is used for authentication purposes 
> during the join process.
> - the join process is handled at the aplication layer through COAP. A message 
> is sent by the JN, forwarded by the JE and processed by the JCE.
> - if the JN is authenticated by the JCE, the JCE sends the K2 (stored and 
> encrypted with the aforementione PSK in a COAP message).
> - JN processes the received COAP message and installs K2.
> 
> Main open issues:
> - messages exchanged between JN and JA must be "protected". For the moment we 
> can assume to use K1. 
> - JA does not know JN; it does not have the corresponding Device Descriptor 
> for JN; it must implemnet a procedure for understanding if the join message 
> should be forwarded or not (protection against DoS ? ).
> - the format of join packets should be defined. Input from COSE. The first 
> packet sent by JN should also contain the ASN (of course, also this field is 
> protected by the PSK). This should avoid replay attacks.
> - definition of mechanisms for installing K2 in JN.
> - the distribution of link layer keys is another problem. Two possibilities: 
> centralized (JCE distribute keys) or distributed (KMP). SHould we define 
> procedures/message formats for both of them ?
> 
> Possible extensions:
> - substitute PSK with certificates .   
> 
> 
> 
> 
> Starting from these premises, it seems that the main action points to target 
> for the moment are:
> - definition of join packets along side COSE inputs
> - procedures to implement at the JA side, i.e., before forwarding the join 
> packet towards the JCE
> 
> 
> Does it make sense ? 
> 
> All the best
> Giuseppe
> 
> 
> -- 
> Giuseppe Piro, PhD
> Post Doc Researcher
> DEI, Politecnico di Bari
> via Orabona 4 - 70125 (Bari), Italy.
> email: pe...@giuseppepiro.com 
> phone: +39 080 5963301
> web: g iuseppepiro.com 
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] [core] Annoncement draft-pelov-core-cosol-00

[Alexander Pelov]

] where the general problem of bootstrapping is 
explained.

Thanks for catching this!



Hope this helps.

Best Regards.

Thanks a lot for your remarks!

Best,
Alexander




El 06/07/2015, a las 17:27, Alexander Pelov  escribió:


Dear all,

I'd like to bring to your attention a new document, which was submitted this 
weekend: draft-pelov-core-cosol-00

It presents a new type of far-reaching, low-rate radio technologies (such as 
Semtech LoRa and SigFox) and an extensible mechanism to operate these networks 
based on CoAP.  We document the way REST can be used to manage these networks.

You can find the current text at the following address: 
https://tools.ietf.org/html/draft-pelov-core-cosol-00

We would be happy to discuss with anyone interested the contents of the draft 
and the possible future works on it. Also, we will be glad if there is any 
possibility to present even briefly during a session.

Best,
Alexander

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

---
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +3486501 Fax: +34868884151 e-mail: r...@um.es
---






___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Annoncement draft-pelov-core-cosol-00

[Alexander Pelov]

Dear all,

I'd like to bring to your attention a new document, which was submitted 
this weekend: draft-pelov-core-cosol-00


It presents a new type of far-reaching, low-rate radio technologies 
(such as Semtech LoRa and SigFox) and an extensible mechanism to operate 
these networks based on CoAP.  We document the way REST can be used to 
manage these networks.


You can find the current text at the following address: 
https://tools.ietf.org/html/draft-pelov-core-cosol-00


We would be happy to discuss with anyone interested the contents of the 
draft and the possible future works on it. Also, we will be glad if 
there is any possibility to present even briefly during a session.


Best,
Alexander

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Reserve space for aliases

[Alexander Pelov]

Hi Andy,

> Le 13 juin 2015 à 00:58, Andy Bierman  a écrit :
> 
> 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.

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 
>  <mailto:alexander.pe...@telecom-bretagne.eu>> 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.
> 
>> Le 12 juin 2015 à 23:57, Andy Bierman > <mailto:a...@yumaworks.com>> a écrit :
>> 
>> Hi,
>> 
>> Here is the "JSON for YANG" draft:
>> https://www.ietf.org/id/draft-ietf-netmod-yang-json-04.txt 
>> <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.
> 
> 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.
> 
>> 
>> 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.
> 
> 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 
>> > <mailto:alexander.pe...@telecom-bretagne.eu>> wrote:
>> Michel,
>> 
>> 
>>> Le 12 juin 2015 à 23:10, Michel Veillette 
>>> >> <mailto:michel.veille...@trilliantinc.com>> a écrit :
>>> 
>>> 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.
>> 
>> 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 
>>&g

Re: [6tisch] Reserve space for aliases

[Alexander Pelov]

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  a écrit :
> 
> Hi,
> 
> Here is the "JSON for YANG" draft:
> https://www.ietf.org/id/draft-ietf-netmod-yang-json-04.txt 
> <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.

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.

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

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 & 0x3C00) > 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 
>  <mailto:alexander.pe...@telecom-bretagne.eu>> wrote:
> Michel,
> 
> 
>> Le 12 juin 2015 à 23:10, Michel Veillette > <mailto:michel.veille...@trilliantinc.com>> a écrit :
>> 
>> 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.
> 
> 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.
>>  
>> 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 <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
> 
> 
>>  
>> In the current draft, the CoMI server need to support two encoding for each 
>> selector, CBOR encoding in the pay

Re: [6tisch] Reserve space for aliases

[Alexander Pelov]

Michel,


> Le 12 juin 2015 à 23:10, Michel Veillette  
> a écrit :
> 
> 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.

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


>  
> 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
> System Architecture Director
> Trilliant Inc.
> Tel: 450-375-0556 ext. 237
> michel.veille...@trilliantinc.com <mailto:michel.veille...@trilliantinc.com>
> www.trilliantinc.com <http://www.trilliantinc.com/>   
>  
>  
> From: Alexander Pelov [mailto:alexander.pe...@telecom-bretagne.eu] 
> Sent: 12 juin 2015 15:26
> To: Michel Veillette
> Cc: Pascal Thubert (pthubert); Andy Bierman; 6tisch@ietf.org; c...@ietf.org
> 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).
>  
> 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. 
>  
> 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  <mailto:michel.veille...@trilliantinc.com>> a écrit :
>  
> Hi Alexander, hi Pascal
>  
&g

Re: [6tisch] Reserve space for aliases

[Alexander Pelov]

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  
> a écrit :
> 
> 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 <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
> System Architecture Director
> Trilliant Inc.
> Tel: 450-375-0556 ext. 237
> michel.veille...@trilliantinc.com <mailto:michel.veille...@trilliantinc.com>
> www.trilliantinc.com <http://www.trilliantinc.com/>   
>  
>  
> From: Alexander Pelov [mailto:alexander.pe...@telecom-bretagne.eu] 
> Sent: 11 juin 2015 17:06
> To: Pascal Thubert (pthubert)
> Cc: Andy Bierman; Michel Veillette; 6tisch@ietf.org; c...@ietf.org
> Subject: Re: [6tisch] Reserve space for aliases
>  
> Hi Pascal,
>  
> Le 10 juin 2015 à 15:25, Pascal Thubert (pthubert)  <mailto:pthub...@cisco.com>> a écrit :
>  
> 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.
>  
> Great analogy! And yes, sadly you cannot satisfy them all, at least not with 
> all devices.
> 
> 
>  
> 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

Re: [6tisch] Reserve space for aliases

[Alexander Pelov]

Hi Pascal,

> Le 10 juin 2015 à 15:25, Pascal Thubert (pthubert)  a 
> écrit :
> 
> 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.

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

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


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

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

>  
> Pascal
>  
> From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of Andy Bierman
> Sent: vendredi 5 juin 2015 20:55
> To: Michel Veillette
> Cc: 6tisch@ietf.org; Alexander Pelov; c...@ietf.org
> Subject: Re: [6tisch] Reserve space for aliases
>  
>  
>  
> On Fri, Jun 5, 2015 at 11:41 AM, Michel Veillette 
>  <mailto:michel.veille...@trilliantinc.com>> wrote:
> 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)

Re: [6tisch] Reserve space for aliases

[Alexander Pelov]

Hi Michel,


> Le 8 juin 2015 à 16:35, Michel Veillette  
> 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


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. 

>  
> REQ: GET example.com/mg/GQB <http://example.com/mg/GQB>
>  
> RES: 2.05 Content (Content-Format: application/cbor)
> {
>   1 : {
> 2 : " leafA1 value",
> 3 : " leafA2 value "
> 26625 : " leafA3 value "
>   }
> }
>  
> 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 
> <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 
> <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

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

Best,
Alexander

>  
> 
> Michel Veillette
> System Architecture Director
> Trilliant Inc.
> Tel: 450-375-0556 ext. 237
> michel.veille...@trilliantinc.com <mailto:michel.veille...@trilliantinc.com>
> www.trilliantinc.com <http://www.trilliantinc.com/>   
>  
>  
> From: Alexander Pelov [mailto:alexander.pe...@telecom-bretagne.eu] 
> Sent: 7 juin 2015 05:21
> To: Michel Veillette
> Cc: Andy Bierman; 6tisch@ietf.org; c...@ietf.org
> Subject: Re: Reserve space for aliases
>  
> 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+00 can be used as YANG 
> id for the module, which can provide meta-information on the loaded module. 
> For 

Re: [6tisch] Reserve space for aliases

[Alexander Pelov]

5 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 <http://example.com/mg>
> {
>   25601 : {
> 2 : " leafA1 value",
> 3 : " leafA2 value "
> 26625 : " leafA3 value "
>   }
> }
>  
> RES: 2.05 Ok
>  
>  
> 
> Michel Veillette
> System Architecture Director
> Trilliant Inc.
> Tel: 450-375-0556 ext. 237
> michel.veille...@trilliantinc.com <mailto:michel.veille...@trilliantinc.com>
> www.trilliantinc.com <http://www.trilliantinc.com/>   
>  
>  
> From: Alexander Pelov [mailto:alexander.pe...@telecom-bretagne.eu 
> <mailto:alexander.pe...@telecom-bretagne.eu>] 
> Sent: 5 juin 2015 16:10
> To: Andy Bierman
> Cc: Michel Veillette; 6tisch@ietf.org <mailto:6tisch@ietf.org>; c...@ietf.org 
> <mailto:c...@ietf.org>
> Subject: Re: Reserve space for aliases
>  
> 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 
>

Re: [6tisch] Reserve space for aliases

[Alexander Pelov]

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?
> 
>  
> 
> 
> 
> 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
> 
> 
> 
>  
> 
> 
> 
> Michel Veillette
> System Architecture Director
> 
> Trilliant Inc.
> Tel: 450-375-0556 ext. 237
> michel.veille...@trilliantinc.com <mailto:michel.veille...@trilliantinc.com>
> www.trilliantinc.com <http://www.trilliantinc.com/>   
> 
>  
> 
>  
> 
> From: Alexander Pelov [mailto:alexander.pe...@telecom-bretagne.eu 
> <mailto:alexander.pe...@telecom-bretagne.eu>] 
> Sent: 5 juin 2015 12:03
> To: Michel Veillette
> Cc: Andy Bierman; 6tisch@ietf.org <mailto:6tisch@ietf.org>; c...@ietf.org 
> <mailto:c...@ietf.org>
> Subject: Re: Reserve space for aliases
> 
>  
> 
> Hi Michel,
> 
>  
> 
>  
> 
> Le 5 juin 2015 à 17:17, Michel Veillette  <mailto:michel.veille...@trilliantinc.com>> a écrit :
> 
>  
> 
> 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.
> 
>  
> 
>  
> 
> 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.
> 
> This can be implemented by a single integer resource (e.g. leaf 
> alliassedModule { type uint32 } )
> 
> 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
> 
> }
> 
> 
> 
> 
> 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
> System Architecture Director
> 
> Trilliant Inc.
> Tel: 450-375-0556 ext. 237
> michel.veille...@trilliantinc.com <mailto:michel.veille...@trilliantinc.com>
> www.trilliantinc.com <http://www.trilliantinc.com/>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Reserve space for aliases

[Alexander Pelov]

Hi Michel,


> Le 5 juin 2015 à 17:17, Michel Veillette  
> a écrit :
> 
> 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.
>  

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.
> This can be implemented by a single integer resource (e.g. leaf 
> alliassedModule { type uint32 } )
> 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
}

> 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
> System Architecture Director
> Trilliant Inc.
> Tel: 450-375-0556 ext. 237
> michel.veille...@trilliantinc.com 
> www.trilliantinc.com 
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] [core] CoMI remote server clash file and YANG hash in URL

[Alexander Pelov]

Hi Michel, Andy,

> 
> Le 5 juin 2015 à 00:36, Michel Veillette  
> a écrit :
> 
> === About "IMO only managed mode is needed."
> 
> Totally agree
> 
> === About "The 10-bit mystery encoding does not seem very interoperable."
> 
> If we " just assigns a module number to a module name", a unique data node 
> identifier need to be formed by this module number + some sort of data node 
> number. The 30 bits data node identifier similar to scheme proposed by 
> Alexander seen to work fine. (e.g. 20 bits module ID, 10 bits data node ID)

If the managed mode is all that is necessary (which also seems reasonable to 
me), then there could be a deterministic assignment of the IDs for the data 
nodes in a module, for example for each module, start from 1 and increase at 
each data node in a breadth-first enumeration of the nodes. At the end of this 
mail I’ve tried to put a short example based on the YANG scheme of 6top.

Also, if the data node ID is 0, then the YANG hash ID will be simply the ID of 
the module, which could then be addressed (maybe for some meta-info?).

Alexander


Example:
id = data node ID
id=1  typedef nodeaddresstype {}

id=2  list CellList {
id=3  leaf CellID {}
id=4 leaf SlotframeID {}
id=5 leaf SlotOffset {}
id=6 leaf ChannelOffset {}
id=7 leaf LinkOption {}
id=8 leaf LinkType {}
id=9 leaf CellType {}
id=10leaf NodeAddress {}
id=11leaf TrackID {}

id=12container Statistic {
id=13leaf NumOfStatistic {}
id=14list MeasureList {
id=15leaf StatisticsMetricsID{}
id=16leaf StatisticsValue{}
  }
  }
  }
  …
  }


> 
> Michel Veillette
> System Architecture Director
> Trilliant Inc.
> Tel: 450-375-0556 ext. 237
> michel.veille...@trilliantinc.com
> www.trilliantinc.com   
> 
> 
> -Original Message-
> From: Andy Bierman [mailto:a...@yumaworks.com] 
> Sent: 4 juin 2015 18:19
> To: Alexander Pelov
> Cc: Michel Veillette; 6tisch@ietf.org; c...@ietf.org
> Subject: Re: [core] CoMI remote server clash file and YANG hash in URL
> 
> On Thu, Jun 4, 2015 at 9:32 AM, Alexander Pelov 
>  wrote:
>> Hi all,
>> 
>> Just a short idea for the hash clash issue.
>> 
>> The 30 bits, which are reserved for the YANG hash can have a structure :
>> 1 bit = structured YANG hash (0) or pure YANG hash (1)
>>   If 0 (structured), then :
>>   1 bit = managed (0) or non-managed (1)
>>   18 bits = module ID
>>   10 bits = item ID
>>   If 1 (non-structured), then:
>>   29 bits = least significant 29 bits of the YANG hash.
>> 
> 
> I do not really want to change the YANG Hash from 30 bits to 29 bits.
> 
> Having a different numbering scheme for every object seems too complicated.
> I would add the constraint that the server must use the same numbering scheme 
> for all objects, so this can be discovered via .well-known capabilities, and 
> all 30 bits can be used in a YANG Hash.
> 
> 
>> In case of clash, send error, the full URI must be used (which should 
>> be with extremely low probability) This way, in the worst case you are 
>> limiting your hash value from 30 to 29 bits (and thus slightly increasing 
>> the clash probability).
>> 
>> If structured YANG hash, then:
>>   0 = managed (e.g. IETF-assigned module ID)
>>  18 bits = the ID of the module (1, 2, 3, …., 262143) assigned 
>> incrementally by IANA (0 reserved for special usage)
>>  10 bits = the ID of the item in the module, incremented at each item 
>> (1..1023 - hope this is sufficient for all cases).
>>   1 = unmanaged
>>   18 bits = ID of module, by default the 18 less significant bits of the 
>> module. It is up to the user to assure that there are no clashes with the 
>> names of the other modules on the device
>>   10 bits = ID of the item. It is up to the implementer to ensure that 
>> there are no clashes within the module.
>> 
>> Two possible drawbacks of this approach, however:
>>  - For managed IDs you will probably have to keep both the YANG hash and the 
>> managed full ID.
>>  - In case of unmanaged IDs you increase the probability of collision of 
>> 1E-9 to 2E-9.
>> 
> 
> 
> IMO only managed mode is needed. The IANA registry (that will be created) 
> should be open to vendors and other SDOs.
> This registry just assigns a module number to a module name.
> 
> The 10-bit mystery encoding does not seem very interoperable.
> It should be standard.  I think the YANG "id" extension to number each object 
> manually will work.
> 
> 
> 
>> Best,
>> Alexander
>

Re: [6tisch] [core] CoMI remote server clash file and YANG hash in URL

[Alexander Pelov]

Hi Michel,

> Le 4 juin 2015 à 19:17, Michel Veillette  
> a écrit :
> 
> Hi Alexander
> 
> In this proposal, the "Managed vs unmanaged" flag is the LSB or MSB?
> If it's the LBB, we can use your compression proposal to save URI and payload 
> space.

Yes, it is the LSB, so managed IDs should compress well. Not sure if the 10 
bits for user item ID are sufficient / too much compared to the typical/max 
size of modules.

Alexander


> 
> I like this approach.
> 
> Michel Veillette
> System Architecture Director
> Trilliant Inc.
> Tel: 450-375-0556 ext. 237
> michel.veille...@trilliantinc.com
> www.trilliantinc.com   
> 
> 
> -Original Message-
> From: Alexander Pelov [mailto:alexander.pe...@telecom-bretagne.eu] 
> Sent: 4 juin 2015 12:32
> To: Michel Veillette
> Cc: Andy Bierman; 6tisch@ietf.org; c...@ietf.org
> Subject: Re: [core] CoMI remote server clash file and YANG hash in URL
> 
> Hi all,
> 
> Just a short idea for the hash clash issue. 
> 
> The 30 bits, which are reserved for the YANG hash can have a structure :
> 1 bit = structured YANG hash (0) or pure YANG hash (1)
>   If 0 (structured), then :
>   1 bit = managed (0) or non-managed (1)
>   18 bits = module ID
>   10 bits = item ID
>   If 1 (non-structured), then:
>   29 bits = least significant 29 bits of the YANG hash.
> 
> In case of clash, send error, the full URI must be used (which should be with 
> extremely low probability) This way, in the worst case you are limiting your 
> hash value from 30 to 29 bits (and thus slightly increasing the clash 
> probability).
> 
> If structured YANG hash, then:
>   0 = managed (e.g. IETF-assigned module ID)
>  18 bits = the ID of the module (1, 2, 3, …., 262143) assigned 
> incrementally by IANA (0 reserved for special usage)
>  10 bits = the ID of the item in the module, incremented at each item 
> (1..1023 - hope this is sufficient for all cases).
>   1 = unmanaged
>   18 bits = ID of module, by default the 18 less significant bits of the 
> module. It is up to the user to assure that there are no clashes with the 
> names of the other modules on the device
>   10 bits = ID of the item. It is up to the implementer to ensure that 
> there are no clashes within the module. 
> 
> Two possible drawbacks of this approach, however:
>  - For managed IDs you will probably have to keep both the YANG hash and the 
> managed full ID.
>  - In case of unmanaged IDs you increase the probability of collision of 1E-9 
> to 2E-9.
> 
> Best,
> Alexander
> 
> 
>> Le 4 juin 2015 à 18:04, Michel Veillette  
>> a écrit :
>> 
>> Hi Andy,
>> 
>> Just to be sure about the scope of your comment.
>> 
>> You say " Each object has a YANG Hash", yes but this is not a uniquely 
>> object identify.
>> Did we reach a consensus about using the  " YANG hash" + "module name or a 
>> module ID" as a unique data node (object) identifier?
>> 
>> This can take the form of a rehash table available on the CoMI server 
>> or elsewhere (" YANG hash", "module name or module ID", "rehash or 
>> alias") This can take the form of an error message containing (" YANG 
>> hash", "module name or module ID", "rehash or alias") This can take 
>> the form of a fully qualified identifier within the request or payload 
>> (REQ: GET example.com/mg?select(.)
>> 
>> Michel Veillette
>> System Architecture Director
>> Trilliant Inc.
>> Tel: 450-375-0556 ext. 237
>> michel.veille...@trilliantinc.com
>> www.trilliantinc.com   
>> 
>> 
>> -Original Message-
>> From: Andy Bierman [mailto:a...@yumaworks.com]
>> Sent: 4 juin 2015 11:37
>> To: Michel Veillette
>> Cc: Alexander Pelov; 6tisch@ietf.org; c...@ietf.org
>> Subject: Re: [core] CoMI remote server clash file and YANG hash in URL
>> 
>> Hi,
>> 
>> I do not agree that the module name or a module ID needs to be used at all 
>> in the object identifier.  Each object has a YANG Hash.
>> Retrieving a node, whether by hash ID or module-ID.hash will cause all 
>> descendant nodes to be included in the retrieval, even if they are 
>> augmenting nodes from another module.
>> 
>> YANG data is hierarchical.
>> The modules are just packaging for definitions.
>> They do not define any containment or structure within the conceptual schema 
>> tree.
>> 
>> 
>> Andy
>> 
>> 
>> On Thu, Jun 4, 2015 at 8:21 AM, Michel Veillette 
>>  wrote:
>>> Hi Andy
>

Re: [6tisch] [core] CoMI remote server clash file and YANG hash in URL

[Alexander Pelov]

Hi all,

Just a short idea for the hash clash issue. 

The 30 bits, which are reserved for the YANG hash can have a structure :
1 bit = structured YANG hash (0) or pure YANG hash (1)
   If 0 (structured), then :
   1 bit = managed (0) or non-managed (1)
   18 bits = module ID
   10 bits = item ID
   If 1 (non-structured), then:
   29 bits = least significant 29 bits of the YANG hash.
 
In case of clash, send error, the full URI must be used (which should be with 
extremely low probability)
This way, in the worst case you are limiting your hash value from 30 to 29 bits 
(and thus slightly increasing the clash probability).

If structured YANG hash, then:
   0 = managed (e.g. IETF-assigned module ID)
  18 bits = the ID of the module (1, 2, 3, …., 262143) assigned 
incrementally by IANA (0 reserved for special usage)
  10 bits = the ID of the item in the module, incremented at each item 
(1..1023 - hope this is sufficient for all cases).
   1 = unmanaged
   18 bits = ID of module, by default the 18 less significant bits of the 
module. It is up to the user to assure that there are no clashes with the names 
of the other modules on the device
   10 bits = ID of the item. It is up to the implementer to ensure that 
there are no clashes within the module. 

Two possible drawbacks of this approach, however:
  - For managed IDs you will probably have to keep both the YANG hash and the 
managed full ID.
  - In case of unmanaged IDs you increase the probability of collision of 1E-9 
to 2E-9.

Best,
Alexander


> Le 4 juin 2015 à 18:04, Michel Veillette  
> a écrit :
> 
> Hi Andy,
> 
> Just to be sure about the scope of your comment.
> 
> You say " Each object has a YANG Hash", yes but this is not a uniquely object 
> identify.
> Did we reach a consensus about using the  " YANG hash" + "module name or a 
> module ID" as a unique data node (object) identifier?
> 
> This can take the form of a rehash table available on the CoMI server or 
> elsewhere (" YANG hash", "module name or module ID", "rehash or alias")
> This can take the form of an error message containing (" YANG hash", "module 
> name or module ID", "rehash or alias")
> This can take the form of a fully qualified identifier within the request or 
> payload (REQ: GET example.com/mg?select(.)
> 
> Michel Veillette
> System Architecture Director
> Trilliant Inc.
> Tel: 450-375-0556 ext. 237
> michel.veille...@trilliantinc.com
> www.trilliantinc.com   
> 
> 
> -Original Message-
> From: Andy Bierman [mailto:a...@yumaworks.com] 
> Sent: 4 juin 2015 11:37
> To: Michel Veillette
> Cc: Alexander Pelov; 6tisch@ietf.org; c...@ietf.org
> Subject: Re: [core] CoMI remote server clash file and YANG hash in URL
> 
> Hi,
> 
> I do not agree that the module name or a module ID needs to be used at all in 
> the object identifier.  Each object has a YANG Hash.
> Retrieving a node, whether by hash ID or module-ID.hash will cause all 
> descendant nodes to be included in the retrieval, even if they are augmenting 
> nodes from another module.
> 
> YANG data is hierarchical.
> The modules are just packaging for definitions.
> They do not define any containment or structure within the conceptual schema 
> tree.
> 
> 
> Andy
> 
> 
> On Thu, Jun 4, 2015 at 8:21 AM, Michel Veillette 
>  wrote:
>> Hi Andy
>> 
>> About "Almost -- this is defined in RFC 6020 -- the augmenting nodes are not 
>> part of the augmented module.  They will be returned in NETCONF and RESTCONF 
>> retrieval operations for an ancestor node but they are not part of the 
>> augmented module.  Only objects defined in the module namespace are part of 
>> the module."
>> 
>> Understood, this is why my contribution introduce the new term, "Module 
>> context". Augmenting nodes are not part of the augmented module but, as 
>> defined, are part of the "Module context". This new concept was require to 
>> minimize the overhead when retrieving the complete datastore containing 
>> multiple module contexts with some having augmenting nodes.
>> 
>>   RES: 2.05 Content (Content-Format: application/cbor)
>>   {
>>  "a" : {
>> 365257235 : "leafA1 value",
>> 702149626 : {
>>215993329 : "leafA2 value",
>>962191682 : "leafC1 value"# Augmenting data 
>> node
>> },
>> 829222983 : "leafS value" # Sub-module data 
>> node
>>  },
>>  "b" : {
>> 289564696 : "leafB value

Re: [6tisch] [core] CoMI remote server clash file and YANG hash in URL

[Alexander Pelov]

Hi Andy,

> Le 4 juin 2015 à 14:56, Andy Bierman  a écrit :
> 
> On Thu, Jun 4, 2015 at 12:02 AM, Alexander Pelov
>  wrote:
>> Hi Andy,
>> 
>>> Le 3 juin 2015 à 23:37, Andy Bierman  a écrit :
>>> 
>>> On Wed, Jun 3, 2015 at 12:48 PM, Michel Veillette
>>>  wrote:
>>>> About "I would prefer if hash collisions in a single module were not 
>>>> allowed."
>>>> Agreed but how this is implemented.
>>>> 
>>> 
>>> 
>>> By checking the YANG hashes before it is published,
>>> similar to checking the YANG syntax with a YANG compiler.
>> 
>>> 
>>> 
>>>> About "But these numbers do not exist in any modules and so they cannot be 
>>>> relied on in CoMI.
>>>> I understand but I assume that a module can be re-published with the added 
>>>> statement when require. If a CoMI implementer try to implement a module 
>>>> containing a clash, he can look for a version of this module containing 
>>>> the special YANG statement. The likelihood of such clash is extremely low 
>>>> and such fallback solution won’t be required often. However, the RFC will 
>>>> specify how to resolve such situation if this ever happen. This statement 
>>>> can also be used to address the need for data node identifier compactness 
>>>> as mentioned by Alexander in its original email.
>>>> 
>>> 
>>> I think the ad-hoc id assignments are pointless because they are not
>>> universal.  The only thing that can be counted on is the module name
>>> and the XPath absolute path expression of each object.
>> 
>> Having a way of re-mapping (or aliasing) an ID to a 
>> locally-understood/negotiated ID is really important in some networks where 
>> the radio resources are extremely limited. If you are able to use IDs 1-23 
>> and you have URL hash compression, you save 8 bytes (using standard CBOR, no 
>> changes here whatsoever). For IDs 24-63 you save 7 bytes, 63-255 - 6 bytes 
>> (without doing any particular treatment).
>> 
> 
> Numbering objects in a schema and numbering radios in a network are different.
> There is no way to assign unique numbers to all objects.
> This is not something IANA should have to do, and not something
> vendors will do.  It was already too difficult to simply number the modules,
> let alone all schema nodes in all modules.

Completely agree.

> 
> 
> 
>> When using a general hash function, the probability of getting a hash value 
>> < 255 is 10E-7, and choosing an URI that statically gives you such ID simply 
>> sounds wrong (and unrealistic).
>> 
>> Two options are then possible here:
>> 1) Leave this out of CoMI
>> 2) Have a minor accommodation, and require no additional resources on the 
>> devices
>> 
> 
> 
> The 6TISCH argument for small clients is important.
> If there is an alterate-ID mapping for every server, then the
> client has a different number for every object (different on
> every server).  This seems like a lot of additional memory
> if there are 1000s of servers.

This is supposing that the 1000s of servers will require unique mapping.

Imagine a network where all radios are of the same type, and you would like to 
manage their parameters (e.g. channel, slot, offset). You could alias the 
channel to ID 1, the slot to ID 2, and operate with these IDs, instead of the 
full hashes. The point is, the way you do the actual mapping does not have to 
do anything with CoMI, where only the first 256 values will be considered 
‘occupied’. 

If you want to do more advanced things, like having several radios and mapping 
1-10 to one of the radios, 11-20 to the second, and so forth - it would be up 
to you to make sure your aliasing scheme is consistent. A hash could help you 
identify to who are you talking to (e.g. /mg/0), but I would suppose that if 
you have a client powerful enough to manage 1000s of devices, it should be able 
to note somewhere - nodes 1-500 use aliasing A, nodes 501-900 use aliasing B, 
and the rest don’t support aliasing, so we’ll go the YANG hash road.

And if the client is too limited, then you just don’t use aliases, no harm done.

> 
> I don't agree that 1 byte object identifiers are needed,
> The 30 bit hash seems small enough.

This of course depends on the case. I agree with you that in many cases it may 
be an overkill to try to save a couple of bytes. If, however, your network has 
long-lived objects (days-months-years), where 90% of your management queries 
are with 20-30 items, you could significantly reduce the trafic by aliasing 
these once to more convenient values. 

The aliases c

Re: [6tisch] [core] CoMI remote server clash file and YANG hash in URL

[Alexander Pelov]

Hi Peter,

> Le 4 juin 2015 à 11:28, peter van der Stok  a écrit :
> 
> Hi Alexander,
> 
> Your suggestion to standardize a handle to a mechanism to do hash aliasing 
> but keep the algorithms out of CoMI seems reasonable to me in a first 
> approach.
> It is then a matter of interest whether the mechanisms of hash aliasing are 
> standardized within CoRE wg or even within CoMI I-D.
> 
> However, I think the idea is interesting and like to investigate it further; 
> and understand what extra standardization is needed.

If the YANG hash compression + reservation of < 256 hash values is accepted to 
CoMI, which I believe can be achieved with minimal modification and at no cost 
in terms of implementation or resource requirements, there are two main 
approaches to implementing the hash aliases:
1) Independent of the YANG schema
  1.a) From a URI, which can be local (e.g /mg/yang.hash-alias or including the 
syntax in the future /mg/yang.hash with special provisioning of having aliased) 
or remote
  1.b) Reserve one of the alias values for the alias mapping resource (e.g. 
/mg/0)

2) Dependent on the YANG schema
  2.a) By using a leaf in the schema (e.g. alternate_hash = 1, or 
comi:alternate_hash = 3)
  2.b) By using an URI specified in the schema (not sure if this would be very 
useful though)

I would say that it should be possible to have the aliasing independent on the 
schema, as a given operator may decide on a different operation modes for the 
same YANG schema. 

==
1.a)
If there is a dedicated file (e.g. /mg/yang.hash-alias), it could be updated by 
the client if necessary. It would be nice to have a way to make sure that the 
server and the client are using the same aliases, which can be implemented with 
the help of a hash over the file + a token which is set upon the creation of 
the file (by the client or upon deploying the object). This way, a client can 
query the server if needed (e.g. GET /mg/yang.hash-alias?keys=hash,token ).

So, to sum up, the simplest solution would be to have a new resource 
/mg/yang.hash-alias which is empty. A client may create the resource with a 
POST operation, where the format is (YANG hash : alias).

Afterwards, the client can use the aliases to issue requests (example at the 
end). This is the bare minimum, but when you have a device (client) which 
manages many servers it is sufficient. 

==
1.b) 
In CoMI reserve all IDs < 256. In a different document specify, that IF you 
want to use hash aliasing, then if works as following:

The value « 0 » can be used for information on the aliases:
1) GET /mg/0 -> Resource not found -> aliases are unsupported feature, don’t 
even try (*standard behavior* - nothing to change to a normal CoMI object, as 
the resource ID 0 is reserved and is inexistent in the YANG hash table).
2) GET /mg/0 -> {} -> aliases are supported, but no alias configuration in 
place (alternatively, this could return some other info, but the source_uri key 
is empty
3) GET /mg/0 ->
  3.1) {"source_uri" : "/mg/yang.hash-alias", "hash": 0x127804bc}
  3.2) {"source_uri" : "example.com/mg/yang.hash-alias", "hash": 0x127804bc}

This can actually be achieved in the following way:

In CoMI:
  1) add YANG hash compression to section 5.4. (minor change)
  2) add a statement that hash values 0-255 inclusive are reserved
  3) eventually, mention as a guidance that these could be used for hash 
aliasing

Afterwards, either add a new document describing hash aliasing, or add a small 
section, which defines:
1) Data ID = 0 is reserved for the alias file. 
2) IDs 1-255 inclusive are mapped to YANG hashes according to the alias 0

As an alternative, the /mg/0 could directly be the alias file, but I like this 
to a smaller extent, as a GET /mg/0 will fetch the whole mapping, and not just 
the ‘yes, aliases are in place, and we’re talking the same thing’.

==


I’d go with 1.b) but have no strong objections to the rest.

Best,
Alexander



REQ: POST /mg/0 <http://example.com/mg/0>(<- this one actually creates a 
file on the server, e.g. /mg/yang.hash-aliases)
 (Content-Format: application/cbor)

{
   0x387804eb: 1,
   0x15370408: 2
}

RES: 2.01 Created 


REQ: GET example.com/mg/C <http://example.com/mg/C>
   (Content-Format: application/cbor)
 
RES: 2.05 Content (Content-Format: application/cbor)
{
 0x2 : "2014-10-26T12:16:51Z",
}



> 
> Peter
> 
> Alexander Pelov schreef op 2015-06-04 09:02:
>> Hi Andy,
>>> Le 3 juin 2015 à 23:37, Andy Bierman  a écrit :
>>> On Wed, Jun 3, 2015 at 12:48 PM, Michel Veillette
>>>  wrote:
>>>> About "I would prefer if hash collisions in a single module were not 
>>>> allowed."
>>>> Agreed but how this is implement

Re: [6tisch] [core] CoMI remote server clash file and YANG hash in URL

[Alexander Pelov]

Hi Andy,

> Le 3 juin 2015 à 23:37, Andy Bierman  a écrit :
> 
> On Wed, Jun 3, 2015 at 12:48 PM, Michel Veillette
>  wrote:
>> About "I would prefer if hash collisions in a single module were not 
>> allowed."
>> Agreed but how this is implemented.
>> 
> 
> 
> By checking the YANG hashes before it is published,
> similar to checking the YANG syntax with a YANG compiler.

> 
> 
>> About "But these numbers do not exist in any modules and so they cannot be 
>> relied on in CoMI.
>> I understand but I assume that a module can be re-published with the added 
>> statement when require. If a CoMI implementer try to implement a module 
>> containing a clash, he can look for a version of this module containing the 
>> special YANG statement. The likelihood of such clash is extremely low and 
>> such fallback solution won’t be required often. However, the RFC will 
>> specify how to resolve such situation if this ever happen. This statement 
>> can also be used to address the need for data node identifier compactness as 
>> mentioned by Alexander in its original email.
>> 
> 
> I think the ad-hoc id assignments are pointless because they are not
> universal.  The only thing that can be counted on is the module name
> and the XPath absolute path expression of each object.

Having a way of re-mapping (or aliasing) an ID to a 
locally-understood/negotiated ID is really important in some networks where the 
radio resources are extremely limited. If you are able to use IDs 1-23 and you 
have URL hash compression, you save 8 bytes (using standard CBOR, no changes 
here whatsoever). For IDs 24-63 you save 7 bytes, 63-255 - 6 bytes (without 
doing any particular treatment). 

When using a general hash function, the probability of getting a hash value < 
255 is 10E-7, and choosing an URI that statically gives you such ID simply 
sounds wrong (and unrealistic).

Two options are then possible here:
1) Leave this out of CoMI
2) Have a minor accommodation, and require no additional resources on the 
devices

Both require defining hash clash handling mechanism, so here the entire 
discussion on how to handle this is pertinent.

For me, 2) can be implemented in two ways:
2.a) Explicit ID re-mapping (or aliasing) through a (external) file. Here, it 
would be nice to have a way to specify the URI of the file, e.g. on the server 
or on a remote location. Something like the mod.uri . 
2.b) Explicit ID re-mapping (or aliasing) in the YANG module (e.g. through the 
"id" option mentioned by Michel or maybe with an extension, e.g. comi:id)

Note that if this is considered hash aliasing (we forget the re-mapping), then 
the behavior can be very simple, e.g.:
It is up to the implementer to define the hash aliases, if any. In case of 
clash with a YANG hash value, the alias must be ignored. In case of clash with 
another alias, both aliases are ignored. 

===
CoMI can decide on a small concession for aliasing uses - say that YANG string 
hash values MUST be >= 64 (256?). The compiler can check that all hashes 
fulfill this before publishing. This way, there is even NO need to add any 
statement about alias clashes. It would be up to the implementer to chose the 
appropriate way of aliasing (if any). Aliases would be local in scope.

What do you think about it? 
===

Best,
Alexander



> 
> 
>> About "In NETCONF, modules tend to use augment a lot"
>> In my document " draft-vanderstok-core-comi-06 - MV.docx ", I propose a new 
>> definition to address this.
>> 
> 
> What is it?
> IMO you should post comments to the mailing list not markup
> to a word document.  It is too hard to follow.
> 
> 
>> Module Context: A module context is composed of all data nodes, 
>> notifications and RPCs defined in a YANG module and included sub-modules or 
>> added to them using the augment YANG statement.
>> 
> 
> Almost -- this is defined in RFC 6020 -- the augmenting nodes are
> not part of the augmented module.  They will be returned in
> NETCONF and RESTCONF retrieval operations for an ancestor node
> but they are not part of the augmented module.  Only objects
> defined in the module namespace are part of the module.
> 
> 
> Andy
> 
> 
> 
>> Section 4.1.3.4 show an example of include, import and augment.
>> 
>> Michel Veillette
>> System Architecture Director
>> Trilliant Inc.
>> Tel: 450-375-0556 ext. 237
>> michel.veille...@trilliantinc.com
>> www.trilliantinc.com
>> 
>> 
>> -Original Message-
>> From: Andy Bierman [mailto:a...@yumaworks.com]
>> Sent: 3 juin 2015 14:54
>> To: Michel Veillette
>> Cc: Alexander Pelov; 6tisch@ietf.org

Re: [6tisch] [core] CoMI remote server clash file and YANG hash in URL

[Alexander Pelov]

Hi Michel,

Thank you for the presentation - I’ve missed it and it clarifies some questions 
I had on the discussions on the ML from the last days.

Actually, I’m not that concerned with the possible clashes, but mostly with the 
possibility to use this mechanism for performance optimization. The aspect that 
interests me the most is the re-mapping of the hashes, which combined with URL 
hash compression can save 4 bytes from the URL and 4 bytes from the CBOR 
representation in some cases (assuming only 1-23 resources are re-maped, 3 
bytes saved if 23-255, which should rarely be used). 

This is somehow similar to the third alternate approach, in which each YANG 
module can specify the data node IDs. 

To elaborate on this, if the YANG module can explicitly specify the hash value 
of some of its items, I think that you could solve the hash clashes with a 
deterministic algorithm working on the loaded modules. For example, if you have 
modules A, B, and C. 
1) Module A’s  calculated IDs and module-defined data node IDs are put in the 
table
2) For each additional module:
   2.a) for each item, if there is a clash:
  while there is a clashing hash value, item’s hash value ++
 
This way, for a fixed set of modules and node IDs you’ll have a collision-free 
hash table. The benefit of this is, as it is deterministic, you can 
pre-calculate the hash remappings offline / statically.

Another point is, in case someone wants to do something optimized, and remaps 
hash value 1 in module A and B, module A’s item will remain with hash 1, while 
module B’s item will become 2, both of which can be compressed efficiently in 
the URL and the CBOR representation (and both of which will always be 1 and 2 
if modules A and B are loaded in this order, with no preceding modules).

Unfortunately, my knowledge of YANG / NETCONF is still basic, so maybe I’m 
missing something obvious which could render this impractical.

Best,
Alexander


> Le 3 juin 2015 à 18:05, Michel Veillette  
> a écrit :
> 
> Hi Alexander
> 
> At the last 6TiSCH bi-weekly call, 4 solutions have been presented to the 
> hash clashes problem. Two based on a rehash table and two based on a new CoAP 
> query parameter carrying the module name or registered module ID. This query 
> parameter is used to select unambiguously the targeted data node(s) assuming 
> that any hash collision within a module have been resolved at design time. 
> You can find this presentation in attachment.
> 
> Both of your proposals make sense to me but I still hope that the clash file 
> can be avoided or be optional.
> 
> Michel Veillette
> System Architecture Director
> Trilliant Inc.
> Tel: 450-375-0556 ext. 237
> michel.veille...@trilliantinc.com
> www.trilliantinc.com   
> 
> 
> -Original Message-
> From: core [mailto:core-boun...@ietf.org] On Behalf Of Alexander Pelov
> Sent: 3 juin 2015 11:01
> To: 6tisch@ietf.org; c...@ietf.org
> Subject: [core] CoMI remote server clash file and YANG hash in URL
> 
> Hello everyone,
> 
> I would like to discuss with you to ideas/proposals in this mail, namely:
> 1) Caching the yang clash file on a remote server
> 2) Compressing the URL representation of YANG hashes
> 
> 1) Caching the yang clash file on a remote server Even though hash collisions 
> should happen rarely (if ever), there may be cases when it could be 
> inevitable, and as such, it may be interesting to cache the clash_file 
> somewhere on a remote server to avoid sending it over the constrained 
> wireless interface. It could be used for other cases, where some frequently 
> used resources are re-hashed for performance purposes. Maybe it would be 
> interesting to allow the server to specify a remote location for the clash 
> file? For static collisions or optimizations it could be that the YANG 
> definition includes alternative hash values, which could be used in addition 
> to the normal ones.
> 
> 2) Compressing the URL representation of YANG hashes Another point (which is 
> unrelated), is to elide the leading "A"s from the base64 representation of 
> the hash in the URL (which corresponds to eliding the leading zeroes from the 
> hash). As specified in section 5.4. a hash value of 0x007e will be 
> encoded as _, but if the leading A’s are elided it will be simply _
> 
> This could pose problems only if in the future the size of the hash values is 
> increased from 30 bits to some other (higher) value.
> 
> This, however, could be very useful when having to frequently access the same 
> resource. In such case, the server/network operator may decide to re-hash the 
> URI to a shorter version, e.g. the 
> /sys:system-state/sys:clock/sys:current-datetime could be remapped from 
> 0x15370408 and VNwQI to 0x1 and _ 
> 
> Best,
> Alex
> 
> PS.
> 

[6tisch] CoMI remote server clash file and YANG hash in URL

[Alexander Pelov]

Hello everyone,

I would like to discuss with you to ideas/proposals in this mail, namely:
1) Caching the yang clash file on a remote server
2) Compressing the URL representation of YANG hashes

1) Caching the yang clash file on a remote server
Even though hash collisions should happen rarely (if ever), there may be cases 
when it could be inevitable, and as such, it may be interesting to cache the 
clash_file somewhere on a remote server to avoid sending it over the 
constrained wireless interface. It could be used for other cases, where some 
frequently used resources are re-hashed for performance purposes. Maybe it 
would be interesting to allow the server to specify a remote location for the 
clash file? For static collisions or optimizations it could be that the YANG 
definition includes alternative hash values, which could be used in addition to 
the normal ones.

2) Compressing the URL representation of YANG hashes
Another point (which is unrelated), is to elide the leading "A"s from the 
base64 representation of the hash in the URL (which corresponds to eliding the 
leading zeroes from the hash). As specified in section 5.4. a hash value of 
0x007e will be encoded as _, but if the leading A’s are elided it will 
be simply _

This could pose problems only if in the future the size of the hash values is 
increased from 30 bits to some other (higher) value.

This, however, could be very useful when having to frequently access the same 
resource. In such case, the server/network operator may decide to re-hash the 
URI to a shorter version, e.g. the 
/sys:system-state/sys:clock/sys:current-datetime could be remapped from 
0x15370408 and VNwQI to 0x1 and _ 

Best,
Alex

PS.
A typo (?), which may be already corrected, in the example of mod.uri on Page 
26: the two responses have different scheme "mod.uri" and "moduri" 

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch