Dear Linda,
Thanks a lot for the review. We addressed your comment in revision -20.
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-on-path-telemetry-20
Doc:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-on-path-telemetry-20
Best wishes
Thomas
-Orig
Dear Tal, Carlos and Adrian,
As an individual, I have reviewed the latest revision of the document.
DOCX:
https://github.com/network-analytics/ietf-network-analytics-document-status/blob/main/document-review/draft-ietf-opsawg-oam-characterization-09.docx
PDF:
https://github.com/network-analytic
Dear Paul,
Thanks a lot! Quick and good catch.
I addressed here:
https://author-tools.ietf.org/diff?doc_1=draft-ietf-opsawg-ipfix-on-path-telemetry-18&url_2=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-on-path-telemetry/refs/heads/main/draft-ietf-opsawg-ipfix-on-pa
Dear OPSAWG,
No, I'm not aware of any IPR that applies to this draft
Best wishes
Thomas
From: Benoit Claise
Sent: Tuesday, July 1, 2025 9:44 PM
To: Dan-work Voyer ; daniel.vo...@bell.ca; Sriram
Gopalakrishnan (sriragop) ; Graf Thomas,
SCS-INI-NET-VNC-E2E ; vyas...@juniper.net; opsawg
Subjec
Dear Mahesh, Paul, Behcet and Qin,
Thanks a lot for your confirmation. We merged your feedback in -18.
Section 4 was removed per Paul's request due its duplication with section 5.2.
There are no more open action items.
Best wishes
Thomas
-Original Message-
From: internet-dra...@ietf.o
Dear Joe,
I haven't gone through all the points yet with the authors but the following
point catches my eyes:
JC> With respect to the platform-id, its description states, "The 'id' has to
be unique within the network scope at every point in time. The same id can
point to different platform if
Dear Joe,
I agreed to be listed as an author. Changing RFC 9232 to be informative makes
perfectly sense since the term "Network Telemetry" is used as overall context
so understand to which data the platform manifest is being used. Moreover
YANG-Push notifications, RFC 8639 and RFC 8641 are norm
Dear Jean,
Apologies for late reply. Thanks a lot. That addresses my comments.
Best wishes
Thomas
From: Jean Quilbeuf
Sent: Monday, June 16, 2025 4:05 PM
To: Graf Thomas, INI-NET-VNC-E2E ;
draft-ietf-opsawg-collected-data-manifest.auth...@ietf.org
Subject: RE: draft-ietf-opsawg-collected-data-
Dear OPSAWG and CCAMP,
Based on feedback from Paul and Amanda, we concluded that the best option is to
create a " G-PON Encapsulation Method PTI Subregistry" which is maintained by a
designated expert.
The designated expert monitors the G-PON Encapsulation Method related
activities at ITU-T a
Dear Qin,
As one of the authors. Thanks a lot for the review.
Regarding point 4 and 6. This has already being raised by Paul at
https://mailarchive.ietf.org/arch/msg/opsawg/zAyBkk5I_3SKHvePBjugmFvXlvg/ and
is in the queue for -18 revision
https://author-tools.ietf.org/diff?doc_1=draft-ietf-ops
Dear Paul,
Thanks for the quick reply.
My understanding from
https://datatracker.ietf.org/doc/html/rfc7011#section-6.1.1 is
MUST be encoded using the default canonical format in network byte order
Looking at https://www.rfc-editor.org/rfc/rfc7133.html#section-5.2 as example,
which is th
Dear Paul and Scott,
I merged the input from Paul on which bits should be encoded for the gponGemPti
IE.
https://author-tools.ietf.org/diff?doc_1=draft-netana-opsawg-ipfix-gpon-gem-00&url_2=https://raw.githubusercontent.com/network-analytics/draft-netana-opsawg-ipfix-gpon-gem/refs/heads/main/dra
Dear Behcet,
Thanks a lot for the review. Much appreciated. We addressed the editorial
comments together with the comments from Mahesh and Paul as following:
https://author-tools.ietf.org/diff?doc_1=draft-ietf-opsawg-ipfix-on-path-telemetry-17&url_2=https://raw.githubusercontent.com/network-anal
Dear Mahesh,
Thanks a lot for the review. Much appreciated. We addressed the editorial
comments together with the comments from Mahesh and Paul as following:
https://author-tools.ietf.org/diff?doc_1=draft-ietf-opsawg-ipfix-on-path-telemetry-17&url_2=https://raw.githubusercontent.com/network-
Dear Med,
Thanks a lot. This is really helpful. Especially the pointer to RFC 8969 I
missed. I understood now from reading into
https://datatracker.ietf.org/doc/html/rfc8969#section-3.2
https://datatracker.ietf.org/doc/html/rfc8969#section-3.3
https://datatracker.ietf.org/doc/html/rfc8969#sectio
Dear Adrian, Qin, Will and OPSAWG,
First of all. I enjoyed reading RFC 8309. It is very helpful in context with
RFC8199 and RFC 3444 to distinguish between "Customer Service Model" and
"Service Delivery Model. The explanations make perfectly sense to me.
I have read the term "Service Delivery M
Dear OPSAWG, CCAMP and NMOP,
On behalf of the authors I like to introduce you to a new IPFIX document:
https://datatracker.ietf.org/doc/html/draft-netana-opsawg-ipfix-gpon-gem
Below the excerpt from the document introduction. We are currently working on
an implementation which will be validated
Dear Giuseppe and OPSAWG chairs,
Apologies. I just noticed that I missed to publish -17 after the cutoff window
re-opened.
Best wishes
Thomas
From: Giuseppe Fioccola
Sent: Thursday, March 6, 2025 2:59 PM
To: Graf Thomas, INI-NET-VNC-E2E ;
jclarke=40cisco@dmarc.ietf.org; opsawg@ietf.org
Su
Dear Med,
We definitely need a refresh. Good catch. Count me as a document contributor
and reviewer. This matches well with what I have already contributed here:
https://datatracker.ietf.org/doc/html/draft-boucadair-nmop-rfc3535-20years-later-07#section-4.10
Best wishes
Thomas
From: mohamed.bo
Dear Rob,
Thanks a lot for the review.
1. Do you want to add any text to explain that the fields are optional,
providing choice at to which fields are populated?
Valid point, We will take it as action item for the next iteration.
1. Quite a few of these are unstructured strings. It wou
Dear Giuseppe,
Many thanks for the shepherd review.
On behalf of the authors, I addressed the RFC 7799 downref and the idnits in -17
TXT:
https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-on-path-telemetry/refs/heads/main/draft-ietf-opsawg-ipfix-on-path-telemetry-17.tx
Dear Joe,
Fair point. I addressed it in -16 as following:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-on-path-telemetry-16
[cid:image001.png@01DB8C5C.276C4B10]
Best wishes
Thomas
From: Joe Clarke (jclarke)
Sent: Sunday, March 2, 2025 3:18 PM
To: Graf Thomas, INI-NET-VNC
Dear Joe, Dear Giuseppe,
Thanks a lot Giuseppe for taking on shepherd.
On behalf of the authors, we submitted -15 with the following changes
* Merged minor editorial input from Paul Aitken, Menachem Dodge and Martin
Duke
(https://mailarchive.ietf.org/arch/msg/opsawg/YXts3FJjcXRBW1gnHUma5a
Dear Martin,
Thanks a lot for the review and apologies for delayed replied. We are preparing
-15 and addressed your comments here:
https://author-tools.ietf.org/diff?doc_1=draft-ietf-opsawg-ipfix-on-path-telemetry-14&url_2=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg
Dear Menachem,
Thanks a lot for the review and apologies for delayed replied. We are preparing
-15 and addressed your comments here:
https://author-tools.ietf.org/diff?doc_1=draft-ietf-opsawg-ipfix-on-path-telemetry-14&url_2=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-i
Dear Prasad,
Speaking as an operator who has IPFIX NAT event logging as per RFC 8158, IPFIX
Flow Aggregation as per RFC 7015/7011 and BMP as per RFC 7854/9069 on the same
network nodes operational, we export both, NAT events, flow account information
and BGP RIB state information and correlate
Dear Prasad,
Thanks for the feedback and confirming that that path delay measurement IPFIX
entities are useful.
Indeed visibility into queuing,
https://www.ietf.org/blog/banishing-bufferbloat/, in particular FQ-CoDel
https://datatracker.ietf.org/doc/html/rfc8290#section-3 dimensions would be
Dear OPSAWG,
No, I'm not aware of any IPR that applies to this draft.
Best wishes
Thomas
From: Joe Clarke (jclarke)
Sent: Monday, November 18, 2024 7:15 PM
To: opsawg@ietf.org
Subject: [OPSAWG]IPR POLL: A Data Manifest for Contextualized Telemetry Data
Be aware: This is an external email.
Dear Giuseppe,
Thanks a lot for the input. That makes perfectly sense that we also describe
the applicability onto the SRv6 Segment Routing Header in the Alternate-Marking
Method and mention Alternate-Marking Method when the delay is being calculated
outside of the network node.
Could you plea
Dear Joe,
Thanks a lot. No, I'm not aware of any IPR that applies to this draft.
Best wishes
Thomas
From: Joe Clarke (jclarke)
Sent: Monday, September 30, 2024 2:00 PM
To: opsawg@ietf.org
Cc: draft-ietf-opsawg-ipfix-on-path-teleme...@ietf.org
Subject: IPR POLL: Export of Delay Performance Metri
Dear OPSAWG,
We posted a new revision based on the editorial related feedback we received
from Paul Aitken.
With that, we addressed all comments. No other updates are pending. Looking
forward to the working group last call.
Best wishes
Thomas
-Original Message-
From: internet-dra...@i
Dear OPSAWG,
No, I'm not aware of any IPR that applies to this draft.
Best wishes
Thomas
From: Joe Clarke (jclarke)
Sent: Thursday, September 19, 2024 6:37 PM
To: opsawg@ietf.org
Cc: draft-voyersriram-opsawg-ipfix-g...@ietf.org
Subject: IPR POLL: Export of GTP-U Information in IP Flow Informati
Dear OPSAWG working group and chairs,
On behalf of the authors. We just submitted -12 revision where we addressed the
following feedback
- Paul Aitken, IPFIX designated expert
- Greg Mirsky, IPPM registry designated expert
- IANA
- Med Boucadair and Yannick Buchs, proof-reading the document
As
Dear Rebecca,
Looks perfect. Thats would be all.
Best wishes
Thomas
-Original Message-
From: Rebecca VanRheenen
Sent: Thursday, July 11, 2024 7:09 PM
To: Graf Thomas, INI-NET-VNC-HCS ; Mahesh
Jethanandani
Cc: benoit.cla...@huawei.com; pierre.franc...@insa-lyon.fr; opsawg@ietf.org;
Dear Carsten,
Valid input! Thanks a lot for spotting this.
Best wishes
Thomas
-Original Message-
From: Carsten Bormann
Sent: Saturday, July 6, 2024 6:58 PM
To: Benoit Claise
Cc: RFC Errata System ;
pierre.franc...@insa-lyon.fr; opsawg@ietf.org
Subject: [OPSAWG]Re: [Editorial Errata
Dear Mahesh and Rebecca,
Can we also take Carsten's feedback into account and change the first two lines
of Figure 7 to move two characters to the left.
Then everything is perfect.
Best wishes
Thomas
From: Mahesh Jethanandani
Sent: Wednesday, July 10, 2024 8:29 PM
To: Rebecca Vanrheenen
Cc:
Dear Joe, Tianran and Henk,
I like to request a 10min presentation slot for
Export of On-Path Delay in IPFIX
draft-ietf-opsawg-ipfix-on-path-telemetry-07
We have been working since IETF 117 on aligning the document to the performance
metrics registry and like to present those changes to the OPS
Dear OPSAWG,
I have read the document and support the adoption in OPSAWG. A OAM terminology
is much needed.
Best wishes
Thomas
-Original Message-
From: OPSAWG On Behalf Of Henk Birkholz
Sent: Wednesday, April 10, 2024 1:06 PM
To: OPSAWG
Subject: [OPSAWG] π WG Adoption Call for
draft-
Dear NMOP and OPSAWG working group,
At IETF 119, I introduced to NMOP below informational overview document.
Describing the YANG-Push integration into Apache Kafka.
https://datatracker.ietf.org/doc/html/draft-netana-nmop-yang-kafka-integration
https://datatracker.ietf.org/meeting/119/materials/s
Dear Joe and Med,
I updated both shepherd writeup's accordingly and adjusted to: that consensus
for introducing a new data type unsigned256 has been achieved.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh/shepherdwriteup/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-t
Dear Xiao,
Correct. Obviously this will be exported per flow and the interface entities
have to be key fields as the flow entities as well.
Best wishes
Thomas
On 3 Apr 2024, at 04:54, xiao.m...@zte.com.cn wrote:
ο»Ώ
Be aware: This is an external email.
Correcting the email address i...@ietf.
Dear Xiao,
I agree that the description and the additional information does not provide
information to distinguish between
ingressInterface, egressInterface
and
ingressPhysicalInterface, egressPhysicalInterface
However from an implementation perspective I have observed that in all cases
ingr
Dear Reshad,
I am refering to the IOAM data fields described in
https://datatracker.ietf.org/doc/html/rfc9197#section-4. So that those entities
can be decomposed on the network node and not at the data collection. Depending
on IPFIX configuration, some of the dimensions will be key fields, some
Dear Justin, Dear OPSAWG and IPPM working groups
Thanks a lot for the presentation at IPPM. I believe that this work needs
further refinement by defining also IPFIX entities for IOAM which allow a
decomposition of each IOAM dimension fields, thus enabling IPFIX Flow
Aggregation as described in
Dear Carlos and Adrian,
As the author of draft-ietf-opsawg-ipfix-on-path-telemetry, I care and value
that you are defining OAM terminology. This is much needed. Count me on the
list of people who misused the term inband previously.
I would appreciate of you could add also OAM node type. As an e
Dear OPSAWG,
As a co-author, I am not aware of any IPR.
Best wishes
Thomas
-Original Message-
From: Henk Birkholz
Sent: Thursday, February 8, 2024 5:00 PM
To: OPSAWG ; draft-feng-opsawg-incident-managem...@ietf.org
Subject: π IPR Call for draft-feng-opsawg-incident-management-04
Be a
Dear Med and Benoit,
Thanks a lot. The document is straight forward and is a very valuable
contribution to the Internet community since it updates existing IPFIX entities
to make them consistent, which is for IPFIX data collections which obtain the
information from the IPFIX IANA registry espec
Dear Med,
That was a mistake by me. The idnits showed nothing. All clear. Will update the
shepherd review in the next iteration.
Bets wishes
Thomas
-Original Message-
From: mohamed.boucad...@orange.com
Sent: Tuesday, January 23, 2024 11:02 AM
To: Graf Thomas, INI-NET-VNC-HCS ;
draft-
Dear Adrian and Davis,
Nice! Thanks a lot for this document. I think it will help future documents to
chose the correct terms and language.
I reviewed and have some minor input.
Regarding
Change: A modification to the state of a resource in time.
I believe it not only applies to a resource bu
Dear Med and Benoit,
Thanks a lot. The document is very well written and straight forward. As shared
previously during the working group, I believe this document is very valuable
to network operators since it addresses current issues in the observation of
IPv6 headers and TCP options.
I have r
Dear OPSAWG,
The Semantic Metadata Annotation for Network Anomaly Detection document was
previously presented at IEPG and NMRG
https://datatracker.ietf.org/meeting/118/materials/slides-118-nmrg-semantic-metadata-annotation-for-network-anomaly-detection-01.pdf
https://youtu.be/zC-R_fWUUEA?si=oAvc
Dear Med,
Thanks a lot for addressing all my points.
I updated and submitted my shepherd review:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tsvwg-udp-ipfix/shepherdwriteup/
I agree with your assessment on Joe's comment that having a figure on udp
options packet header and short descrip
Dear OPSAWG,
I read the document and think it is very valuable for network operators. I like
that it is defined as information module so later we can see how this would be
applicable in IPFIX and YANG.
Best wishes
Thomas
-Original Message-
From: OPSAWG On Behalf Of Henk Birkhol
Dear opsawg,
We updated the document and replaced the references from Path Tracing
(draft-filsfils-ippm-path-tracing) to Alternate Marking (RFC 9341, RFC 9343,
draft-ietf-ippm-ioam-deployment, draft- fz-spring-srv6-alt-mark) currently
under development at IPPM. Describing with IOAM (RFC 9197,
Dear netconf,
The following two documents have been updated:
Name: draft-tgraf-netconf-notif-sequencing
Revision: 03
Title:Support of Hostname and Sequencing in YANG Notifications
Date: 2024-01-14
Group:Individual Submission
Pages:10
URL:
https://www.ietf.org/arch
Dear netconf and opsawg,
In order to align with the new Message Publisher ID terminology in
draft-ietf-netconf-distributed-notif-08 we updated
draft-tgraf-netconf-notif-sequencing accordingly. Looking forward to feedback
from the working group.
Best wishes
Thomas
-Original Message-
Fr
Dear Chaitanya,
Thanks a lot for the updated document. As previously stated, as a network
operator, I value contributions describing reasons why packets are being
dropped.
I reviewed the latest document revision and have the following comments:
Looking at
https://datatracker.ietf.org/doc/html
Dear Massimo,
My apology for late reply. Both your comments are very valid.
packetDeltaCount(IE2) can be also used for loss measurement. As well
flowEndSeconds(IE151), flowEndMilliseconds(IE153),flowEndMicroseconds(IE155) or
flowEndNanoseconds(IE157) for delay measurement. Both has been added
Dear netconf and opsawg,
We updated draft-ietf-netconf-distributed-notif to address Benoit's comment on
the use of domain observation id terminology. We believe that by introducing a
new terminology, Message Publisher and Message Publisher ID we have been
addressing his concerns. Looking forwar
Dear draft-fz-ippm-alt-mark-deployment authors, Dear IPPM working group,
First of all I think draft-fz-ippm-alt-mark-deployment is a valuable document
describing the deployment of Alternat Marking.
I have reviewed
https://datatracker.ietf.org/doc/draft-fz-ippm-alt-mark-deployment/ the Network
Dear Greg,
Thanks a lot. Valid point on connectivity service terminology. The proposed
text works for me. Perfect.
Best wishes
Thomas
On 18 Aug 2023, at 21:53, Greg Mirsky wrote:
ο»Ώ
Hi Thomas,
thank you for the feedback and proposed update. Please find my notes below
tagged by GIM2>>.
Regard
Dear Greg,
Thanks a lot for addressing my comments.
GIM> It could be easier to take out "flow" altogether. WDYT?
TG> Let me propose something else:
Change from
"When analyzing the availability metrics of a service flow between two nodes"
To
"When analyzing the availability metrics of a conne
Dear Alex and Greg,
I reviewed draft-ietf-ippm-pam-04 and draft-clemm-opsawg-pam-ipfix-00 and have
some comments and questions.
Section 3.1 of draft-ietf-ippm-pam-04
(https://datatracker.ietf.org/doc/html/draft-ietf-ippm-pam-04#section-3.1)
mentions the term "service flow".
I haven't been abl
Dear OPSAWG and IPPM wg,
As described at IETF 116, draft-ietf-opsawg-ipfix-on-path-telemetry has been
updated to -03 with an example section. Show an example with
PathDelayMeanDeltaMicroseconds where the mean is already calculated at the
IPFIX export and one with PathDelaySumDeltaMicroseconds w
Dear OPSAWG wg,
I support the adoption. I find this work very important to keep the IPFIX
registry up to date. In particular I like to contribute to
draft-boucadair-opsawg-ipfix-tcpo-v6eh since proper visibility of the IPv6
extension headers are a great concern.
Best wishes
Thomas
From: OPSAW
Hi Med,
Thanks a lot for this. I am looking very forward to the discussion in the
working group whether/how we will export also the observed occurrences of
Routing Types. I believe with the continuous adoption of IPv6 and SRv6 this
work will become important to network operators.
Best wishes
T
Dear Andrew,
Thanks a lot for the review and comment. The intent of the authors was never to
violate RFC 8200 but help the implementers of draft-ietf-opsawg-ipfix-srv6-srh
how to deal with multiple SRH by referencing to Section 8 of RFC 7011. However,
I understand from your feedback that multip
Dear Lars,
Thanks a lot for the review and comment. I addressed them in -14 version.
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-srv6-srh-14
Best wishes
Thomas
-Ori
Dear John,
My apology. Your assumption is correct.
In case when the compressed SID container is only used in the IPv6 destination
address of the provider data plane and the SRH is not being present at all, it
would be a zero lenght array.
Best wishes
Thomas
> On 24 May 2023, at 17:32, John S
Dear Paul,
Thanks a lot. I addressed both in -13 along with other IESG feedback.
There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh-13
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?u
Dear Erik,
Thanks a lot for your review and comment. I added the following sentence in the
-13 revision to make it clear which IEs are needed and where the decoding needs
to be done:
By using described information from srhSegmentIPv6EndpointBehavior and
srhSegmentIPv6LocatorLength the compress
Dear Eric,
Thanks for your comments.
With srhIPv6ActiveSegmentType the authors intended to have the operational
experience in SRv6 than we have in MPLS-SR with mplsTopLabelType
https://datatracker.ietf.org/doc/html/rfc9160
https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mpls-label-type
Dear Paul and Med,
Makes completely sense. I had the same thoughts. Thanks a lot. I submitted -12.
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-srv6-srh-12
Best wishes
Dear Paul and Med,
Excellent. Thanks a lot for your suggestions. I merged them into the -11
version.
There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh-11
A diff from the previous version is available at:
https://author
Dear Roman,
Thanks a lot for your review and comment. I merged them into the -11 version.
There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh-11
A diff from the previous version is available at:
https://author-tools.ietf.org/iddi
Dear Med,
Thanks a lot.
Regarding your feedback on expert review, for me valid and ok but I am waiting
on Paul's feedback if that make sense to him as well.
Regarding, IPFIX IPv6 SRH Segment Type Subregistry. I believe the section is
related to the srhIPv6ActiveSegmentType section. Therefore
Dear Paul,
Thanks a lot. I adjusted the indent structure as it was before but under 5.1
since Med added the 5.1 "New SRH Information Elements" section and reference it
in the text, which makes sense to me and addressed your nit.
Here the -10 document:
https://raw.githubusercontent.com/network-
Dear Med,
Thanks a lot for your comment on the designated expert in the "IPFIX IPv6 SRH
Segment Type Subregistry" and the removal of the intro section in the "IANA
Considerations"
Here the -10 document:
https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/dr
Dear Paul,
Thank you very much. I merged all your input.
PA> 5.4. srhActiveSegmentIPv6 / Additional Information, Changed from RFC8754 to
RFC8402, is that correct? Please say which section of the RFC is relevant.
TG> That is correct. The active section is specified in Section 2 of RFC 8402
and
Dear Paul,
Thanks a lot. I updated section 5.9.1 as you suggested.
https://author-tools.ietf.org/iddiff?url1=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-09.txt&url2=https://raw.githubusercontent.com/network-analytics/d
Dear Paul,
Thanks a lot for your review and comments. With one minor editorial exception,
all are valid and merged in the coming -10 version of the document.
https://author-tools.ietf.org/iddiff?url1=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-
Dear Jim,
Thank you very much for the review. We addressed your comments together with
some minor editorial nits from Med in version -09 which just has been
published. Below inline the feedback
Best wishes
Thomas
The IETF datatracker status page for this Internet-Draft is:
https://datatracker
Dear Med and Benoit,
Excellent. Thank you very much for addressing this so quickly. The proposed
changes make perfectly sense and addresses my concerns.
Indeed I was miss leaded by the IANA IPFIX registry indicating unisgned8 where
RFC7270 defined unisgned32 for the IE89 forwardingStatus. There
Dear Tero, Med and Rob
Thanks a lot for the SECDIR review. Below the feedback from the authors inline.
Looking forward to your feedback and please let me know if we should proceed to
add suggested paragraph in the security section for the document version.
Best wishes
Thomas
TK> On t
Dear OPSAWG, Med and Benoit
Regarding section 6.2, forwardingStatus
(https://datatracker.ietf.org/doc/html/draft-boucla-opsawg-ipfix-fixes-04#section-6.2).
Section 4.12 of RFC 7270
(https://www.rfc-editor.org/rfc/rfc7270.html#section-4.12) describes that
reduced-size encoding according to Sect
Dear Joe,
No, I am not aware of any IPR applying to this draft.
Best wishes
Thomas
From: Joe Clarke (jclarke)
Sent: Tuesday, May 2, 2023 12:20 AM
To: Benoit Claise ; jean.quilb...@huawei.com; IGNACIO
DOMINGUEZ MARTINEZ-CASANUEVA ;
diego.r.lo...@telefonica.com; Graf Thomas, INI-NET-VNC-HCS
C
Dear Med and Benoit,
Regarding adding a new IE ipv6ExtensionHeadersFull
(https://datatracker.ietf.org/doc/html/draft-boucadair-opsawg-ipfix-tcpo-v6eh-01#section-3).
I would appreciate if that new IE ipv6ExtensionHeadersFull would support more
than one extension header of the same kind.
Best wi
Dear OPSAWG,
We updated the draft document to version -02 by adding the Implementation
Status section. Reflecting what we have been testing/implementing during IETF
116 hackathon.
The hackathon slides describing implementation details and use case be applied
to can be found here:
https://githu
Dear OPSAWG and IPPM working group,
Thanks a lot for the comments during the adoption call. We updated the document
accordingly.
Here in brief the differences to the previous version:
- Extended the introduction and the terminology section with performance
registry relevant information's.
- C
Dear opsawg,
I support the adoption and think draft-boucla-opsawg-ipfix-fixes should follow
the adoption call next as well. Both are very valuable to keep the IPFIX
registry up to date.
I agree with the author that IE6 tcpControlBits should mirror the TCP header
flags registry
(https://www.ia
Dear Joe,
My appology. Sure! Just submited with the correct name.
Best wishes
Thomas
From: Joe Clarke (jclarke)
Sent: Thursday, January 19, 2023 6:40 PM
To: Graf Thomas, INI-NET-VNC-HCS ;
zhoutian...@huawei.com; opsawg@ietf.org
Cc: draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org
Subject:
Dear Tianran,
Thanks a lot. We submitted draft-opsawg-ipfix-on-path-telemetry-00 and awaiting
your approval.
We addressed the working group feedback in -01 version and will submit it right
after.
Best wishes
Thomas
From: Tianran Zhou
Sent: Wednesday, January 18, 2023 4:39 AM
To: opsawg@ietf.
https://mailarchive.ietf.org/arch/browse/opsawg/?q=draft-tgraf-opsawg-ipfix-on-path-telemetry-01
Danke! Angekommen π
Sorry fΓΌr den Stress.
Lg Thomas
On 13 Jan 2023, at 07:16, Buchs Yannick, INI-NET-VNC-HCS
wrote:
ο»Ώ
Dear OPSAWG,
I strongly support the adoption of
draft-tgraf-opsawg-ipfix
Dear Zhenqiang,
Thanks a lot for the feedback. Much appreciated.
I do not disagree that YANG push isn't capable of exporting control and
forwarding plane metrics. However it is not the best choice in terms of scale.
Table 1 of RFC 9232 gives a good summary. It even makes the distinction between
Dear Tianran,
ZTR> I think I understand how you can achieve. You can add to bits in
"extension-flags" in rfc9326, as the knob to control the existence of
timestamp, just like the flow id and sequence. Right?
Correct. That works as well. Thanks for pointing out.
Best wishes
Thomas
From: Tianra
Dear Tianran,
Thanks a lot for your feedback. I understood that with
draft-zhou-ippm-enhanced-alternate-marking we already have a document which
intends to extend alternat path marking with timestamping. Very well.
Regarding IOAM-DEX. I was refereeing to the Section 3.2 of RFC 9326
(https://da
Dear Med,
Also many thanks from my side. Much appreciated. I just submitted the -06
version.
If there aren't any objections anymore I think Joe can go ahead from here.
Best wishes
Thomas
From: Benoit Claise
Sent: Thursday, January 5, 2023 10:08 AM
To: mohamed.boucad...@orange.com; Graf Thom
Dear Jean,
Thanks a lot for the comprehensive review and comments. They all make perfectly
sense.
I merged them into the -02 version
https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-on-path-telemetry/main/draft-tgraf-opsawg-ipfix-on-path-telemetry-02.txt
And here the diff:
Dear Zhenqiang,
Thanks a lot for your feedback.
I presume with gRPC you are referring to YANG push (RFC 8639, RFC 8641,
draft-ietf-netconf-udp-notif, draft-ietf-netconf-https-notif). gNMI (gRPC is
the transport of gNMI) has been proposed (draft-openconfig-rtgwg-gnmi-spec) in
2018 but not stand
Dear Zhenqiang,
Thanks a lot for your feedback.
I presume with gRPC you are referring to YANG push (RFC 8639, RFC 8641,
draft-ietf-netconf-udp-notif, draft-ietf-netconf-https-notif). gNMI (gRPC is
the transport of gNMI) has been proposed (draft-openconfig-rtgwg-gnmi-spec) in
2018 but not stand
1 - 100 of 165 matches
Mail list logo
