Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt

[Andy Bierman <andy at netconfcentral.com>]

Sharon Chisholm wrote:
> hi
>  
> Thanks for your comments.  Replies inline.
>  
> Sharon
>
> ------------------------------------------------------------------------
> *From:* Balazs Lengyel [mailto:balazs.lengyel at ericsson.com]
> *Sent:* Tuesday, July 22, 2008 7:58 AM
> *To:* Scott, Mark (CAR:2Y01); Chisholm, Sharon (CAR:ZZ00); Martin Bjorklund
> *Cc:* netconf mailing list
> *Subject:* [Netconf] Review of draft-ietf-netconf-monitoring-02.txt
>
> Hi Marc, Sharon, Martin,
>
> I reviewed the draft NETCONF Monitoring Schema.
> Please find my comments below.
>
>  <clip> 
>
>
> 2.1.1. capabilities
>  From RFC4741: "The device uses capabilities to announce the set of data 
> models that the device implements."
> This to me means that the device MUST advertise all it's models as 
> capabilities as well. So the models will be included both in the 
> capabilities and the schemas branch. Please indicate this. 
>
>  <sharon>
> Experience has shown that was a not the best way to get data model 
> definitions.  I don't think we need to repeat that advise here. We may 
> want to remove it in an update to RFC4741.
> </sharon>  

I think it is useful to send the module capabilities in the <hello>.
The very first the manager needs to do is get these module caps,
so it can make sure compatible versions of all the relevant modules
are loaded.  Unless the manager is using a proprietary mechanism
(e.g., identifying packages or profiles, not individual modules),
then it will take the same amount of bandwidth and memory for
the <get> as the <hello>.

I support an additional <get> for module-caps, because the
alternative is to rely on a proprietary API to access the
<hello> message.


Andy



> 5.2 int:host schema
> This should be a separate draft as many other will need it. Is there 
> today no XML schema for such basic stuff? Can we refer to 
> draft-ietf-opsawg-smi-datatypes-in-xsd? What is the state of that? 
> Anyone who cares about XSD should start pushing that draft! 
>
> <sharon>
>
> We looked at that and either it didn't meet our needs or there was a 
> namespace issue, either way, we couldn't use it. In general, if we can 
> get better data types by not deriving them from legacy definitions then 
> we should not be afraid to do that. I agree though that this should be a 
> separate document..
>
> </sharon>
>
>  
> Appendix A YANG
>
>  <clip a long list of issues>
>
> <sharon>  
>  We probably should only have a  pointer to the yang definition stored 
> elsewhere. We can't have any dependencies on  the netmod work if we plan 
> on completing on schedule. Anything we include in this ID, even in 
> non-normative form, can't help but be out of date since netmod  won't be 
> done when we publish.
>
> </sharon> 
>
>
>
> regards Balazs
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Netconf mailing list
> Netconf at ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


_______________________________________________
Netconf mailing list
Netconf at ietf.org
https://www.ietf.org/mailman/listinfo/netconf