Subject: Re: [OPSAWG] Call for adoption: draft-boydseda-ipfix-psamp-bulk-data-yang-model

From: "Arokiaraj, Anand (Nokia - IN/Chennai)" <[email-masked]>
Date: Wed, 6 May 2020 07:18:12 +0000

Hi,
IPFIX has been quite a useful tool for bulk data export. But the configuration model has posed quite a bit of a challenge in integrating IPFIX into the contemporary Netconf-Yang systems (no interface-ref, lists without keys, etc). The model proposed in draft-boydseda-ipfix-psamp-bulk-data-yang-model-03 effectively addresses these challenges.
Further, by defining a dedicated model for bulk data export, it has ironed out the complexities that existed in having to use a model meant for packet sampling (most of the fields in the cache node were not applicable/needed for bulk data export).
I support this draft being taken into the OPSAWG and hope/believe that it would mature into a full-fledged RFC in the near future.

Regards,

Anand Arokiaraj

-----Original Message-----
From: Joe Clarke (jclarke) <jclarke=[email-masked]<mailto:[email-masked]>>
Date: Sat, 18 Apr 2020 at 22:14
Subject: [OPSAWG] Call for adoption: draft-boydseda-ipfix-psamp-bulk-data-yang-model
To: opsawg <[email-masked]<mailto:[email-masked]>>

As was discussed in the April 7 virtual interim, we are doing a three-week call for opsawg adoption for this work.

This draft was an AD-sponsored work with Ignas and has now moved under Rob.  It has received a number of reviews (some thorough, some more cursory), and it is destined to obsolete 6728 (Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols) if ratified.  Because of that latter point, making this a WG item seems more appropriate than pushing it through as an AD-sponsored document.

To that end, does the WG feel this work is important and wants to take it up?  In a nutshell, this document breaks up the original YANG module into three for the IPFIX collector and exporter functions, the PSAMP functions, and the templates for bulk data exports.  While it preserves the SCTP support, SCTP is no longer mandatory.  It also adds support for ietf-interfaces and hardware management (those did not exist at the time of 6728).

The reason for the three-week call is to give people enough time to read through and digest this document.  Please reply with support (or objections) as well as comments by May 10, 2020.

Thanks.
Joe
_______________________________________________
OPSAWG mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 15 May 2020 15:08:58 +0000

[With AD hat on]

Hi,

I was really hoping that there would be more support for adopting this work in OPSAWG, given it covers both YANG and IPFIX it does seem like the correct home for it.

In general, I am keen that IETF continues to flesh out and improve YANG models for the protocols standardized in IETF.

I'm also not sure whether I would realistically be able to AD sponsor this document, given that I am new in the AD role, and this is currently a long document.  The document and YANG model both look like they are in reasonable shape, but probably could do with some more reviews.

I have a question for the authors:

Would it be feasible to split this work up into smaller chunks that would make it easier to review.  E.g. to put the packet-sampling and bulk-data-export into separate drafts?  Perhaps pare back some optional functionality.

And a question for the WG:

2) If this work was split up, and if I ask very nicely ;-), then is it possible that a few more people would be willing to help review a smaller shorter version of this document?

Regards,
Rob

> From: OPSAWG <[email-masked]> On Behalf Of Joe Clarke (jclarke)
> Sent: 18 April 2020 22:13
> To: opsawg <[email-masked]>
> This draft was an AD-sponsored work with Ignas and has now moved under
> Rob.  It has received a number of reviews (some thorough, some more
> cursory), and it is destined to obsolete 6728 (Configuration Data Model
> for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP)
> Protocols) if ratified.  Because of that latter point, making this a WG
> item seems more appropriate than pushing it through as an AD-sponsored
> document.
> 
> To that end, does the WG feel this work is important and wants to take it
> up?  In a nutshell, this document breaks up the original YANG module into
> three for the IPFIX collector and exporter functions, the PSAMP functions,
> and the templates for bulk data exports.  While it preserves the SCTP
> support, SCTP is no longer mandatory.  It also adds support for ietf-
> interfaces and hardware management (those did not exist at the time of
> 6728).
> 
> The reason for the three-week call is to give people enough time to read
> through and digest this document.  Please reply with support (or
> objections) as well as comments by May 10, 2020.
> 
> Thanks.
> 
> Joe
> [email-masked]

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Fri, 15 May 2020 15:40:52 +0000

> On May 15, 2020, at 11:08, Rob Wilton (rwilton) <[email-masked]> wrote:
> 
> [With AD hat on]
> 
> Hi,
> 

I will say (as a contributor) I would find it more manageable.

Joe

---

From: "Mehmet Ersue" <[email-masked]>
Date: Sat, 16 May 2020 16:02:28 +0300

Hi All,

although technically (and surprisingly) allowed I would like to state my
discomfort for publishing this draft as AD sponsored document. I believe a
draft which is proposed to replace a standard-track RFC developed with long
discussions and reviews in an IETF WG should be again re-discussed and
reviewed with its changes in a WG before publishing. Otherwise it feels like
bypassing IETF process. 

I personally have no big interest in this draft as I assume RFC 6728 has not
been used in the industry widely. Though if there is strong support in
OPSAWG for the changes in this draft and updating RFC 6728 I would be
supportive too. However I did not see such strong support in OPSAWG yet. I
think we also should clarify on the maillist whether the changes in the
draft are only technically interesting or sufficient amount of people in the
WG (excluding draft authors) are planning to implement and use.

If ever the WG decides to develop such a draft replacing RFC 6728 I believe
it should be divided in parts where the WG should at the first place focus
on changes related to RFC 6728. The decision on developing a draft on bulk
data transfer should be provided separately as I assume the interest on this
part would be less than updating the existing RFC. Dividing into parts makes
it indeed more manageable.

My 2 cents.

Cheers,
Mehmet

> From: OPSAWG <[email-masked]> On Behalf Of Rob Wilton
> (rwilton)
> Sent: Friday, May 15, 2020 6:09 PM
> To: Joe Clarke (jclarke) <[email-masked]>; opsawg <[email-masked]>;
> [email-masked]
> Subject: Re: [OPSAWG] Call for adoption: draft-boydseda-ipfix-psamp-bulk-
> data-yang-model
> 
> [With AD hat on]
> 
> Hi,
> 
> I was really hoping that there would be more support for adopting this
work
> in OPSAWG, given it covers both YANG and IPFIX it does seem like the
> correct home for it.
> 
> In general, I am keen that IETF continues to flesh out and improve YANG
> models for the protocols standardized in IETF.
> 
> I'm also not sure whether I would realistically be able to AD sponsor this
> document, given that I am new in the AD role, and this is currently a long
> document.  The document and YANG model both look like they are in
> reasonable shape, but probably could do with some more reviews.
> 
> Would it be feasible to split this work up into smaller chunks that would
make
> it easier to review.  E.g. to put the packet-sampling and bulk-data-export
into
> separate drafts?  Perhaps pare back some optional functionality.
> 
> 
> 2) If this work was split up, and if I ask very nicely ;-), then is it
possible that a
> few more people would be willing to help review a smaller shorter version
of
> this document?
> > Subject: [OPSAWG] Call for adoption:
> > draft-boydseda-ipfix-psamp-bulk-data-
> > yang-model
> >
> > As was discussed in the April 7 virtual interim, we are doing a
> > three-week call for opsawg adoption for this work.
> >
> > cursory), and it is destined to obsolete 6728 (Configuration Data
> > Model for the IP Flow Information Export (IPFIX) and Packet Sampling
> > (PSAMP)
> > Protocols) if ratified.  Because of that latter point, making this a
> > WG item seems more appropriate than pushing it through as an
> > AD-sponsored document.
> >
> > To that end, does the WG feel this work is important and wants to take
> > it up?  In a nutshell, this document breaks up the original YANG
> > module into three for the IPFIX collector and exporter functions, the
> > PSAMP functions, and the templates for bulk data exports.  While it
> > preserves the SCTP support, SCTP is no longer mandatory.  It also adds
> > support for ietf- interfaces and hardware management (those did not
> > exist at the time of 6728).
> >
> > The reason for the three-week call is to give people enough time to
> > read through and digest this document.  Please reply with support (or

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 16 May 2020 11:48:51 -0400

Are you really simultaneously saying
1) As far as you know, the existing draft is not being used
2) You do not want the working group to work on the replacement a number 
of operators need
3) And you oppose the AD sponsoring the work

You are not even saying you don't like it, as you also say you would not 
want to work on the problem.  Even ADs don't get to say "this should not 
go forward even though there is no technical objection."

Huh?
Yours,
Joel