Subject: [Netconf] draft updated NETCONF WG charter

From: Bert Wijnen <[email-masked]>
Date: Wed, 18 Jul 2012 16:20:03 +0200

Dear WG participants,

Please find below a first draft for a new WG charter.

It takes into account the discussions we have had over
the last half year or so.

Please post your comments/objections/agreements (if at
all possible) before the upcoming IETF mtg in Vancouver.
We can then also further discuss it at that meeting.

Possibly we should also add work on REST-API, but we
believe that needs a bot more discussion first. Maybe we
can add it based on our discussions in Vancouver.

W.r.t. Netconf Lite:
the WG obviously does not want a Netconf 2.0. The analysis of the
discussion as well as the last direct response of WG members is rather
positive than being negative. WG members are in general against 2.0 but
most of them support 1.2 and don't have anything against N-L if the WG
does it. Only a few are against 2.0 or any other change.

Mehmet and Bert

---- draft netconf-charter-2012-jul-18-v2.txt ----------------------

Network Configuration (netconf)
-------------------------------

  Charter

  Current Status: Active

  Chairs:
      Bert Wijnen <[email-masked]>
      Mehmet Ersue <[email-masked]>

  Operations and Management Area Directors:
      Ronald Bonica <[email-masked]>
      Benoit Claise <[email-masked]>

  Operations and Management Area Advisor:
      Benoit Claise <[email-masked]>

  Mailing Lists:
      General Discussion: [email-masked]
      To Subscribe:       [email-masked]
         or:              https://www.ietf.org/mailman/listinfo/netconf
      Archive:            http://www.ietf.org/mail-archive/web/netconf/

Description of Working Group:

   Configuration of networks of devices has become a critical requirement
   for operators in today's highly interoperable networks. Operators from
   large to small have developed their own mechanisms or used vendor
   specific mechanisms to transfer configuration data to and from a
   device, and for examining device state information which may impact
   the configuration. Each of these mechanisms may be different in
   various aspects, such as session establishment, user authentication,
   configuration data exchange, and error responses.

   The NETCONF Working Group has produced a protocol suitable for
   network configuration, with the following characteristics:

   - Provides retrieval mechanisms which can differentiate between
     configuration data and non-configuration data
   - Is extensible enough so that vendors can provide access to all
     configuration data on the device using a single protocol
   - Has a programmatic interface (avoids screen scraping and
     formatting-related changes between releases)
   - Uses an XML-based data representation, that can be easily manipulated
     using non-specialized XML manipulation tools.
   - Supports integration with existing user authentication methods
   - Supports integration with existing configuration database systems
   - Supports multiple (e.g. candidate and running) data-stores to
     optimize configuration preparation and activation
   - Supports network wide configuration transactions (with features such
     as locking and rollback capability)
   - Runs over a secure transport; SSH is mandatory to implement while TLS,
     BEEP, and SOAP are optional transports.
   - Provides support for asynchronous notifications.
   - Supports an Access Control Model and a YANG module for configuring
     the Access Control parameters.
   - Supports a YANG module for System Notifications

   The NETCONF protocol has been designed independent of the data modeling
   language.  The IETF recommends to use YANG as the NETCONF  modeling
   language, which introduces advanced language features for configuration
   management.

   In the current phase of the incremental development of NETCONF the
   workgroup will focus on following items:

   1. Advance NETCONF over TLS to be in-line with NETCONF 1:1.

      This means that RFC5593 needs to be updated.

   2. To enable an implementation with a reduced code-size.

      There seems to be a need for a modular NETCONF solution
      (Netconf-Lite), which can be used e.g. in constrained
      devices or for an incremental deployment.
      The WG will create a document defining the minimal base
      of features for such a standard

   3. RFC5277 (Netconf Event Notifications) was written before the
      YANG modeling language existed. The WG will "YANGify" that
      RFC, so that we have a proper YANG module for the Netconf
      Event Notifications.

   4. Based on the implementation and deployment experience, the WG
      will document the status of NETCONF in order to advance the
      base documents (at least RFC6241 and RFC6242) on the standards
      track.

   5. Since Netconf over BEEP and over SOAP seem not being deployed
      the WG will write a document that makes those 2 protocols
      (RFC4743 and RFC4744) HISTORIC.

Goals and Milestones:
   done     - Send with-defaults to IESG for consideration as Proposed Standard
   done     - WG Last Call on rfc4741bis
   done     - rfc4741bis to IESG for consideration as Proposed Standard
   done     - Send rfc4742bis to IESG for consideration as proposed Standard.
   done     - first WG draft (rev 00) on NACM posted
   done     - first WG draft (rev 00) on NETCONF specific YANG modules posted
   done     - WGLC for NACM document
   done     - WGLC for NETCONF specific notifications document
   done     - submit NACM document to IESG for consideration as Proposed Standard
   done     - submit NETCONF specific notifications  document to IESG for consideration as Proposed Standard
   aug 2012 - submit initial WG draft for rfc5539bis
   aug 2012 - submit initial WG draft for rfc5277bis
   aug 2012 - submit initial WG draft for Netconf Lite
   aug 2012 - submit initial WG draft for making RFC4743 and RFc4744 historic.
   sep 2012 - WGLC for rfc5539bis
   sep 2012 - WGLC for RFC4743 and 4743 to historic
   okt 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed Standard
   okt 2012 - WGLC for rfc5277bis
   okt 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic
   okt 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242
   nov 2012 - Second WGLC for rfc5277bis (if needed)
   nov 2012 - WGLC for Netconf Lite
   nov 2012 - Initial I-D for RFC6241/6242 implementation/deployment experience
   dec 2012 - submit rfc5277bis to AD/IESG for consideration as Proposed Standard
   dec 2012 - submit rfc5277bis to AD/IESG for consideration as Proposed Standard
   jan 2013 - second WGLC for Netconf Lite (if needed)
   jan 2013 - WGLC on RFC6241/6242 document to advance on standards track
   feb 2013 - submit Netconf Lite to AD/IESG for consideration as Proposed Standard
   feb 2013 - submit request to AD/IESG to advance RFC6241/6242 on Standards Track

---

From: Andy Bierman <[email-masked]>
Date: Wed, 18 Jul 2012 07:41:08 -0700

Hi,

I have a few comments about the charter.

I like the way (2) is stated.  This is how customers have stated
the problem to me.

I've looked at (3) and will publish the Yuma YANG modules for this,
except not the <notification> element.  There is no way in YANG
to have an 'anyxml' with a dynamic name (or complexType in XSD).
There is no way to augment the <notification> element, just the event.
This is consistent with rpc-stmt, so it should be OK.

Is the WG going to deprecate RFC 6241 (i.e., create a base:1.2)?
If so, what is the point of advancing 6241 on the standards track?

Andy

On Wed, Jul 18, 2012 at 7:20 AM, Bert Wijnen <[email-masked]> wrote:
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Bert Wijnen <[email-masked]>
Date: Wed, 18 Jul 2012 16:43:46 +0200

> If so, what is the point of advancing 6241 on the standards track?
Depends on how we exactly define Netconf Lite. If it becomes a 1.2
which obsoletes 6241, then sure we cannot advance 6241.

Bert

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 18 Jul 2012 16:54:24 +0200

> which obsoletes 6241, then sure we cannot advance 6241.

My understanding is that Netconf-Lite is not 1.2.

Mehmet

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 Jul 2012 17:01:32 +0200

> My understanding is that Netconf-Lite is not 1.2.

Are you talking as co-chair or as contributor?

/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: Wed, 18 Jul 2012 08:08:22 -0700

> My understanding is that Netconf-Lite is not 1.2.

Good.  It's time to advance base:1.1 to DS.
I agree with Phil that deploying 1.1 should be the main goal.

<btw>
It may not be possible to cleanly keep base:1.1 and netconf-lite
completely separate.  Since session startup is so expensive in SSH,
we really do not want to make updated clients connect twice to talk
to a lite server.  E.g., send a <hello> with base:1.0 and base:1.1,
have the server drop the session, then retry with the netconf-lite <hello>.
</btw>

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 18 Jul 2012 08:13:34 -0700

> Good.  It's time to advance base:1.1 to DS.

oops -- there is no Draft Standard anymore right?
(I have to pay more attention to the ietf list.)
So we would have to meet the 'widely deployed' criteria?
I don't think we are there yet.

Can somebody clarify what the WG needs to do to advance base:1.1
in the new standards track?

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 Jul 2012 17:44:33 +0200

> in the new standards track?

I suggest RFC 6410, in particular section 2.2.

/js

---

From: Bert Wijnen <[email-masked]>
Date: Wed, 18 Jul 2012 17:48:44 +0200

On 7/18/12 5:44 PM, Juergen Schoenwaelder wrote:
> \

Right. It says:
    (1) There are at least two independent interoperating implementations
        with widespread deployment and successful operational experience.

    (2) There are no errata against the specification that would cause a
        new implementation to fail to interoperate with deployed ones.

    (3) There are no unused features in the specification that greatly
        increase implementation complexity.

    (4) If the technology required to implement the specification
        requires patented or otherwise controlled technology, then the
        set of implementations must demonstrate at least two independent,
        separate and successful uses of the licensing process.

We may have a hard time proving "widespread deployment".
Other than that? I think we're fine. So... do we believe we
have "widespread deployment"? The term is not defined explicitly,
so I take it as something that is subjective.

I would say that netconf is as widely deployed as some features of
SNMPv3. But that is just my opinion.

bert

---

From: Andy Bierman <[email-masked]>
Date: Wed, 18 Jul 2012 09:16:00 -0700

>        separate and successful uses of the licensing process.

OK -- I remember reading all this in I-D form.
I would say that we might meet all these requirements by now.
Between ncclient, yuma, and tail-f products there are
multiple servers working with multiple clients.

I think we would still need to document an actual interoperability test,
like we used to do for SNMP, RMON, etc.

> We may have a hard time proving "widespread deployment".

You WG chairs can beg and plead for companies to send implementation
reports (like the old days).   Most will ignore you, but a few might
respond. ;-)

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 18 Jul 2012 22:48:08 +0200 (CEST)

Hi,

> does it. Only a few are against 2.0 or any other change.

Mehmet then wrote:

Juergen's original proposal was a separate protocol, not even NETCONF
1.2, which I believe is what Mehmet is also suggesting.  But this
seems to contradict what Bert wrote above.

Personally, I do not think that NETCONF light is top prio, but if we
do it, I would rather see it as a separate protocol, than 1.2 or 2.0
of NETCONF.

>      RFC, so that we have a proper YANG module for the Netconf

Do we have to be on-the-wire compatible with 5277?  I.e., should the
charter be explicit about this - either state that we must be
compatible, or say that we don't have to be.

5277 defines the unfortunate "netconf" container in the namespace
"urn:ietf:params:xml:ns:netmod:notification".  The standard
notifications "replayComplete" and "notificationComplate" are also
defined in this namespace.  Not to be confused with the namespace
"urn:ietf:params:xml:ns:netconf:notification:1.0" which defines the
operation "createSubscription"!

I also think that Andy's ideas around configuration of streams would
be interesting to look at.  (this probably needs more time though)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 18 Jul 2012 14:06:35 -0700

> do it, I would rather see it as a separate protocol, than 1.2 or 2.0

Agreed

> be interesting to look at.  (this probably needs more time though)

There seems to be a lower bound on completion time in the IETF,
like minimum packet size.  You might as well fill the packet if
it's going to take the same amount of time either way. ;-)

I prefer not to open any existing RFC unless we are prepared to
improve it based on deployment experience.  I prefer not to
decide it advance the exact sections of text that might change,
or if a notification:1.1 capability is needed, etc.

Andy

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Thu, 19 Jul 2012 09:08:48 +0200

Inline

> seems to contradict what Bert wrote above.

Separate is fine by me too. And that would nicely allow us to possinly
advance rfc6241/42

> be interesting to look at.  (this probably needs more time though)

We (WG chairs) would like to hear opinions on what kind of things we
want to change if we indeed do open up 5277. If it is more than
YANGifying, then maybe our usggested milestones for this item are
a bit too aggressive.

Bert

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 19 Jul 2012 12:57:21 +0200

> > seems to contradict what Bert wrote above.

As a co-chair and contributor I differentiate between Netconf-Lite and
1.2. IOW somebody who wants Netconf-Lite to be equally the same as 1.2,
needs to state this explicitly. 
The description above is as difficult as the long discussion on the
maillist was. Different persons have seen different overlapping between
the acronyms 2.0, 1.2, 1.1 and N-L.

At the end of the day we need to proceed. So I fully agree with and
support the advancement of 1.1. If the WG approves the charter proposal
we can do Netconf-Lite too.

BTW: I assume we also need to care bullet (4) in section 2.2. of 6410.
http://www.ietf.org/mail-archive/web/netconf/current/msg07621.html 

Mehmet

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 Jul 2012 04:11:25 -0700

> http://www.ietf.org/mail-archive/web/netconf/current/msg07621.html

Does anybody know what this patent claims to cover?
What part of NETCONF does Huawei claim to have invented?

Andy

---

From: Kent Watsen <[email-masked]>
Date: Thu, 19 Jul 2012 13:49:58 -0700

>What part of NETCONF does Huawei claim to have invented?

The email linked to https://datatracker.ietf.org/ipr/1800/ which states
that the patent is "CN200910176679 and the counterpart applications
PCT/CN2010/075102, US 13/428659 and EP10818328.6".  Being in the US, I
googled the US number and found it here:
http://www.freepatentsonline.com/y2012/0179795.html

>From the "Background of the invention" section:

"In the prior art, if the user modifies the configuration of the
confirmed-commit operation, the candidate configuration database of the
current confirmed-commit operation will be discarded, and the telecom
device performs confirmed-commit operation again according to the
configuration information resent by the user until the user's requirements
are met. The method in the prior art requires the user to perform
configuration again, with complicated operations and low efficiency.
Moreover, the user commits a configuration of current confirmed-commit
operation to be effect, and performs a next modification to the
configuration, the current operation of the service will be impacted."

Also note this from the IPR:

"If any claim of any patent owned or controlled by Huawei or its
Affiliates is essential on a technical ground to the specification adopted
by IETF, Huawei on behalf of itself and its Affiliates hereby covenant not
to assert any such claim against any party for making, using, selling,
offering for sale or importing a product that implements the corresponding
part of the specification. However, nothing herein shall preclude Huawei
or any of its Affiliates from asserting the above mentioned patent claims
against any party that asserts directly or indirectly a patent it owns or
controls against Huawei and/or its Affiliates, or against any products of
Huawei or its Affiliates either alone or in combination with other
products.
FRAND royalty-bearing licenses will be available to anyone who prefers
that option."

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Fri, 20 Jul 2012 09:21:39 +0200

So (but I am not a lawyer) this seems to tell me that you can
freely implement/use this technology as long as you do not
assert any (any I guess means in any context, so also context outside
netconf)patent claims against Huawei.

Oh well... I guess that if 2 of our implementations/deployments
are no holding any patent assertions against Huawei, then we have met
the rfc6410 requirements, no?

Bert

---

From: Kent Watsen <[email-masked]>
Date: Fri, 20 Jul 2012 08:53:34 -0700

AFAIK, that is correct (disclaimer: I'm also not a lawyer)

Juniper also submits IPR claims for drafts, as IETF requests this of
submitters (e.g. I directed my company to submit one for the Reverse SSH
draft).  In this case, Huawei didn't submit anything (at least, not yet),
but they went ahead and filed the IPR, enabling the WG to consider
incorporating their invention in a future update to NETCONF, which is
pretty cool of them I think.

Thanks,
Kent