Subject: [Netconf] new WG charter

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Thu, 29 Jul 2010 13:43:06 +0200

As part of the action items from our meeting in Maastricht,
the WG chairs are working on a revised charter.

I see this in our current charter:

  The following items have been identified as important but are currently
  not considered in scope for re-chartering and may be candidates for work
  when there is community consensus to take them on:

  - NETCONF Notification content
  - Access Control requirements
  - NETCONF access to SMI-based MIB data

I believe that the Netconf Notification content has partially been
addressed by the Netconf Monitoring document that we delivered to
the IESG. The new System Monitor draft that Andy has posted (as an
individual document) does include some of those notifications as
well. So do we consider that part of the first bullet above?

The NACM is clearly addressing the 2nd bullet and in fact also
addresses a solution.

What we are really unclear of us the 3rd bullet.
Does anyone still want to work on those? Or has that in fact been
addressed in OPSAWG and or OPS-AREA discussion/documents?

Anyway, if we want to do work on that 3rd bullet, pls send concrete
proposals/ideas.

Bert and Mehmet

---

From: Andy Bierman <[email-masked]>
Date: Thu, 29 Jul 2010 05:23:53 -0700

> Anyway, if we want to do work on that 3rd bullet, pls send concrete

I would like to make it clear that NACM is a solution, not
just requirements.

IMO, we should start with a complete but minimalist solution.
This means that it must maintain security but other features
such as very-fined-grained control or fancy authentication features
may be left out.

> Bert and Mehmet

Andy

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 29 Jul 2010 19:08:39 +0200

> well. So do we consider that part of the first bullet above?

Yes, the notifications of Andy's system module seem to fall into the
existing charter. And I would prefer to move the rest of the system
module into NETMOD, subject to the deliberations of the WG chairs and
Dan of course.

> The NACM is clearly addressing the 2nd bullet and in fact also

Just doing requirements is a waste of time.

> Anyway, if we want to do work on that 3rd bullet, pls send concrete

There is the SMIv2 to YANG translation which I presented at the NETMOD
session in Maastricht (and more detailed in Stockholm). This mapping
is addressing this third work item. I thought it makes sense to do the
SMIv2 to YANG translation in NETMOD since there is really nothing
affecting the protocol directly and YANG is kind of NETMOD's baby.

/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: Fri, 30 Jul 2010 09:23:08 +0200

> module into NETMOD, subject to the deliberations of the WG chairs and

I agree with the principle.

But in Andy YANG module, there is some data nodes as well that I think
are NETCONF specific. I see that the System COntainer that Andy defined 
could
be seen as the container for the operating system.
I was more seeing it as the container that contained:
- the system info on which netconf is running
- the start time of the netconf server.
But indeed that is not so clear from the descriptions.
It could also have things like a netconf-serverContainer with things like:
- netconf capabilities
- netconf version(s)
- netconf vendorid
- xxx

> Just doing requirements is a waste of time.

Understood, and the current NACM proposal for our charter does include 
that.,
The item above was on our current charter, and our new text (and 
Andy's/Martins
document) address indeed requirements AND solution. ANd that does 
address that
old point on our charter (and more).
> affecting the protocol directly and YANG is kind of NETMOD's baby.
That would be fine with us as NETCONF chairs.

I brought it up, because it was on our old/current charter and wanted to 
figure
out if we still need to do something about that in NETCONF.  We will check
with Dan where he wants this work (your work may be the tsrating point)
is to be done.

Bert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 30 Jul 2010 09:26:35 +0200

> It could also have things like a netconf-serverContainer with things like:

But the netconf server container should have been part of the netconf
monitoring module. I understood Andy's system objects as operating
system specific object, that is the OS boot time not the NETCONF
server boot time etc.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 30 Jul 2010 01:12:19 -0700

> system specific object, that is the OS boot time not the NETCONF

Well, if the running code
(http://www.netconfcentral.org/modulereport/yuma-system)
is any indication of the intent of a particular object, then:

   - all notifications are NETCONF server specific
   - sys-netconf-server-id is NETCONF specific
   - all other objects are based on linux system information

I agree with Juergen that we should try to have strong cohesion
within our YANG modules, even if that means there are more modules
and the WG chartering is more complicated.

Andy

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Fri, 30 Jul 2010 13:57:26 +0200

Inline

> and the WG chartering is more complicated.

OK, so should we call the effort "netconf-monitoring" instead?

Bert

---

From: Andy Bierman <[email-masked]>
Date: Fri, 30 Jul 2010 05:13:59 -0700

On 07/30/2010 04:57 AM, Bert (IETF) Wijnen wrote:
>>>> are NETCONF specific. I see that the System COntainer that Andy
>>>> defined could

Well that module (and charter) has already been completed,
except the container is called <netconf-state> to confuse people.
(Not to be confused with <netconf> container in RFC 5277 that
contains the monitoring info for the supported streams.)

At this point we've already done such a bad job organizing the
standard data that I'm not sure we could mess it up much worse.

Andy

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Fri, 30 Jul 2010 14:17:52 +0200

> standard data that I'm not sure we could mess it up much worse.
So maybe then we should update the existing netconf-monitoring RFC?

Just checking these options.
Now is the time to make the decision which path to take.

Bert

---

From: Andy Bierman <[email-masked]>
Date: Fri, 30 Jul 2010 05:26:26 -0700

On 07/30/2010 05:17 AM, Bert (IETF) Wijnen wrote:
....
> Now is the time to make the decision which path to take.

My preference:

  - ietf-netconf-events.yang  : contains the notifications from system.yang
  - ietf-system.yang : contains the data nodes from system.yang and maybe the
     <authentication> container from nacm.yang.
  - ietf-netconf-nacm.yang : contains the <nacm> container objects

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 30 Jul 2010 14:32:23 +0200

>   - ietf-netconf-events.yang  : contains the notifications from system.yang

Yes, perhaps ietf-netconf-notifications.yang instead of
ietf-netconf-events.yang.

>      <authentication> container from nacm.yang.

I agree, with the little caveat that I would move this to NETMOD.

>   - ietf-netconf-nacm.yang : contains the <nacm> container objects

I agree.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 30 Jul 2010 05:37:26 -0700

> ietf-netconf-events.yang.

OK

> I agree, with the little caveat that I would move this to NETMOD.

OK

>>   - ietf-netconf-nacm.yang : contains the <nacm> container objects

Is this agreement thing a trend (5 times in a year! :-)

Andy

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Fri, 30 Jul 2010 15:59:47 +0200

To celebrate that Andy and Juergen agreed 5 times this year, may I 
suggest then
this text (to cover the work item of Andy's system-monitoring draft)

  4. The NETCONF protocol and the netconf server may want to
     allow a client to check the status at the server end.
     In addition, the server may want to notify interested
     clients about particular NETCONF protocol/server events.
     The WG will work on a NETCONF specific YANG module to
     address this requirement. It is specific for NETCONF
     protocol and server information.

Bert