On Thu, Jun 4, 2015 at 10:45 AM, Michel Veillette <[email protected]> wrote: > 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. >
But hash collisions are only within a server. The client will get the ietf-yang-library inventory for the server and see that mod3 is not supported by that server. The client cannot treat rehash info as global. It has to remember the rehash info from each server. > Michel Veillette > System Architecture Director > Trilliant Inc. > Tel: 450-375-0556 ext. 237 > [email protected] > www.trilliantinc.com > Andy > > -----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
