Hi Andy
I was assuming that YANG hash values was unique within a module context (Module
data nodes + augmenting data nodes).
If this is not the case, we might have a more important issue than what you are
describing.
Let assume that we have two modules augmenting the same container.
Let also assume that the YANG hash of data node A2 and A3 are the same.
mod1:
container A { # YANG hash 2345
leaf A1 { type string; } # YANG hash 1234
}
mod2:
augment /mod1:A {
leaf A2 { type string; } # YANG hash 5678
}
mod3:
augment /mod1:A {
leaf A3 { type string; } # YANG hash 5678
}
Finally, let assume that the CoMI server implements mod1 and mod2 and the CoMI
client implements all three modules.
{ 2345: {
1234 : "foo",
5678 : "bar"
}
}
How the CoMI client known the meaning of "bar" ?
Michel Veillette
System Architecture Director
Trilliant Inc.
Tel: 450-375-0556 ext. 237
[email protected]
www.trilliantinc.com
-----Original Message-----
From: Andy Bierman [mailto:[email protected]]
Sent: 4 juin 2015 12:30
To: Michel Veillette
Cc: Alexander Pelov; [email protected]; [email protected]
Subject: Re: [core] CoMI remote server clash file and YANG hash in URL
On Thu, Jun 4, 2015 at 9:04 AM, Michel Veillette
<[email protected]> wrote:
> 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?
>
I don't know if any consensus has been reached.
IMO the YANG hash is all that is needed.
There is a small probability that the hash is not unique.
If this happens, the rehash is needed.
If a specific value maps to more than 1 object on a server, then that value
triggers a rehash if the client uses it.
I prefer to send the rehash info as an error response only when needed.
I prefer to limit optional features so the server code can be as small as
possible.
There is a problem with GET.
Let's say the data model is a simple container with 2 leafs:
mod1:
container A {
leaf A1 { type string; }
}
mod2:
augment /mod1:A {
leaf A2 { type string; }
}
What if the server does a GET on /A but A1 and A2 have a hash collision?
The server is supposed to return
{"A": {
"A1":"foo",
"A2":"bar"
}
}
But the original hashes will not work:
{"2345": {
"1234":"foo",
"1234":"bar"
}
}
The client never requested A1 or A2 directly but will still need to know the
rehash info for these nodes.
The server could return the rehash info in the GET response, or return some
flag that the client needs to retrieve the rehash info.
Even if A1 and A2 are not siblings, the rehash info needs to be sent because
the server will remap the collided hash value "1234".
In this case it might be useful for the server to return a "long form"
of the node, which includes the requested value and the rehash info.
This part of your plan I like (if I understand it). But requiring the server
to accept the long-form as input is not needed.
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
