Subject: Re: [Netconf] One or three drafts?

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 1 Mar 2016 16:55:23 +0000

Hi Tom,

In the end, the number of drafts is not a huge issue for us.  To date, we have segmented drafts so as to:

(a) Maximize transport independence. 

(b) Reduce technology options within any one draft.  (We don't want things overly complex so that operators can't easily refer to desired  subset.)

(c) Maximize alignment with any in-flight RFC5277bis spec   

At the next IETF, we would be happy to make a proposal for functionality segmentation across the following elements:  

Subscription Configuration 
 - Static  (& Multiple Receivers)
 - Dynamic (& Parameter Negotiation)
 - Subscription QoS & Prioritized Push
 - Filter (RFC6241, RFC5277, other)
Transport (Netconf, Restconf, HTTP2, other?)
RFC5277bis (new and/or augmented RPCs)

Based on whatever discussion follows, we will take WG guidance on appropriate draft segmentation.

Eric

> -----Original Message-----
> From: Netconf, February 27, 2016 11:14 AM
> 
> ---- Original Message -----
> From: "Mahesh Jethanandani" <[email-masked]>
> To: "NETCONF" <[email-masked]>
> Sent: Saturday, February 27, 2016 1:21 AM
> 
> > I am following up on the discussion in IETF 94 on the question of
> whether we need one or three drafts for YANG push. One draft would mean a
> merge of NETCONF and RESTCONF YANG push draft, while three drafts would
> be a common draft, the second one for NETCONF specific part and the third for
> the RESTCONF specific part. There was no preference for just two drafts - one
> for NETCONF and one for RESTCONF with common parts either duplicated or
> referenced. The vote in the room seemed to indicate a tie for 1 or 3 drafts with
> no apparent winner.
> >
> > The authors indicated a preference to keep them as separate drafts,
> but others in the room seemed to indicate that other drafts, like call home and
> zero touch are doing it as a single draft.
> >
> > Can we have a discussion of whether folks would prefer to read and
> follow YANG push as three separate drafts or would they prefer to see them
> merged?
> 
> I don't know, can we have a discussion:-)
> 
> Well, assuming we can, I am for a merge into one I-D.
> 
> Tom Petch
> 
> > Thanks.
> >
> > Mahesh & Mehmet.
> >
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: t.petch <[email-masked]>
Date: Thu, 3 Mar 2016 10:05:07 +0000

----- Original Message -----
From: "Eric Voit (evoit)" <[email-masked]>
To: "t.petch" <[email-masked]>; "Mahesh Jethanandani"
<[email-masked]>; "NETCONF" <[email-masked]>
Sent: Tuesday, March 01, 2016 4:55 PM

Hi Tom,

In the end, the number of drafts is not a huge issue for us.  To date,
we have segmented drafts so as to:

(b) Reduce technology options within any one draft.  (We don't want
things overly complex so that operators can't easily refer to desired
subset.)

At the next IETF, we would be happy to make a proposal for functionality
segmentation across the following elements:

Based on whatever discussion follows, we will take WG guidance on
appropriate draft segmentation.

<tp>
As an editor of an I-D, I much prefer multiple drafts so that I can have
my own self-contained world and do not have to liaise with people I  do
not know over a slow and unreliable communication medium, like e-mail:-)

As a consumer of I-Ds, I want everything together in one place so I do
not have to shuffle multiple documents (feasible with paper on desk, a
potential nightmare on screens) and chase cross references, terms
defined elsewhere etc.

The only caveat is that when an I-D gets too big, which YANG did years
ago, then it becomes unusable and should be split.  'push' may be
approaching that state but I think not.  Some splits are more sensible
that others.  I think that layered stacks was one of the great
inventions of IT and so would bundle applications together and split
them from transport, from the transport-like security, and so on.

Tom Petch

Eric

---

From: Andy Bierman <[email-masked]>
Date: Thu, 3 Mar 2016 18:17:47 -0800

On Tue, Mar 1, 2016 at 8:55 AM, Eric Voit (evoit) <[email-masked]> wrote:

> (b) Reduce technology options within any one draft.  (We don't want things
> overly complex so that operators can't easily refer to desired  subset.)
>

If you mean each of these sub-topics is part of 1 RFC then OK.
IMO YANG features should make these all optional.

> Transport (Netconf, Restconf, HTTP2, other?)

I agree Transport should be a separate RFC.
Will there be a mandatory-to-implement transport?
(IMO, no)

other? might be RESTCONF over CoAP,
or perhaps using NETCONF like SNMP (with configured
listeners) and sending notifications in XML over DTLS/UDP.

Agree it is time to update this RFC

NETCONF notifications are deployed and being used, so I hope
the update will not disturb any running code. This is easily done
by defining new RPCs and even new standard streams.

There is little point in updating this RFC unless all deficiencies and new
features can be considered by the WG.

> appropriate draft segmentation.

Andy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 4 Mar 2016 12:52:56 +0000

From: Andy Bierman, March 03, 2016 9:18 PM

On Tue, Mar 1, 2016 at 8:55 AM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tom,

<Eric> Yes, this is what we were thinking.

<Eric> Yes, this would be our preference as well.

<Eric> On ‘other’, we were thinking about IPFIX as an example as well at some point.   New drafts could come for new options.

<Eric> Agree with new RPCs and new standard streams.   Look for a strawman before the IETF cut-off date.  We are hoping to see other proposals as well so that we can have more eyes on the problem.

Eric

Eric

Andy

> From: "Mahesh Jethanandani" <[email-masked]<mailto:[email-masked]>>
> To: "NETCONF" <[email-masked]<mailto:[email-masked]>>
> [email-masked]<mailto:[email-masked]>

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