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

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

> -----Original Message-----
> From: OPSAWG <opsawg-bounces@ietf.org> On Behalf Of Rob Wilton
> (rwilton)
> Sent: Friday, May 15, 2020 6:09 PM
> To: Joe Clarke (jclarke) <jclarke@cisco.com>; opsawg <opsawg@ietf.org>;
> draft-boydseda-ipfix-psamp-bulk-data-yang-model@ietf.org
> 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.
> 
> 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
> 
> 
> > -----Original Message-----
> > From: OPSAWG <opsawg-bounces@ietf.org> On Behalf Of Joe Clarke
> > (jclarke)
> > Sent: 18 April 2020 22:13
> > To: opsawg <opsawg@ietf.org>
> > 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.
> >
> > 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
> > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsawg
> 
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg