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 <[email protected]> On Behalf Of Rob Wilton > (rwilton) > Sent: Friday, May 15, 2020 6:09 PM > To: Joe Clarke (jclarke) <[email protected]>; opsawg <[email protected]>; > [email protected] > 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 <[email protected]> On Behalf Of Joe Clarke > > (jclarke) > > Sent: 18 April 2020 22:13 > > To: opsawg <[email protected]> > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
