Subject: [Netconf] new draft charter - Action before Aug 15th

From: Bert Wijnen <[email-masked]>
Date: Wed, 01 Aug 2012 14:37:10 -0700

WG participants, based on our discussions at IETF84,
we  (WG chairs) propose the following new charter text.

Pls comment and let us know your opinion no later than
August 15th (any timezone).

Bert and Mehmet

------ proposed charter as of Augist 1st) ---------

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. The exact title of
      Netconf-Lite can be determined by the WG.

   3. 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.

   4. 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 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 - submit request to AD/IESG to make RFC4743 and 4744 historic
   okt 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242
   nov 2012 - WGLC for Netconf Lite
   nov 2012 - Initial I-D for RFC6241/6242 implementation/deployment experience
   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: "Patrick Gili (pgili)" <[email-masked]>
Date: Wed, 1 Aug 2012 21:49:13 +0000

Hi Bert,

We'd like to see something in the charter regarding work on additional message models. Most importantly, we'd like to see an effort to standardize a NETCONF-like interface that uses REST, such as that proposed by Andy Bierman in draft-bierman-netconf-yang-api-00. However, we would also like to explore the possibility of using XMPP/JSON as a message model.

This also raises the question whether the NETCONF WG should explore partitioning the NETCONF architecture in a manner similar to the architecture introduced with SNMPv3, separating the message processor, access control, RPC processors, and notification processor, increasing the modularity of NETCONF.

Cheers,
Patrick Gili

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bert Wijnen
Sent: Wednesday, August 01, 2012 5:37 PM
To: netconf
Subject: [Netconf] new draft charter - Action before Aug 15th

WG participants, based on our discussions at IETF84, we  (WG chairs) propose the following new charter text.

Pls comment and let us know your opinion no later than August 15th (any timezone).

Bert and Mehmet

------ proposed charter as of Augist 1st) ---------

  Charter

  Current Status: Active

  Chairs:

  Mailing Lists:

Goals and Milestones:

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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 01 Aug 2012 14:51:48 -0700 (PDT)

>      Netconf-Lite can be determined by the WG.

A couple of comments.

 1.  Doing this as a standards track document will be confusing.  Why
     do we have two standards doing almost the same thing?  If we
     really believe this is a useful standard, why not change
     base:1.1?

 2.  The motivation for this work as stated is to be suitable for
     constrained devices.  AFAIK there is one implementation of this,
     and the implementor was not sure that this is the right solution
     for constrained devices.

I wasn't supporting or opposing this work in the meeting, but after
giving it some more thought, I am opposed to doing this.

/martin

---

From: Bert Wijnen <[email-masked]>
Date: Wed, 01 Aug 2012 14:56:06 -0700

>       and the implementor was not sure that this is the right solution

So maybe we should change
                       which can be used e.g. in constrained
      devices or for an incremental deployment.
into
                       which MIGHT be used e.g. in constrained
      devices or for an incremental deployment.
might in lowercase of course, used capitals to show the change.

Bert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Aug 2012 23:56:09 +0200

> August 15th (any timezone).

Do we have to respin RFC 6241 to advance it? I think there is an open
errata. (And if we do more interoperability testing, there might even
be more errata coming along.)

I am concerned that we might leave a confusing impression if we do all
of the below more or less at the same time:

- publish a revision of RFC 6241 to advance it
- publish a competitor to RFC 6241(bis) called NC Lite
- publish an extension (to both?) solving the get operational
  state issue

Perhaps we need to rethink the isolated decision and look at the
overall direction we want to go. And perhaps bundling all the above
into a single revision of RFC 6241 (which later might advance without
a further revision) is overall simpler and less confusing.

/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: Bert Wijnen <[email-masked]>
Date: Wed, 01 Aug 2012 14:57:26 -0700

Understood. But see thesummary of our meeting posted by
Mehmet. We do not have a base document yet that is mature
enough to start our work in this space.

Bert

---

From: Andy Bierman <[email-masked]>
Date: Wed, 1 Aug 2012 14:59:26 -0700

Hi,

I am not objecting to NETCONF Light, but I have some concerns
about this work.
   - the lack of coordination with COMAN
      If this work is for management of constrained devices (as it claims)
      then I do not understand how COMAN can possibly be left out
      of the equation

   - the assumption that a pure subset of NETCONF base:1.1 is the
     correct solution for constrained devices.  The only implementor
     of NETCONF Light says this might not be the best solution.
     I would like to know more about this implementation experience.

  - the new client/old server problem: A client supporting all 3 versions
    of NETCONF needs to be able to connect to a server using the
    "correct" version, using just 1 session attempt.  I don't think base:1.1
    can just be ignored in this new work.

  - wrt/ protocol mechanics there is no difference between calling it
    NETCONF light or base:1.2.  That is pure politics.  If we really need
    to cycle at proposed standard to make the protocol work correctly, then this
   is more important than advancing 6241/6242 at this time

Andy

---

From: Bert Wijnen <[email-masked]>
Date: Wed, 01 Aug 2012 14:59:34 -0700

> a further revision) is overall simpler and less confusing.

I believe we did indeed discuss this in our session, and the outcome
was that the majority of people want to advance 6241/42.

People who were not present and want to state an opinion, by all
means, please do so.

Bert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Aug 2012 00:06:07 +0200

> was that the majority of people want to advance 6241/42.

We took polls on isolated questions and the result in combination
looks, well, to some contributors somewhat surprising or not like a
well thought out plan or whatever your preferred wording is.

/js

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 2 Aug 2012 00:19:56 +0200

We by no means aim to address the management needs of constrained
devices in the Netconf WG.
Netconf-Lite (or whatever you call it) is just for one single purpose,
namely reducing the code size with modular implementations.
We assume that this _could_ be useful for small  devices _or_ for
incremental deployment.

That said I don't think Netconf-Lite is a competition to base 1.1.
If advancing Netconf 1.1 is not an urgent issue my personal suggestion
would be to do it as 1.2.

Mehmet 

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext
> Andy Bierman
> Sent: Wednesday, August 01, 2012 2:59 PM
> To: Bert Wijnen
> Cc: netconf
> Subject: Re: [Netconf] new draft charter - Action before Aug 15th
> 
> Hi,
> 
> >         or:
> >      Archive:
http://www.ietf.org/mail-archive/web/netconf/
> >   done     - Send with-defaults to IESG for consideration as
Proposed
> > Standard
> >   done     - submit NACM document to IESG for consideration as
Proposed
> > Standard
> >   done     - submit NETCONF specific notifications  document to IESG
for
> > consideration as Proposed Standard
> >   okt 2012 - submit rfc5539bis to AD/IESG for consideration as
Proposed
> > Standard
> >   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, 1 Aug 2012 15:29:05 -0700

> We assume that this _could_ be useful for small  devices _or_ for

I find the premise that you can reduce the code size be refactoring
the protocol to be somewhat absurd.  You can take out functionality
and the protocol does less useful things.  Whether this is progress
or not is a subjective matter.

Andy

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Wed, 01 Aug 2012 21:41:08 -0700

Inline

> be more errata coming along.)

Yep we MUST fix any reported/open errata.
But that is allowed as far as I understand the process.

> - publish a competitor to RFC 6241(bis) called NC Lite

That was sort of the rough consensus during the meeting.
That is why we propose in the charter text stds-track.
But we (WG) can at any time decide that we rather see it published
as Experimental as well

> - publish an extension (to both?) solving the get operational
I thought we had tabled that one and are waiting for individual
submission so we can start discussion.

> a further revision) is overall simpler and less confusing.
I have no skin in this. If (as a result of this poll for comments
on the proposed charter text) we see consensus forming on doing your
suggestion... that is fine by me too.

People just need to speak up and express their opinions.

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Wed, 01 Aug 2012 21:46:16 -0700

Inline

>        then I do not understand how COMAN can possibly be left out

It does NOT claim that it will solve all COMAN problems.
It states:

So "which can be used e.g. in constrained devices..."
I have already offered to do s/can/might/
My understanding was that in our session we came to consensus
that it is not our primary goal to address all COMAN requirements.

>       I would like to know more about this implementation experience.
Yep, see above

>      can just be ignored in this new work.
You mentioned that in the NETCONF session. I thought we agreed that
we can work out the details for that once we start the work in the WG.

>     is more important than advancing 6241/6242 at this time

So you switched your opinion too?

Bert

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Wed, 01 Aug 2012 21:48:18 -0700

Inline

> well thought out plan or whatever your preferred wording is.

We showed the overall concept of the new charter text and conceptually
I believe everyone supported that.
But if people want to change their position, then pls do speak up.

Bert

---

From: Andy Bierman <[email-masked]>
Date: Wed, 1 Aug 2012 23:07:40 -0700

> So you switched your opinion too?

Not really.  I want to advance 6241 but it is not as important
as a workable solution for customers.

I need to support tools that implement NETCONF.
IMO the premises supporting NL are seriously flawed.
Customers are not going to care about refactoring the protocol spec.
They will care that the client is way slower now (because copy-config
requires the entire config be retrieved, edited and replaced, or since
there is no filtering the entire config always has to be retrieved and
filtered on the client instead).   The changes proposed for NL
will have a huge negative impact on protocol performance.

Andy

---

From: t.petch <[email-masked]>
Date: Thu, 2 Aug 2012 15:17:13 +0100

----- Original Message -----
From: "Bert Wijnen" <[email-masked]>
To: "netconf" <[email-masked]>
Sent: Wednesday, August 01, 2012 10:59 PM

> was that the majority of people want to advance 6241/42.

I believe that advancement of this, or of most protocols, is an
irrelevant distraction, like changing the number of steps of
advancement.

Most people in this world have no awareness of the status, quite a few
equate I-D to a standard.  Yes, I have heard on IETF lists of a few
organisations which do treat the change in status as material but to me
it seems to be more about the status of those involved:-(

So, an academic issue (unlike producing a better 'base and towers'
model, where the base is suitable for devices that are not multicore,
multiGHz workstations:-)

Tom Petch

---

From: Andy Bierman <[email-masked]>
Date: Thu, 2 Aug 2012 07:47:09 -0700

> model, where the base is suitable for devices that are not multicore,

You know what is not academic?  Interoperability.
IMO, most NETCONF server implementations are
somewhat  broken.  The WG  can ignore artificial standards
classifications if it wants, but advancement requires that
interoperability testing be done -- something the WG has
completely ignored from the start.

We have a core + towers approach now.  Some people think
locking and filtering are much too complicated to implement
so we are going to work on making the core smaller.
Since the general implementation quality is so poor, I am forced
to consider the possibility that we over-reached with NETCONF
and need to lower our expectations (and reduce the mandatory
feature  set).

Andy

---

From: t.petch <[email-masked]>
Date: Thu, 2 Aug 2012 18:31:58 +0100

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Bert Wijnen" <[email-masked]>; "netconf" <[email-masked]>
Sent: Thursday, August 02, 2012 3:47 PM
> completely ignored from the start.

Yes, interoperability is paramount, else we have nothing, but I
am less sure that advancement achieves that, based on the
reports I have seen produced.  Some are good, but many seem
weak.

And, ironically, I seem to recall, early in the days of Netconf, at
Paris,
being impressed by how quickly Netconf had got into
interoperability testing:-)

Tom Petch

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 2 Aug 2012 19:55:55 +0200

Is it the compromise solution to publish N-L and get-oper together in a
6241bis leading to a 1.2?
Sounds a doable way forward to me.

I would appreciate if we can close the very long discussion with such a
solution.

Mehmet 

Behalf Of ext
> Juergen Schoenwaelder
> Sent: Wednesday, August 01, 2012 2:56 PM
> To: Bert Wijnen
> Cc: netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Aug 2012 20:03:00 +0200

> I would appreciate if we can close the very long discussion with such a

It might also be useful to do some interoperability testing so that
any needed fixes or clarifications can be included in a 1.2
version. This may increase the likelihood that we get a 1.2
specification that is good enough for advancement without another
revision.

/js

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 2 Aug 2012 20:09:10 +0200

> specification that is good enough for advancement without another

Sounds perfect to me.

Mehmet

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Thu, 02 Aug 2012 11:13:46 -0700

> specification that is good enough for advancement without another

Interoperability testing can certainly be part of the "advancement" process
as input for the Implementation/Deployment/Interoperability report that
we must provide.

But interoperability testing is not necessarily a WG chartered
activity or obligation. Of course if we as WG chairs can help
to get such an event going, we will do so as much as we can.

Do we want to do this ASAP or at or around the next IETF?
If ASAP, is anyone offering to arrange it at their site/location?
If needed, I think I can arrange space at the RIPE-NCC in
Amsterdam. Let me know if I should investigate.

Bert

---

From: Andy Bierman <[email-masked]>
Date: Thu, 2 Aug 2012 11:32:24 -0700

> Amsterdam. Let me know if I should investigate.

I would be interested in attending.
It might lead to an Implementation Guidelines document.
It seems obvious, but the more complicated and arbitrary
the client request, the less likely the server will implement
it correctly.  (e.g., alter 1 resource at a time works OK but
altering N resources at once is not handled correctly.)

I now think base:1.2 is our least-worst option, especially
if we start working on operational data.  Martin and Juergen
have some good ideas for operational data and it should
be worked on ASAP.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 02 Aug 2012 15:01:39 -0700

> a further revision) is overall simpler and less confusing.

I support the idea of integrating all the above ideas into a revision of 6241. I believe that with a little care it can be done so that existing implementations of 1.1 will have very few problems in adapting to the new version.  

Having two standard track protocols where protocol A has the same functionality as protocol B + several optional capabilities is IMO hardly defensible, to say the least.

Lada   

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 02 Aug 2012 15:36:56 -0700 (PDT)

> I would be interested in attending.

+1

/martin

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 07 Aug 2012 13:23:11 +0200

So, to my offer:

> Amsterdam. Let me know if I should investigate.

I have hear a "yes I am interested" from Andy and from Martin.
Are there any others?

I don't think that organizing ot for just 2 implementations
makes sense... well, they could then visit each other instead
of me organizing it in Amsterdam.

So pls express your potential interest before Aug 15th.
If there is enough interest, then I will investigate possible
options in Amsterdam.

Bert

---

From: Andy Bierman <[email-masked]>
Date: Tue, 7 Aug 2012 06:26:39 -0700

Maybe we can set something up online instead of meeting for a few days
in Amsterdam.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Aug 2012 16:20:45 +0200

> If there is enough interest, then I will investigate possible

We might participate, depending on whether we find enough time to
update our "old" test suite to cover NETCONF 1.1 and some newer data
models.  Jacobs University can also very easily host such an
event. While Bremen is easily reachable from Stockholm and most
European hubs, it might be a bit more inconvenient for people from
other continents.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 7 Aug 2012 07:57:56 -0700

I can not really allocate the travel and time expense for this,
but I can participate online, assuming you will have
Internet access at the test.

You can also just download yuma at any time, (since Aug. 2010):
http://sourceforge.net/projects/yuma/
Install and test all you want.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 7 Aug 2012 09:25:55 -0700

We also have a test suite to validate NETCONF implementations and, of
course, we have a number of NETCONF implementations (JUNOS, IVE, VSE, BX,
plus some device-adapters).

Can we create a matrix of all the tests we'd like to run?  Perhaps we can
start by each of us enumerating our clients and servers, and with which
base versions are supported.  Should we also enumerate which optional
capabilities are supported?

   Name              Type      Base Versions    Comments
   --------------    ------    -------------
-----------------------------
   DMI Test Suite    client    1.0 only         can test any NETCONF
implementation
   Space             client    1.0 only         needs a data model defined
via XSD
   NSM               client    1.0 only         needs a data model defined
via XSD
   Junos             server    1.0 only         data model defined via XSD
   IVE               server    1.0 only         data model defined via XSD
   VSE               server    1.0 only         data model defined via XSD

   BX                server    1.0 only         data model defined via XSD

   VSE               server    1.0 only         data model defined via XSD

   ScreenOS adapter  server    1.0 only         data model defined via XSD
   Trapeze adapter   server    1.0 only         data model defined via XSD

Like Andy, it would be difficult for me to travel for this (unless at IETF
85), but it seems that we should be able to do this online - especially
with Skype video, screen-sharing, and what not...

Thanks,
Kent

---

From: Xiang Li <[email-masked]>
Date: Wed, 08 Aug 2012 09:40:08 -0500

Hi,

> capabilities are supported?

We have a relatively new NETCONF client implementation (NETCONFc) and is 
interested
in such an event. But in my view, right now perhaps it's more important 
to focus on getting
the initial set of IETF standard track YANG modules (ietf-system, 
ietf-interfaces, etc. ) out
the door before such Interoperability testing event.

Our NETCONFc client application implements NETCONF 1.1 and 1.0.

--Xiang Li

---

From: Andy Bierman <[email-masked]>
Date: Wed, 8 Aug 2012 08:22:38 -0700

On Wed, Aug 8, 2012 at 7:40 AM, Xiang Li <[email-masked]> wrote:
> in such an event. But in my view, right now perhaps it's more important to
> focus on getting

It takes vendors awhile to get server implementations of standard modules done.
We can test retrieval of ietf-netconf-monitoring, etc., but it may be awhile
before all servers we want to test support the same configuration module.

Andy

---

From: Matjaz Vrecko <[email-masked]>
Date: Mon, 13 Aug 2012 14:51:51 +0200

Hello Bert,

In MG-SOFT we are also interested. We are more interested in an on-line
interop testing, at least in the first step, which could also lead to a
face-2-face meeting in Bremen, Amsterdam or someplace else.

In MG-SOFT we have various NETCONF and YANG applications and our NETCONF
protocol implementation supports both 1.0 and 1.1.

Best regards for now,

Matjaz

-- 
Matjaz Vrecko
MG-SOFT Corporation, Strma ulica 8, SI-2000 Maribor, Slovenia
Internet: http://www.mg-soft.si/  E-mail: <[email-masked]>
Phone: +386 2 2506565, Fax: +386 2 2506566

---

From: Andy Bierman <[email-masked]>
Date: Mon, 13 Aug 2012 08:13:24 -0700

> But if people want to change their position, then pls do speak up.

I was trying to be accommodating on NETCONF Lite, even though
I don't agree that it will significantly reduce server code size.
I would rather drop the whole thing than spend lots of time
debating which features can be removed and how much server code
will be removable.  I think a tiny constrained device should avoid
SSH, XML, and state-full protocols for configuration management.

I think operational state could be interesting to work on, but
I have not seen any solution proposals, so I don't support
any sort of charter item for that work yet.

The NETCONF over TLS maintenance work is minor and
non-controversial.  I do not object to that work.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 15 Aug 2012 22:17:51 +0200 (CEST)

Hi,

We (tail-f) have a couple of different NETCONF clients, and a NETCONF
server, implementing 1.0 and 1.1.

I would prefer a f2f meeting for the interop, b/c I believe we can
easier discuss interpretations of the text and fix issues in the code
and continue testing if we meet.  If Amsterdam (or Bremen) is
difficult, how about doing the interop say Saturday / Sunday before
the next IETF?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 15 Aug 2012 13:31:10 -0700

> difficult, how about doing the interop say Saturday / Sunday before

That is a good idea, except it might be better Friday/Saturday if
people have IETF (or other I*) meetings on Sunday.  Not sure
how we test servers embedded in networking devices either.

What modules are we testing?  Just published in RFCs?
Not much config=true so far.  I would not blame vendors
for waiting until the new modules are published before
starting any implementations.

Andy

---

From: Xiang Li <[email-masked]>
Date: Wed, 15 Aug 2012 15:43:51 -0500

> difficult, how about doing the interop say Saturday / Sunday before

I like this idea.

--Xiang Li

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Thu, 16 Aug 2012 09:21:46 +0200

So...

Anyone who knows people that can help with arranging a location
in Atlanta, before the Next IETF.
I think the dates would indeed best be Friday and Saturday
2-3 November 2012.

Bert

---

From: Andy Bierman <[email-masked]>
Date: Thu, 16 Aug 2012 07:57:06 -0700

> I think the dates would indeed best be Friday and Saturday

This sort of test event requires some planning.
IMO people should not be required to attend in person
so conference calls (WebEx?) will be needed.

Shipping routers and switches to Atlanta for this test seems extreme,
so vendors should be able to setup servers in a DMZ for testing.
Decent Internet connectivity will be needed (IETF net will not be
ready so have to use hotel wifi).

Mutual NDA is usually required.  The point of the test is to improve
code, not beat up vendors for having bugs.  We can report problem
areas in the RFCs without identifying which implementations had
trouble.

We need to identify 'false interoperability' (e.g., client apps that have been
working for years with various servers by coding workarounds to particular
server bugs.)

If we need to spend a lot of time setting up equipment, then we have to
rent a conf. room that can be locked.  IMO, if we brought some Ethernet
hubs and cables, we could find somewhere to test each day, and not
leave equipment setup.

If we find (after bugfixes) that we have at least 2 independent implementations
of all features, then the discussion about base:1.2 vs. standards advancement
of base:1.1 will get interesting. ;-)

Andy

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 16 Aug 2012 17:54:50 +0200

Hi All, 

it seems that I can book some rooms for November 2-3, 2012 in NSN
Atlanta office at the Glenridge connector NE, which is 12-13 miles away
from Atlanta downtown.
There are hotels nearby, e.g. Courtyard Perimet Ctr Marriott and Holiday
Inn Express (less expensive), The Westin Atlanta North (closest). May be
should organize to book the same hotel to ease the transport.

The meeting rooms AFAIK have beamer, phone and Internet connection via
WLAN. I assume we bring the equipment we need such as notebooks, some
Ethernet hubs and cables, etc.

To get into the building on Saturday I definitely need the concrete name
list some time earlier. So, whether we do such an interop event we
should decide by e.g. October 1, 2012 and people interested should let
me know their full name and affiliation by then privately.

Cheers, 
Mehmet 

Behalf Of ext
> Bert Wijnen (IETF)
> Sent: Thursday, August 16, 2012 9:22 AM
> To: [email-masked]
> Subject: Re: [Netconf] Interoperability Testing - Action before Aug
15th