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 On Behalf Of Rob Wilton > (rwilton) > Sent: Friday, May 15, 2020 6:09 PM > To: Joe Clarke (jclarke) ; opsawg ; > draft-boydseda-ipfix-psamp-bulk-data-yang-mo...@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 On Behalf Of Joe Clarke > > (jclarke) > > Sent: 18 April 2020 22:13 > > To: opsawg > > 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 ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Opsdir last call review of draft-ietf-opsawg-sdi-03
Reviewer: Mehmet Ersue Review result: Has Nits I reviewed the document "Secure Device Install (draft-ietf-opsawg-sdi-03) as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Intended status: Informational Current IESG state: I-D Exists IANA State: N/A Summary: The document extends existing auto-install / Zero-Touch Provisioning mechanisms to make the process more secure. There are no relevant draft nits in the document. Though there are a few typos, etc. s/There are also a/There is also a/ s/an auto-install techniques/an auto-install technique/ s/etc;/etc.;/ 5x s/e.g/e.g./ s/operations is/operations are/ As far as I can see the document has been repeatedly improved and is in good shape. I don't see any big issues related to management preventing from publication. Cheers, Mehmet ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Request for review: draft-boydseda-ipfix-psamp-bulk-data-yang-model
Hi Warren, Thank you for taking over the lead and responsibility for this draft. Yes, OPSAWG is the best place for this document to be discussed. Yes, the authors should ask for adoption / discussion here. And yes, it is necessary to have a significant discussion before allowing to obsolete a standard track RFC published at IETF after long discussions in IPFIX/PSAMP WGs. Cheers, Mehmet > -Original Message- > From: OPSAWG On Behalf Of Warren Kumari > Sent: Monday, January 27, 2020 6:22 PM > To: opsawg@ietf.org; draft-boydseda-ipfix-psamp-bulk-data-yang- > model@ietf.org; Paul Aitken ; Gerhard Muenz > ; Benoit Claise > Subject: Re: [OPSAWG] Request for review: draft-boydseda-ipfix-psamp- > bulk-data-yang-model > > Hi there all, > > A quick update - I'm now the responsible AD for this document; chairs / WG - > this feels very much like an OPSAWG document (PSAMP / IPFIX have > concluded, and much of the work has moved into OpsAWG). > Is there any reason why this **isn't** the best place for this document to be > discussed? Should the authors ask for adoption / discussion here? If not, > where should it be discussed? I'm uncomfortable progressing it without > significant discussion, especially because it "Obsoletes: 6728 (if approved)". > > W > > On Wed, Jan 22, 2020 at 5:38 PM Warren Kumari > wrote: > > > > Hi there all, > > > > Back in Nov 2018 Ignas agreed to AD sponsor this document. Directorate > > reviews were requested in Nov 2019[0], and two OpsDir reviews were > > supplied, both with the status "OPSDIR Last Call Review: Not Ready > > (partially completed)" : > > 1: > > https://datatracker.ietf.org/doc/review-boydseda-ipfix-psamp-bulk-data > > -yang-model-02-opsdir-lc-ersue-2019-12-01/ > > 2: > > https://datatracker.ietf.org/doc/review-boydseda-ipfix-psamp-bulk-data > > -yang-model-02-opsdir-lc-clarke-2019-12-20/ > > A third reviewer recently let us know that, due to other commitments / > > being over-committed they no longer have the time to complete this > > review either. > > > > However, the reviewers all felt that additional review / discussion > > was in order, and so I'm politely asking / begging OpsAWG to review / > > discuss. > > > > From the "Guidance on Area Director Sponsoring of Documents" > > (https://ietf.org/about/groups/iesg/statements/area-director-sponsorin > > g-documents/) > > : > > "The exact nature of the review within the IETF is not specified, but > > it is expected that documents be posted for review in the relevant WG > > mailing lists. Often no relevant mailing list exists, in which case > > area-specific or IETF main discussion list can be used. Individual > > reviewers, review teams, and review boards for specific topics can > > also be used. If no sufficient review has been obtained, the AD should > > solicit it explicitly." > > > > PSAMP (and IPFIX) is closed, and much of this discussion now occurs in > > OpsAWG. Joe (as one of the OpsAWG chairs) has agreed to let us use the > > OpsAWG list for this discussion / feedback, etc. > > > > To help jog people's memory, get the ball rolling, this was discussed > > at IETF 103: > > Minutes: https://datatracker.ietf.org/doc/minutes-103-opsawg/ > > Video (link to start of preso): https://youtu.be/PDVOfKqOb3Y?t=6680 > > > > So, please, read the draft, and the reviews, and provide feedback here > > > > > > I'd also like to sincerely thank Mehmet, Joe and Benoit for their > > (partial) reviews, and Gunter Van de Velde for organizing the OpsDir - > > they are incredibly helpful. > > > > W > > [0]: > > https://datatracker.ietf.org/doc/draft-boydseda-ipfix-psamp-bulk-data- > > yang-model/history/ > > > > -- > > I don't think the execution is relevant when it was obviously a bad > > idea in the first place. > > This is like putting rabid weasels in your pants, and later expressing > > regret at having chosen those particular rabid weasels and that pair > > of pants. > >---maf > > > > -- > I don't think the execution is relevant when it was obviously a bad idea in the > first place. > This is like putting rabid weasels in your pants, and later expressing regret at > having chosen those particular rabid weasels and that pair of pants. >---maf > > ___ > 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
[OPSAWG] FW: [OPS-DIR] Opsdir last call partial review of draft-boydseda-ipfix-psamp-bulk-data-yang-model-02
I think this draft should be reviewed and commented by OPSAWG WG before publishing as "AD sponsored standard track RFC" obsoleting RFC 6728. (RFC 6728 authors CCed). BR, Mehmet -Original Message- From: OPS-DIR On Behalf Of Mehmet Ersue via Datatracker Sent: Sunday, December 1, 2019 7:33 PM To: ops-...@ietf.org Cc: last-c...@ietf.org; opsawg@ietf.org; draft-boydseda-ipfix-psamp-bulk-data-yang-model@ietf.org Subject: [OPS-DIR] Opsdir last call partial review of draft-boydseda-ipfix-psamp-bulk-data-yang-model-02 Review is partially done. Another assignment may be needed to complete it. Reviewer: Mehmet Ersue Review result: Not Ready I reviewed the document "YANG Data Models for the IP Flow Information Export (IPFIX) Protocol, Packet Sampling (PSAMP) Protocol, and Bulk Data Export (draft-boydseda-ipfix-psamp-bulk-data-yang-model-02) as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Obsoletes: 6728 (if approved) Intended status: Standards Track Current IESG state: I-D Exists Summary: The document aims to replace the YANG model for packet sampling (PSAMP) and bulk data collection and export via the IPFIX protocol originally defined in standard track RFC 6728 (Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols). The YANG data model in the document also aims to be conform with the Network Management Datastore Architecture (NMDA) defined in RFC 8342. FYI: The YANG model is currently in review by Martin Bjorklund from YANG modeling perspective. The document further aims to decouple the PSAMP collecting process and the IPFIX exporting process as well as defining an exporting process which does not require SCTP support. The document tries to enable the export frequency to be controlled by the exporting process, support of large IPFIX mediation functions, and flexible referencing of interfaces. The new functionality described above and the necessary restructuring of the model in RFC 6728 might become useful if done properly as an extension to RFC 6728. However based on missing IPFIX and PSAMP expertise, unfortunately I'm not able to give a solid statement on to whether the document is capable to replace the standard track RFC 6728. Moreover the new functionality and changes to the original model require thorough and in-depth review by IPFIX and PSAMP experts. Also as the document is largely based on RFC 6728, introducing the authors of RFC 6728 as co-authors and involving them for review would very useful. As a minimum they need to be involved as reviewers and mentioned in the Acknowledgments section. The document is proposed to publish as an AD sponsored draft, which is not an issue per se. It is also not forbidden but very unusual that an AD sponsored draft is proposed to replace a standard track RFC. I would be highly interested to know why this path has been chosen. However I believe it is a substantial issue that this draft has not been discussed and supported in any IETF maillist until today. There was only a short presentation in OPSAWG WG session one year ago without any record of support. The authors are not known at IETF and have not written any other than the current draft. The authors have most likely BBF background. As IPFIX and PSAMP WGs have already concluded, I would like to recommend _urgently_ to introduce the draft to OPSAWG maillist and ask for support. It is IMO essentially important that the document gets discussed and reviewed by IPFIX and PSAMP people available in OPSAWG and by the authors of RFC 6728 before publication. It also needs to be clarified whether the draft has been already or is going to be implemented. In case there is no support in OPSAWG WG for this draft to replace the standard track RFC 6728 I believe it would be appropriate to publish it as an "AD sponsored Experimental RFC". It can still become a standard track RFC after getting implementation reports and appropriate community feedback on its usage. Sorry for not being the right expert reviewer for the draft content. Therefore I've set the review result to "Partially Completed - extra reviewer is to be assigned" and hope the draft gets a proper review in OPSAWG WG and by the authors of RFC 6728. Mehmet ___ OPS-DIR mailing list ops-...@ietf.org https://www.ietf.org/mailman/listinfo/ops-dir ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Opsdir last call partial review of draft-boydseda-ipfix-psamp-bulk-data-yang-model-02
Review is partially done. Another assignment may be needed to complete it. Reviewer: Mehmet Ersue Review result: Not Ready I reviewed the document "YANG Data Models for the IP Flow Information Export (IPFIX) Protocol, Packet Sampling (PSAMP) Protocol, and Bulk Data Export (draft-boydseda-ipfix-psamp-bulk-data-yang-model-02) as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Obsoletes: 6728 (if approved) Intended status: Standards Track Current IESG state: I-D Exists Summary: The document aims to replace the YANG model for packet sampling (PSAMP) and bulk data collection and export via the IPFIX protocol originally defined in standard track RFC 6728 (Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols). The YANG data model in the document also aims to be conform with the Network Management Datastore Architecture (NMDA) defined in RFC 8342. FYI: The YANG model is currently in review by Martin Bjorklund from YANG modeling perspective. The document further aims to decouple the PSAMP collecting process and the IPFIX exporting process as well as defining an exporting process which does not require SCTP support. The document tries to enable the export frequency to be controlled by the exporting process, support of large IPFIX mediation functions, and flexible referencing of interfaces. The new functionality described above and the necessary restructuring of the model in RFC 6728 might become useful if done properly as an extension to RFC 6728. However based on missing IPFIX and PSAMP expertise, unfortunately I'm not able to give a solid statement on to whether the document is capable to replace the standard track RFC 6728. Moreover the new functionality and changes to the original model require thorough and in-depth review by IPFIX and PSAMP experts. Also as the document is largely based on RFC 6728, introducing the authors of RFC 6728 as co-authors and involving them for review would very useful. As a minimum they need to be involved as reviewers and mentioned in the Acknowledgments section. The document is proposed to publish as an AD sponsored draft, which is not an issue per se. It is also not forbidden but very unusual that an AD sponsored draft is proposed to replace a standard track RFC. I would be highly interested to know why this path has been chosen. However I believe it is a substantial issue that this draft has not been discussed and supported in any IETF maillist until today. There was only a short presentation in OPSAWG WG session one year ago without any record of support. The authors are not known at IETF and have not written any other than the current draft. The authors have most likely BBF background. As IPFIX and PSAMP WGs have already concluded, I would like to recommend _urgently_ to introduce the draft to OPSAWG maillist and ask for support. It is IMO essentially important that the document gets discussed and reviewed by IPFIX and PSAMP people available in OPSAWG and by the authors of RFC 6728 before publication. It also needs to be clarified whether the draft has been already or is going to be implemented. In case there is no support in OPSAWG WG for this draft to replace the standard track RFC 6728 I believe it would be appropriate to publish it as an "AD sponsored Experimental RFC". It can still become a standard track RFC after getting implementation reports and appropriate community feedback on its usage. Sorry for not being the right expert reviewer for the draft content. Therefore I've set the review result to "Partially Completed - extra reviewer is to be assigned" and hope the draft gets a proper review in OPSAWG WG and by the authors of RFC 6728. Mehmet ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
