Re: [OPSAWG] [Last-Call] Intdir last call review of draft-ietf-opsawg-9092-update-06
RFC 9092 includes a normative reference to RFC 8805.The shepherd writeup for draft-ietf-opsawg-finding-geofeeds (which eventually became RFC 8805) calls out this downref. The downward references were referenced in the Last Call: https://mailarchive.ietf.org/arch/search/?q=draft-ietf-opsawg-finding-geofeeds At this point, RFC 5485 and RFC 8805 should have been added to the downref registry; however I do not see either of them here https://datatracker.ietf.org/doc/downref I hope the OPS AD can correct this now. Russ > On Nov 20, 2023, at 6:36 AM, Sheng Jiang via Datatracker > wrote: > > Reviewer: Sheng Jiang > Review result: Ready with Nits > > I have reviewed this document as part of the IntArea directorate's ongoing > effort to review all IETF documents being processed by the IESG. Comments that > are not addressed in last call may be included in AD reviews during the IESG > review. Document editors and WG chairs should treat these comments just like > any other last call comments. > > Document: draft-ietf-opsawg-9092-update-06 > Reviewer: Sheng Jiang > Review Date: 2023-11-20 > Result: Ready with Nits > > This Standards Track document specifies how to augment the > Routing Policy Specification Language inetnum: class to > refer specifically to geofeed data files and describes an > optional scheme that uses the Resource Public Key > Infrastructure to authenticate the geofeed datafiles. It intends > to obsolete RFC 9092. It is well written and almost ready with > several Nits regarding to references, see beloww. > > Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) > Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) > Downref: Normative reference to an Informational RFC: RFC 8805 ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Aiming to charter a new "Network Management Operations" WG
Hi, I just wanted to let everyone know that I'm trying to charter a new "Network Management Operations" WG. We are in the process of discussing the charter scope, WG name, and initial work, currently on the ne...@ietf.org open mailing list. I'm hoping to get put a draft version of the charter in the Datatracker by this Thursday so that it can be considered by the IESG next Thursday. Please join this list if you are potentially interested in the new work (although, it seems fairly likely that the working group will get chartered with a different name and email address). If you would like to see what has been discussed so far, then please look at the archives here: https://mailarchive.ietf.org/arch/browse/netmo/, and in particular the outline of my plan here: https://mailarchive.ietf.org/arch/msg/netmo/xgkZ1hqYnndqlIYFMXmk6pn_l_s/, and details of the initial charter here: https://mailarchive.ietf.org/arch/msg/netmo/i9d4SqPtbGJmU0KZtauC3YTJFbE/ Regards, Rob ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-rfc7125-update-06: (with COMMENT)
Hi Éric, Thank you for the review. Please see inline. Cheers, Med > -Message d'origine- > De : Éric Vyncke via Datatracker > Envoyé : lundi 20 novembre 2023 13:18 > À : The IESG > Cc : draft-ietf-opsawg-rfc7125-upd...@ietf.org; opsawg- > cha...@ietf.org; opsawg@ietf.org; jcla...@cisco.com; jcla...@cisco.com > Objet : Éric Vyncke's No Objection on draft-ietf-opsawg-rfc7125- > update-06: (with COMMENT) > > Éric Vyncke has entered the following ballot position for > draft-ietf-opsawg-rfc7125-update-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this introductory paragraph, however.) > > > -- > COMMENT: > -- > > # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-rfc7125-update- > 06 > > Thank you for the work put into this document. ROA are indeed critical > for the > security and stability of the Internet. As usual for a -bis document, > I > reviewed only the diffs. > > Please find below some non-blocking COMMENT points (but replies would > be > appreciated even if only for my own education), and one nit. > > Special thanks to Joe Clarke for the shepherd's detailed write-up > including the > WG consensus *and* the justification of the intended status. > > I hope that this review helps to improve the document, > > Regards, > > -éric > > # COMMENTS > > ## Misleading file name > > While not important at this stage, this document appears more like a > 7125-bis > than a 7125-update. > [Med] The effort started actually as an update but we went for a bis during the development of the document. > ## Section 3 > > In which cases can the Exporter deviate from the SHOULD in `SHOULD use > reduced-size encoding` ? > [Med] Please note that this SHOULD is inherited from RFC7125. The SHOULD can be relaxed when the exporter wants the collector to have an explicit indication about all the bits. That is indirectly covered by the following (also inherited from 7125): A Collector receiving this Information Element with reduced-size encoding must not assume anything about the content of the four bits with bit offset positions 4 to 7. > # NITS > > ## Section 3 > > Suggest to either use actions (on receiving) or roles(i.e., Exporter) > in all > clauses in `this Information Element MUST be exported with a value of > zero and > MUST be ignored by the Collector` > [Med] I made some changes that you can see at: https://github.com/boucadair/-ipfix-rfc7125-update/pull/6/files. Not sure if that addresses your comment, though. Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] advancing PCAP drafts
mohamed.boucad...@orange.com wrote: > Noted for the second point. However, I think there is more than > mirroring the table. I remember that we discussed deprecating values > (?) and ensuring some consistency for future assignments vs. the > historic range. In what way is the draft unclear about how things would go forward? I don't know that we can effectively deprecate anything; but we could certainly try. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-rfc7125-update-06: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-rfc7125-update-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc7125-update/ -- COMMENT: -- # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-rfc7125-update-06 Thank you for the work put into this document. ROA are indeed critical for the security and stability of the Internet. As usual for a -bis document, I reviewed only the diffs. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and one nit. Special thanks to Joe Clarke for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric # COMMENTS ## Misleading file name While not important at this stage, this document appears more like a 7125-bis than a 7125-update. ## Section 3 In which cases can the Exporter deviate from the SHOULD in `SHOULD use reduced-size encoding` ? # NITS ## Section 3 Suggest to either use actions (on receiving) or roles(i.e., Exporter) in all clauses in `this Information Element MUST be exported with a value of zero and MUST be ignored by the Collector` ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] IETF 118 opsawg minute
Thanks to Rob Wills and Rob Wilton (and any others that contributed to the minutes). The minutes from both opsawg sessions at IETF 118 (Monday and Wednesday) have been imported from HedgeDoc and are available at https://datatracker.ietf.org/meeting/118/materials/minutes-118-opsawg-202311061200-00. There have already been some on-list post-meeting discussions for some of the presented work, which is great. There was one chair action item noted, which was to poll the WG to see if there was an appetite to take on a bis to I2RS’s RFC8345 based on lessons learned on the digital map and specific routing protocol management fronts. That said, Rob Wilton is working on a new operator-centric OPS WG (tentatively called “netmo”) where this bis work was mentioned as perhaps happening there. Therefore, we’d like to get AD input as to whether we first discuss this with opsawg or wait until this new WG forms. Of course, all other comments/corrections on the minutes are welcome. Joe ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Intdir last call review of draft-ietf-opsawg-9092-update-06
Thank you for the review, Sheng Jiang. OPSAWG appreciates it. Joe From: Sheng Jiang via Datatracker Date: Monday, November 20, 2023 at 06:36 To: int-...@ietf.org Cc: draft-ietf-opsawg-9092-update@ietf.org , last-c...@ietf.org , opsawg@ietf.org Subject: Intdir last call review of draft-ietf-opsawg-9092-update-06 Reviewer: Sheng Jiang Review result: Ready with Nits I have reviewed this document as part of the IntArea directorate's ongoing effort to review all IETF documents being processed by the IESG. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document: draft-ietf-opsawg-9092-update-06 Reviewer: Sheng Jiang Review Date: 2023-11-20 Result: Ready with Nits This Standards Track document specifies how to augment the Routing Policy Specification Language inetnum: class to refer specifically to geofeed data files and describes an optional scheme that uses the Resource Public Key Infrastructure to authenticate the geofeed datafiles. It intends to obsolete RFC 9092. It is well written and almost ready with several Nits regarding to references, see beloww. Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) Downref: Normative reference to an Informational RFC: RFC 8805 ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Intdir last call review of draft-ietf-opsawg-9092-update-06
Reviewer: Sheng Jiang Review result: Ready with Nits I have reviewed this document as part of the IntArea directorate's ongoing effort to review all IETF documents being processed by the IESG. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document: draft-ietf-opsawg-9092-update-06 Reviewer: Sheng Jiang Review Date: 2023-11-20 Result: Ready with Nits This Standards Track document specifies how to augment the Routing Policy Specification Language inetnum: class to refer specifically to geofeed data files and describes an optional scheme that uses the Resource Public Key Infrastructure to authenticate the geofeed datafiles. It intends to obsolete RFC 9092. It is well written and almost ready with several Nits regarding to references, see beloww. Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) Downref: Normative reference to an Informational RFC: RFC 8805 ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] advancing PCAP drafts
Hi Michael, Noted for the second point. However, I think there is more than mirroring the table. I remember that we discussed deprecating values (?) and ensuring some consistency for future assignments vs. the historic range. Thanks. Cheers, Med > -Message d'origine- > De : Michael Richardson > Envoyé : vendredi 17 novembre 2023 14:56 > À : BOUCADAIR Mohamed INNOV/NET ; > opsawg@ietf.org > Objet : Re: [OPSAWG] advancing PCAP drafts > > > mohamed.boucad...@orange.com wrote: > >> draft-ietf-opsawg-pcaplinktype - Standards Track to create > Registry > > > I thought that we agreed that this justification for PS is not > accurate > > (1): "linktypes "highest" level is Specification Required". A > better > > reason should be provided. > > I'd heard that the ISE couldn't create registries of the kind we > wanted, and that WG processing was not too a difficult change. > > > BTW, any update about how you addressed the comments: > > > https://mailarchive.ietf.org/arch/msg/opsawg/7yE7THneT48DBzmGq3e5M_bwO > ok/? > > I would do a final pass to import linktypes.html just before WGLC, and > then update linktypes.html to note that new document exists. > > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- *I*LIKE*TRAINS* > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
