Subject: [Netconf] Don't make with-defaults explicit mode mandatory

From: Balazs Lengyel <[email-masked]>
Date: Tue, 01 Dec 2009 17:50:40 +0100

Hello,
During the last IETF the question was asked:

Shall we use 3 features/capabilities instead of using parameters for the with-defaults capability?

The proposal accepted by the room in Hiroshima is:

No the current solution is more simple.
No changes will be made to the with-defaults draft due to this issue.

Balazs

---

From: Phil Shafer <[email-masked]>
Date: Tue, 1 Dec 2009 12:17:33 -0500

>No changes will be made to the with-defaults draft due to this issue.

I can't follow the logic here, so maybe I'm missing something.

I don't see why we would want to use a non-YANG construct (like
parameters) when there is a perfect valid YANG construct (like
features) that can be used.  How can this possibly make sense?

Should we use parameters since they are "simple" even though they
are not YANG friendly?  Are we trying to encouraging behaviors that
can't be represented in the YANG module, or to encourage behaviors
that can be modeled in YANG?

Imagine that the MAMAGAMILLIAN working group came to the "YANG
Doctors" mailing list proposing to do this?  Would we encourage it?
Are there any modeling rules in YANG that should be encouraged?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 01 Dec 2009 09:58:16 -0800

> that can be modeled in YANG?

But features cannot distinguish the 'basic' behavior
from the 'additional' behavior, supported by the server.

> Are there any modeling rules in YANG that should be encouraged?

If it weren't for the 'basic' parameter, I would
agree with you on W-D.  I'm sure the YANG Doctors (like the
MIB Doctors) would try to understand all the requirements
of the author(s), and determine if features would be
better than URI parameters, in this case.

>  Phil

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 01 Dec 2009 19:02:21 +0100 (CET)

Phil Shafer <[email-masked]> wrote:
> Balazs Lengyel writes:
> >Shall we use 3 features/capabilities instead of using parameters for the
> >with-defaults c
> >apability?
> features) that can be used.

So we have the 'basic' parameter, which is mandatory and can take
three values, and we have the 'also-supported' parameter, which can
take the extra one or two values, e.g.:

   ?basic=report-all&also-supported=trim,explicit

How would you do this with YANG features?

We would need parameterized features...

/martin

---

From: Phil Shafer <[email-masked]>
Date: Tue, 1 Dec 2009 13:56:59 -0500

>How would you do this with YANG features?

"also supported" translates directly into features.  Basic
can be either three features (basic-trim means your basic
behavior is trim) or as a config=false leafs that describes
the current basic behavior.   Hmmm... so this would be:

    feature report-all { ... }
    feature basic-report-all {
        if-feature report-all;
        description "Basic behavior is report-all";
        ...
    }
    ...

If you can't model this without parameters, does that mean YANG
needs to add parameters?  What would we be saying if another
working group were coming to us with this scenario?  Would we
tell them that YANG can't do what they need?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 01 Dec 2009 11:42:36 -0800

> tell them that YANG can't do what they need?

Your solution doesn't really work because 'report-all'
is not optional, and exactly 1 basic behavior must
be reported by the server, not 0 to 3.

This is not a YANG issue.
The basic W-D server behavior is a NETCONF capability.
I think the use of a capability URI with parameters
is appropriate.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 01 Dec 2009 20:47:02 +0100 (CET)

Phil Shafer <[email-masked]> wrote:
> "also supported" translates directly into features. 

Yes.

> Basic
> behavior is trim)

This could work, but you would still have to have text that says that
exactly one of these basic-* features MUST be supported.

> or as a config=false leafs that describes
> the current basic behavior.

Right; that is always an alternative to using features this way.

> tell them that YANG can't do what they need?

No I don't think we should add parameters now.  Let's put it on the
wish list for yang v2.  We need to put down the pen.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 1 Dec 2009 21:28:37 +0100

> be reported by the server, not 0 to 3.

Can this not be spelled out in the 'description' statement?
 
/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: Andy Bierman <[email-masked]>
Date: Tue, 01 Dec 2009 13:00:42 -0800

> Can this not be spelled out in the 'description' statement?

IMO, that is a hack and not how features were intended
to be used.  It takes 6 features to convey this simple
information to the client.

This is also a server behavior detail at the operation
layer, not the content layer.

The W-D server behavior is also not YANG-specific.
The <with-defaults> leaf added to the 3 RPC operations could
apply to any content, not just YANG content.
So waiting for YANG, and making the W-D extension YANG-only,
would go against the agreed upon charter goals.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 1 Dec 2009 22:09:33 +0100

> apply to any content, not just YANG content.

So you make up an argument against using features in the 4741bis
YANG module?

> would go against the agreed upon charter goals.

Now you are mixing threads. It helps us to stay focused.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 01 Dec 2009 13:23:35 -0800

> So you make up an argument against using features in the 4741bis

Yes. I already implemented the YANG module.
It simply augments the existing RPC functions.
Nothing in ietf-netconf.yang needs to be
touched.  The correct server behavior
is obtained with augment, not if-feature.
The <with-defaults> leaf is not even in the
same namespace as ietf-netconf.yang.

In this specific case, the solution that the
WG has agreed upon all along is the correct one.

> Now you are mixing threads. It helps us to stay focused.

No -- getting rid of the parameters and making
them features would introduce a normative dependency on
YANG.  The advertisement of default processing behavior
is not YANG-specific.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 1 Dec 2009 22:32:20 +0100

> same namespace as ietf-netconf.yang.

I fail to see how this relates to the discussion at hand (which
unfortunately carries a wrong subject line to do a mistake made by
Balasz).
 
> WG has agreed upon all along is the correct one.

I leave the concensus reading to the chairs.

> YANG.  The advertisement of default processing behavior

I guess we talk about two very different things in a thread carrying
a subject line that talks about a third issue.

/js

---

From: Phil Shafer <[email-masked]>
Date: Tue, 1 Dec 2009 16:53:43 -0500

>exactly one of these basic-* features MUST be supported.

This is completely acceptable.

>wish list for yang v2.  We need to put down the pen.

Just to be clear, I do not want to add this feature, but use it to
say that either what we have in YANG is good and useful and we
should be using it, or it's not and we are not done with YANG.  I
am definitely not in the second camp.

We should be solving this problem using the mechanisms defined in
YANG, both to prove that what we have works and to not give a
precedent to other WGs that will say YANG doesn't do what they need
and they are going to use parameters or some other odd non-YANG-ish
construct.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Tue, 1 Dec 2009 16:59:55 -0500

>apply to any content, not just YANG content.

W-D is not YANG-specific, but we are moving toward using YANG as a
modeling language for NETCONF, and W-D should be using YANG for its
data modeling needs.  If YANG isn't good enough for us to use, we
aren't done with it.

And while W-D is not YANG specific, the expectation is that all
future IETF work will use YANG, so using something that cannot be
modeled in YANG works against the interest of both the NETCONF/NETMOD/IETF
community and the pool of implementors that will be adding NETCONF
and YANG to various devices.

IMHO this is a no-brainer and I'm embarrassed that we didn't see
it earlier.

Thanks,
 Phil

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Wed, 02 Dec 2009 13:57:28 +0100

See below for explanation.
It would be good if people could use the PROPER subject line to express
their opinion for consensus forming!

-------- Original Message --------
Subject: 	Re: [Netconf] Don't make with-defaults explicit mode mandatory
Date: 	Tue, 1 Dec 2009 22:32:20 +0100
From: 	Juergen Schoenwaelder <[email-masked]>
Reply-To: 	Juergen Schoenwaelder <[email-masked]>
To: 	Andy Bierman <[email-masked]>
CC: 	[email-masked] <[email-masked]>

> I leave the concensus reading to the chairs.
And we are following the discussions.
Now I think, this IS indeed the incorrect subject line.
The one we want to use is this one:

------ Original Message --------
Subject: 	[Netconf] Use 3 features/capabilities for with-defaults
Date: 	Tue, 01 Dec 2009 17:52:27 +0100
From: 	Balazs Lengyel <[email-masked]>
To: 	netconf mailing list <[email-masked]>

Hello,

Balazs

PS. Sorry for the wrong title in the previous mail

---

From: Andy Bierman <[email-masked]>
Date: Thu, 03 Dec 2009 12:54:03 -0800

> IMHO this is a no-brainer and I'm embarrassed that we didn't see

Using YANG correctly means different things to everybody.

Having some familiarity with MIBs,
my first instinct was to use a data model,
not a hacked-up capability URI.
But people want this info in the <hello>,
so a few simple read-only leafs in the ietf-netconf-monitoring
module is not going to work.

IMO, your proposal is a misuse of YANG feature-stmt.
The appropriate YANG usage (if any) would be to
define a protocol operation (rpc-stmt or data-def-stmt),
not <hello> content.  The <hello> message is not
part of the NETCONF content layer.  We should
maintain proper protocol layering.

BTW, the 'with-defaults' feature in the ietf-with-defaults.yang
is pointless.  The module capability itself already conveys
that information.  Advertising the module, but not the feature,
makes no sense at all.  I'm embarrassed I didn't realize that
from the start.

Andy