Subject: DRAFT agenda for NETCONF meeting at IETF 70 in Vancouver

From: Simon Leinen <[email-masked]>
Date: Thu, 22 Nov 2007 23:28:46 +0100

I heard that the new NETCONF charter was approved by the IESG on 11/15.
(official announcements are a little slow to come out at the moment,
due to the secretariat transition)

Andy and myself are stepping down as chairs with the conclusion of the
old charter.  Pending the appointment of new chairs, I'll chair the
meeting in Vancouver.  This is the DRAFT meeting agenda - sorry for
the late submission! Please send any change suggestions to the NETCONF
list, CC'ing the NGO list if you wish.

[VOLUNTEERS FOR NOTETAKER/JABBER SCRIBE WELCOME - PLEASE SEND ME MAIL!]

http://www3.ietf.org/proceedings/07dec/agenda/netconf.txt

NETCONF WG
IETF 70, Vancouver, BC, Canada

TUESDAY, December 4, 2007 1850-1950

  "Wrapping up work under the old charter"

  We will probably cancel this slot.

WEDNESDAY, December 5, 2007 1300-1500 (Salon 1)

  "Bootstrapping work under the new charter"

  Scribes (1-5 minutes)
  
  Agenda bashing (5 minutes)

  WG status (10 minutes)
    call for WG chair volunteers

  New charter items

    1. Fine-grained locking (15 minutes)

       draft-lengyel-ngo-partial-lock-01.txt

    2. Netconf monitoring (10 minutes)

       draft-scott-netconf-monitoring-00.txt

    3. Schema advertisement (30 minutes)

       draft-okita-netconf-advertisement-00.txt
       draft-scott-netconf-schema-query-00.txt

    4. NETCONF over TLS (10 minutes)

       draft-badra-tls-netconf-04.txt

  AOB (35 minutes)
-- 
Simon.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Simon Leinen <[email-masked]>
Date: Fri, 23 Nov 2007 12:55:26 +0100

Since there are a few other sessions with NETCONF content (haha, pun
intended), I collected those on:

http://www.ops.ietf.org/netconf/#ietf70

Complain if I have overlooked anything.

Mon 0900-1130: APPAREA (Discussion on XML schemas and modeling, e.g. YANG)
Mon 1740-1950: OPSAREA Open Meeting (MIB2RDML, XML Schema for NETCONF, YANG)
Tue 1850-1950: NETCONF - will be CANCELED unless something comes up
Tue 1520-1720: OPSAWG (Datatypes for NETCONF, smidump MIB->XSD conversion)
Wed 1300-1500: NETCONF (New charter items)
-- 
Simon.

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 23 Nov 2007 07:50:02 -0500

Hi

It would be good to reserve the timeslot and the room for an informal
meeting. Now that the protocol extensions and the content specification
discussions seem to have homes, what I think would be interesting is to
try to identify a working group interesting in being a guinea pig for
defining some NETCONF content for their work. This session could work
out the plan to make that happen.

Either that or for more detailed discussion of the items in the updated
NETCONF charter.

Sharon

-----Original Message-----
From: Simon Leinen [mailto:[email-masked]] 
Sent: Friday, November 23, 2007 6:55 AM
To: [email-masked]
Cc: [email-masked]
Subject: [NGO] NETCONF-related sessions at IETF 70

Mon 0900-1130: APPAREA (Discussion on XML schemas and modeling, e.g.
YANG) 
Mon 1740-1950: OPSAREA Open Meeting (MIB2RDML, XML Schema for NETCONF,
YANG) 
Tue 1850-1950: NETCONF - will be CANCELED unless something comes up 
Tue 1520-1720: OPSAWG (Datatypes for NETCONF, smidump MIB->XSD
conversion) 
Wed 1300-1500: NETCONF (New charter items)
--
Simon.

_______________________________________________
NGO mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ngo

---

From: Phil Shafer <[email-masked]>
Date: Mon, 26 Nov 2007 00:21:32 -0500

>Either that or for more detailed discussion of the items in the updated

Another thought is to come up with a list of the five biggest
impediments to NETCONF's complete domination of the configuration
space.  Do we know the answers to questions like:

- Why aren't/won't device folks shipping netconf implementations?
- Why aren't/won't application writers moving to NETCONF?
- Why isn't NETCONF becoming the answer to configuration problems?
- What's stopping it?
- Where's the chicken?
- What's the egg?
- What's the key to moving forward from here?
- Where should we be concentrating our (precious and few) resources?
- Will any of the new charter items be on this list?

Thanks,
 Phil

---

From: Bharadwaj Kalahasti <[email-masked]>
Date: Mon, 26 Nov 2007 09:51:51 -0800 (PST)

Phil,
  As an implementor, I can think of one obstacle I face with movement of MIBs from
use with SNMP to Netconf protocol:
-- Separation of configuration and state data.
-- Non-definition of a state datastore.
-- Difficulty in converting existing MIB stata data into Netconf state data. 

  My 2 cents.
Kalahasti

> - Will any of the new charter items be on this list?

      ____________________________________________________________________________________
Get easy, one-click access to your favorites. 
Make Yahoo! your homepage.
http://www.yahoo.com/r/hs

---

From: Phil Shafer <[email-masked]>
Date: Mon, 26 Nov 2007 13:25:40 -0500

>-- Difficulty in converting existing MIB stata data into Netconf state data. 

My hope is that the YANG work will address these points.  Juergen
Schoenwaelder has a backend to libsmi that emits YANG for MIBs,
which goes a long way toward helping carry existing MIB data in
NETCONF.  Have you had a chance to read the YANG draft?
It's available at:

   http://www.ietf.org/internet-drafts/draft-bjorklund-netconf-yang-00.txt

Thanks,
 Phil

---

From: Bharadwaj Kalahasti <[email-masked]>
Date: Mon, 26 Nov 2007 11:14:32 -0800 (PST)

Phil,
  Thanks for the answer.
  I will review the YANG draft.
Regards,
Kalahasti

      ____________________________________________________________________________________
Be a better pen pal. 
Text or chat with friends inside Yahoo! Mail. See how.  http://overview.mail.yahoo.com/

---

From: John Dickinson <[email-masked]>
Date: Tue, 27 Nov 2007 09:38:16 +0000

> - Will any of the new charter items be on this list?

I think that such a discussion would be very useful in getting the  
word out about NETCONF and helping people understand how it could be  
used.

There has, for example, been some discussion in the dnsop WG about  
developing a protocol for configuring and controlling nameservers (http://tools.ietf.org/wg/dnsop/minutes?item=minutes69.html 
) and I am one of the authors of a draft (http://www.ietf.org/internet-drafts/draft-arends-nscp-00.txt 
) that suggests using NETCONF.

The biggest issue for me in choosing NETCONF was and is to be sure I  
am using NETCONF appropriately and that it really is the correct  
solution to my problem. I am currently looking at such things as, what  
would be an appropriate data model, how to correctly use capabilities  
and how to engineer things that are not strictly configuration, such  
as control commands, monitoring and statistics gathering.

Thanks,
John

---
John Dickinson
[email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 27 Nov 2007 11:36:51 +0100 (CET)

Hi John,

John Dickinson <[email-masked]> wrote:
> solution to my problem.

I have read your draft and I do believe (and hope!) that NETCONF is
a good solution to this problem.

> I am currently looking at such things as, what  

In your draft you also listed:

  Be extensible to allow implementors to extend to cover new objects
  and methods.

Maybe not suprising, but these are exactly the problems that YANG is
designed to help you with.

To be more specific, with YANG, you can write a standard data model
with the the (most) common configuration parameters.  Vendors can then
augment this standard data model with vendor-specific config params.

As an example (NOTE: I don't know what parameters actually would make
sense, this is just an example):

  container server {
      container panorama {
          list view {
              key view-name;
              leaf-list match-client { type inet:ip-prefix; }
              leaf recursion         { type boolean; }
              ...
          }
      }
  }
 
Then vendor X can add its own proprietary stuff:

   augment /dns:server/dns:panorama/dns:view {
       leaf funky-cache-option { ... }
       ...
   }

And in the NETCONF XML you might see:

   <server>
     <panorama>
       <view>
         <view-name>mybiew</view-name>
         <match-client>192.168.23.0/24</match-client>
         <match-client>172.16.30.0/16</match-client>
         <recursion>true</recursion>
         <x:funky-cache-option>magic</x:funky-cache-option>
       </view>
     </panorama>
   </server>

The same goes for commands (rpcs).  You can define standard rpc, and
vendors can e.g. add new rpcs, or augment the standard rpcs.

/martin

---

From: Simon Leinen <[email-masked]>
Date: Thu, 29 Nov 2007 22:20:48 +0100

Sharon Chisholm writes:
> It would be good to reserve the timeslot and the room for an
> informal meeting.

OK, so let's go ahead like this: As I suggested, we cancel the short
NETCONF slot (TUESDAY, December 4, 2007 1850-1950), and try to keep
the room for informal discussions.

> Now that the protocol extensions and the content specification
> discussions seem to have homes, what I think would be interesting is
> to try to identify a working group interesting in being a guinea pig
> for defining some NETCONF content for their work. This session could
> work out the plan to make that happen.

IPFIX seems to be a good candidate, because they have development of
"an XML-based configuration data model that can be used for
configuring IPFIX devices and for storing, modifying and managing
IPFIX configurations parameter sets" on their brand-new charter, which
also notes that "This work will be performed in close collaboration
with the NETCONF WG".

IPFIX meets on Tuesday 1300-1500, and I'll be chairing the meeting
(since the real IPFIX chairs won't be in Vancouver), so I can invite
interested participants to our informal meeting on Tuesday evening.

OK?

> Either that or for more detailed discussion of the items in the
> updated NETCONF charter.

I hope two hours are sufficient for that.
-- 
Simon.

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 30 Nov 2007 08:11:31 +0100

Hello Simon, Sharon,
We also have John Dickinson from DNSOP. He seems a very promising candidate.
Balazs

John Dickinson <[email-masked]> wrote:
 > > developing a protocol for configuring and controlling nameservers 
(http://tools.ietf.org/wg/dnsop/minutes?item=minutes69.html
 > > ) and I am one of the authors of a draft 
(http://www.ietf.org/internet-drafts/draft-arends-nscp-00.txt

   container server {
       container panorama {
           list view {
               key view-name;

    <server>
      <panorama>
        <view>

/martin

http

---------------------------------------------------------------------------------------

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]