Subject: Re: [Netconf] js review of draft-ietf-netconf-with-defaults-08.txt

From: Phil Shafer <[email-masked]>
Date: Thu, 10 Jun 2010 18:02:00 -0400

"t.petch" writes:
>Make that four supporters of the change.

Put me in the "against" column.  The purpose of 4741bis is
to fix issues and make clarifications.  This is clearly
outside that scope.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 11 Jun 2010 10:03:23 +0200

> to fix issues and make clarifications.  This is clearly

How about the new "remove" operation? IMO this operation really changes
the NETCONF vocabulary, so the namespace URI should be changed as well.
In comparison, signalling the base defaults handling in hello is pretty
benign.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Fri, 11 Jun 2010 04:59:33 -0700

> In comparison, signalling the base defaults handling in hello is pretty

IMO, the basic-mode is marginally useful, and not at all critical
information.
The intent of the WG (way back when) was to have create/delete
be picky and merge/replace not be picky wrt/  instances already
existing.

It turns out that using replace as a remove is a really
lame idea and the WG got it wrong in 4741.  IMO,
that makes 'remove' a bugfix not a new feature.

>>  Phil

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 11 Jun 2010 18:09:15 +0200

> that makes 'remove' a bugfix not a new feature.

Don't get me wrong, I think the "remove" operation in a great idea, but
in fact a bigger change than the basic mode signalling. As long as
"delete" and "create" operations stay in the portfolio, I consider the
basic mode signalling a must and bugfix as well.

And yes, I am suggesting a change of XML namespace URI if "remove" makes
it to 4741bis.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Fri, 11 Jun 2010 12:58:57 -0400

>that makes 'remove' a bugfix not a new feature.

Clearly a new operation is a new feature.  I can't see a believable
claim otherwise.

I think we need to be honest with ourselves and admit that this
4741bis work is really about producing "NETCONF 1.1" and stop the
"bugfix" charade.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 11 Jun 2010 10:22:05 -0700

> basic mode signalling a must and bugfix as well.

If the WG agrees that conformance for the basic-mode advertisement
is a MUST and not a SHOULD (current), then the WG has to reverse
the decisions made on the mailing list and at the last IETF.

I don't see that consensus.

One of the disconnects here is that moving the basic-mode
advertisement to a new document changes the conformance
we already agreed on.

Another disconnect is the concept of NETCONF conformance.
It seems to me the requirements are derived from a composite
of all current standards-track NETCONF RFCs.  If we agreed
that a server MUST do X or Y, then any RFC will do.
Coupling the conformance of basic-mode advertisement
to base:1.1 advertisement is not needed for conformance
or URI definition purposes.

> And yes, I am suggesting a change of XML namespace URI if "remove" makes

Yes.  But maybe too late to avoid  that anyway...
We could create a new namespace just for the 1.1 operation attribute,
but that may be more confusing, not less.  Technically, we are no
longer using the XSD that was registered with IANA for the 1.0
XML namespace.  Technically, we are removing and altering some
contents of the 1.0 XML namespace, and the IESG may not like that.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 11 Jun 2010 10:36:12 -0700

> 4741bis work is really about producing "NETCONF 1.1" and stop the

I don't agree it is a charade.
Even a bugfix release needs a new version number.
I want to wrap up 4741bis because we are way
past the point of diminishing returns.  We are not
reaching consensus on the open complex issues,
so it's time to just drop them and publish what we have
already.

We have waited almost a year (2+ IETFs) trying
to summarize the 4741bis issues and see if we can reach consensus
on the list.  The co-authors have tried to get decisions
made, but no issues ever seem to get fully resolved.

At some point, the WG process demands an outcome.
That is up to the co-chairs though.

BTW, what about the new confirmed-commit stuff?
That is a new feature, just as much as a bugfix.
Every new feature is based on operational dissatisfaction
with the current release.  In that sense, our 1.1 release
is no different from any other software product ever made.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 11 Jun 2010 21:41:53 +0200 (CEST)

> And yes, I am suggesting a change of XML namespace URI if "remove" makes

There is no technical requirement for changing the namespace URI.  The
validity of this new value is tied to the base:1.1 capability.  All
old "instance documents" are still valid.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 11 Jun 2010 12:47:29 -0700

> old "instance documents" are still valid.

Really?
What about the XSD we need to define the XML syntax
that YANG does not cover, including the nc:operation
attribute?  Can it have the same targetNamespace as
the RFC 4741 XSD?  I don't think it can.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 11 Jun 2010 22:03:33 +0200 (CEST)

> the RFC 4741 XSD?  I don't think it can.

Why not?  As I wrote, all old instance documents are still valid.
XSD does not have any "upgrade rules" like SMIv2 or YANG.

XSD does have a "version" attribute, which we could use in 4741bis, in
order to make it clear that this is a new version.  But this attribute
has no semantic meaning in XSD.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 11 Jun 2010 13:17:21 -0700

> has no semantic meaning in XSD.

OK -- I was thinking maybe the 'version' attribute is good enough.
The new XSD is not backward-compatible.  Lots of stuff
was removed.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 11 Jun 2010 22:18:34 +0200

> old "instance documents" are still valid.

So when do you want to change the 1.0 in the XML namespace URI?

There is no other indication of the vocabulary version except in the
session hello messages, which creates problems for tools that process
NETCONF stuff offline.

Having the version number in the namespace URI has been considered a bug
by some, so let's make it into a feature.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 11 Jun 2010 22:33:55 +0200 (CEST)

> So when do you want to change the 1.0 in the XML namespace URI?

I don't :)

Note that if we change the namespace URI for <hello>, it will not be
possible to make a server that supports 1.0 and 1.1 at the same time.

> session hello messages, which creates problems for tools that process

I don't know what this would be - a tool that processes NETCONF
*messages* but not part of a NETCONF session?  This is out of scope.

> by some, so let's make it into a feature.

The problems with embedding the version number in the XML namespace
URI is by no means unique for NETCONF.  And yes, I do believe it is a
bug.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 11 Jun 2010 22:52:05 +0200

> URI is by no means unique for NETCONF.  And yes, I do believe it is a

+1

/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: Ladislav Lhotka <[email-masked]>
Date: Mon, 14 Jun 2010 07:22:28 +0200

> > So when do you want to change the 1.0 in the XML namespace URI?

Major changes should lead to changing the NS URI. Of course, adding a
single new operation may not be classified as a major change. Perhaps
some policy in this regard should be stated in 4741bis.

> possible to make a server that supports 1.0 and 1.1 at the same time.

Yes, we discussed this in March, <hello> would have to keep the old
version number. IMO <hello> should have been assigned a NS URI other
than the one used for NETCONF messages, and have it's own versioning.

> URI is by no means unique for NETCONF.  And yes, I do believe it is a

Both approaches have their pros and cons.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C