review of draft-ietf-netconf-monitoring-01

[Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>]

My comments on draft-ietf-netconf-monitoring-01:

- General: This document needs a lot of work.

- The first two sentences of the abstract should be moved into the
  introduction and the introduction clearly could have a bit more
  text.

- Remove the term Managed Object - it does not seem to be used.

- Is 'netconfState' a good idea? How do we in general like to organize
  data models?

- In the following text, is the right verb exchanged or announced?

     Minimally must contain the same capabilities exchanged during
     session setup.

  If a device reports more than announced during the session setup,
  how can I actually find out what has been announced for a given
  session? Is the idea that an implementation can have capabilities
  that are only announced on some session??

- Several of the elements (e.g. transport, protocol) are just strings
  - so how do we achieve interoperability?

- The description of sourceIdentifier is inconsistent with the XSD.

- Can you you refer to inet:ip-address in the XSD??

- Where are things such as netconf:SessionId or netconf:configNameType
  or netconf:filterInlineType defined? Is there a common
  capitalization rule for identifiers or is this just random?

- I read:

   sessionId:
     unique identifier for the notifications.  Same value as returned in
     'sessions' to allow correlation.

  I assume sessionId is an identifier for the notification session, not
  for the notifications...

- What is NetconfSubscriptionInfo?? And how does it map to "event
  subscriptions"?

- I don't find any of the schema reporting stuff in the XSD.

- I read:

  location:
    a location from which the schema can be retrieved.  Can be either on
    the network device (eg: URL), retrievable explicitly via netconf
    ('netconf') or some network location (eg: URL).

  What is the difference between a 'network device' and a 'network
  location'??

- Section 3 is all about "will be" but not about how things are
  actually done.

- I read:

    <identifier> and <version> elements are
    mandatory and their values are unique

  It is unclear what specifically is going to be unique. All the
  identifers? All version numbers? The combinations of identifiers
  with version numbers? Something else?

- Is there concensus that we do access control in units of schemas?

- How do I actually retrieve a schema via NETCONF? I know what to do
  with a URL but this is where it ends...

- The list-schema example is not even valid XML. I am missing a clear
  definition of the proposed NETCONF capability. And whay is
  list-schema good for - it seems to do the same as the get operation,
  no?

- I suggest to remove the first paragraph of section 4 since this text
  is also in the security considerations (where it belongs).

- There needs to be IANA considerations since you need to allocate at
  least a URN.

- I would love to have an appendix with a YANG module.

- I did not bother to read the XSD.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>