Subject: Re: [Netconf] Comments on Monitoring Draft

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 10 Jul 2008 09:51:56 -0400

Hi

For some internal stuff I need clarification on the first point. As
such, I propose that the given list of statistics be clarified to just
be for NETCONF. This would not preclude adding additional statistics in
the future that go beyond this (current number of sessions for example
might include CLI sessions).

Please let me know if this is not a reasonable approach.

Thanks,

Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Chisholm, Sharon (CAR:ZZ00)
Sent: Thursday, June 26, 2008 2:41 PM
To: [email-masked]
Subject: [Netconf] Comments on Monitoring Draft

Hi

1. If the statistics are limited to NETCONF traffic, this should be
clarified in the description clauses. Since we discuss CLI sessions in
another part of the data model, this is not completely obvious.

2. For consistency with other NETCONF specifications, the protocol
operation definition should be broken out separately from the content
definition.

3. Should any of the parameters to the <get-schema> verb be optional?
Currently they are all mandatory. If my device only has XSDs, do I
really have to specify this parameter every single time?

Sharon Chisholm
Nortel
Ottawa, Ontario
Canada
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/From [email-masked]  Thu Jul 10 06:53:22 2008
Content-class: urn:content-classes:message
Date: Thu, 10 Jul 2008 09:51:56 -0400
From: "Sharon Chisholm" <[email-masked]>
To: <[email-masked]>
Subject: Re: [Netconf] Comments on Monitoring Draft
Sender: [email-masked]

Hi

For some internal stuff I need clarification on the first point. As
such, I propose that the given list of statistics be clarified to just
be for NETCONF. This would not preclude adding additional statistics in
the future that go beyond this (current number of sessions for example
might include CLI sessions).

Please let me know if this is not a reasonable approach.

Thanks,

Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Chisholm, Sharon (CAR:ZZ00)
Sent: Thursday, June 26, 2008 2:41 PM
To: [email-masked]
Subject: [Netconf] Comments on Monitoring Draft

Hi

1. If the statistics are limited to NETCONF traffic, this should be
clarified in the description clauses. Since we discuss CLI sessions in
another part of the data model, this is not completely obvious.

2. For consistency with other NETCONF specifications, the protocol
operation definition should be broken out separately from the content
definition.

3. Should any of the parameters to the <get-schema> verb be optional?
Currently they are all mandatory. If my device only has XSDs, do I
really have to specify this parameter every single time?

Sharon Chisholm
Nortel
Ottawa, Ontario
Canada
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/lisnetconf
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 10 Jul 2008 16:19:43 +0200

All this looks reasonable to me. 

And all this stuff is useful. 

Dan
(contributor opinion) 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sharon Chisholm
> Sent: Thursday, July 10, 2008 4:52 PM
> To: [email-masked]
> For some internal stuff I need clarification on the first 
> point. As such, I propose that the given list of statistics 
> be clarified to just be for NETCONF. This would not preclude 
> adding additional statistics in the future that go beyond 
> this (current number of sessions for example might include 
> CLI sessions).
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Chisholm, 
> Sharon (CAR:ZZ00)
> 1. If the statistics are limited to NETCONF traffic, this 
> should be clarified in the description clauses. Since we 
> discuss CLI sessions in another part of the data model, this 
> is not completely obvious.
> 
> 2. For consistency with other NETCONF specifications, the 
> protocol operation definition should be broken out separately 
> from the content definition.
> 
> Currently they are all mandatory. If my device only has XSDs, 
> do I really have to specify this parameter every single time?
> 
> Sharon Chisholm
> Nortel
> Ottawa, Ontario
> Canada

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 10 Jul 2008 16:19:43 +0200

Dan
(contributor opinion)

---

From: "Mark Scott" <[email-masked]>
Date: Thu, 17 Jul 2008 12:34:40 -0400

Hi Sharon,

Points 1 and 2 can be updated in next version.

On Point 3 my preference would be to keep the 'format' parameter
mandatory.

My thinking here:

It encourages a manager to specifically request the format of interest.
I also think it helps to simplify cases like this:

- device has only one format for a specific schema
	- likely rare but each schema may not be the same format
- manager can send <get-schema> without 'format' parameter
- device returns whatever format it has for that identifier and version
- manager has to either cross-check the schema-list entry or the result
contents to confirm the format
- later, a new instance of same schema (in another format) is added
- manager still sends <get-schema> without 'format', would we expect:
	A) to return an error indicating format not specified?
Effectively making the parm mandatory
	B) return a 'default format'?  In which case would be need to
define and advertise the default format?  However, this won't work in
cases where a device doesn't have a schema in the default format;
unless the device enforced the presence of at least the default format
but that's putting too many resFrom [email-masked]  Thu Jul 17 09:34:21 2008
Content-class: urn:content-classes:message
Date: Thu, 17 Jul 2008 12:34:40 -0400
From: "Mark Scott" <[email-masked]>
To: "Sharon Chisholm" <[email-masked]>, <[email-masked]>
Subject: Re: [Netconf] Comments on Monitoring Draft
Sender: [email-masked]

Hi Sharon,

Points 1 and 2 can be updated in next version.

On Point 3 my preference would be to keep the 'format' parameter
mandatory.

My thinking here:

It encourages a manager to specifically request the format of interest.
I also think it helps to simplify cases like this:

- device has only one format for a specific schema
	- likely rare but each schema may not be the same format
- manager can send <get-schema> without 'format' parameter
- device returns whatever format it has for that identifier and version
- manager has to either cross-check the schema-list entry or the result
contents to confirm the format
- later, a new instance of same schema (in another format) is added
- manager still sends <get-schema> without 'format', would we expect:
	A) to return an error indicating format not specified?
Effectively making the parm mandatory
	B) return a 'default format'?  In which case would be need to
define and advertise the default format?  However, this won't work in
cases where a device doesn't have a schema in the default format;
unless the device enforced the presence of at least the default format
but that's putting too many restrictitrictions on the device in my opinion 

So I'd like to just keep it simple with the mandatory parameter.

I'm open to discussion though.

thx,
Mark

> be for NETCONF. This would not preclude adding additional statistics 
> in the future that go beyond this (current number of sessions for 
> example might include CLI sessions).
> 
> [mailto:[email-masked]] On Behalf Of Chisholm, Sharon 
> (CAR:ZZ00)

ons on the device in my opinion 

So I'd like to just keep it simple with the mandatory parameter.

I'm open to discussion though.

thx,
Mark

> be for NETCONF. This would not preclude adding additional statistics 
> in the future that go beyond this (current number of sessions for 
> example might include CLI sessions).
> 
> [mailto:[email-masked]] On Behalf Of Chisholm, Sharon 
> (CAR:ZZ00)