[OPSAWG] Hi

___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] IPR poll for 3 IPFIX drafts

Hi Tianran, all, (ccing co-authors and interested contributors, fwiw) No, I'm not aware of any IPR that applies to these drafts. Cheers, Med De : OPSAWG De la part de Tianran Zhou Envoyé : mardi 6 juin 2023 08:12 À : opsawg Cc : opsawg-chairs Objet : [OPSAWG] IPR poll for 3 IPFIX drafts Hi

Re: [OPSAWG] draft-ietf-opsawg-ipfix-srv6-srh-14.txt

Hi Paul, Thank you for catching those. As the document is now in the RFC Editor Queue, I suggest that these are fixed during AUTH48. I trust the authors will keep a note about this request. I suspect that some of them will be catched by the RFC Editor, but will monitor this when the doc is in

Re: [OPSAWG] WG Adoption call for IPFIX

Hi Qin, Thanks for the comments. Much appreciated. Please see inline. Cheers, Med De : OPSAWG De la part de Qin Wu Envoyé : mardi 13 juin 2023 19:28 À : Tianran Zhou ; opsawg Cc : opsawg-chairs Objet : Re: [OPSAWG] WG Adoption call for IPFIX Support, a few comments below: draft-boucla-opsa

Re: [OPSAWG] WG Adoption call for IPFIX

Hi Éric, You are right that the content of twswg-udp-ipfix may be merged with the tcp draft. However, we prefer to leave these as separate I-Ds for logistic matters: twswg-udp-ipfix has a normative dependency on draft-ietf-tsvwg-udp-options/

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tsvwg-udp-ipfix-01.txt

agement 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 >Filename: draft-ietf-opsaw

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-fixes-01.txt

gt;Title : Simple Fixes to the IP Flow Information > Export (IPFIX) IANA Registry >Authors : Mohamed Boucadair > Benoit Claise >Filename: draft-ietf-opsawg-ipfix-fixes-01.txt >Pages : 39 >Date

Re: [OPSAWG] Fw: New Version Notification for draft-liu-opsawg-ipfix-network-slice-00.txt

Hi Yao, all, Thank you for sharing this draft. Good to have more interest in ops considerations of slicing. I’m ccing teas as you also circulated this draft there. The goal of the draft is completely fine. However, I don’t think we are ready yet to specify a generic NRP-ID IE for the following

Re: [OPSAWG] draft-ymbk-opsawg-9092-update-01

Hi Randy, Please find below some few minor comments on this update: (1) As a complement to the discussion in the first para of the Introduction, I would add a note that the source address does not necessary point to the user. You may add a pointer to https://datatracker.ietf.org/doc/html/rfc

Re: [OPSAWG] draft-ymbk-opsawg-9092-update-01

Hi Randy, Thank you for the follow-up. Please see inline. Cheers, Med > -Message d'origine- > De : Randy Bush > Envoyé : lundi 3 juillet 2023 20:25 > À : BOUCADAIR Mohamed INNOV/NET > Cc : Ops Area WG ; draft-ymbk-opsawg-9092- > upd...@ietf.org > Objet : Re: [OPSAWG] draft-ymbk-opsa

Re: [OPSAWG] New Version Notification for draft-palmero-opsawg-ps-almo-00.txt

Hi Marisol, all, Thank you for sharing this version. I like much this new version/approach/scope of the draft compared to the dmlmo draft I reviewed early this year. I expect more concrete description to be added to some of the use cases, but I trust that is something you can manage in the nex

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-03.txt

Hi Joe, all, On the port number point, I'm afraid that the arguments in Section 8 are more for justifying why distinct port numbers might be useful, not why a well-known port number has to be assigned. I would suggest to strengthen that part before making the request (see more in rfc6335#sectio

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-03.txt

Hi Joe, all, Thanks. I went and reviewed the spec in more detail. I'm afraid that simply pointing to that section in 7605 is not sufficient, especially that the spec: * requests for a service name: which can be used to discover address/port used by a server * asks for implementations t

Re: [OPSAWG] PCAP documents (was Re: I-D Action: draft-ietf-opsawg-pcap-03.txt)

Hi Michael, For this part: > draft-ietf-opsawg-pcaplinktype needs to be standards track to > establish the needed registries. The document does very little > else. I used to know that IANA registries can be created also for Info documents, including ISE published documents (see, e.g., https:/

Re: [OPSAWG] PCAP documents (was Re: I-D Action: draft-ietf-opsawg-pcap-03.txt)

Hi Michael, OK, thanks. Publishing the doc as Info would be OK then. I sent you right now a PR with some minor edits. For the specification required range, you may consider adding some guidance for DEs. The initial table does not mirror the current values in https://www.tcpdump.org/linktyp

Re: [OPSAWG] PCAP documents (was Re: I-D Action: draft-ietf-opsawg-pcap-03.txt)

Re-, Please see inline. Cheers, Med > -Message d'origine- > De : Michael Richardson > Envoyé : mercredi 26 juillet 2023 10:41 > À : BOUCADAIR Mohamed INNOV/NET ; > opsawg@ietf.org > Objet : Re: [OPSAWG] PCAP documents (was Re: I-D Action: draft- > ietf-opsawg-pcap-03.txt) > > > moha

Re: [OPSAWG] PCAP documents (was Re: I-D Action: draft-ietf-opsawg-pcap-03.txt)

Re-, That wouldn't be FCFS anymore but Expert Review. Those who applies for FCFS range should be aware that no filtering is applied other than requests are well-formed + not duplicating records. Cheers, Med > -Message d'origine- > De : Carsten Bormann > Envoyé : mercredi 26 juillet

Re: [OPSAWG] IPR poll for draft-ma-opsawg-ucl-acl-03

Hi Tianran, all, No, I'm not aware of any IPR that applies to this draft. Cheers, Med De : OPSAWG De la part de Tianran Zhou Envoyé : vendredi 1 septembre 2023 09:51 À : opsawg@ietf.org Cc : opsawg-cha...@ietf.org Objet : [OPSAWG] IPR poll for draft-ma-opsawg-ucl-acl-03 Hi WG, According to th

Re: [OPSAWG] [inventory-yang] poll for network inventory base model

Hi all, I do think that both documents include parts that are very relevant to the IVY work. I'm in favor of (3) with the chairs holding the pen at least for -00. It is unlikely that parts of (1) and (2) will be injected into (3). Cheers, Med De : Inventory-yang De la part de maqiufang (A)

[OPSAWG] draft-ietf-opsawg-ipfix-fixes: ipv6ExtensionHeaders

Hi all, draft-ietf-opsawg-ipfix-fixes creates a sub-registry to mirror the assignments in the IPv6 EH registry. The current text [1] says that codes are not assigned directly from the IPFIX sub-registry. Please let us know if we need to change that policy ? For example, whether we need to also

[OPSAWG] draft-ietf-opsawg-ipfix-fixes: tcpOptions/ipv4Options bit mappings

Hi all, The description of these IEs says that "Options are mapped to bits according to their option numbers. Option number X is mapped to bit X", however the drawing does not reflect that (tcpOptions): 0 1 2 3 4 5 6 7 +-+-+-+-+-+-

Re: [OPSAWG] draft-ietf-opsawg-ipfix-fixes: tcpOptions/ipv4Options bit mappings

Hi Paul, Yes, that's what I was referring to in my previous messages when I said "FWIW, (1) is what was followed in RFC5102 but changed since then by errata.". I'm having trouble with that errata as I don't understand why the reversal was only made at the octet level and not the full IE + how t

Re: [OPSAWG] draft-ietf-opsawg-ipfix-fixes: tcpOptions/ipv4Options bit mappings

Hi Paul, all, I digged into ipfix archives to see the discussion that happened around these errata and when scrolling I found this message: https://mailarchive.ietf.org/arch/msg/ipfix/v9ywSgTeYzataQnhMG-x7SxLo0U/ but no follow-up. This confirms my initial assessment that a fix is needed. Cheer

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-fixes-02.txt

.txt is now available. > It is a work item of the Operations and Management Area Working Group > (OPSAWG) WG of the IETF. > >Title: Simple Fixes to the IP Flow Information Export (IPFIX) > IANA Registry >Authors: Mohamed Boucadair > Benoit Claise >

Re: [OPSAWG] IPR POLL: Attachment circuits work

Hi Joe, all, No, I'm not aware of any IPR that applies to these drafts. Cheers, Med De : Joe Clarke (jclarke) Envoyé : lundi 25 septembre 2023 17:29 À : opsawg@ietf.org; BOUCADAIR Mohamed INNOV/NET ; Richard Roberts ; Oscar González de Dios ; samir.barg...@gmail.com; Wubo (lana) ; victor.lo

[OPSAWG] draft-ietf-opsawg-ucl-acl: User Access Control Group ID RADIUS Attribute

Hi RADEXT, FWIW, the document specifies the following new RADIUS attribute: https://boucadair.github.io/policy-based-network-acl/draft-ietf-opsawg-ucl-acl.html#name-user-access-control-group-i Your review of that part of the spec is appreciated. Thank you. Cheers, Med __

Re: [OPSAWG] CALL FOR ADOPTION: Attachment circuits work

Hi Joe, all, I support this work, obviously. This work is referenced by O-RAN and 3GPP. Cheers, Med De : OPSAWG De la part de Joe Clarke (jclarke) Envoyé : lundi 2 octobre 2023 15:22 À : opsawg@ietf.org Objet : [OPSAWG] CALL FOR ADOPTION: Attachment circuits work At IETF 117, we asked the roo

Re: [OPSAWG] draft-ietf-opsawg-ipfix-fixes: tcpOptions/ipv4Options bit mappings

Hi Andrew, all, Thank you for your effort and for digging into that impressive amount of scans. Much appreciated! I also agree that rather than deprecating this IE, a careful fix would be sufficient here. My suggestion is to leave the drawing that is already there, but remove the text about th

[OPSAWG] One or two documents RE: Some comments on draft-ietf-opsawg-ipfix-tcpo-v6eh

Hi Éric, Thank your for the comments. I will start by the easy one: "I still wonder why the tcpOptions and ipv6ExtensionHeaders are in the same I-D though ;-)" This was mainly for the authors convenience to avoid many I-Ds. We defer to the Chairs for this one. Cheers, Med De : OPSAWG De la

[OPSAWG] Desambiguite unknwon EH vs. unknown upper layer headers RE: Some comments on draft-ietf-opsawg-ipfix-tcpo-v6eh

Re-, Your comment about "unknown L4" reminded me another comment you had about how to disambiguate unknown EH vs. upper layer headers: Our local copy includes now the following NEW text: If an implementation determines that it includes an extension header that it does no support, then the

Re: [OPSAWG] [radext] draft-ietf-opsawg-ucl-acl: User Access Control Group ID RADIUS Attribute

Hi Alan, Thank you for the review and comments. We prepared a PR to address these at: https://github.com/boucadair/policy-based-network-acl/pull/18/files Please note that for this one: > It may be good to give an example packet, but that may also be too > restrictive. What should be disc

Re: [OPSAWG] Some IPv6 comments on draft-ietf-opsawg-ipfix-fixes-02

Hi Éric, Thank you for the review. Please see inline. Cheers, Med De : OPSAWG De la part de Eric Vyncke (evyncke) Envoyé : vendredi 6 octobre 2023 13:46 À : opsawg@ietf.org Cc : ip...@ietf.org Objet : [OPSAWG] Some IPv6 comments on draft-ietf-opsawg-ipfix-fixes-02 Benoît and Med, Thanks for

[OPSAWG] Full or Truncated EHs RE: Some comments on draft-ietf-opsawg-ipfix-tcpo-v6eh

Hi Éric, "There should be a way to convey the information that the exporter was (un)able to parse the *full* extension header chain due to HW limitation. This could be done by adding a bit/counter "KNOWN" (the opposite of UNKNOWN in the sense of a known layer-4 header)." I think that it would

[OPSAWG] count of EHs (RE: Some comments on draft-ietf-opsawg-ipfix-tcpo-v6eh

Re-, Focusing on this part of your comments: == About having counters per extension header how is "This Information Element echoes the order and number of occurrences" to be interpreted for the following flow? HBH-RH-DST HBH-DST-RH-FRA0-DST HBH-DST-RH-FRA1-... RH-DST Will it be a single IE wi

Re: [OPSAWG] [radext] draft-ietf-opsawg-ucl-acl: User Access Control Group ID RADIUS Attribute

Re-, Great, thanks. Yes, I confirm that the reference is cited as informative. Cheers, Med > -Message d'origine- > De : Alan DeKok > Envoyé : lundi 9 octobre 2023 14:26 > À : BOUCADAIR Mohamed INNOV/NET > Cc : rad...@ietf.org; opsawg ; draft-ma-opsawg-ucl- > a...@ietf.org > Objet :

[OPSAWG] Length of EHs RE: About draft-boucadair-opsawg-ipfix-tcpo-v6eh

Hi Éric, all, > - what would also be SUPER interesting / useful is the length of those > Ext Headers and their order... The order part of the comment was already addressed. For the length, I think that the aggregate length would be more useful to explain packet drops, use of slow paths, etc.

Re: [OPSAWG] Some IPv6 comments on draft-ietf-opsawg-ipfix-fixes-02

Re-, Thanks for the follow-up. For "No Next Header", I added the following so far to draft-ietf-opsawg-ipfix-tcpo-v6eh: The "No Next Header" (59) value is used if there is no upper-layer header in an IPv6 packet. Even if the value is not considered as an extension header as su

Re: [OPSAWG] AD review of draft-ietf-opsawg-rfc7125-update-03

Hi Rob, Thanks for the review. I agree having an example is useful to avoid that bit offset is interpreted as bit value. We do having the following in the introduction to basically say that we are echoing what is in RFC9293 about the meaning of offet: Also, Section 6 of [RFC9293] intro

Re: [OPSAWG] Length of EHs RE: About draft-boucadair-opsawg-ipfix-tcpo-v6eh

Hi Éric, Updated the name in my local copy. I'm not sure to get your question. Can you please clarify? Thanks. Cheers, Med De : Eric Vyncke (evyncke) Envoyé : mercredi 11 octobre 2023 18:06 À : BOUCADAIR Mohamed INNOV/NET ; opsawg@ietf.org Objet : Re: Length of EHs RE: About draft-boucadair-op

Re: [OPSAWG] AD review of draft-ietf-opsawg-rfc7125-update-03

Hi Rob, Thanks for the follow up. Looks good to me. This is now fixed in draft-ietf-opsawg-rfc7125-update-04 which is available online. Thanks. Cheers, Med > -Message d'origine- > De : Rob Wilton (rwilton) > Envoyé : jeudi 12 octobre 2023 12:53 > À : BOUCADAIR Mohamed INNOV/NET ; >

Re: [OPSAWG] [radext] draft-ietf-opsawg-ucl-acl: User Access Control Group ID RADIUS Attribute

Hi Heikki, Thank you for catching this. What is actually interesting is that we are discussing a PR to make the change in the other way around: https://github.com/boucadair/policy-based-network-acl/pull/20/files. Cheers, Med De : radext De la part de Heikki Vatiainen Envoyé : jeudi 12 octobr

Re: [OPSAWG] Artart last call review of draft-ietf-opsawg-rfc7125-update-05

Hi Tim, Thank you for the review. The changes made to take into account this review can be seen at: https://github.com/boucadair/-ipfix-rfc7125-update/pull/5/files. Please see inline for more context. Cheers, Med > -Message d'origine- > De : Tim Bray via Datatracker > Envoyé : lun

[OPSAWG] draft-ietf-opsawg-ipfix-tcpo-v6eh

Hi 6man, FWIW, the following specification is being developed in OPSWAG: https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh/ Comments to the extension headers part of the spec are welcome. Cheers, Med __

Re: [OPSAWG] CALL FOR ADOPTION: Attachment circuits work

Hi Joe, Yes, I confirm. See Slide # 7 of [1] (TEAS#117) or [2] (TEAS#116). Cheers, Med [1] https://datatracker.ietf.org/meeting/117/materials/slides-117-teas-attachment-circuits-updates-next-steps-00 [2] https://datatracker.ietf.org/meeting/116/materials/slides-116-teas-14-bearers-attachment-c

Re: [OPSAWG] Should the schedule YANG model be seperated from draft-ietf-opsawg-ucl-acl?

Hi Chairs, Now that the content was moved to a separate draft (https://datatracker.ietf.org/doc/draft-ma-opsawg-schedule-yang/) and that draft-ietf-opsawg-ucl-acl has a normative dependency on that new I-D, can we please consider issuing an adoption call for it? Thank you Cheers, Med De : Jo

Re: [OPSAWG] [IPFIX] Full or Truncated EHs RE: Some comments on draft-ietf-opsawg-ipfix-tcpo-v6eh

Hi Paul, Thanks for sharing your thoughts. Unless we hear objections, we will proceed with the following change: https://github.com/boucadair/ipfix-tcpoptions-and-v6eh/commit/aba9db5fec77a699b5a218c1893889320320b42f Cheers, Med De : Aitken, Paul Envoyé : mercredi 18 octobre 2023 14:15 À : Eric

Re: [OPSAWG] AD review of draft-ietf-opsawg-mud-iot-dns-considerations-08

Hi Michael, (Focusing on this specific comment and part of the text) * I don't think we can leave the ref to the bootstrap I-D as that was abandoned since a while. I was delete that citation. * Not sure why DoT/DoH is explicitly mentioned in that text. I think the reasoning should be more abou

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-tcpo-v6eh-04.txt

It is a work item of the Operations and Management Area > Working Group (OPSAWG) WG of the IETF. > >Title: Extended TCP Options and IPv6 Extension Headers IPFIX > Information Elements >Authors: Mohamed Boucadair > Benoit Claise >Name:draft-ietf-opsawg-ipf

Re: [OPSAWG] [IPFIX] Full or Truncated EHs RE: Some comments on draft-ietf-opsawg-ipfix-tcpo-v6eh

Hi Paul, Thank you for the review. A PR can be seen at: https://github.com/boucadair/ipfix-tcpoptions-and-v6eh/pull/10/files. Please see inline for more context. Cheers, Med De : Aitken, Paul Envoyé : jeudi 19 octobre 2023 21:05 À : BOUCADAIR Mohamed INNOV/NET Cc : ip...@ietf.org; Eric Vync

Re: [OPSAWG] Secdir last call review of draft-ietf-opsawg-rfc7125-update-05

Hi Shawn, Thank you for the review. This will be acked in the next version [1]. Cheers, Med [1] https://github.com/boucadair/-ipfix-rfc7125-update/commit/837b4c914e009c46fbdefa667bcec163671df01c > -Message d'origine- > De : Shawn Emery via Datatracker > Envoyé : vendredi 20 octobre

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-tcpo-v6eh-05.txt

roup (OPSAWG) WG of the IETF. > >Title: Extended TCP Options and IPv6 Extension Headers IPFIX > Information Elements >Authors: Mohamed Boucadair > Benoit Claise >Name:draft-ietf-opsawg-ipfix-tcpo-v6eh-05.txt >Pages: 15 >Dates: 2023-10-23 >

Re: [OPSAWG] draft-ietf-opsawg-rfc7125-update-05 review

Hi Paul, Thank you for the review. The changes can be tracked here: https://github.com/boucadair/-ipfix-rfc7125-update/commit/7af0cc67d2abbf7aed241b35098e48076e2923f8 See inline for more context. Cheers, Med > -Message d'origine- > De : Aitken, Paul > Envoyé : mercredi 25 octobre 2

Re: [OPSAWG] Genart last call review of draft-ietf-opsawg-rfc7125-update-05

Hi Elwyn, Thank you for the review. Please see inline. Cheers, Med > -Message d'origine- > De : Elwyn Davies via Datatracker > Envoyé : samedi 28 octobre 2023 00:07 > À : gen-...@ietf.org > Cc : draft-ietf-opsawg-rfc7125-update@ietf.org; last- > c...@ietf.org; opsawg@ietf.org >

Re: [OPSAWG] New Version Notification for draft-opsawg-poweff-00.txt

Hi Marisol, all, Thank you for sharing this document. FWIW, you may find some comments at: * Pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-opsawg-poweff-00-rev%20Med.pdf * Doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-opsawg-poweff-00-

[OPSAWG] Attachement Circuits Issue #14: bundling ACs

Hi all, Some deployments may imply some dynamicity in the terminating points of a service (e.g., containers). Providing stable AC references for the service that uses such ACs, while allowing to managing such dynamic AC is worth to consider. Leveraging the ac-group-profile and allowing for thes

[OPSAWG] Attachment Circuits Issue #6: multiple local subnets (local-address) - ip-connection list

Hi all, The structure of the ip-connection in the spec is inherited from LxNM, which reflect most deployments I'm aware of. Only one single local IP address is allowed for an AC as shown in the following tree: | ... +--rw ip-connection | +--rw ipv4 {vpn-common:ipv4}?

[OPSAWG] Attachment Circuits Issue #34: Add a flag for service feasibility check

Hi all, Ivan raised a comment about indicating in a service request whether this is a feasibility check only or an actual request for activation. As discussed in https://github.com/boucadair/attachment-circuit-model/issues/34, this functionality is natively supported in NETCONF but may not be a

Re: [OPSAWG] WG LC: draft-ietf-opsawg-9092-update

Hi Joe, all, I think the document is ready to move forward. Some very minor items to save Randy some cycles: * Abstract: add "This document obsoletes RFC 9092." * Abstract: s/datafiles/data files * The changes vs 9092 lists "Geofeed file only UTF-8 CSV", but the NEW abstract remove

Re: [OPSAWG] WG LC: draft-ietf-opsawg-9092-update

Re-, Thank you Randy for the follow-up. Please see one comment inline. Cheers, Med > -Message d'origine- > De : Randy Bush > Envoyé : mercredi 15 novembre 2023 18:07 > À : BOUCADAIR Mohamed INNOV/NET > Cc : Oops Area WG > Objet : Re: [OPSAWG] WG LC: draft-ietf-opsawg-9092-update > >

Re: [OPSAWG] ipfix-fwd-exceptions - Request WG adoption

Hi all, I agree with Benoît that the justification of limited space (64 values) seems to be weak given existing codes and proposed new ones. However, after reading RFC 7270, I think that there might be a value in refreshing the existing IE#89 for the sake of better interoperability and promotin

Re: [OPSAWG] WG LC: draft-ietf-opsawg-9092-update

Hi Randy, Deal! Thanks. Cheers, Med > -Message d'origine- > De : Randy Bush > Envoyé : jeudi 16 novembre 2023 17:37 > À : BOUCADAIR Mohamed INNOV/NET > Cc : Oops Area WG > Objet : Re: [OPSAWG] WG LC: draft-ietf-opsawg-9092-update > > how about rewording to remove second must so we d

Re: [OPSAWG] advancing PCAP drafts

Hi Michael, > 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. BTW, any update about how you addressed th

Re: [OPSAWG] advancing PCAP drafts

Hi Carsten, I already provided examples of Informational RFCs that create IANA registries (please refer to the thread). https://authors.ietf.org/required-content (IANA Considerations) does not mandate in the first bullet the track of the doc. Cheers, Med > -Message d'origine- > De :

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 R

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...@ci

Re: [OPSAWG] advancing PCAP drafts

Hi Michael, Hmm...I remember at least the following candidates changes from that thread, e.g., * https://mailarchive.ietf.org/arch/msg/opsawg/u0__66zIpCMHA4syzt8fWtyx98Y/ * https://mailarchive.ietf.org/arch/msg/opsawg/ExlyBZ9eRP_UHUvCAmtKu0b28Z4/ I trust that you will check that thread and do

Re: [OPSAWG] Paul Wouters' No Objection on draft-ietf-opsawg-rfc7125-update-06: (with COMMENT)

Hi Paul, Thank you for the review. Added a pointer and fixed the broken URL as you can see here: https://github.com/boucadair/-ipfix-rfc7125-update/pull/7/files. Cheers, Med > -Message d'origine- > De : OPSAWG De la part de Paul Wouters via > Datatracker > Envoyé : lundi 27 novembre

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-ac-lxsm-lxnm-glue-02.txt

-02.txt is now > available. It is a work item of the Operations and Management Area > Working Group (OPSAWG) WG of the IETF. > >Title: A YANG Data Model for Augmenting VPN Service and Network > Models with Attachment Circuits >Authors: Mohamed Boucadair >

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-ntw-attachment-circuit-02.txt

opsawg-ntw-attachment-circuit-02.txt > > Internet-Draft draft-ietf-opsawg-ntw-attachment-circuit-02.txt is now > available. It is a work item of the Operations and Management Area > Working Group (OPSAWG) WG of the IETF. > >Title: A Network YANG Data Model for Attachment Circuits

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-ac-lxsm-lxnm-glue-02.txt

> Action: draft-ietf-opsawg-ac-lxsm-lxnm-glue- > > 02.txt > > > > Internet-Draft draft-ietf-opsawg-ac-lxsm-lxnm-glue-02.txt is now > > available. It is a work item of the Operations and Management Area > > Working Group (OPSAWG) WG of the IETF. &

Re: [OPSAWG] WG LC: draft-ietf-opsawg-9092-update

Hi Michael, I guess Rob has to call this out in the last call; please see RFC8067: For Standards Track or BCP documents requiring normative reference to documents of lower maturity, the normal IETF Last Call procedure will be issued, with the need for the downward reference

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-ntw-attachment-circuit-03.txt

work YANG Data Model for Attachment Circuits >Authors: Mohamed Boucadair > Richard Roberts > Oscar Gonzalez de Dios > Samier Barguil Giraldo > Bo Wu >Name:draft-ietf-opsawg-ntw-attachment-circuit-03.txt >Pages: 94 >

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-teas-attachment-circuit-03.txt

G of the IETF. > >Title: YANG Data Models for 'Attachment Circuits'-as-a-Service > (ACaaS) >Authors: Mohamed Boucadair > Richard Roberts > Oscar Gonzalez de Dios > Samier Barguil Giraldo > Bo Wu >Name:

Re: [OPSAWG] New Version Notification for draft-opsawg-evans-discardmodel-01.txt

Hi John, FWIW, please find some comments at: * pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-opsawg-evans-discardmodel-01-rev%20Med.doc.pdf * doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-opsawg-evans-discardmodel-01-rev%20Med.doc I support t

Re: [OPSAWG] WGLC for draft-ietf-rtgwg-net2cloud-problem-statement

Hi Linda, This is actually defined in draft-ietf-opsawg-ntw-attachment-circuit-03. Please search for "violate-action" and "bgp-max-prefix". Only max prefix is handled at the network level. The AC spec does not d

Re: [OPSAWG] WGLC for draft-ietf-rtgwg-net2cloud-problem-statement

Hi Linda, This looks good except that that BGP model does not intend to expose a local configuration outside a domain. I suggest the following: NEW: Leveraging YANG models to programmatically synchronize configurations between BGP peers (e.g., [SVC-AC]) and to adjust the local configuration ac

Re: [OPSAWG] [IPv6] IOAM, iOAM, and oOAM abbreviations

Hi Greg, all, I personally prefer IOAM and OOAM. I suggest that you edit rfc6291-bis (BCP 161) with a discussion on this specific point and a reco. Cheers, Med De : ipv6 De la part de Greg Mirsky Envoyé : mercredi 13 décembre 2023 04:13 À : DetNet WG ; mpls ; 6man WG ; IETF IPPM WG ; opsawg

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-ntw-attachment-circuit-04.txt

gt; >Title: A Network YANG Data Model for Attachment Circuits >Authors: Mohamed Boucadair > Richard Roberts > Oscar Gonzalez de Dios > Samier Barguil Giraldo > Bo Wu >Name:draft-ietf-opsawg-ntw-attachment-circu

Re: [OPSAWG] Opsdir early review of draft-ietf-opsawg-ipfix-fixes-03

Hi Qin, (apologies for the delay to reply as I was out of office for the last three weeks) Thank you for the review. Please see inline. Cheers, Med > -Message d'origine- > De : Qin Wu via Datatracker > Envoyé : lundi 25 décembre 2023 13:51 > À : ops-...@ietf.org > Cc : draft-ietf-

Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-teas-common-ac-02

Hi Ebben, Thank you for the review. Updated the spec to take into account your comments as you can see at: https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-opsawg-teas-common-ac&url_2=https://boucadair.github.io/attachment-circuit-model/draft-ietf-opsawg-teas-common-ac.txt Please see

Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-teas-attachment-circuit-03

Hi Ebben, Thank you for the review. A new version that takes into account the review can be seen at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-teas-attachment-circuit-04 Please see inline for more context. Cheers, Med > -Message d'origine- > De : Ebben Aries via D

Re: [OPSAWG] Intdir early review of draft-ietf-opsawg-tsvwg-udp-ipfix-03

Hi Joe, Thanks for the review. Please see inline. Cheers, Med > -Message d'origine- > De : Joseph Touch via Datatracker > Envoyé : samedi 13 janvier 2024 05:03 > À : int-...@ietf.org > Cc : draft-ietf-opsawg-tsvwg-udp-ipfix@ietf.org; > opsawg@ietf.org > Objet : Intdir early revi

Re: [OPSAWG] Tsvart early review of draft-ietf-opsawg-tsvwg-udp-ipfix-03

Hi Tommy, Thank you for the review. The encoding should allow to export the full 256 range, but it is likely that fewer bits will be needed. unsigned32/unsigned64 are provided as examples to illustrate the use of reduced encoding (https://datatracker.ietf.org/doc/html/rfc7011#section-6.2). C

Re: [OPSAWG] Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05

Hi Wes, Thank you for the review. The changes to take into account your review can be seen at: https://github.com/boucadair/ipfix-tcpoptions-and-v6eh/commit/8bd7d7f92180a8eeaeb9ce13c0028a5c698b1738 Please see inline for more context. Cheers, Med > -Message d'origine- > De : Wesley

Re: [OPSAWG] Opsdir early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05

Hi Yingzhen, Thank you for the review. The changes to address your review can be seen at: https://github.com/boucadair/ipfix-tcpoptions-and-v6eh/commit/ee2f459370d67df88866600438f315d55a0942b9 Please see inline for more context. Cheers, Med > -Message d'origine- > De : Yingzhen Qu v

Re: [OPSAWG] Intdir early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05

Hi Dirk, Thank you for the review. Good catches. Fixed them all in https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh/06/. Cheers, Med > -Message d'origine- > De : Dirk Von Hugo via Datatracker > Envoyé : samedi 13 janvier 2024 18:01 > À : int-...@ietf.org > Cc : dra

Re: [OPSAWG] Genart early review of draft-ietf-opsawg-ipfix-fixes-03

Hi Behcet, Thank you for the review. Please see inline. Cheers, Med > -Message d'origine- > De : Behcet Sarikaya via Datatracker > Envoyé : lundi 8 janvier 2024 18:13 > À : gen-...@ietf.org > Cc : draft-ietf-opsawg-ipfix-fixes@ietf.org; opsawg@ietf.org; > sarik...@ieee.org > Obj

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tsvwg-udp-ipfix-05.txt

Export of UDP Options Information in IP Flow > Information Export (IPFIX) >Authors: Mohamed Boucadair > Tirumaleswar Reddy.K >Name:draft-ietf-opsawg-tsvwg-udp-ipfix-05.txt >Pages: 8 >Dates: 2024-01-15 > > Abstract: > >This document

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-tcpo-v6eh-07.txt

(OPSAWG) WG of the IETF. > >Title: Extended TCP Options and IPv6 Extension Headers IPFIX > Information Elements >Authors: Mohamed Boucadair > Benoit Claise >Name:draft-ietf-opsawg-ipfix-tcpo-v6eh-07.txt >Pages: 16 >Dates: 2024-01

Re: [OPSAWG] Tsvart early review of draft-ietf-opsawg-tsvwg-udp-ipfix-03

Hi Tommy, Thanks for clarifying. You have a valid point. Updated the type to point to unsigned256, which is now defined in draft-ietf-opsawg-ipfix-tcpo-v6eh. Cheers, Med > -Message d'origine- > De : Tommy Pauly > Envoyé : lundi 15 janvier 2024 15:06 > À : BOUCADAIR Mohamed INNOV/NET

Re: [OPSAWG] Intdir early review of draft-ietf-opsawg-tsvwg-udp-ipfix-03

Hi Joe, Thanks for the follow-up. Please see inline. Cheers, Med De : to...@strayalpha.com Envoyé : lundi 15 janvier 2024 17:17 À : BOUCADAIR Mohamed INNOV/NET Cc : int-...@ietf.org; draft-ietf-opsawg-tsvwg-udp-ipfix@ietf.org; opsawg@ietf.org Objet : Re: Intdir early review of draft-ietf

Re: [OPSAWG] Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05

Hi Wes, Please see inline. Cheers, Med De : Wesley Eddy Envoyé : mardi 16 janvier 2024 16:09 À : BOUCADAIR Mohamed INNOV/NET ; tsv-...@ietf.org Cc : draft-ietf-opsawg-ipfix-tcpo-v6eh@ietf.org; opsawg@ietf.org Objet : Re: Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05 The chan

Re: [OPSAWG] Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05

Hi Wes, Please see inline. Cheers, Med De : Wesley Eddy Envoyé : mardi 16 janvier 2024 21:21 À : BOUCADAIR Mohamed INNOV/NET ; tsv-...@ietf.org Cc : draft-ietf-opsawg-ipfix-tcpo-v6eh@ietf.org; opsawg@ietf.org Objet : Re: Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05 On 1/16/2

Re: [OPSAWG] [Int-dir] Intdir early review of draft-ietf-opsawg-tsvwg-udp-ipfix-03

Hi Joe, The very short introduction to SAFE/UNSAFE is there to help reader digest the difference between EXP and UEXP introduced right after and understand the rationale for having two IPFIX IEs. Of course, the authoritative reference for implementers is the TSVWG base spec; the exact section

Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-teas-attachment-circuit-03

Hi Ebben, Please see inline. Cheers, Med > -Message d'origine- > De : Ebben Aries > Envoyé : lundi 15 janvier 2024 16:49 > À : BOUCADAIR Mohamed INNOV/NET > Cc : yang-doct...@ietf.org; draft-ietf-opsawg-teas-attachment- > circuit@ietf.org; opsawg@ietf.org > Objet : Re: Yangdoctors

Re: [OPSAWG] 🔔 WG Adoption Call for draft-opsawg-evans-discardmodel-02

Hi all, I support adopting this document. The authors kindly addressed many of my comments in -02. Cheers, Med > -Message d'origine- > De : OPSAWG De la part de Henk Birkholz > Envoyé : mercredi 17 janvier 2024 13:52 > À : OPSAWG > Objet : [OPSAWG] 🔔 WG Adoption Call for draft-opsaw

Re: [OPSAWG] Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05

Re-, What about adding the following under "Operational Considerations": NEW: Implementations of tcpSharedOptionExID16 and tcpSharedOptionExID32 IEs are assumed to be provided with a list of valid Experiment IDs {{IANA-TCP-EXIDs}}. How that list is maintained is implementation-specific. Absent

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

Hi Carlos, Adrian, all, Thank you for editing this document. This is really useful. Alternate terms to consider for the path-congruent terms are path-coupled/path-decoupled OAM (inspired from RFC4080). When editing RFC 9451, I wish I had terms for: * "OAM packet that exclusively includes O

Re: [OPSAWG] [IPFIX] WG LC: IPFIX documents

Hi Paul, Thanks for the review. Please see inline. Cheers, Med De : ipv6 De la part de Aitken, Paul Envoyé : vendredi 19 janvier 2024 11:58 À : Joe Clarke (jclarke) ; opsawg@ietf.org Cc : t...@ietf.org; ts...@ietf.org; 6...@ietf.org; ip...@ietf.org Objet : Re: [IPv6] [IPFIX] WG LC: IPFIX docum

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-teas-common-ac-04.txt

ble. It is a work item of the Operations and Management Area > Working Group (OPSAWG) WG of the IETF. > >Title: A Common YANG Data Model for Attachment Circuits >Authors: Mohamed Boucadair > Richard Roberts > Oscar Gonzalez de Dios >

  1   2   3   4   >