Hi Andy About " The server knows that hash 5678 is a clash"
In the described scenario, the CoMI server implement only mod1 and mod2 and in this context the hash value 5678 is not a clash. On the client side, the CoMI client implement mod1, mod2 and mod3 and is confused about the received data. 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 13:31 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 10:09 AM, Michel Veillette <[email protected]> wrote: > 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" ? > Because this response message that you are describing is not allowed to happen. The server knows that hash "5678" is a clash and does not send this hash out as normal. The value "5678" is no longer valid on this server. Both nodes that hashed to "5678" need to be re-hashed. NETCONF allows in-line <rpc-error> to be returned for get*. Something similar could be done for CoMI. > Michel Veillette Andy > 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
