Subject: Re: [Netconf] WGLC: draft-ietf-netconf-with-defaults-02

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 6 Aug 2009 17:55:26 +0200

Hi,

I reviewed the I-D draft-ietf-netconf-with-defaults-03.txt
for WGLC. Please find my comments below.

Abstract
- s/manger/manager/

Ch. 1.  Introduction
- Last paragraph:
I agree their is no explicite statement on default/non-default 
handling in RFC 4741. 
OTOH RFC 4741 says that in case a filter element is not 
defined the "entire configuration" is returned for a 
<get-config> operation.
As a native reader of the standard I interprete this as 
the default behaviour of NETCONF protocol, where both, 
default and non-default data, are returned. 

But the With-default draft assumes the opposite, i.e. the 
default behaviour of the NETCONF protocol is to suppress 
the default data in <rpc-reply> message.

I think we need to align the two documents by choosing 
one of the options:
a) add a clear statement to 4741bis saying that 
"the agent MAY suppress the default data" or
b) address the assumption of a native 4741 reader 
in With-defaults draft I mentioned above.

Ch. 1.1.2. NETCONF Terms

I agree that if the default is '3' and the value is '3', it is 
considered to contain the default, regardless of how it 
was created.

The draft does not specify explicitly set (default) data 
clearly.
How do we handle non-default values which have been 
set explicitely, where the default is '3' but the value is 
_not_ '3' ? Are they suppressed too? 

Ch. 1.2. Current handling of default data

- Change:
   o  explicit: Report values if they are explicitly set.  
       For state data this has the same effect as report-all
to
   o  explicit: Report values if they are explicitly set and 
       match the default.  For state data this has the same 
       effect as report-all

- s/report-all/report-all./

Ch. 2.5. Modifications to Existing Operations

- Enclose the example code in <CODE BEGINS> and 
<CODE ENDS> as a preparation for the code licence 
statement.

Ch. 4. Data Model XSD

- I checked the XSD model for it's validity. The XSD 
model is valid.

- Unfortunately we have still the policy in O&M area to 
use XSD as the normative language for data models.
If we want to publish the With-defaults draft soon I
would suggest to follow the example of Partial Lock 
draft and indicate the XSD as normative. 
To keep them together I would put the XSD schema 
and YANG module into the appendix. 

OTOH if the authors and the WG decide that the 
With-default draft should be published together 
with 4747bis and after the publication of YANG 
we can mark the YAM as normative. In this case 
there is no need for XSD at all.

Change log - 01-02:
says "Placeholder for YAM added, XSD will be 
removed when 4741 provides the NETCONF YAM."

We cannot remove the XSD if this draft gets 
published before YANG becomes normative.

Cheers,
Mehmet 

From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Ersue, Mehmet (NSN - DE/Munich)
Sent: Monday, August 03, 2009 11:42 PM
To: [email-masked]
Subject: [Netconf] WGLC: draft-ietf-netconf-with-defaults-02

Dear NETCONF WG, 
we had a good progress on the draft "With-defaults capability 
for NETCONF". In the NETCONF session at IETF we decided to 
bring the draft to WGLC to initiate additional discussion. 
With this mail we start a WGLC for the "With-defaults capability 
for NETCONF" draft, which is planned to publish as a Proposed 
Standard RFC. The WGLC will run until August 21, 2009. 
Everybody on the NETCONF WG maillist PLEASE REVIEW the 
draft and send your comments to the NETCONF maillist. 
(http://tools.ietf.org/html/draft-ietf-netconf-with-defaults-02) 
Thank you and looking forward for your comments. 
Cheers, 
Mehmet

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 Aug 2009 21:14:54 +0200

> default and non-default data, are returned.

That is _your_ interpretation of what config data is, but there are
other possible interpretations where default values are not part of
the config. In most Unix config files, you do not set the defaults
since they are implicitely there.

> the default data in <rpc-reply> message.

I think it says implementation behaviour is not defined in RFC 4741
and this is why the with-defaults document exists.

> in With-defaults draft I mentioned above.

I assume a) is what we have to in 4741bis.

> considered to contain the default, regardless of how it

This is one interpretation, but not all systems have this
interpretation.

> The draft does not specify explicitly set (default) data

This is the interpretation where 3 is the default value but there was
an explicit management operation to set the value to 3 and thus this
value now becomes part of the config (because it was explicitely set,
not because of the value itself).

> _not_ '3' ? Are they suppressed too?

In this model, everything explicitly set is config data - the value
does not matter. It matters that the value was explicitely set.

We probably need some more text plus an example to describe these
three models more clearly.

/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: "tom.petch" <[email-masked]>
Date: Fri, 7 Aug 2009 19:23:45 +0200

Mehmet

I am not sure that I agree with you suggestion to wrap the example XML in this
I-D with CODE BEGINS and CODE ENDS.  It is not clear to me that this achieves
what is intended.

Code has become a technical, legal term, defining those parts of an I-D that can
be extracted and modified without further permission outside the IETF standards
process, as opposed to requiring special permission from the IETF Trust so to
do.

As RFC5377 s4.3 says,
  "Additionally, the Trustees of the IETF Trust should define a textual
   representation to be included in an IETF Contribution to indicate
   that a portion of the document is considered by the authors (and
   later, the working group, and upon approval, the IETF) to be code and
   thus subject to the permissions granted to use code."

So I see this is nothing to do with an agreement in the IESG; it is a matter for
Balazs and Andy, and perhaps the rest of the Working Group, whether or not they
wish to make such a grant.

While I see it as appropriate to grant such permission for Appendix A and
Section 4, indeed it would by default be so, for myself, I would not grant it
for informal snippets that may or may not have been validated and tested.  So
for me, wrapping up everything that is code-like so as to grant that extra
copyright would be wrong.  But as I say, it is in the first place up to Balazs
and Andy.

Tom Petch

----- Original Message -----
From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, August 06, 2009 5:55 PM
Subject: Re: [Netconf] WGLC: draft-ietf-netconf-with-defaults-02

Hi,

Abstract
- s/manger/manager/

Ch. 1.  Introduction
- Last paragraph:

Ch. 1.1.2. NETCONF Terms

- Change:

Ch. 4. Data Model XSD

Change log - 01-02:

Cheers,
Mehmet

Dear NETCONF WG,

--------------------------------------------------------------------------------

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

---

From: Phil Shafer <[email-masked]>
Date: Fri, 7 Aug 2009 17:33:34 -0400

>I-D with CODE BEGINS and CODE ENDS.  It is not clear to me that this achieves

--BLOCK-BEGINS-- or --DATA-BEGINS--?  XML or YANG isn't really code
anyway.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 8 Aug 2009 08:25:14 +0200

> --BLOCK-BEGINS-- or --DATA-BEGINS--?  XML or YANG isn't really code

I think there are two issues to consider here. The first one is to
add marks so that a generic rfcstrip tool can extract stuff out of
IDs/RFCs - a yangstrip is much harder to do compared to an smistrip.
For that, I once proposed to mark things like this:

== start "foo.yang"

module foo {
  // ...
}

== end "foo.yang"

This would be a simple convention to make it easy to extract stuff out
of IDs. The second thing are copyright considerations and while I am
not a big fan of this kind of affairs, I guess YANG modules need to
carry the appropriate boilerplate text, as we do with MIB modules.  As
a matter of fact, YANG modules will be extracted from RFCs and they
will be shipped as part of larger software systems so it is important
to have the legal words in these extracted fragments that make it
clear that doing so it allowed.

That said, I do not think we need to mark every little example as
code / extractable fragments.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 08 Aug 2009 07:34:53 -0700

> For that, I once proposed to mark things like this:

I like this idea.

> clear that doing so it allowed.

the YANG usage guidelines draft needs to deal with this,
so the rule needs to be clear:

  YANG CODE == a complete [sub]module that NETCONF devices
  are supposed to implement

  YANG example == YANG snippets that are meant to help
  understand the document content

> code / extractable fragments.

agreed

> /js

Andy

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 10 Aug 2009 11:27:14 +0200

> == end "foo.yang"

Having the module name in the marking text is a good idea.
 
> code / extractable fragments.

Agreed.

Mehmet

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 10 Aug 2009 16:27:10 +0200

I agree that it is not necessary to label every small example code as
"CODE".
But it is up to the contributor of the code to decide whether he or she
sees it as worth to license.

Cheers,
Mehmet

> -----Original Message-----
> From: ext tom.petch [mailto:[email-masked]] 
> Sent: Friday, August 07, 2009 7:24 PM
> To: Ersue, Mehmet (NSN - DE/Munich); [email-masked]
> Subject: CODE BEGINS wasRe: [Netconf] WGLC: 
> draft-ietf-netconf-with-defaults-02
> 
> Mehmet
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 10 Aug 2009 10:51:36 -0400

We seem to be mixing two very different kinds of marking in this discussion.

One use of marking is to make it easier for a tool to extract the marked 
material.  Given taht folks using other languages have not had any 
problem with this, I am not sure what the need is.  (I had to extract 
XML Schema and XML content from an I-D for validation.  Reviewers had to 
extract it.  Another participant had to extract it.  The extraction was 
not a problem.)  However, if you really want to mark that, it is the 
WG's priviledge.

Please do not confuse that with the granting of rights for folks to use 
the code.  As defined by the IETF trust, folks can use the YANG code 
from our documents any way they want to.  No marking is needed.
If there is other material that is not YANG, not XML Schema, and not 
ABNF, that folks need to be able to extract, modify, and use, please use 
the trust defined labels <CODE BEGINS> <CODE ENDS> to mark that material.

Yours,
Joel