Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-pcaplinktype-03.txt
internet-dra...@ietf.org wrote: > Diff: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-pcaplinktype-03 readers will find: https://author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-pcaplinktype-01&url2=draft-ietf-opsawg-pcaplinktype-03&difftype=--html more useful because the table in -02 is broken. I notice that in -01 the table seems constrained to 72 columns,but not in -03. I am not certain how to fix this, or what happened. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] I-D Action: draft-ietf-opsawg-pcaplinktype-03.txt
Internet-Draft draft-ietf-opsawg-pcaplinktype-03.txt is now available. It is a work item of the Operations and Management Area Working Group (OPSAWG) WG of the IETF. Title: Link-Layer Types for PCAP and PCAPNG Capture File Formats Authors: Guy Harris Michael C. Richardson Name:draft-ietf-opsawg-pcaplinktype-03.txt Pages: 18 Dates: 2024-04-26 Abstract: This document creates an IANA registry for the PCAP and PCAPNG LINKTYPE values. The PCAP and PCAPNG formats are used to save network captures from programs such as tcpdump and wireshark, when using libraries such as libpcap. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-pcaplinktype/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-opsawg-pcaplinktype-03.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-pcaplinktype-03 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] advancing PCAP drafts
mohamed.boucad...@orange.com wrote: > However, I checked > https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-opsawg-pcaplinktype&url_2=https://IETF-OPSAWG-WG.github.io/draft-ietf-opsawg-pcap/draft-ietf-opsawg-pcaplinktype.txt > and I'm afraid that your main copy override many changes agreed in the > past. May be I'm not looking in the right branch? There is definitely a failure on my part to git push after the last posting. Guy then patched somethings, and I've just dealt with the conflict. Trailing periods on a bunch of entries. type 209, name changed. Some line wrapping changes too. The table got broken in -02, sorry about that. https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-opsawg-pcaplinktype-01&url_2=https%3A%2F%2FIETF-OPSAWG-WG.github.io%2Fdraft-ietf-opsawg-pcap%2Fdraft-ietf-opsawg-pcaplinktype.txt might be a better diff. I will post -03 now. Let me paste in here the Designated Expert advice. What do you think about sentence two? We aren't telling them not to accept specifications that are hard to get at, but rather to maybe push a bit for something more accessible. # Guidance for Designated Experts When processing a request for a Specification Required allocation the Designated Experts are expected to be able to find the relevant specification at a clearly stable URL. It is noted that many enterprise web sites do not maintain URLs over a long period of time, and a documented in a "wp-uploaded" section is highly likely to disappear. In addition Specifications that require a reader to click through any kind of marketing or legal agreement are not considered public. (This is the opinion of other corporate lawyers, who worry about what their employees might have agreed to) The specification needs to be clearly written, and when the contents of the link type can contain an IPv4 or IPv6 header, then the octets between the beginning of the link type and the IP header needs to be very clearly specified in that document. Specifications which are not publically available, but which may be obtained via liason agreements (such as to ITU-T, 3GPP, IEEE, etc.) are acceptable particularly if the document will be public eventually, but are discouraged. For other documents, the Designated Expert will need use their judgement, or consult the WG or an Area Director. Linktypes may be allocated for specifications not publically available may be made within the First-Come/First-Served area. This includes specifications that might be classified. The minimal requirement is for a contact person for that link type. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] I-D Action: draft-ietf-opsawg-tsvwg-udp-ipfix-08.txt
Internet-Draft draft-ietf-opsawg-tsvwg-udp-ipfix-08.txt is now available. It is a work item of the Operations and Management Area Working Group (OPSAWG) WG of the IETF. Title: Export of UDP Options Information in IP Flow Information Export (IPFIX) Authors: Mohamed Boucadair Tirumaleswar Reddy.K Name:draft-ietf-opsawg-tsvwg-udp-ipfix-08.txt Pages: 10 Dates: 2024-04-26 Abstract: This document specifies new IP Flow Information Export (IPFIX) Information Elements for UDP options. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Operations and Management Area Working Group Working Group mailing list (opsawg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/opsawg/. Source for this draft and an issue tracker can be found at https://github.com/boucadair/udp-ipfix. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tsvwg-udp-ipfix/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-opsawg-tsvwg-udp-ipfix-08.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-tsvwg-udp-ipfix-08 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Last Call: (Export of UDP Options Information in IP Flow Information Export (IPFIX)) to Proposed Standard
The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'Export of UDP Options Information in IP Flow Information Export (IPFIX)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-05-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies new IP Flow Information Export (IPFIX) Information Elements for UDP options. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Operations and Management Area Working Group Working Group mailing list (opsawg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/opsawg/. Source for this draft and an issue tracker can be found at https://github.com/boucadair/udp-ipfix. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-opsawg-tsvwg-udp-ipfix/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: draft-ietf-tsvwg-udp-options: Transport Options for UDP (None - Internet Engineering Task Force (IETF)) ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Last Call: (Extended TCP Options and IPv6 Extension Headers IPFIX Information Elements) to Proposed Standard
The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'Extended TCP Options and IPv6 Extension Headers IPFIX Information Elements' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-05-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies new IP Flow Information Export (IPFIX) Information Elements (IEs) to solve issues with existing ipv6ExtensionHeaders and tcpOptions IPFIX IEs, especially the ability to export any observed IPv6 extension headers or TCP options. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh/ No IPR declarations have been submitted directly on this I-D. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Last Call: (Simple Fixes to the IP Flow Information Export (IPFIX) IANA Registry) to Proposed Standard
The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'Simple Fixes to the IP Flow Information Export (IPFIX) IANA Registry' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-05-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides simple fixes to the IANA IP Flow Information Export (IPFIX) registry. Specifically, this document provides updates to fix a shortcoming in the description of some Information Elements (IE), updates to ensure a consistent structure when calling an existing IANA registry, and updates to fix broken pointers, orphaned section references, etc. The updates are also meant to bring some consistency among the entries of the registry. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes/ No IPR declarations have been submitted directly on this I-D. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] IPR POLL: Attachment circuits work
Thank you to all authors and named contributors. We have received acknowledgement that there is no currently known IPR associated with these drafts. As a reminder, IPR disclosure is not just a do-it-when-polled thing. If you learn of IPR at any point in the process, you must disclose as part of the guidelines in BCP79 and the relevant RFCs below. The WG LC on this work is still open until May 10. Joe From: OPSAWG on behalf of Joe Clarke (jclarke) Date: Friday, April 19, 2024 at 10:33 To: opsawg@ietf.org Subject: [OPSAWG] IPR POLL: Attachment circuits work We’re up to WG LC on these four drafts. And while we did an IPR poll before, we want to be thorough since this work has evolved. https://datatracker.ietf.org/doc/draft-ietf-opsawg-ntw-attachment-circuit/ https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-attachment-circuit/ https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-common-ac/ https://datatracker.ietf.org/doc/draft-ietf-opsawg-ac-lxsm-lxnm-glue/ Are you aware of any IPR that applies to drafts identified above? Please state either: "No, I'm not aware of any IPR that applies to these drafts” or "Yes, I'm aware of IPR that applies to these drafts" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3669, 5378 and 8179 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules” or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author. Also please send the response to the list above, and not unicast it. As of this time, no IPR has been disclosed on any of the four drafts. Joe ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Notes on draft-gfz-opsawg-ipfix-alt-mark
Dear authors, I finally got some time to read the draft. I have the same comment as Greg, Standard track seems more appropriate. Also, I have also read RFC9341 and Alt-Mark can also compute the delay between the ingress interface and the egress interface within a single node (node monitoring). I have done a quick research on the IPFIX registry, AFAIK, the only delays defined in that registry are from the current work from draft-ietf-opsawg-ipfix-on-path-telemetry. Yet this delay is between the encapsulating node and the local node. I wonder if it is worth defining an IE for the delay between the ingress and the egress interface within a single node. I would imagine an implementation able to monitor both interfaces and just exporting the average delay directly from the node (or even the mean, max, min as draft-ietf-opsawg-ipfix-on-path-telemetry are doing). Any thoughts about this? Other than that, I think the draft is well written and it explains clearly why these IEs are necessary for IPFIX. Regards, Alex > On 25 Apr 2024, at 17:19, Greg Mirsky wrote: > > Dear, Authors et al., > thank you for your continued work on the Alternate Marking method. In my > opinion, draft-gfz-opsawg-ipfix-alt-mark provides an essential IEs making the > use of IPFIX operationally viable option for the Alternate Marking method. > While I've read the document, it seems that its current track, Informational, > may not be consistent with the request for specific actions from IANA. Could > it be that the Standard track is more appropriate for the draft? > > Regards, > Greg > > ___ > 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
Re: [OPSAWG] Notes on draft-gfz-opsawg-ipfix-alt-mark
Hi Greg, Thank you for your review and for your opinion of the draft. I fully agree that the intended status must be standards track. I will change it in the next revision. Regards, Giuseppe From: Greg Mirsky Sent: Thursday, April 25, 2024 10:20 AM To: opsawg ; IETF IPPM WG ; draft-gfz-opsawg-ipfix-alt-m...@ietf.org Subject: Notes on draft-gfz-opsawg-ipfix-alt-mark Dear, Authors et al., thank you for your continued work on the Alternate Marking method. In my opinion, draft-gfz-opsawg-ipfix-alt-mark provides an essential IEs making the use of IPFIX operationally viable option for the Alternate Marking method. While I've read the document, it seems that its current track, Informational, may not be consistent with the request for specific actions from IANA. Could it be that the Standard track is more appropriate for the draft? Regards, Greg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
