Re: [Netconf] FW: New Version Notification for draft-ietf-netconf-monitoring-05
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Netconf] FW: New Version Notification for draft-ietf-netconf-monitoring-05



Hi Balazs,

Balazs Lengyel <balazs.lengyel at ericsson.com> wrote:
> Hello Mark,
> Some comments:
> General)
> I think we should not exclude the possibility of monitoring non-netconf
> sessions in this schema.

I don't think we do.  The intention was that *if* the NETCONF server
can manage other sessions, it MAY include them in the session list.  

> 2.1.2) "The /netconf-state/datastores subtree contains configuration data"
> This seems to indicate it contains writable data. I know that was not your
> intention, so please reword.

Ok.

> Some changes to the paragraph starting with "For partial locks the list":
> For partial locks the list of locked nodes and the select expressions
> originally used to request the lock are returned. The scope of the partial lock
> is defined by the list of locked nodes. This list might change during the
> lifetime of the lock.
> The select expressions indicate the original intended scope of the lock.

Ok.

> Ch 2.1.3)
> YIN should be added as a format.

Originally we had text that said that the format 'yang' also covered
the yin syntax form.  So either we add that back, or we add 'yin'.
Should we also add 'rnc' (in addition to 'rng')?

> s/One of more locations/Zero one of more locations/
> 
> 2.1.4) in several places you use "a <rpc> message was expected"
> Who expects it? Does the device know that an <edit-config> should be arriving
> at 7:00 PM? :-) Rather remove the expected part.

The server waits for (and thus expects) <rpc> messages.  If it gets
something else, the counter is incremented.

> 2.1.5) Please indicate if droppedSessions includes session closed due to
> parseErrors.

There is nothing in 4741 that says that a parse error MUST terminate the
session.  So droppedSessions says that if the session is abnormally
terminated the counter is incremented.  A server that terminates a
session due to a parse error should increment this counter.

> 3.1)
> - One XML error, search for ><

Actually, there are 3 similar errors in this example...  and the text
Positive Response is mixed with the example.

> - negative response missing
> 3.2)
> - s/schema may be supported in multiple locations/schema may be available in
> - multiple locations/
> - first paragraph last sentence is trivial, remove it.
> - Why do you have a negative response section here? Does this belong to 3.1?

Yes.

> 5) didn't check XSD. How about generating it automatically from YANG? That
> would more or less remove the need to review it.

It is not trivial, since the YANG module uses types from
ietf-inet-types and ietf-yang-types.  We would need them as XSDs as
well...


> 9) Include non-normative references for yang and yang-types

Ok.

> Appendix)
> - location should be a leaf-list not a leaf

Yes.

> - get-schema output: if we have a YANG schema will it will be a string not any
>   XML

A string can be sent in anyxml.

> - the level of descriptions is uneven in this YAM

I don't understand what you mean?


/martin

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.