Re: [Netconf] draft-ietf-netconf-monitoring-09 last call comments fromjs

["Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue at nsn.com>]

Hi Juergen,

thank you for the thorough review. It seems that we need another
update for the monitoring draft.

> :   [...]  The
> :   capabilities of a NETCONF server may change over time.  
> However, once
> :   a NETCONF server has announced its capabilities in the <hello>
> :   message, the capabilities for that session MUST NOT 
> change.  A server
> :   MUST reply with a 'capabilities-changed' error if the 
> client sends a
> :   request which is affected by a modified capability.  A server MAY
> :   choose to send 'capabilities-changed' as the response to 
> any request
> :   other than <close-session> if its capabilities has changed.
> 
> It seems to me that it is not the job of the monitoring document to
> establish rules how NETCONF works. I suggest to remove this text and
> to include such text in RFC 4741bis instead.

True, it is not the job of the monitoring document to establish rules 
how NETCONF works. I agree to remove this text and to add it to 4741bis.

> :   Schema:  A machine readable data model definition.  The schema is
> :      independent of which data modeling language is used 
> for the data
> :      model.
> 
> I have trouble to understand the second sentence. Every machine
> readable data model is written in a specific format. So how can the
> schema be format specific and at the same time independent? Perhaps
> the second sentence should just be removed.

The schema is dependent on the data modeling language. I agree,
that the second sentence should be removed.

> :   To provide clients the ability to manage locked resources lock
> :   information is provided for each ConfigurationDataStore instance.
> 
> I have no clue what this ConfigurationDataStore instance is.

Additionally the sentence is somehow mishapen.

> :    For YANG data models, the format is one of "yang" or "yin".
> 
> I am concerned about interoperability here. I prefer that the "yang"
> format is required and "yin" can be provided optionally. Otherwise,
> you require that all management applications have two parsers instead
> of one.

I think it is a good proposal to have "yang" format required and 
"yin" optional. This can reduce the implementation cost.
 
: ....
: ....

> I am badly missing description statements here. In general, it seems
> that many description statements leave out details that are explained
> in section 2. In SMIv2 land, it was considered good practice to have
> all normative texts in the data model so that the text is there once
> extracted from the RFC. I believe we should follow this practice and
> move most of the text from section 2.1 into description clauses. This
> also avoids any potential inconsistencies.

I think we should avoid having the RFC text and the normative YANG
module 
as redundant. I agree that the YANG module has to be self-explanatory
and 
complete from the management information definition POV where the RFC
text 
should contain explanations and additional text for the YANG module.
 
I agree also with Randy that content relevant to management should be in
the 
YANG module. However, if we describe the monitoring approach or
operational 
characteristics this might not be subject to management.  

Cheers,
Mehmet