Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-ntw-attachment-circuit-04

Hi Martin, Thanks for the review. Please see inline. Cheers, Med > -Message d'origine- > De : Martin Björklund via Datatracker > Envoyé : mercredi 24 janvier 2024 16:20 > À : yang-doct...@ietf.org > Cc : draft-ietf-opsawg-ntw-attachment-circuit@ietf.org; > opsawg@ietf.org > Objet 

Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-ac-lxsm-lxnm-glue-04

Hi Martin, Thanks for the review. FWIW, a new version that fixes the nit you reported and other minor pending we had is available online: https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ac-lxsm-lxnm-glue-05 Cheers, Med > -Message d'origine- > De : Martin Björklund via

Re: [OPSAWG] [**EXTERNAL**] RE: [IPFIX] WG LC: IPFIX documents

Hi Paul, Thanks for the follow-up. Much appreciated. Please see inline. Cheers, Med De : Aitken, Paul Envoyé : mardi 23 janvier 2024 18:25 À : BOUCADAIR Mohamed INNOV/NET ; Joe Clarke (jclarke) ; opsawg@ietf.org Cc : t...@ietf.org; ts...@ietf.org; 6...@ietf.org; ip...@ietf.org Objet : Re:

[OPSAWG] deprecating ipv6ExtensionHeaders and tcpOptions IEs RE: [IPFIX] WG LC: IPFIX documents

Re-, Paul suggested to tag these two IEs as deprecated in favor of the new full IEs. I do personally think this is OK (especially given what Andrew reported at: https://mailarchive.ietf.org/arch/msg/opsawg/QNm9p8V2vKuhUX5rxBCqcxD-WAY/), but would like to hear if there objections to proceed

[OPSAWG] octetArray/hextetArray/32tetArray RE: Re: [IPFIX] WG LC: IPFIX documents

Hi Paul, (restricted the distribution lists to OPSAWG and IPFIX) The octetArray type is especially confusing as these are really hextetArrays. [Med] Not sure we need a new data type here as octeArray is defined as follows: The octetArray data type has no encoding rules; it represents a raw

[OPSAWG] Bitfields vs. Unsigned RE: Re: [IPFIX] WG LC: IPFIX documents

Hi Paul, > It is consistent but wrong, as the numeric value of these fields is > meaningless. Bitfields with flags semantics don't have a meaningful > "unsigned" value. You raised this comment for both TCP/UDP specs. As I mentioned in the previous message, all existing IEs of type flags are

[OPSAWG] errata eid7775 RE: [**EXTERNAL**] RE: [IPFIX] WG LC: IPFIX documents

Re-, Please see inline. Cheers, Med De : Aitken, Paul Envoyé : mardi 23 janvier 2024 11:26 À : BOUCADAIR Mohamed INNOV/NET ; Joe Clarke (jclarke) ; opsawg@ietf.org Cc : t...@ietf.org; ts...@ietf.org; 6...@ietf.org; ip...@ietf.org Objet : Re: [**EXTERNAL**] RE: [IPFIX] WG LC: IPFIX documents

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

Hi Paul, Thank you very much for the detailed review. There are some points that are common to the udp spec. Will discuss those in separate threads. Please see inline. Cheers, Med De : tsvwg De la part de Aitken, Paul Envoyé : vendredi 19 janvier 2024 10:52 À : Joe Clarke (jclarke) ;

Re: [OPSAWG] draft-ietf-opsawg-ipfix-tcpo-v6eh-08 shepherd review

Hi Thomas, Thank you much for preparing the writeup. I'm not sure I received the comments mentioned in point 14 of the writeup, though. I suspect this is because of the issues I'm having with the IETF aliases. Please forward me offline these comments. Thanks and apologies for the

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

Hi Paul, Thank you for the careful review and good suggestions. Went with almost all of them. Please see inline for more context. Cheers, Med De : ipv6 De la part de Aitken, Paul Envoyé : lundi 22 janvier 2024 22:50 À : Joe Clarke (jclarke) ; opsawg@ietf.org Cc : t...@ietf.org;

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

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 > Sam

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

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

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]  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

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:

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] 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

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

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

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

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

WG) 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-15 &

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

t 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 speci

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 >

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 :

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

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] 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).

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

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

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_2=https://boucadair.github.io/attachment-circuit-model/draft-ietf-opsawg-teas-common-ac.txt Please see

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 :

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

>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-circuit-04

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] 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

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

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

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

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:draft-ietf-ops

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

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 >Dat

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-ac-lxsm-lxnm-glue-02.txt

on: 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] I-D Action: draft-ietf-opsawg-ntw-attachment-circuit-02.txt

g-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

glue-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 > R

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

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] É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;

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

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, > 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

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

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

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] 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

[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

[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] 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

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:

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] 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

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

WG) 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 > > Ab

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] [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

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

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-ipfix-tcpo-v6

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

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 À :

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 :

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]

[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] 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é :

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

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] 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

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]

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

[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] [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] 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

[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

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

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

[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

[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

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

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

[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] 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) ;

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

xes-02.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 >Name:

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.

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

[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

[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

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)

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

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] 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) > > >

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

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.,

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

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

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

<    1   2   3   >