Subject: [Netconf] Summary of action items, decisions, etc. from the NETCONF session in IETF 77

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 25 Mar 2010 20:07:12 +0100

> Dear NETCONF WG, 
> 
> please find below a summary of the WG decisions and the action items
> from the NETCONF WG session on March 22, 2010.
> Please speak up if you don't agree with any of the consensus achieved
> in the session.
> 
Mehmet & Bert

______________________________________________________

> We had approx. 30 participants in the 2,5 hour NETCONF session. 
> 
> Chartered items:
> 
> 1. 4741bis-draft
> 
> Andy to put the base:1.1 and the Yang features issue discussion to the
> ML.
> Andy will also put the 12 open issues presented to the ML in separate
> emails, and the co-chairs will ask for consensus.
> 
> 2. With-defaults capability for NETCONF 
> 
> No open issues available, the WG has consensus for starting WGLC.
> Andy to submit a new version and the co-chairs to start WGLC.
> 
> 3. 4742bis draft (NETCONF over SSH) 
> 
> Margaret will make 4742bis dependent on 4741bis and submit a new
> version based on the terminology discussion in the session.
> The co-chairs will start a WGLC. After WGLC it will be handed over to
> Dan in parallel to 4741bis.
> 
> Non-Chartered items:
> 
> 1. Robust Configuration Management within NETCONF 
> 
> The WG is in favor of having the draft as WG item. 
> Bob to bring in the issues from the session to the ML.
> After solving the issues on the ML the co-chairs will discuss with the
> authors how to proceed and the potential charter  text.
> 
> 2. Network Configuration Protocol Access Control Model 
> 
> The WG has consensus that we need ACM. 
> General feeling is that the requirements are a good base set we want
> to have.
> The co-chairs asked for volunteers: Andy and Martin volunteered to be
> editors.
> With this the ACM discussion is started and everybody is invited to
> bring in input.
> The intension is to first cycle on the requirements section.
> => If anybody feels that he/she should bring in a new draft should
> please do so before end of April.
> Co-chairs will ask on the ML whether somebody else wants to
> co-author/edit.
> 
> AOB:
> The discussion on the security section for YANG modules has been
> shifted to the NETMOD session, where Bert presented his proposal. 
> The proposal has been generally accepted and will be reviewed in
> Netconf/Netmod MLs.
> 
There was a joint NETCONF/NETMOD "editing/discussion" on Tuesday
afternoon, which has been announced on the two MLs to enable everybody
to attend.
There were some 8 or so participants in that session and we had a good
exchange of ideas/issues/concerns on topics like:

- base 1.1 capability
- conversion of existing netconf capabilities to YANG features
- some ACM related topics.
- which IETF base YANG modules we need to work on

Lada posted a short summary of this session to NETCONF/NETMOD MLs.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Mar 2010 21:47:19 +0100

> > authors how to proceed and the potential charter text.

The subset of participants at a WG meeting is not "the WG". I think
there needs to be mailing list discussion of a document before a
sentence like "The WG is in favor of having the draft as WG item." can
be rightfully written.

Given the number of things proposed as new work, I think it is crucial
to take a realistic look at the resources (editors, reviewers) we have
available here (and in NETMOD or any NETMOD followup WG). It is then
crucial to prioritize work items. As far as I am concerned, we need to
finish stabilizing the base protocol (means complete 1.1, chartered
work), we need to work on access control, and we need to get core data
models worked out. The last two work items (and especially the core
date models one) are not going to be easy. I would feel much more
comfortable if we focus our resources on exactly these things first
before entertaining "nice to have" extensions as part of chartered
work items.

So, now shoot your arrows. ;-)

/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 (IETF) Wijnen" <[email-masked]>
Date: Thu, 25 Mar 2010 14:04:15 -0700

Juergen, you are correct. In fact all/most "The WG" in the summary means 
"The WG members present".
All such statements indeed need to (and will) be verified on the list.

W.r.t. the Robust Config document, the way to check that would be to try 
and define text
that explains what exactly we would do in the form of proposed charter text.

I personally agree with you that we may need to prioritize the work 
items in the whole
NETCONF/NETMOD/Modeling space. It is clear from your message that you 
would put
the Cobust COnfig document at low priority.

Other people may chime in please

Bert

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 26 Mar 2010 02:35:39 +0100

Juergen, Bert,

I can just second your thoughts. 
I as a co-chair would like to avoid overloading the WG too.

The consensus achieved in the session is for sure based on "The WG
members present",
which is now public and should be discussed and approved.

in the session.

> Other people may chime in please

Mehmet

> -----Original Message-----
> From: ext Bert (IETF) Wijnen [mailto:[email-masked]] 
> Sent: Thursday, March 25, 2010 2:04 PM
> To: Ersue, Mehmet (NSN - DE/Munich); NETCONF WG
> Subject: Re: [Netconf] Summary of action items, decisions, 
> etc. from the NETCONF session in IETF 77
>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 26 Mar 2010 18:11:03 -0700

> So, now shoot your arrows. ;-)

You are right (as usual).

This is a nice-to-have, compared to what else we don't have.

Since Bob and Dan are not current WG authors, we would be
providing additional resources, other than the usual crowd,
and gaining new perspectives on our work.

IMO, this is a big part of the automation story that is
at the core of NETCONF/YANG.

Randy Bush scolded us at the OPS-NM meeting because,
after 10 years (since 'It's the CLI, stupid), we
are still struggling with device management, and
not even started on network management.

Some companies took the message about the CLI as
an affirmation that they were done with NM because
they had a CLI.

In order to move to a management framework that
allows us to manage the network instead of the
devices, we need to understand how to describe
the network model and how it translates to interactions
with the devices.

The robust config work is an excellent test case
for this type of work.  (I believe Phil is going to
propose a solution, which I support before even reading it ;-)

I think the robust config work is a framework for
applications to do verification testing, which is in itself
an instance of an application that needs Phil's
network-to-device management framework.  (Split that part out
of robust config since it isn't explained anyway).

Andy

---

From: Kent Watsen <[email-masked]>
Date: Mon, 29 Mar 2010 17:47:14 -0700

1. I wish to call this I-D something besides "robust configuration" as it has little to do with configuration --> how about simply "verification"?

2. I find the all the references to "candidate" and "commit" somewhat misleading - because of them, I kept expecting that this solution was dependent on the :candidate/:confirmed-commit capabilities.  Perhaps my reaction would not have been so strong had the two diagrams in the Introduction been swapped.  I know you're envisioning this capability being especially useful in conjunction with :confirmed-commit, but it seems that it would be enough to mention this use case just once in the document.

3. Section 3.1.4.2 (<cancel-verify>) specifies that the "server terminates in-progress tests immediately" - this seems too prescriptive, isn't it sufficient for the server to just stop reporting the results?

4. More generally, though, as mentioned during the WG meeting, this I-D doesn't seem to justify why a client couldn't execute the very same RPCs remotely.  Specifically, I'm thinking the "Benefits of This Work" section should be replaced with text that explains:

  a. how having a uniform invocation/cancelling/completing
    - is provably sufficient
    - is a good thing for clients
    - is a good thing for servers
    - is important for interoperability (is it?)
    - etc.

  b. how pre-staging the tests on the server
    - allows the server to execute them in parallel
    - reduces the latency involved with remote invocations
    - enables the tests to be executed automatically (on a commit trigger)
    - anything else?

I say "replace" as existing bullets 1,2,3 and 5 are satisfiable using multiple RPCs and bullet 4 is satisfiable by having YANG modules define thief own test RPCs...

Thanks,
Kent

---

From: "Cole, Robert G Dr CIV USA" <[email-masked]>
Date: Tue, 30 Mar 2010 07:27:18 -0400

Classification: UNCLASSIFIED
Caveats: NONE

Kent,

Please see below.

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Kent Watsen
Sent: Monday, March 29, 2010 8:47 PM
To: [email-masked]'
Cc: NETCONF WG
Subject: [Netconf] robust configuration (was: Summary of action items,
decisions, etc. from the NETCONF session in IETF 77)

1. I wish to call this I-D something besides "robust configuration" as
it has little to do with configuration --> how about simply
"verification"?

RGC> Yes, I agree.  I mentioned this during the meeting.  I also would
prefer a more descriptive term.

2. I find the all the references to "candidate" and "commit" somewhat
misleading - because of them, I kept expecting that this solution was
dependent on the :candidate/:confirmed-commit capabilities.  Perhaps my
reaction would not have been so strong had the two diagrams in the
Introduction been swapped.  I know you're envisioning this capability
being especially useful in conjunction with :confirmed-commit, but it
seems that it would be enough to mention this use case just once in the
document.

RGC>  I'll clean this up.  But you're correct, we wanted to define a
verify mechanism which is independent of these capabilities.  Use cases
should be sufficient to illustrate potential interactions/uses.

3. Section 3.1.4.2 (<cancel-verify>) specifies that the "server
terminates in-progress tests immediately" - this seems too prescriptive,
isn't it sufficient for the server to just stop reporting the results?

RGC> The notion of Test Suite comprised on multiple Test Sets comprised
of multiple tests, lead us to specify this behavior.  At most the server
would report upon completion of each test set.  However, a test set may
comprise multiple (tens) of test measurements.  So we wanted the
<cancel-verify> to terminate all test measurements immediately.

4. More generally, though, as mentioned during the WG meeting, this I-D
doesn't seem to justify why a client couldn't execute the very same RPCs
remotely.  Specifically, I'm thinking the "Benefits of This Work"
section should be replaced with text that explains:

  b. how pre-staging the tests on the server
    - allows the server to execute them in parallel
    - reduces the latency involved with remote invocations
    - enables the tests to be executed automatically (on a commit
trigger)
    - anything else?

I say "replace" as existing bullets 1,2,3 and 5 are satisfiable using
multiple RPCs and bullet 4 is satisfiable by having YANG modules define
thief own test RPCs...

RGC> Thanks for this list.  I agree, this seems to be the current
challenge with this work and gaining WG acceptance. 

Thanks,
Kent

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

---

From: Kent Watsen <[email-masked]>
Date: Tue, 30 Mar 2010 08:07:49 -0700

> <cancel-verify> to terminate all test measurements immediately.

Certainly I understand that, if there are 10 tests and the cancel comes while running test #3, that we want the server to not execute tests 4-10.  My concern is that the current text makes it sound like the server must stop running test #3 in midcourse.  While this may be ideal, it may be challenging for some implementations, which is why I'm wondering if the language could the loosened up a little bit to allow that flexibility.

Thanks,
Kent

---

From: "Cole, Robert G Dr CIV USA" <[email-masked]>
Date: Wed, 31 Mar 2010 07:36:39 -0400

Kent,

OK, I'll try to reflect this in the next rev.

Thanks,
Bob

-----Original Message-----
From: Kent Watsen [mailto:[email-masked]] 
Sent: Tuesday, March 30, 2010 11:08 AM
To: Cole, Robert G Dr CIV USA; [email-masked]
Cc: NETCONF WG
Subject: RE: [Netconf] robust configuration (UNCLASSIFIED)

> <cancel-verify> to terminate all test measurements immediately.

Certainly I understand that, if there are 10 tests and the cancel comes
while running test #3, that we want the server to not execute tests
4-10.  My concern is that the current text makes it sound like the
server must stop running test #3 in midcourse.  While this may be ideal,
it may be challenging for some implementations, which is why I'm
wondering if the language could the loosened up a little bit to allow
that flexibility.

Thanks,
Kent