Subject: Re: [Netconf] comments on monitoring-08 draft

From: Andy Bierman <[email-masked]>
Date: Thu, 01 Oct 2009 06:02:38 -0700

Martin Bjorklund wrote:
> Andy Bierman <[email-masked]> wrote:
>> Hi,
>>
>> I noticed that the 'transport' identity was replaced
>> with a 'session-type' identity, and now the
>> /sessions/session/transport leaf
>> has been changed to a session-type leaf.  Yet no new
>> standard identities were added, and no semantics were
>> altered.
> 
> Right, this was just a name change of the identity.
> 
>> I object to this gratuitous incompatible change with -07.
>> It looks like some tweaks to support proprietary data models.
> 
> I don't understand how changing the name of a data type is a tweak for
> proprietary data models.
> 

Why was it changed at all?
The leaf changed names, not just the data type.

> The only reason we changed this name was that the old name,
> 'transport' has too many connotations.  In NETCONF, SSH is a
> transport, but for the purpose of this document we say that
> netconf-ssh is a session-type.

I can't find any discussion in the ML archive on this
topic.  Since all changes are this point are made
through WGLC resolution procedures,  I assume there was
a request to make this change, which was supported on
the mailing list and confirmed by one of the co-Chairs.

I can't find any of that email.
It looks like you just decided to change the
name of the identity and the leaf that uses it,
on your own.

We use the term "transport" in our NETCONF layer cake
diagram.  The term "session type" is nowhere to be found
in any of our RFCs or I-Ds.  The enums exactly match the
list of transports available for NETCONF.

> 
>> IMO, the vendor should augment the entry with a different leaf.
>> I really want to know the transport, not some meaningless
>> 'session type' that happens to look like a transport type.
>>
>> Also, I thought we were going to make the get-schema/input/version
>> parameter optional, and add a default=YANG to the format
>> parameter.
> 
> I agree with you.
> 

I never saw 1 objection to making this change.
Again, where is the email documenting the co-Chairs decision
to exclude this change?

>> Instead the /sessions/session/loginTime was
>> changed to mandatory.
> 
> Do you think it should be mandatory false?  If so, why?  Should any
> other leaf be mandatory true?
> 

this leaf is fine as mandatory.

> /martin

Andy

---

From: "Mark Scott" <[email-masked]>
Date: Thu, 1 Oct 2009 14:32:41 -0400

Andy,

A rationale for not modifying the mandatory parameters in <get-schema>
was posted to the ML on Sept 16th.

I suspect you missed that based on the comment below so I am repeating
it here for further discussion:

	"2.  <get-schema> mandatory parameters:  Initially <identifier>
was the only mandatory parameter in the <get-schema> operation, however
after we agreed to expand the key definition in the schema list we made
<version> and <format> mandatory parameters in the operation.  My
preference would be to keep this alignment between the key and
<get-schema> mandatory parms.  I agree in cases where only 1 revision
and/or 1 format exists this is heavy-handed but it protects against
agents returning schema a manager may not have intended since
<identifier> is not unique in schema list and the logic on agent to
select the default revision may differ from what the manager would have
selected (esp. if more than 1 version exists)."

Previously no one else had objected to these being mandatory parameters
and no ML consensus had been reached to modify it.

I have changed the subject header of this email in an attempt to
initiate a ML discussion and will update the draft based on consensus.

Mark

---

From: Andy Bierman <[email-masked]>
Date: Thu, 01 Oct 2009 17:13:08 -0700

> and no ML consensus had been reached to modify it.

I don't understand why the <get-schema> RPC
is coupled to the /netconf-state/schemas data structure.

Revisions are optional in YANG.  A valid module
can exist without a <version>.  This module forces
a YANG module to use the empty string as the
version, which is somewhat of a hack.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 01 Oct 2009 17:21:58 -0700

> Right, this was just a name change of the identity.

No it was not:

     leaf session-type {
          mandatory true;
          type identityref {
            base session-type;
          }
     }

The enum choices are:

   netconf-ssh
   netconf-soap-over-beep
   netconf-soap-over-https
   netconf-beep
   netconf-tls

These match the transport mappings for NETCONF.
In all the NETCONF RFCs, these are called transport mappings,
not session types.

I object to this change -- this entire change should be
removed, and the -07 text should be restored.

Andy

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 2 Oct 2009 12:05:46 +0200

Hi Mark, Andy,

it is common practice that during WGLC or later in the 
process that the document editor does not do changes 
without without making sure that such a change is 
supported by the WG (and the co-chairs). Our goal at 
this late stage should be to finalize the document text.

I would suggest to start a new discussion if you 
strongly believe the change is necessary.
Otherwise my proposal as a co-chair would be to redo 
the change for "transport" vs. "session-type" even 
though it was well-meant.

Cheers,
Mehmet

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Andy Bierman
> Sent: Friday, October 02, 2009 2:22 AM
> To: Martin Bjorklund
> Cc: [email-masked]
> Subject: Re: [Netconf] comments on monitoring-08 draft
> 
> Martin Bjorklund wrote:
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 2 Oct 2009 12:16:44 +0200

Hi Mark, Andy, 

modifying the the mandatory parameters in <get-schema> 
has been proposed earlier in September. There were no 
arguments against it at that time.

In the sake of progress I would like to ask you to try 
to converge on a solution.
OTHERS: PLEASE speak up if you agree or disagree with 
any points made by either Mark or Andy.

It would be good if we can bring this to a conclusion 
and the draft one step further soon.

Cheers,
Mehmet

> Sent: Friday, October 02, 2009 2:13 AM
> To: Mark Scott
> Cc: [email-masked]
> Subject: Re: [Netconf] [NETCONF] <get-schema> mandatory parms 
> discussion
> 
> Mark Scott wrote:
> > Andy,
> >

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 02 Oct 2009 12:22:30 +0200 (CEST)

> any points made by either Mark or Andy.

I agree with Andy, i.e. <format> and <version> should be optional.  I
think Mark's concern that the client might get a schema it didn't
intended is covered by saying that if there are more than one schema
with the given <identifier>, an error is returned.  In this case the
client must give all parameters.

/martin

---

From: Mark Ellison <[email-masked]>
Date: Fri, 2 Oct 2009 09:21:16 -0400

> any points made by either Mark or Andy.

I do think the important aspect to a client would be the ability to
use <get-schema> to retrieve the actual set of schemata in use by a
server.  I do not think it should be necessary for a client to know a
priori, or derive from the capabilities present in the server <hello>,
the name and revision of each schema/YANG module.

When would a server actually have two revisions of the same schema
module in concurrent use?  As long as the revision information is part
of the retrieved schema and a server implements at most one revision
of a schema, then I see no value in having a client ask for a schema
by name and revision.

If the name+revision of each schema does not appear in the server
<hello>, then maybe there could be a <list-schema> operation to get a
list of name+revision of each schema utilized by a server and then it
would be up to the client to get desired schemata from the retrieved
list.

As an alternative to a <list-schema> operation, there could be a state
data node containing this information, similar to the intent of the
SNMPv2-MIB sysORTable.

> and the draft one step further soon.

Just my attempt to be helpful.

Regards,

Mark

---

From: Andy Bierman <[email-masked]>
Date: Fri, 02 Oct 2009 08:02:20 -0700

> would be up to the client to get desired schemata from the retrieved

The operative word is 'if'.
I'm sure these corner-cases are obvious to everyone,
but I'll list them anyway:

 * The module name may appear in a deviation and not
   appear in its own module capability.
 * A module 'A' can import 'B' without giving its revision,
   and there is no module capability for 'B'.
 * A submodule can be included without a revision date,
   and there is no module capability for the sub-module
   (this is not even supported in <hello>, let alone optional).
 * A module may not even have a revision.

> data node containing this information, similar to the intent of the

there is already <get select="/netconf-state/schemas"/>

no need for a special <get> operation

Andy

---

From: Mark Ellison <[email-masked]>
Date: Fri, 2 Oct 2009 12:53:53 -0400

> Mark Ellison wrote:

[deletions]

> no need for a special <get> operation

Thanks for pointing this out to me.  I'll take a 'my bad' on this for
not having read through the netconf-monitoring draft prior to
articulating my thoughts.

[deletions]

Regards,

Mark

---

From: "Mark Scott" <[email-masked]>
Date: Mon, 5 Oct 2009 17:09:07 -0400

All,

The definition will be reverted to the -07 version per Andy's earlier
suggestion.

Mark

-----Original Message-----
From: Ersue, Mehmet (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Friday, October 02, 2009 6:06 AM
To: ext Andy Bierman; Scott, Mark (CAR:2N00)
Cc: [email-masked]; Martin Bjorklund
Subject: RE: [Netconf] comments on monitoring-08 draft

Hi Mark, Andy,

Cheers,
Mehmet

---

From: "Mark Scott" <[email-masked]>
Date: Mon, 5 Oct 2009 17:19:59 -0400

Martin and Andy,

Agreed we can make <format> and <version> optional so long as the server
returns an error if more than one entry exists with the same
<identifier>.

The revised <get-schema> negative responses (sec 3.1) proposed:
	If requested schema does not exist, the <error-tag> is
'invalid-value'.
	If requested schema is not unique, the <error-tag> is
'operation-failed' and the <error-app-tag> is 'data-not-unique'.

Default <format> of YANG is also specified in sec 3.1, and example 2b is
updated to show default of YANG when format not specified.

and the revised RPC definition proposed:
	rpc get-schema {
	    description
      	  "When the schema is available on the device this operation is
	         used to return it via NETCONF.  If requested schema
does not exist,
               the <error-tag> is 'invalid-value'.  If requested schema
is not unique,
               the <error-tag> is 'operation-failed' and the
<error-app-tag> is
		   'data-not-unique'.";
	    input {
	      leaf identifier {
      	  type string;
	        mandatory true;
	      }
      	leaf version {
	        type string;
	      }
      	leaf format {
	        type identityref {
      	    base schema-format;
	        }
	      }
	    }
	    output {
	      anyxml data {
	        description "Contains the schema content.";
	      }
	    }

These updates will be made in v-09 update.  Any comments or concerns
please raise them.  

cheers,
Mark

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Friday, October 02, 2009 6:23 AM
To: [email-masked]
Cc: [email-masked]; Scott, Mark (CAR:2N00); [email-masked]
Subject: Re: [Netconf] [NETCONF] <get-schema> mandatory parms discussion

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 05 Oct 2009 15:04:52 -0700

> returns an error if more than one entry exists with the same

IMO, if <version> is empty, then the server needs to pick a version.
It SHOULD be the most recent version (perhaps MUST).

The module itself will indicate the revision, if the client
really cares.

The operator may not know the revision, or really care.

I prefer text that says:

  If the version parameter is missing, and the /netconf-state/schemas/schema
  list contains more than one entry for a specific identifier
  value, then the server SHOULD return the more recent version.

This is better for servers that will just have the most
recent version of accessible modules, and rarely have more
than 1 version of a groupings/typedefs module.

Andy

---

From: WashamFan <[email-masked]>
Date: Tue, 06 Oct 2009 22:01:54 +0800

> It SHOULD be the most recent version (perhaps MUST).

Or the version the server supports? Did you imply
no "data-not-unique" error is returned when the parameters are 
missing, instead, the server will use defaults when the parameters
are missing?

washam

---

From: Andy Bierman <[email-masked]>
Date: Tue, 06 Oct 2009 07:36:36 -0700

> missing, instead, the server will use defaults when the parameters

Of course the server only returns revisions that it supports.
It would return the most recent revision date of the schema list
entries it has in its /netconf-state/schemas subtree.

Andy