Subject: [Netconf] Priority of the topics in queue WAS:RE: Developing Call-Home for the SSH and TLS transport bindings - New Charter text

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 15 Apr 2013 14:37:51 +0000

Hi All,

the co-chairs agree that Juergen has a point and the priorities should be discussed.

The co-chairs are mainly interested to finalize the TLS draft with the addition the WG members proposed.
As Bert raised, it is an issue to extend TLS for call-home and not doing the same for the mandatory SSH binding.
Iow. to extend both transport bindings at once seems to be the best way to go.

This was the agreement of the Netconf session in IETF #86, which is now subject to approve.

As far as we know, there are no drafts for the other topics in the list, which would be ready for asking the WG to adopt as WG item.

- For operational state, we had different proposals, which need to be aligned and/or updated before we can ask for re-chartering.
- Concerning get2, Andy was planning to do it after YANG-API is done and after getting implementation experience.
- For the REST API, Andy proposed to discuss it first in a BoF.
- Mechanisms to comment out-config is new and includes requirements coming from i2rs. Based on our agreement with the i2rs chairs drafts addressing i2rs requirements need to be aligned with the discussion in i2rs.
- As of today we did not get much input for alternate encodings.
- Advancement of RFCs will/can be done once we get more input on the deployment and implementation.

That said we would like to hear what the WG thinks on the priority of different topics in queue.
Should we try to push one or the other topic specifically?

Please comment on and indicate your priorities below:

Priority  Work item
(1=high)
          Call home for TLS
          Call home for SSH
          Operational state
          Improved retrieval (get2)
          Alternate encodings
          Conditional-enablement
          REST API to access NETCONF datastore(s)
          Advancement of RFCs

Mehmet & Bert

> -----Original Message-----
> From: ext Juergen Schoenwaelder [mailto:[email-masked]]
> Sent: Saturday, April 13, 2013 9:10 PM
> To: Andy Bierman
> Cc: Ersue, Mehmet (NSN - DE/Munich); [email-masked]<mailto:[email-masked]>
> Subject: Re: [Netconf] Developing Call-Home for the SSH and TLS transport bindings -
> New Charter text
>
> On Sat, Apr 13, 2013 at 11:41:11AM -0700, Andy Bierman wrote:
> > On Sat, Apr 13, 2013 at 11:20 AM, Juergen Schoenwaelder
> > <[email-masked]<mailto:[email-masked]>> wrote:
> > > On Sat, Apr 13, 2013 at 08:35:14AM -0700, Andy Bierman wrote:
> > >>
> > >> I must be thinking of draft-bjorklund-netmod-operational-00,
> > >> which expired 5 days ago.
> > >>
> > >
> > > An individual submission under a name picked by an individual. The
> > > discussion of this I-D took place in the NETCONF WG meeting at the
> > > last IETF:
> > >
> > > http://tools.ietf.org/wg/netconf/agenda?item=agenda-86-netconf.html
> > >
> > > While it may make sense to merge NETCONF/NETMOD, I disagree with "many
> > > NETMOD drafts specify YANG extensions that change NETCONF protocol
> > > behavior".
> > >
> >
> > I did not say merge -- I said coordinate the charters better.  Big difference.
> >
>
> The existing charters are IMHO well coordinated - I do not know what
> should have been done better in terms of separating protocol work from
> data modeling work.
>
> /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: Ladislav Lhotka <[email-masked]>
Date: Tue, 16 Apr 2013 11:19:49 +0200

> - As of today we did not get much input for alternate encodings.

This input is draft-lhotka-netmod-yang-json-01, presented in NETMOD.

BTW, it might really make sense to consider a merger of NETCONF & NETMOD. In my experience, external people are often confused as to which topic belongs where, and I don't see any benefits of having two groups - there is a significant overlap in terms of both topics and active participants.  

> (1=high)

1. REST API to access NETCONF datastore(s), 
2. Alternate encodings,
3. Conditional-enablement, 
4. Operational state,
5. Improved retrieval (get2), 
6. Call home for TLS,
7. Call home for SSH,
8. Advancement of RFCs (unless it means NETCONF over TLS, which should certainly be finished first).

Lada

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