I don't remember in the CoMI draft a method which can be used by CoMI clients to get the list of YANG modules supported by CoMI servers. Do you means that CoMI clients need be pre-loaded with the list of YANG modules implemented by each CoMI server they might need to interact with? How we will deal with dynamic change in these list of YANG modules?
Instead, should we require that augmented data nodes are always identified using a fully qualified identifier? (e.g. " ietf-interfaces.jVLxJ" or the 18 bits module ID + 10 bits = data node ID as proposed by Alexander) 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 15:03 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: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 _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
