On Thu, Jun 4, 2015 at 12:33 PM, Michel Veillette
<[email protected]> wrote:
> 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?


comi-06, pg 26:

   Therefore, it is recommended that details about management objects
   are discovered following the RESTCONF protocol.  The YANG module
   information is stored in the "ietf-yang-library" module
   [I-D.ietf-netconf-restconf].  The resource "/mg/mod.uri" is used to
   retrieve the location of the YANG module library.

I think Carsten suggested that an additional attribute
(last-changed-time or an entity-tag) be maintained by the server
so it can be observed by the client, and get notified if the YANG
module list changes for the specific server.

Andy

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

Reply via email to