Subject: [Netconf] draft-ietf-netconf-monitoring-09 last call comments from js

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 2 Nov 2009 22:12:32 +0100

On Tue, Oct 20, 2009 at 02:36:24PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote:
 
> With this mail we start a new WGLC for the NETCONF 
> monitoring draft, which is planned to publish as a 
> Proposed Standard RFC. The WGLC will run until 
> November 2, 2009. 

I have reviewed the monitoring document and below are my comments. I
quoted (using the : marker) text from the monitoring document and then
wrote down my comments/questions/suggestions. I did not find any show
stoppers, but I believe more editing work (means at least one more
revision) is to be done to get this document into good shape.

:   [...]  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.

:   Through updated monitoring data NETCONF clients can adjust their
:   capabilities throughout a session.

I wonder how this is supposed to work. Once the server starts to
generate 'capabilities-changed' errors, I need an explicit resync
action - reading the monitoring data can hardly be sufficient to
declare that things are not synchronized again.

:   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 following data allows a NETCONF client to monitor both the
:   NETCONF server itself and the associated network device operational
:   data.

I wonder what "associated network device operational data" means. I
thought the YANG model only reports NETCONF server operational state
and statistics.

:   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.

:    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.

:    A schema entry may be located on a network device (eg: xs:anyURI),
:    a remote file system (eg: xs:string reference to file system for
:    ftp retrieval) or available explicitly via NETCONF (xs:string
:    value 'NETCONF') for NETCONF servers which support the
:    <get-schema> operation.

You probably want to replace the references to XSD types for
consistency.

:    For YANG data models, this is the module's namespace.  If the list
:    entry describes a submodule, this field contains the namespace of
:    the module to which the submodule belongs.

This text seems misplaced since I believe this has nothing to do with
the location.

:   Includes session specific data for NETCONF management sessions.
:   The session list MUST include all currently active NETCONF sessions,
:   and MAY include other sessions as well.

It is unclear what "other sessions" mean. If you mean "inactive"
sessions or "recently closed sessions", simply say so. If you mean non
NETCONF sessions, well that that kind of violates the first sentence.
Please clarify.

:     For purposes of NETCONF management all sessions are one of:
:
:       Known session:  any session which can be managed by the
:         NETCONF server SHOULD be reported in this table.
:
:       Unknown session:  such sessions are not managed by the
:         NETCONF server and map to NETCONF session identifier 0.
:            These MUST be excluded from the session table as a result.

I dislike the word table - XML is not tables like SMIv2. That said, I
find the text confusing. What you are really saying is: Monitoring
data is only provided for session with a non-zero session-id.

:   transport (identityref, transport)
:     Idenfities type for each session, e.g. "netconf-ssh",
:     "netconf-soap", etc.

Replace with "Identifies that transport for each ..."

:   username (string)
:     If present, the username contains an identifier which can be
:     used to uniquely identify an individual client (human or
:     machine).  This is likely to be implementation specific and
:     subject to the security requirements of the device vendor
:     and/or operators,  e.g., an SSH user, a host RSA fingerprint
:     or other identifier deemed acceptable.

I do not want to boil the ocean, but we will likely have to work this
out in more detail later when access control is defined and we need a
deterministic way to derive a username from whatever has been used for
authentication. Those who follow the ISMS work will know why I have to
comment on this. So take this as a warning that in the future, we will
have to define much more precise ways to derive a username if we
associate access control rules with user identities.

:   When the schema is available on the device this operation is
:   used to return it via NETCONF.

This conditional sentence sounds backwards. What about this:

     This operation can be used to retrieve a schema form the NETCONF
     server.

:             module bar {
:               bar version 2008-06-01 yang module
:               contents here ...
:             }

Make this legal yang by using comments:

             module bar {
               // bar version 2008-06-01 yang module
               // contents here ...
             }

:           module bar-types {
:             bar-types version 2008-06-01 yang module
:             contents here ...
:           }

Make this legal yang by using comments:

           module bar-types {
             // bar-types version 2008-06-01 yang module
             // contents here ...
           }

:  identity transport {
:    description
:      "Base identity for session types.";
:  }

This should be "Base identity for NETCONF transports.". Please remove all
mentions of "session types".

:    reference "RFC 4742";

Replace with

    reference "RFC 4742: Using the NETCONF Configuration Protocol 
                         over Secure SHell (SSH)";

:    reference "RFC 4743";

Replace with

    reference "RFC 4743: Using NETCONF over the Simple Object 
		         Access Protocol (SOAP)";

:    reference "RFC 4744";

Replace with

    reference "RFC 4744: Using the NETCONF Protocol over the
                         Blocks Extensible Exchange Protocol (BEEP)";

:    reference "RFC 5539";

Replace with

    reference "RFC 5539: NETCONF over Transport Layer Security (TLS)";

:    reference "W3C REC REC-xmlschema-1-20041028";

Replace with

    reference "W3C REC REC-xmlschema-1-20041028: XML Schema Part 1: Structure
               W3C REC REC-xmlschema-2-20041028: XML Schema Part 2: Datatypes";

:    reference "ISO/IEC 19757-2";

Replace with

    reference "ISO/IEC 19757-2: RELAX NG";

:    reference "ISO/IEC 19757-2";

Replace with

    reference "ISO/IEC 19757-2: RELAX NG";

:            list partial-locks {
:              key lock-id;
:              description
:                "For a partial lock this is the lock id returned
:                  in the <partial-lock> response.";
:              leaf lock-id {
:                type uint32;
:              }

The description like should be a description of the leaf lock-id and
not the partial-locks list itself.

:      list session {
:        key session-id;
:        leaf session-id {
:          type session-id;
:        }
:        leaf transport {
:          mandatory true;
:          type identityref {
:            base transport;
:          }
:        }
:        leaf username  {
:          type string;
:        }
:        leaf source-host {
:          type inet:host;
:        }

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.

        leaf login-time {
          mandatory true;
          type yang:date-and-time;
          description
            "Time at which the session was established.";
        }

I am wondering why some objects are mandatory while others are
not. For example, why is the login-time mandatory while the
netconf-start-time is not mandatory? It is not clear to me as a reader
whether there are any specific requirements on login-time that give it
a special status and that do not apply to netconf-start-time.

Finally, I like to comment that I find the choice lock-type a somewhat
artifical construction.  I understand that a global lock and a partial
lock can't exist together. Still, I would have modeled a simple
global-lock container and a partial-locks list. I find this somewhat
simpler to follow, also because partial locks really are a
feature. (The model does not really distinguish features in general.)
But perhaps this is just a style issue and not really important to
agree on.

/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/>

---

From: Phil Shafer <[email-masked]>
Date: Mon, 2 Nov 2009 21:38:38 -0500

>associate access control rules with user identities.

There's also the issue of radius/tacplus users, where the "user
name" and "login name" are distinct and both are needed.

>     This operation can be used to retrieve a schema form the NETCONF

Needs to indicate that the schema form cannot always be
retrived.  My earlier suggestion was s/When/If/, but
that wasn't incorporated.

>also avoids any potential inconsistencies.

Amen.  Can we go further and encourage the YANG module to _be_
the full RFC, so extracting the module gives the full normative
text of the RFC inside the module?  So the RFC is some introductory
text, followed by the YANG module with all the normative text as
comments or descriptions inside that file.  Extracting the module
gives you everything and there's not duplicate text to get out of
sync or to add confusion.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Nov 2009 08:11:55 +0100

> name" and "login name" are distinct and both are needed.

Not sure I understand your comment - why does radius/tacplus lead to a
difference between a "user name" and a "login name"? Which AVPs are
you referring to?

> sync or to add confusion.

This is pretty much what we have been doing in SMIv2 land.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 3 Nov 2009 11:34:14 +0100

> -----Original Message-----
> > 
> > Amen.  Can we go further and encourage the YANG module to _be_ the 
> > full RFC, so extracting the module gives the full normative text of 
> > the RFC inside the module?  So the RFC is some introductory text, 
> > followed by the YANG module with all the normative text as 
> comments or 
> > descriptions inside that file.  Extracting the module gives you 
> > everything and there's not duplicate text to get out of 
> sync or to add 
> > confusion.
> 

Yes. This may be straighten up in the guideline document -
http://www.ietf.org/id/draft-ietf-netmod-yang-usage-02.txt . 

While completing avoiding duplication is not always possible it should
be made clear that the YANG module is the normative text. Useful
information may be present in the RFC (like security considerations,
relations with other modules, application examples, etc.) but the
information in the module itself should be complete enough to allow for
implementation.

Dan

---

From: Phil Shafer <[email-masked]>
Date: Tue, 3 Nov 2009 08:51:09 -0500

>difference between a "user name" and a "login name"? Which AVPs are

AVP?  My comment has that with radius I can login as one user and
have the radius server return a different user name to use locally,
so I can remotely administer a hundred operators as a single
"operator" local user.  So the permissions may track with the real
user name ("operator") but the login name ("phil") is also vital
information.

>This is pretty much what we have been doing in SMIv2 land.

Cool.  I've seen examples that aren't this way, where the
MIB text documents the leafs, but not their meaning.  An
example would be rfc3412, where in a ~40 page rfc, the mib
is ~3 pages.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Nov 2009 15:22:39 +0100

> user name ("operator") but the login name ("phil") is also vital

Tell me how this works (AVPs are the things RADIUS sends around in the
payload) - or better tell me not, since this would impact ISMS badly.

> example would be rfc3412, where in a ~40 page rfc, the mib

You won't expect TCP objects to document how TCP works, right. The
same logic applies to RFC 3412 and all the other SNMP RFCs.

/js

---

From: Phil Shafer <[email-masked]>
Date: Tue, 3 Nov 2009 09:32:58 -0500

>payload) - or better tell me not, since this would impact ISMS badly.

Look for "JUNOS Configuration" in:

http://www.cymru.com/gillsr/documents/junos-radius-authentication.htm

>same logic applies to RFC 3412 and all the other SNMP RFCs.

No, but I would expect the tcp.yang to fully describe how the tcp
objects work, not just that this leaf has a range of such and the
leaf is a boolean.  Given that we can say:

    description "

Lots of very detailed text.
More detailed text.

";

and:

/*

Some detailed text that needn't be in the description statement.

*/

And given the number of mib implementors that seem to not read the
rfc, just the mib, I'd vote to have all real text live within the
yang module.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 03 Nov 2009 16:04:00 +0100 (CET)

> rfc, just the mib, I'd vote to have all real text live within the

I also agree.  For this particular document, it started out with an
XSD model, and having all the text in the XSD was not very readable.
But now that we moved to YANG, I agree that descriptive text should be
moved into the description clauses.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Nov 2009 16:22:33 +0100

> http://www.cymru.com/gillsr/documents/junos-radius-authentication.htm

That seems to be a Juniper specific thing and given my experience with
IETF Radius folks, they might or might not agree this is good usage of
Radius. RFC 5607 seems the closest in the IETF world as it provides a
Management-Policy-Id - this Management-Policy-Id might be used for
access control decisions. But it is not changing the user identity.
Anyway, this gets us deeply into terminology issues and implementation
details - we will have to go there if we do access control work. Lets
not do it now.

> rfc, just the mib, I'd vote to have all real text live within the

We both agree on the principle - I just disagree with your citation of
RFC 3412 in an attempt to prove me wrong that the SMIv2 practice has
been for a long time to have MIB modules self-contained.

/js

---

From: Phil Shafer <[email-masked]>
Date: Tue, 3 Nov 2009 11:44:47 -0500

Juergen Schoenwaelder writes:
>Radius.

IOS does this also, and this behavior exists for both radius and
tacplus.  I'd be surprised if other vendors do not do this, since
customers don't tend to be flexible on password administration
issues, at least for larger ISPs.

Thanks,
 Phil

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 3 Nov 2009 09:42:46 -0700

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Phil Shafer" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, November 03, 2009 8:22 AM
> Subject: Re: [Netconf] draft-ietf-netconf-monitoring-09 last call comments from js
...
> been for a long time to have MIB modules self-contained.

I agree with Juergen.  Yes, the stuff relevant to management should be
in the MIB module.  However, most RFCs with MIBs describe a system or
protocol that actually *does* something other than just sit around and be
managed, and many of these operational characteristics are not (and should
not) be subject to management control or monitoring.  Such information does
not belong in a MIB module.

Randy

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Sat, 7 Nov 2009 03:42:47 +0100

Hi Juergen,

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

> 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.

> 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.

> I have no clue what this ConfigurationDataStore instance is.

Additionally the sentence is somehow mishapen.

> you require that all management applications have two parsers instead

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

> 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

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Sat, 7 Nov 2009 04:27:31 +0100

Hi Mark,

please find below some additional comments. Some of 
them have been brought up already earlier.

Chapter 1. Introduction

s/adjust their capabilities/adjust their knowledge of
the server's capabilities/

Chapter 1.1. Definition of Terms

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [Key words for use in
   RFCs to Indicate Requirement Levels].

Please use the regular RFC template which says:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14, [RFC2119].

Chapter 2. Data Model to Monitor NETCONF

IIRC we wanted to change "urn:ietf:params:xml:ns:netconf:state" to
"urn:ietf:params:xml:ns:netconf:monitor:", or? The consensus was not 
to have a version number.

Mehmet

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Ersue, 
> Mehmet (NSN - DE/Munich)
> Sent: Friday, October 30, 2009 4:11 PM
> To: [email-masked]
> Subject: Re: [Netconf] WGLC for draft-ietf-netconf-monitoring-09
> 
> 
> Hi All,
> 
> this is a friendly reminder for the WGLC of the 
> draft "NETCONF monitoring draft", which runs 
> until November 2.
> 
> I would like to ask all to give the monitoring 
> draft a chance and send your comments to the 
> NETCONF maillist.
> 
> We are planning to bring the draft in the NETCONF 
> session at IETF 76 to the next stage. So, please 
> help to get it stable.
> 
> Thank you.
> 
> Mehmet
>  
> 
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of ext Ersue, 
> > Mehmet (NSN - DE/Munich)
> > Sent: Tuesday, October 20, 2009 2:36 PM
> > To: [email-masked]
> > Subject: [Netconf] WGLC for draft-ietf-netconf-monitoring-09
> > 
> > 
> > Dear NETCONF WG, 
> > 
> > we had a good discussion on the NETCONF monitoring 
> > draft since the last WGLC in July. 
> > 
> > The draft Mark and Martin submitted solves the issues 
> > raised on the maillist and introduces the YANG model 
> > as normative. The new version of the draft appears to 
> > be stable for a final WGLC before we go one step further. 
> > 
> > All WG members PLEASE REVIEW the draft again and send 
> > your comments to the NETCONF maillist:
> > 
> > http://tools.ietf.org/html/draft-ietf-netconf-monitoring-09
> > 
> > Thank you. 
> > 
> > Mehmet
> >  
> > 
> > > From: [email-masked] 
> > > [mailto:[email-masked]] On Behalf Of ext Mark Scott
> > > Sent: Wednesday, October 14, 2009 7:47 PM
> > > To: [email-masked]
> > > Subject: [Netconf] FW: New Version Notification 
> > > fordraft-ietf-netconf-monitoring-09
> > > 
> > > Hello,
> > > 
> > > A new version (v9) of the NETCONF Monitoring Schema draft has 
> > > been posted.
> > > 
> > > This version addresses mailing list comments received on v8:
> > > - reversion of 'session-type' to 'transport'
> > > - element naming consistency.  All lowerCamelCase names have 
> > > been converted to 'hyphen-delimited' or 
> > > 'netconf-style-naming' as it is sometimes referred to on the 
> > > ML.  E.g.  'sessionType' -> 'session-type'.  This change 
> > > impacts both the draft text and yang module.  
> > > - <get-schema> operation updated:
> > > 	- now has only one mandatory parameter, 'identifier'
> > > 	- updated negative responses, including the rpc 
> > > operation description in yang module
> > > - comments added to the yang module indicating that the 
> > > definition of 'session-id' is consistent with 4741bis 
> > > 'session-id-type' and could be imported from that pending 
> > > RFC.  Similar for 'netconf-datastore-type'.  This was in 
> > > favour of adding further dependencies and delays by waiting 
> > > for 4741bis to complete.
> > >  
> > > Please direct any comments on this version to the mailing list.
> > > 
> > > cheers,
> > > Mark
> > > 
> > > 
> > > From: IETF I-D Submission Tool [mailto:[email-masked]] 
> > > Sent: Wednesday, October 14, 2009 1:22 PM
> > > To: Scott, Mark (CAR:2N00)
> > > Cc: [email-masked]
> > > Subject: New Version Notification for 
> > > draft-ietf-netconf-monitoring-09 
> > > 
> > > 
> > > A new version of I-D, draft-ietf-netconf-monitoring-09.txt 
> > > has been successfuly submitted by Mark Scott and posted to 
> > > the IETF repository.
> > > 
> > > Filename:	 draft-ietf-netconf-monitoring
> > > Revision:	 09
> > > Title:		 NETCONF Monitoring Schema
> > > Creation_date:	 2009-10-14
> > > WG ID:		 netconf
> > > Number_of_pages: 30
> > > 
> > > Abstract:
> > > This document defines a NETCONF data model to be used to 
> monitor the
> > > NETCONF protocol.  The monitoring data model includes information
> > > about NETCONF datastores, sessions, locks and statistics. 
>  This data
> > > facilitates the management of a NETCONF server.  This 
> document also
> > > defines methods for NETCONF clients to discover data models 
> > supported
> > > by a NETCONF server and defines a new NETCONF 
> <get-schema> operation
> > > to retrieve them.
> > >                                                               
> > >                     
> > > 
> > > 
> > > The IETF Secretariat.
> > > 
> > > 
> > > _______________________________________________
> > > Netconf mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/netconf
> > > 
> > _______________________________________________
> > Netconf mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/netconf
> > 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: "Mark Scott" <[email-masked]>
Date: Wed, 11 Nov 2009 11:47:51 -0500

Juergen and Randy,

I can't speak for how many implementers actually read both the RFC and
associated MIBs, but in the YANG module we have included references to
the related RFCs, descriptions of the monitored data, and where required
the behavior (e.g. the rpc definition).

Do you have specific examples of additional text from the RFC which
should be included in the module

Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Randy Presuhn
Sent: Tuesday, November 03, 2009 11:43 AM
To: [email-masked]
Subject: Re: [Netconf] draft-ietf-netconf-monitoring-09 last call
commentsfrom js

Hi -

...

I agree with Juergen.  Yes, the stuff relevant to management should be
in the MIB module.  However, most RFCs with MIBs describe a system or
protocol that actually *does* something other than just sit around and
be
managed, and many of these operational characteristics are not (and
should
not) be subject to management control or monitoring.  Such information
does
not belong in a MIB module.

Randy

---

From: "Mark Scott" <[email-masked]>
Date: Wed, 11 Nov 2009 11:58:49 -0500

Martin,

Related to the reply I posted to Juergen and Randy on this thread:

By descriptive text I assume we mean only the text for each parm in sec
2 specifically.  In which case are we effectively saying that 'see yang
module for details' is sufficient for sec 2?

If not, can someone help me better understand which descriptive text
belongs in the yang module (to augment what is already there) and which
should remain in sec 2 of the RFC?

Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Martin Bjorklund
Sent: Tuesday, November 03, 2009 10:04 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] draft-ietf-netconf-monitoring-09 last call
comments from js

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 11 Nov 2009 21:44:23 +0100 (CET)

> module for details' is sufficient for sec 2?

One option is to remove section 2 and 3, and make sure all details are
moved to the YANG module.

However, it might be nice to keep an overview, like the one in section
2.1.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Nov 2009 23:21:31 +0100

> However, it might be nice to keep an overview, like the one in section

Exactly.

/js

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 12 Nov 2009 11:25:40 +0100

Juergen Schoenwaelder Wednesday, November 11, 2009 11:22 PM
> > However, it might be nice to keep an overview, like the one 

We talked in the session to have the YANG module definition complete and
self-explaining first.
You can have any overview, explaining text or examples in the RFC
chapters.

Mehmet

---

From: "Mark Scott" <[email-masked]>
Date: Thu, 12 Nov 2009 16:01:45 -0500

The content will be moved into the YANG module in the next version.

Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ersue, Mehmet (NSN - DE/Munich)
Sent: Thursday, November 12, 2009 5:26 AM
To: Juergen Schoenwaelder; Martin Bjorklund
Cc: [email-masked]
Subject: Re: [Netconf] draft-ietf-netconf-monitoring-09 last call
commentsfrom js

Mehmet

---

From: "Mark Scott" <[email-masked]>
Date: Mon, 30 Nov 2009 14:59:00 -0500

Juergen,

Thank you for your detailed comments.  v10 addresses these per responses
below and will be posted today.

If I have missed anything or you see further changes required please let
me know.

Mark

Comment 1:
----------
:   [...]  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.

UPDATE:  text has been rewritten in monitoring-10 and have asked Martin
to ensure
4741bis covers this instead

Comment 2:
----------

RESPONSE:  When this was discussed earlier the agreement was to cover
this in 4741bis.  Per last notes I had on this one the intent is to add
something of this nature to 4741bis:

"The agent MUST return the capability-changed error (except safe RPCs
***) unless the session has invoked the
<turn-off-capability-changed-error/>
operation.

*** close-session, kill-session, get-schema,
     turn-off-capability-changed-error, lock, unlock,
     partial-lock, partial-unlock, discard-changes"

With respect to re-synch a client which leaves the error enabled is
expected
to close their existing session and establish a new one when they see
this
error.  This was chosen in favour of putting onus on the server to track
per session schema synch information.  I expect this to be covered in
4741bis.

A client which opts to disable the error has to have its own means to
detect
loss of synch and implement its own method to re-synch.  This will
likely be
implementation specific.

Comment 3:
----------

UPDATE:  Second sentence has been removed.

Comment 4:
----------

UPDATE:  Leftover from earlier versions/intent to include non-NETCONF 
Data (e.g. CLI session data, sysUpTime).  Reworded to be NETCONF
specific.

Comment 5:
----------

UPDATE:  Reference to XSD type in earlier draft.  Replaced with text
Indicating this information is contained in /netconf-state/datastores
list entries.

Comment 6:
----------

UPDATE:  Updated.  Proposing YANG as required and YIN is optional in the
new
Text.

Comment 7:
----------

UPDATE:  Done.

Comment 8:
----------

UPDATE:  Fixed.  It belonged under namespace.

Comment 9:
----------

UPDATE:  Reworded.  References only active sessions now.
   
Comment 10:
----------

UPDATE:  Yes.  Reworded to list.

Comment 11:
----------

UPDATE:  Reworded.

Comment 12:
----------

:   username (string)

RESPONSE:  Valid point to raise.  At present assumption is that
regardless
of underling security and access control a string representation should
be sufficient if an implementation so chooses. It is not mandatory and 
an implementation can choose to omit as appropriate.

Comment 13:
----------

UPDATE:  Ok.  Reworded.

:             module bar {

Comment 14:
----------

             module bar {

:           module bar-types {

           module bar-types {

UPDATE:  Done.

Comment 15:
----------

:  identity transport {
:    description

This should be "Base identity for NETCONF transports.". Please remove
all
mentions of "session types".

UPDATE:  Done.

:    reference "RFC 4742";

Comment 16:
----------

Replace with

:    reference "RFC 4743";

Replace with

:    reference "RFC 4744";

Replace with

:    reference "RFC 5539";

Replace with

Replace with

    reference "W3C REC REC-xmlschema-1-20041028: XML Schema Part 1:
Structure
               W3C REC REC-xmlschema-2-20041028: XML Schema Part 2:
Datatypes";

Replace with

Replace with

UPDATE:  Done.   (thank you for the detailed rewording above.)

Comment 17:
----------

:            list partial-locks {
:              key lock-id;
:              description

UPDATE:  Fixed.  Moved existing description for lock-id and added new
description for the list.

:      list session {
:        key session-id;
:        leaf session-id {
:          type session-id;
:        }
:        leaf transport {
:          mandatory true;
:          type identityref {
:            base transport;
:          }
:        }
:        leaf username  {
:          type string;
:        }
:        leaf source-host {
:          type inet:host;
:        }

Comment 18:
----------

        leaf login-time {
          mandatory true;
          type yang:date-and-time;
          description

UPDATE:  Yang module and section 2 have been merged to make the module
self describing.  I have added description clauses to all elements.
Please
let me know if any are missing and/or are not clear.

Comment 19:
----------

UPDATE:  I've added explanations for each based on comments from the ML
requesting the changes.  Please feel free to comment on any which are
not clearer now.

Comment 20:
----------

RESPONSE:  Leaving as is at this point.  Does anyone else feel strongly
about this one way or the other?

/js