Subject: [Netconf] Summary of the NETCONF Session at IETF 87

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 1 Aug 2013 09:16:08 +0000

Dear NETCONF WG,

below is a summary and action items from the NETCONF WG session on July 31, 2013 in Berlin, Germany. The agenda is available at: http://www.ietf.org/proceedings/87/agenda/agenda-87-netconf

- We had approx. 51 participants in the 2 hour NETCONF session,
- We reviewed the status of the WG,
- We went through the chartered WG items and had a discussion also on three non-chartered documents.
- Note takers were: Lada Lhotka and Robert Varga. The Jabber scribe was Peter Saint-Andre.

Status of the documents (http://www.ietf.org/proceedings/87/slides/slides-87-netconf-6.ppt):
NETCONF Over TLS - RFC 5539bis has been updated addressing the issues and the call-home mechanism.
Reverse SSH addressing the call-home mechanism has been adopted as WG item. Long discussion on the maillist on security.

Juergen Schoenwaelder on NETCONF Over TLS: Module update can cause consistency issues if the base module gets updated repeatedly partly. To solve the issue replacing the base module for an update has been proposed. Community poll: 9 in favor, 5 against. AI: Check on the maillist.
Option 3 for swapping the roles on slide 5 (http://www.ietf.org/proceedings/87/slides/slides-87-netconf-7.pdf), i.e. swapping directly after establishing the TCP connection, has been supported by the security experts in the room.
Juergen will specify the 3rd option and the session discussion will be verified on the maillist. A security review is needed and will be initiated once the draft is ready. Juergen will further discuss potential security issues with TLS experts. The solution seems to be a generic solution but only for network management scenarios. Next step is WGLC and TLS WG review.

Andy Bierman on YANG API: Concerning the notifications we need to understand the need and the possible solutions. Kent Watsen is going to co-author. The community had already showed interest in diverse meetings. Once we have a new draft available we can start discussing officially how to adopt. (http://www.ietf.org/proceedings/87/slides/slides-87-netconf-0.pdf)

Kent Watsen on Reverse Secure Shell: It was very useful that the security experts for SSH were in the room. It has been stated that the configuration of the NMS should be also mandatory. Issues to solve are authentication, initial secure state, validating the host key, identification and Zero-configuration. The latter has been seen as essentially important and should be done in a separate draft. Steve Hanna volunteered to work on this together with Kent. Manuel configuration will be done in the Reverse SSH draft.
Steve Hanna will further provide a draft on the applicability statement for the TLS and SSH solutions.
Kent will update the draft based on the session discussion and provide the draft update for discussion and get comments of the security experts.
Based on show-hands there is a huge interest to proceed with this draft as discussed in the session.

Tal Mizrahi on Time Capability in NETCONF: The time capability allows a time-triggered configuration. Show-hands showed no hands in favor or opposed. The draft should be taken again to the maillist for discussion.

Robert Varga on Efficient XML Interchange Capability for NETCONF: 12 attendees were in favor and nobody against. As the WG cannot re-charter right now the document should be further discussed and updated.

Shouchuan Yang on NETCONF rpc-error extension: There were 2 persons in favor and 6 against. The draft should be further discussed on the maillist to win peoples interest.

Cheers,
Mehmet

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 1 Aug 2013 13:23:50 +0200

> Juergen Schoenwaelder on NETCONF Over TLS: Module update can cause consistency issues if the base module gets updated repeatedly partly. To solve the issue replacing the base module for an update h…

I think this is not stated well - there is no consistency issue in
both options. Let me try to restate it in a neutral way:

  The WG discussed the usage of submodules and a single namespace for
  NETCONF configuration YANG models (current I-D) or the usage of
  separate modules with different namespaces. Community poll: 9 in
  favor of separate modules with different namespaces, 5 in favor
  of submodules with a single namespace. AI: Check on the maillist.

/js

PS: I love to have this recorded clearly so that later I can point
    to this. ;-)

-- 
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: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 2 Aug 2013 14:40:32 +0000

Hi Juergen,

the chairs agree with your correction.

There is also a very short version available on the OPS Wiki provided to Benoit as input for the IESG meeting:
http://trac.tools.ietf.org/area/ops/trac/wiki/IETF87summary

Cheers, 
Mehmet 

> -----Original Message-----
> From: ext Juergen Schoenwaelder [mailto:[email-masked]]
> Sent: Thursday, August 01, 2013 1:24 PM
> To: Ersue, Mehmet (NSN - DE/Munich)
> Cc: NETCONF
> Subject: Re: [Netconf] Summary of the NETCONF Session at IETF 87
> 
> > Juergen Schoenwaelder on NETCONF Over TLS: Module update can cause
> consistency issues if the base module gets updated repeatedly partly. To solve the
> issue replacing the base module for an update has been proposed. Community poll: 9
> in favor, 5 against. AI: Check on the maillist.
>

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 03 Aug 2013 22:49:19 +0200 (CEST)

Hi,

Juergen Schoenwaelder <[email-masked]> wrote:
> > consistency issues if the base module gets updated repeatedly
> > partly. To solve the issue replacing the base module for an update has
> > been proposed. Community poll: 9 in favor, 5 against. AI: Check on the
> > maillist.
> 

Listening to the audio recording of the meeting, this is not what I
heard.  The discussion was about the method of updating a previous RFC
whenever the main module is revisioned.  5 was in favor of this, and 9
opposed.

But I did not hear any vote (or discussion) about the alternative
using separate modules (and different namespaces).  Andy expressed the
opinion that in order to use submodules, we'd have to obsolete the
previous RFC and re-publish the old submodules whenever the main
module is updated.

I can see at least two alternatives to this approach:

  1.  Keep the design with submodules, but publish the main module in
      its own RFC.  When a new submodule is added, the main-module-rfc
      gets re-published, (obsoletes the old one).

  2.  Keep the design with submodules, but let IANA maintain the main
      module.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 5 Aug 2013 17:31:19 +0200

Hello Martin,
I missed the original discussion, sorry, but what advantages do we get 
by using submodules instead of separate modules?
(With modules you at least do not have to republish the main module.)
regards Balazs

On 2013-08-03 22:49, Martin Bjorklund wrote:
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 5 Aug 2013 19:38:20 +0200

On Mon, Aug 05, 2013 at 05:31:19PM +0200, Balazs Lengyel wrote:
> Hello Martin,
> I missed the original discussion, sorry, but what advantages do we
> get by using submodules instead of separate modules?

A consistent namespace, i.e. all NETCONF configuration objects in one
namespace.

The IETF sometimes partitions work in ways that reflect the timeline
of how things are done mixed with a bit of procedural aspects.  The
question is to what extend we want to expose that to the users of the
data models.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 7 Aug 2013 06:59:04 -0700

> question is to what extend we want to expose that to the users of the

So what is the resolution to this issue?
It seems to me 9 people did not like the new changes
and 5 people did like them.

The module construction should go back to the way it was
before (without submodules).  It turns out that the
normative reference to the RFC with the /netconf root
is unavoidable (either via include-stmt or augment-stmt).

So we should just publish 1 YANG module and if there
is ever another NETCONF configuration feature added,
it will be in a new RFC that augments the RFC with the
/netconf root.

The WG did not actually discuss what 9 - 5 meant,
or the followup action items for the next draft.
I guess that is supposed to happen on the mailing list.

> /js

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 7 Aug 2013 16:17:58 +0200

> I guess that is supposed to happen on the mailing list.

I was among the nine, and my understanding was that I was expressing support to the statement that whenever a submodule changes, the revision of the main module has to be advanced, too.

A practical guideline could be that the main module and all its submodules should be always published as a single RFC.

Lada 

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

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Wed, 07 Aug 2013 16:53:06 +0200

If I see:
4.1.  Module 'ietf-netconf-config'

    <CODE BEGINS> file "[email-masked]"

    module ietf-netconf-config {

      namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-config";
      prefix "ncconf";

      include ietf-netconf-common {
        revision-date 2013-05-07;
      }

      include ietf-netconf-tls {
        revision-date 2013-05-07;
      }
Then to me that means that:
- if a submodule gets updated, then it seems to me that the above needs to
   be updated too in order to include the proper revision date of
   the updated submodule.
   And so that would mean the whole RFC gets updated (or in
   principle) I guess the new one would obsolete the old one.

So what is the problem with that?

I asked the question that got 9-5 result, and what I believe I asked
(I would have to go back to the audio recording to be 100% sure) is

- who can live with (or agrees with) that updating/obsoleteing the whole
   RFC if a submodule changes (9 hands)
- who objects (5 hands).

If I get statements of disagreement on the above, then I will go
back and listen to the audio,

Bert

---

From: Andy Bierman <[email-masked]>
Date: Wed, 7 Aug 2013 07:55:05 -0700

> A practical guideline could be that the main module and all its submodules should be always published as a single RFC.

OK.  I remember Bert saying we don't have to really decide
until the RFC is updated in the future.

Andy

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Wed, 07 Aug 2013 17:37:35 +0200

> until the RFC is updated in the future.

That I did indeed also say.

Bert
On 8/7/13 4:53 PM, Bert Wijnen (IETF) wrote:
>> I was among the nine, and my understanding was that I was expressing support to the statement that whenever a submodule changes,
>> the revision of the main module has to be advanced, too.
>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Aug 2013 09:53:48 +0200

> So what is the problem with that?

This is what the I-D says:

   This organizations allows to add configuration support for additional
   NETCONF features while keeping the number of namespaces that have to
   be dealt with down to a minimum.  If new definitions need to be added
   to the NETCONF configuration data model, either an existing YANG
   submodule can be updated or a new YANG submodule can be written.  In
   both cases, the new document will carry an updated version of the
   "ietf-netconf-config" module importing the submodules.

It is fine to add an explicit statement that import by revision is to
be used.

>   RFC if a submodule changes (9 hands)

The basic question in my view is whether we want one namespace for
NETCONF configuration objects or multiple namespaces, one for the TLS
config objects, one for the SSH config objects, one for general
NETCONF config objects (e.g. idle timeouts etc. that do not exist in
RFCs yet but it seems they will do them at some point in time since
implementations commonly have such configuration parameters).

There is flexibility how submodules map to RFCs and I would simply
trust the WG to take the most suitable decision when documents are
written or revised - I do not see a need to put up rules in an attempt
to protect or guide future WG decisions.

I personally prefer to have a single /netconf root in a single
namespace with all NETCONF related config objects below it instead of
/netconf-tls, /netconf-ssh, /netconf-misc, ... with different
namespaces (or a single /netconf but then below it /netconf/tls and
/netconf/ssh, /netconf/misc, etc, each in a separate namespace).

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 8 Aug 2013 10:10:15 +0200

> implementations commonly have such configuration parameters).

IMO, submodules should be reserved for the party that is in control of the main module (that can be an IETF WG). Other parties (including other WGs) should always use another namespace.

Lada

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Thu, 08 Aug 2013 10:13:13 +0200

Lada, can I conclude from the below that you agree with the
approach that Juergen has currently taken?

Bert

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 8 Aug 2013 17:57:35 +0200

> approach that Juergen has currently taken?

In this case, I think it is not realistic to assume that additional submodules will be defined in other documents, because every revision of such a submodule would require an update to the NETCONF-over-TLS document, which would be counterproductive.

Therefore, 5539bis should IMO simply define the "ietf-netconf-tls" module, essentially with the contents of the current "ietf-netconf-tls" submodule.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 8 Aug 2013 09:23:11 -0700

Hi,

I don't think Martin's suggestion (which I made early in the email debate)
solves the problem 100%.

Publish 1 RFC with the main module and the 'netconf' container.
The main container will include the TLS module and have a normative
reference to the NETCONF over TLS RFC

Publish NETCONF-over-TLS RFC which has a "belongs-to" main module
and a normative reference to the main module RFC.

>>> Circular normative references; OK or not?

Assuming the normative references are not a problem:

In the future:

Publish NETCONF-over-FOO RFC which has a "belongs-to" main module
and a normative reference to the main module RFC.

Publish a new RFC with the main module and the 'netconf' container.
The main container will include the TLS and FOO submodules and
have a normative reference to the NETCONF over TLS RFC,
and NETCONF over FOO RFC.

Advantages:
  * The new RFC(main-module) always obsoletes the previous version
  * Always clear which RFC has the main module (RFC series tracks it)
  * The existing submodule RFCs do not get touched or republished
    when the main module is updated

Disadvantages:
  * Requires extra RFC
  * Main module reference in NETCONF over TLS RFC may be perceived
    as out of date; (It is valid for the conformance required when published,
    so should be OK)

IMO, it is no big deal to publish NETCONF-over-tls  in 1 module,
and then NETCONF-over-FOO will just augment the /netconf
container using its own namespace.  Then there is no main module
+ /netconf submodule RFC needed.

All this submodule stuff seems like a lot of extra work to save an
XML namespace.  That is not a very expensive resource.
It costs 1 attribute in XML or 1 module prefix in JSON.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 8 Aug 2013 18:55:03 +0200

> reference to the NETCONF over TLS RFC

A submodule like "ietf-netconf-common" in 5539bis would still be needed, because submodules cannot augment nodes in the main module.

> and a normative reference to the main module RFC.

But it would also have to include "ietf-netconf-common", which is a another complication (I think this CLR is unnecessary, and should be removed in YANG 2.0).

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 08 Aug 2013 19:28:44 +0200 (CEST)

> >>> Circular normative references; OK or not?

Seems to be ok; e.g., 6241 & 6242; 3412 & 3413 (and others).

>     as out of date; (It is valid for the conformance required when published,

Another solution that I suggested, that does not have these
disadvantages, is to let IANA maintain the main module.

An advantage of the submodule approach is that it is easier to find
all data models related to a technology - if you find ietf-netconf
you'll see all submodules included.

> It costs 1 attribute in XML or 1 module prefix in JSON.

I don't think there's any extra work.  It is not just one extra
attribute or module prefix; it is going to be one extra per module
(subtree).  It is certainly doable, but probably easier and less error
prone if we can avoid it.

/martin