Subject: [Netconf] Subject: RE: review of draft-ietf-netconf-monitoring-01

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Mon, 17 Mar 2008 12:59:55 +0100

Thanks Juergen for your extensive review and detailed comments.
I assume the authors/editors will react and/or make changes
to the document accordingly.

Other WG members: PLEASE do also review and send your comments.
Only if we all participate can we come to consensus and create
a good quality document.

Bert Wijnen 

> -----Oorspronkelijk bericht-----
> Van: [email-masked]
> [mailto:[email-masked]]Namens Juergen Schoenwaelder
> Verzonden: maandag 10 maart 2008 16:36
> Aan: [email-masked]
> Onderwerp: review of draft-ietf-netconf-monitoring-01
> 
> 
> 
> 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.
> 
>From [email-masked]  Mon Mar 17 05:02:33 2008
From: "Bert Wijnen - IETF" <[email-masked]>
To: "Netconf" <[email-masked]>
Date: Mon, 17 Mar 2008 12:59:55 +0100
Importance: Normal
Subject: [Netconf] Subject: RE: review of draft-ietf-netconf-monitoring-01
Sender: [email-masked]

Thanks Juergen for your extensive review and detailed comments.
I assume the authors/editors will react and/or make changes
to the document accordingly.

Other WG members: PLEASE do also review and send your comments.
Only if we all participate can we come to consensus and create
a good quality document.

Bert Wijnen 

> -----Oorspronkelijk bericht-----
> Van: [email-masked]
> [mailto:[email-masked]]Namens Juergen Schoenwaelder
> Verzonden: maandag 10 maart 2008 16:36
> Aan: [email-masked]
> Onderwerp: review of draft-ietf-netconf-monitoring-01
> 
> 
> 
> 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 [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

   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 [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf