Hi John,
I would personally prefer if we use RFC 8791 to model the IM as an abstract
data structure. The mapping with JSON will be straightforward per RFC7951.
An advantage I see in using 8791 is that related data models can reuse the
groupings that can be defined in the parent IM and, thus,
Hi Joe,
Works for me [1]. Will queue the change for the next iteration.
Thank you.
Cheers,
Med
[1]
https://github.com/boucadair/udp-ipfix/commit/5d7394f847d45619bd95527f44827fdc5537560c
De : to...@strayalpha.com
Envoyé : vendredi 24 mai 2024 01:43
À : BOUCADAIR Mohamed INNOV/NET
Cc :
Re-,
Thanks. Please see one comment inline.
Cheers,
Med
De : Aitken, Paul
Envoyé : jeudi 23 mai 2024 18:31
À : BOUCADAIR Mohamed INNOV/NET ;
drafts-expert-review-comm...@iana.org; Joe Touch
Cc : ie-doct...@ietf.org; opsawg@ietf.org
Objet : Re: [IANA #1363824] Expert review for
Re-,
Please share the OLD/NEW text that you would like to see and will implement it.
Thanks.
Cheers,
Med
De : Aitken, Paul
Envoyé : jeudi 23 mai 2024 17:16
À : BOUCADAIR Mohamed INNOV/NET ;
drafts-expert-review-comm...@iana.org; Joe Touch
Cc : ie-doct...@ietf.org; opsawg@ietf.org
Objet :
Re-,
> Is it possible to use unsigned256, say that topmost bits must be
> zero, and reduced size encoding MAY be used?
That was exactly what I initially proposed, but you seemed to question the RSE
applicability
(https://mailarchive.ietf.org/arch/msg/opsawg/VfPqkyXB07fe9VEneTXZ_2Z0-BY/)
Hi Paul,
What prevails in that text is the wording in the guidance.
Made the changes to avoid confusion:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-tcpo-v6eh-15
Thanks.
Cheers,
Med
De : Aitken, Paul
Envoyé : mercredi 22 mai 2024 22:25
À : BOUCADAIR Mohamed INNOV/NET ;
Hi Jouni,
Good catch. This is now fixed in -11.
Thank you for the review.
Cheers,
Med
> -Message d'origine-
> De : Jouni Korhonen via Datatracker
> Envoyé : mercredi 22 mai 2024 05:57
> À : ops-...@ietf.org
> Cc : draft-ietf-opsawg-tsvwg-udp-ipfix@ietf.org; last-
>
Hi Paul,
-10 fixes all these, including the ToC level.
Thank you.
Cheers,
Med
De : Aitken, Paul
Envoyé : mardi 21 mai 2024 22:58
À : BOUCADAIR Mohamed INNOV/NET ;
drafts-expert-review-comm...@iana.org
Cc : ie-doct...@ietf.org; opsawg
Objet : Re: [Ie-doctors] [IANA #1363822] Expert review
Hi Doug, all,
Thank you for preparing this update.
Please find below minor items that you may fix before or after the WGLC. Fixing
them before would be my preference, though :-)
* Header
OLD: Updates: RFC8907 (if approved)
OLD: Updates: 8907 (if approved)
* Title
OLD: TACACS+ over TLS 1.3
wg-boun...@ietf.org>> De la
part de Douglas Gash (dcmgash)
Envoyé : mercredi 20 mars 2024 16:40
À : opsawg@ietf.org<mailto:opsawg@ietf.org>
Cc : John Heasley mailto:h...@shrubbery.net>>; Andrej Ota
mailto:and...@ota.si>>
Objet : Re: [OPSAWG] New Version Notification for
Hi Joe,
Great. Thank you.
Cheers,
Med
De : to...@strayalpha.com
Envoyé : vendredi 17 mai 2024 23:14
À : BOUCADAIR Mohamed INNOV/NET
Objet : Re: [Last-Call] Intdir last call review of
draft-ietf-opsawg-tsvwg-udp-ipfix-08
AOK - all set.
Joe
—
Dr. Joe Touch, temporal epistemologist
Hi Hilarie,
(ccing OPSAWG)
Thank you. The review will be ACKed in the next iteration.
Cheers,
Med
> -Message d'origine-
> De : Hilarie Orman
> Envoyé : lundi 20 mai 2024 06:49
> À : i...@ietf.org; sec...@ietf.org
> Cc : draft-ietf-opsawg-ipfix-fixes@ietf.org
> Objet : Security
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-ipfix-tcpo
Hi Valery,
(ccing the OPSAWG to have a public record of your excellent review).
All good points. Many thanks.
I trust the authors will follow up SOON.
Please see some comments from my side.
Cheers,
Med
De : Valery Smyslov
Envoyé : jeudi 16 mai 2024 15:24
À : BOUCADAIR Mohamed INNOV/NET
Cc
Hi Reza,
Thank you for the review.
We don’t provide the full structure but snippets per the guidance in
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-11#name-tree-diagrams.
We provided the following in Section 4:
==
The full tree diagram of the module can be generated
Hi Krzysztof,
Thank you for the review.
Can you please check and let us know if any further change is needed:
Hi Joe,
Thank you for the follow-up.
A candidate version can be seen at: Diff: draft-ietf-opsawg-tsvwg-udp-ipfix.txt
-
cuit-10.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
>Authors: Mohamed Boucadair
> Richard Roberts
> Oscar Go
cuit-12.txt
> is now available. It is a work item of the Operations and
> Management Area Working Group (OPSAWG) WG of the IETF.
>
>Title: YANG Data Models for Bearers and 'Attachment
> Circuits'-as-a-Service (ACaaS)
>Authors: Mohamed Boucadair
> R
A Common YANG Data Model for Attachment Circuits
>Authors: Mohamed Boucadair
> Richard Roberts
> Oscar Gonzalez de Dios
> Samier Barguil Giraldo
> Bo Wu
>Name:draft-ietf-opsawg-teas-common-ac-11.txt
>Pages: 57
>
Hi Reza,
Thank you for preparing the writeup.
Please see inline.
Cheers,
Med
De : Rokui, Reza
Envoyé : lundi 13 mai 2024 21:35
À : Joe Clarke (jclarke) ; opsawg@ietf.org; BOUCADAIR
Mohamed INNOV/NET ; Wubo (lana)
; Richard Roberts ; Oscar González
de Dios ;
Hi Paul,
The new version with all received reviews and comments is available at:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tsvwg-udp-ipfix/
Please see inline.
Cheers,
Med
De : Aitken, Paul
Envoyé : lundi 13 mai 2024 21:53
À : BOUCADAIR Mohamed INNOV/NET ;
Hi Paul,
Thanks for double checking.
I don’t think there is a conflict between 3.3/3.4-3.6 because these are
covering distinct aspects of the information export.
Fixed the nit.
Cheers,
Med
De : Aitken, Paul
Envoyé : lundi 13 mai 2024 22:13
À : BOUCADAIR Mohamed INNOV/NET ;
Hi Tero,
Thank you for the review.
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Tero Kivinen via Datatracker
> Envoyé : jeudi 9 mai 2024 17:35
> À : sec...@ietf.org
> Cc : draft-ietf-opsawg-ipfix-tcpo-v6eh@ietf.org; last-
> c...@ietf.org; opsawg@ietf.org
> Objet
Hi Paul,
Thanks for the review.
Please see inline.
You may also see the diff that integrates your comments and intdir review:
Diff: draft-ietf-opsawg-tsvwg-udp-ipfix.txt -
Hi Joe,
Thank you for the excellent review.
The changes to address the review can be seen here:
Hi Paul,
Thank you for the careful review, as usual. Much appreciated!
The diff to track all the changes (including other reviewers) can be seen at:
Diff: draft-ietf-opsawg-ipfix-tcpo-v6eh-11.txt -
Hi Paul,
Thank you for the review. The changes can be tracked at: Diff:
draft-ietf-opsawg-ipfix-fixes-08.txt -
Hi Donald,
Thank you for the review.
I like the suggestions. I went with almost all of them (except the one about
the ToC) as you can see in the candidate version:
https://boucadair.github.io/attachment-circuit-model/draft-ietf-opsawg-teas-attachment-circuit.txt.
Cheers,
Med
> -Message
Hi Tiru,
Many thanks for the review. Forwarding it to the list, fwiw.
I trust the authors will follow up. See one comment inline.
Cheers,
Med
De : tirumal reddy
Envoyé : mardi 7 mai 2024 15:17
À : BOUCADAIR Mohamed INNOV/NET
Cc : draft-ietf-opsawg-tacacs-tl...@ietf.org
Objet : Re: Request to
Re-,
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Michael Richardson
> Envoyé : lundi 6 mai 2024 12:18
> À : BOUCADAIR Mohamed INNOV/NET ;
> opsawg@ietf.org
> Objet : Re: [OPSAWG] advancing PCAP drafts
>
>
> {please ignore unicast message I sent thirty seconds ago}
>
Hi Donald,
Thanks for the review.
All good suggestions. I went with all of the suggestions, except the refs:
Hi Watson,
Thank you for the review.
The review will be ACKed in the next iteration:
https://github.com/boucadair/udp-ipfix/pull/5/commits/d1ea84a92a972e4ed00f408fd70362c2101b26a9
Cheers,
Med
> -Message d'origine-
> De : Watson Ladd via Datatracker
> Envoyé : dimanche 5 mai 2024
Hi Robert,
Thanks for the review.
The changes made to take into account your comment can be seen at:
Hi Joel,
Thank you for the review.
You got it right. Please see more context at [1].
I updated the text to address your review. Please check the diff [1] and let
me know if any further change is needed. Thanks.
Cheers,
Med
[1]
Hi Eliot,
Thank you for addressing these. Please find some additional comments:
1. I created a PR for some minor points:
https://github.com/elear/opsawg-ol/pull/3/files: TLP + follow the guidance for
the list names.
2. I know that you don’t use the security template in 8520, but given that
Hi Michael,
Thank you for fixing this.
FWIW, I created a PR that you can see at:
https://github.com/IETF-OPSAWG-WG/draft-ietf-opsawg-pcap/pull/154/files. Please
grab whatever you think useful out there.
I think that it would be useful to have a new column to easily tag the status
of an
Hi Dirk,
Thank you for the review.
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Dirk Von Hugo via Datatracker
> Envoyé : jeudi 25 avril 2024 17:05
> À : int-...@ietf.org
> Cc : draft-ietf-opsawg-ipfix-tcpo-v6eh@ietf.org; last-
> c...@ietf.org; opsawg@ietf.org
>
Hi Guy,
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Guy Harris
> Envoyé : jeudi 25 avril 2024 09:53
> À : BOUCADAIR Mohamed INNOV/NET
> Cc : Michael Richardson ; opsawg@ietf.org
> Objet : Re: [OPSAWG] advancing PCAP drafts
>
>
> On Apr 25, 2024, at 12:04 AM,
Hi Michael,
Any update about this draft?
Other than fixing a bug in Table 3.1, I thought that we were close to the WGLC.
However, I checked
Hi Alan,
Please see one comment inline.
Cheers,
Med
> -Message d'origine-
> De : OPSAWG De la part de Alan DeKok
> Envoyé : mardi 23 avril 2024 17:20
> À : opsawg
> Objet : Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-tls13-
> 07.txt
>
>
> Some comments on the latest draft:
Re-,
This can wait unless the Chairs are planning to apply for an early port/service
request SOON.
Cheers,
Med
Orange Restricted
De : Douglas Gash (dcmgash)
Envoyé : mardi 23 avril 2024 17:16
À : BOUCADAIR Mohamed INNOV/NET ; opsawg@ietf.org
Cc : Andrej Ota ; John Heasley ; Thorsten
Dahm
Hi Doug,
Thank you for the updates. Looks good to me.
Noted the pending point about 9525, though.
One minor comment about the description in Section 7, I suggest to update
"Description: Login Host Protocol (TACACSS)" to mention TLS or "secure" in the
description to differentiate the new entry
Hi all,
Like Michael, I'm puzzled about the development of this draft.
I raised comments back in 05/2021 that I reiterated during the call for
adoption:
https://mailarchive.ietf.org/arch/msg/opsawg/OlkjFOk55hB-29UG4FQaNbunXTY/ but
still see the same issues in 2024. Putting aside the
psawg@ietf.org<mailto:opsawg@ietf.org>
Cc : John Heasley mailto:h...@shrubbery.net>>; Andrej Ota
mailto:and...@ota.si>>
Objet : Re: [OPSAWG] New Version Notification for
draft-ietf-opsawg-tacacs-tls13-06.txt
Dear OPSAWG,
We have uploaded a new version of the doc, primarily to
rej Ota
mailto:and...@ota.si>>
Objet : Re: [OPSAWG] New Version Notification for
draft-ietf-opsawg-tacacs-tls13-06.txt
Dear OPSAWG,
We have uploaded a new version of the doc, primarily to address as much as
possible of the comprehensive review kindly submitted by Mohamed Boucadair. We
than
Hi Joe, all,
No, I'm not aware of any IPR that applies to these drafts.
Cheers,
Med
De : OPSAWG De la part de Joe Clarke (jclarke)
Envoyé : vendredi 19 avril 2024 16:32
À : opsawg@ietf.org
Objet : [OPSAWG] IPR POLL: Attachment circuits work
We're up to WG LC on these four drafts. And while
À : opsawg@ietf.org
Cc : John Heasley ; Andrej Ota
Objet : Re: [OPSAWG] New Version Notification for
draft-ietf-opsawg-tacacs-tls13-06.txt
Dear OPSAWG,
We have uploaded a new version of the doc, primarily to address as much as
possible of the comprehensive review kindly submitted by Mohamed
Hi Mahesh,
Thank you for the review.
The candidate version can be seen at: Diff:
draft-ietf-opsawg-tsvwg-udp-ipfix.txt -
Hi Martin,
Thank you for the review.
Good point about the ranges. Updated the text as you can see at:
https://github.com/boucadair/simple-ipfix-fixes/pull/10/files.
I double checked the registry and found that same issue should be fixed for
other IEs:
Re-,
I'm afraid so.
I may see a construct where one would need to insist that "virtual out-of-band"
is actually relying on an underlying (physical/shared) in-band thing. But,
something which is in-band; no matter whether this is virtual or physical, it
is still in-band.
Cheers,
Med
>
Hi Greg, all,
Having this discussion is by its own sufficient to justify why we need to amend
rfc6291 with terms that reflect recent needs/usages in a manner that can be
easily and generally visible to the target audience.
For example, Michael indicated that he wished he had a better name for
Hi Mahesh,
Please see inline.
Cheers,
Med
Orange Restricted
De : Mahesh Jethanandani
Envoyé : lundi 15 avril 2024 22:47
À : BOUCADAIR Mohamed INNOV/NET
Cc : draft-ietf-opsawg-ipfix-tcpo-v...@ietf.org; opsawg@ietf.org;
pait...@ciena.com
Objet : Re: AD review of
Hi Mahesh,
Thank you for the follow-up. Will proceed with the submission of the new
version.
Please see inline.
Cheers,
Med
De : Mahesh Jethanandani
Envoyé : lundi 15 avril 2024 21:05
À : BOUCADAIR Mohamed INNOV/NET
Cc : draft-ietf-opsawg-ipfix-fi...@ietf.org; opsawg@ietf.org
Objet : Re: AD
Hi Mahesh,
Thank you for the review.
The changes can be tracked at: Diff: draft-ietf-opsawg-ipfix-tcpo-v6eh.txt -
Hi Mahesh,
Thank you for the review.
The candidate version to address your review can be seen at: Diff:
draft-ietf-opsawg-ipfix-fixes.txt -
Hi all,
This is really useful work. I support adoption.
Some coordination with other WGs will be needed, but I'm confident
Carlos/Adrian will drive that through.
I have comments about some of the proposed terms: consider path coupled/path
decoupled OAM instead of path path-congruent terms +
.txt
>
>
> Internet-Draft draft-ietf-opsawg-teas-attachment-circuit-10.txt is now
> available. It is a work item of the Operations and Management Area
> Working Group (OPSAWG) WG of the IETF.
>
>Title: YANG Data Models for Bearers and 'Attachment Circuits'-as-
> a-Se
atest version 6 and the ideas behind the concept of
> the draft makes sense, however some additional recommendations on
> clarity of the draft I believe is necessary before publication.
>
> This draft was presented at IETF 117 last summer by Mohamed Boucadair
> and adopted on November 6th 20
d the ideas behind the concept of
the draft makes sense, however some additional recommendations on
clarity of the draft I believe is necessary before publication.
This draft was presented at IETF 117 last summer by Mohamed Boucadair
and adopted on November 6th 2023. As the draft was adopted fairly
rec
Hi all,
As indicated in IETF#119, we suggest to tag this issue as closed and proceed
with the publication of the current versions of the various I-Ds.
Cheers,
Med
De : BOUCADAIR Mohamed INNOV/NET
Envoyé : vendredi 23 février 2024 15:55
À : 'Aitken, Paul' ; 'Joe Clarke (jclarke)'
;
sion 5 and the ideas behind the concept of
> the draft makes sense, however some additional recommendations on
> clarity of the draft I believe is necessary before publication.
>
> This draft was presented at IETF 117 last summer by Mohamed Boucadair
> and adopted on November 6th 2023. As the dr
ndations on
> clarity of the draft I believe is necessary before publication.
>
> This draft was presented at IETF 117 last summer by Mohamed Boucadair
> and adopted on November 6th 2023. As the draft was adopted fairly
> recently, my goal is to catch any issues with the draft before
Hi Andy,
Thank you for the review. Much appreciated.
Your review will be acked in next iteration of the spec:
https://github.com/boucadair/attachment-circuit-model/commit/7de5b2ad817cb61813ef896885b2296d00d002bc
Cheers,
Med
> -Message d'origine-
> De : Andy Smith via Datatracker
>
Hi Donald,
FYI, the changes are now published as -08.
Thank you.
Cheers,
Med
De : Donald Eastlake
Envoyé : mardi 12 mars 2024 03:05
À : BOUCADAIR Mohamed INNOV/NET
Cc : opsawg@ietf.org; draft-ietf-opsawg-teas-attachment-circuit@ietf.org;
Routing Directorate ; t...@ietf.org
Objet : Re:
Hi Donald,
(adding OPSAWG as it seems the review was not shared on that list)
Thanks for the careful review.
A diff to track the changes to address your comments can be seen at:
Hi Paul,
Do you still think there is an issue with the design? Thanks.
Cheers,
Med
De : BOUCADAIR Mohamed INNOV/NET
Envoyé : mardi 23 janvier 2024 14:56
À : 'Aitken, Paul' ; Joe Clarke (jclarke)
; opsawg@ietf.org
Cc : ip...@ietf.org
Objet : octetArray/hextetArray/32tetArray RE: Re: [IPFIX] WG
Hi Paul,
Unless I'm mistaken, I didn't see any follow-up to this issue.
May I consider this point as closed? Thanks.
Cheers,
Med
De : BOUCADAIR Mohamed INNOV/NET
Envoyé : mardi 23 janvier 2024 14:23
À : 'Aitken, Paul' ; Aitken, Paul
; Joe Clarke (jclarke)
; opsawg@ietf.org
Cc :
and Management Area
> Working Group (OPSAWG) WG of the IETF.
>
>Title: YANG Data Models for Bearers and 'Attachment Circuits'-as-
> a-Service (ACaaS)
>Authors: Mohamed Boucadair
> Richard Roberts
> Oscar Gonzalez de Dios
>
anagement 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
> Samier Barguil Giraldo
> Bo Wu
Hi all,
FWIW, the proposed changes are now implemented in the published version:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ntw-attachment-circuit-05.
Cheers,
Med
> -Message d'origine-
> De : BOUCADAIR Mohamed INNOV/NET
> Envoyé : jeudi 25 janvier 2024 13:46
> À : 'Martin
Hi Martin, all,
FWIW, the proposed changes are now implemented in the public version:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ac-lxsm-lxnm-glue-06.
Cheers,
Med
> -Message d'origine-
> De : BOUCADAIR Mohamed INNOV/NET
> Envoyé : jeudi 25 janvier 2024 13:56
> À :
Hi all,
Bob is right here.
However, the intent of the original text is unambiguous as per the following:
==
Description
This Information Element describes the forwarding status of the
flow and any attached reasons. The reduced-size encoding rules as
per [RFC7011] apply.
ing 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-v6eh-10.txt
>Pages: 20
>Dates: 2024
f-opsawg-ipfix-fixes-06.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
> Ben
Hi all,
As no objection was raised in the last two weeks, I will tag these two IEs as
deprecated by the new IEs.
Cheers,
Med
De : Benoit Claise
Envoyé : lundi 5 février 2024 17:37
À : BOUCADAIR Mohamed INNOV/NET ; Aitken, Paul
; Joe Clarke (jclarke)
; opsawg@ietf.org
Cc : ip...@ietf.org
Extended TCP Options and IPv6 Extension Headers IPFIX Information
Elements
Authors: Mohamed Boucadair
Benoit Claise
Name:draft-ietf-opsawg-ipfix-tcpo-v6eh-09.txt
Pages: 16
Dates: 2024-01-23
Abstract:
This document specifies new IP Flow Information Expor
Hi Michael,
Thanks for the follow-up.
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Michael Richardson
> Envoyé : mercredi 31 janvier 2024 15:10
> À : BOUCADAIR Mohamed INNOV/NET ;
> opsawg@ietf.org
> Objet : Re: [OPSAWG] advancing PCAP drafts
>
>
>
Hi Thomas, all,
Thanks for preparing the writeup. Looks good to me.
I hope to receive more feedback on whether we mark these two IEs as
deprecated.
For forwardingStatus, I reiterate that the type should be unsigned32
as per the RFC.
Cheers,
Med
De : thomas.g...@swisscom.com
Hi Authors, all,
Many thanks for your effort on this document.
I managed finally to read the new version. I'm afraid that some of the comments
in
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-opsawg-tacacs-tls13-03-rev%20Med.pdf
were not addressed or at least I fail
Hi Martin,
Thank you for the follow-up.
Fixed the nits in the yang file. Also updated the module to make use of the new
groupings for referencing purposes instead of the broken typedefs in the
ac-ntw:
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
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
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:
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
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
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
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
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) ;
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
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;
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
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
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-,
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
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
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:
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
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
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
1 - 100 of 191 matches
Mail list logo
