As a co-author of many of the IPFIX RFCs, expert reviewer for IANA, and author
of IPFIX code, I disagree with the premise that the current tcpControlBits
definition is problematic for interoperability because some values have since
been deprecated.
Rather, the interoperability risk is in making
This cleanup seems good and useful. Thanks for the draft. Please find some
feedback below, with quoted text in black and my comments in blue.
1. Introduction
This document intends to update the IANA registry and bringing some consistency.
Consistency with ... ?
3. Update the Description
Thi
(There is a formatting issue with a table; this will be fixed in the next
iteration)
For the comment about references, I prefer to leave those to make idnits happy.
Cheers,
Med
De : Aitken, Paul <mailto:pait...@ciena.com>
Envoyé : vendredi 20 janvier 2023 23:17
À : opsawg <mailto:op
"No, I'm not aware of any IPR that applies to this draft"
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
IE-doctors already looked at this under [IANA #1240167] and [IANA #1263583].
I've reviewed draft-ietf-opsawg-ipfix-srv6-srh-08 and -09 which appeared during
the review window.
(Editors, please don't move the goalposts while reviews are in progress!)
3. New SRv6 IPFIX Information Elements
The
Thanks Thomas, I will re-review the updated draft later.
PA> 7. Implementation Status, I would put this section in an appendix to avoid
the need to renumber sections 8, 9, and 10 when this is removed.
TG> Good point. I double checked. I am following Section 2 of RFC 7942
(https://datatracker.ie
Thomas,
3. srhSegmentIPv6BasicList
"As specified in Section 2 of [RFC8754]" versus 5.5 / Description, "As
described in Section 2 of [RFC8754]".
3. srhSegmentIPv6ListSection
Remove "Exposes" for consistency with 5.6 / Description.
3. srhSegmentsIPv6Left
"Segment List from th
v6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-10.txt
Best wishes
Thomas
From: Graf Thomas, INI-NET-VNC-HCS
Sent: Wednesday, May 17, 2023 7:48 AM
To: 'Aitken, Paul' <mailto:pait...@ciena.com>
Cc: ie-doct...@ietf.org<mailto:ie-doct...@ietf.org>;
opsawg@ietf.org<mai
ssage-
From: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>
<mailto:mohamed.boucad...@orange.com>
Sent: Monday, May 22, 2023 8:50 AM
To: opsawg@ietf.org<mailto:opsawg@ietf.org>; Graf Thomas, INI-NET-VNC-HCS
<mailto:thomas.g...@swisscom.com>
Cc: Aitken, Paul <mailto:pait..
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-srv6-srh-11
Best wishes
Thomas
From: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>
mailto:mohamed.boucad...@orange.com>>
Sent: Monday, May 22, 2023 2:50 PM
To: Aitken, Paul mailto:pait...@c
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-srv6-srh-12
Best wishes
Thomas
From: Aitken, Paul <mailto:pait...@ciena.com>
Sent: Tuesday, May 23, 2023 10:36 AM
To: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>; Graf
Thomas, INI-NET-VNC-
Thomas, I have to repeat some of my previous feedback about inconsistencies
between sections 3 and 5:
* srhSegmentsIPv6Left don't match
S3: "to reach the end of the Segment List from the SRH" vs S5: "to reach
the end of the Segment List in the SRH".
* srhIPv6Section
S3: Remove "expo
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 the AUTH48.
Cheers,
Med (Doc Shepherd)
De : Aitken, Paul <mailto:pait...@ciena.com>
Envoyé : vendredi 9 juin 2023 13:24
À : Graf Thomas, INI
Med, this figure originally appeared in section 5.8.8 of
draft-ietf-ipfix-info-13, -14, and RFC 5102 with the bits in this order:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| 0 | 1 | 2 | 3 | 4 | 5 |
assessment that a fix is needed.
Cheers,
Med
De : BOUCADAIR Mohamed INNOV/NET
Envoyé : mardi 19 septembre 2023 15:02
À : 'Aitken, Paul' <mailto:pait...@ciena.com>; opsawg
<mailto:opsawg@ietf.org>; Benoit Claise
<mailto:benoit.cla...@huawei.com>
Objet : RE: draft-i
Eric Vyncke wrote:
Adding a new IE to signal the issue, why not ? I usually do not like too much
having a ‘negative signalling’, i.e., the absence of an IE having an important
meaning.
+1
No meaning can be inferred from the absence of an IE, since existing exporters
and those which choose not
Med, I reviewed the current draft-ietf-opsawg-ipfix-tcpo-v6eh.
1.1 "Specify how to automatically update the IANA IPFIX registry"
- is "automatically" correct? I didn't see any mention of this later in the
draft.
1.2 "Support means to report the observed Experimental Identifiers (ExIDs) that
Med,
0. "This document obsoletes RFC 7125."
-> It would have been good to ask the authors of that document to review
the new draft.
1. Introduction
"The bits in offsets 0 through 3 are not header flags, but the TCP
segment Data Offset field."
-> This paragraph appears out of
IE-doctors approves.
Thanks,
Brian, Andrew, Paul
On 24/10/2023 18:20, David Dong via RT wrote:
> Dear IE Doctors (cc: opsawg WG),
>
> As the designated experts for the IPFIX Information Elements registry, can
> you review the proposed registration in draft-ietf-opsawg-rfc7125-update-05
> for u
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh
Essentially the middle of this document is missing: a summary of issues is
given and new IEs are proposed as a solution. But the issues are not developed
or explained.
1.1. Issues with ipv6ExtensionHeaders Information Elem
https://www.ietf.org/archive/id/draft-ietf-opsawg-tsvwg-udp-ipfix-06.txt
1. Introduction
A brief overview of UDP option is provided in Section 3.
Typo, "UDP options" (plural).
The IE specified in Section 4.1 uses the new abstract data type
defined in [I-D.ietf-opsawg-ipfix-tcpo
Med,
The IE specified in Section 4.1 uses the new abstract data type
defined in [I-D.ietf-opsawg-ipfix-tcpo-v6eh].
The unsigned256 type? It makes more sense to introduce a bitfield type.
[Med] I think the use of unsigned256 is consistent with the current use in IP
Flow Information Export (
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes
Abstract
The updates are also meant to bringing some
consistency among the entries of the registry.
Typo, "meant to bring in".
1. Introduction
As the OPSAWG is currently considering
This will soon become out
Med,
The following drawing indicates
the position of each bit in the encoding of the Information
Element.
No, not any more - so this should be removed.
[Med] It is useful as it indicates the bit position that is then referred to in
the new IANA registry. Updated the figure to
Med,
Why does the document identify issues without proposing solutions to them all?
How and when will those other issues be fixed?
[Med] The new IEs in this I-D fix all the issues.
Then please don't write "some of".
MSB LSB
0
This document is simply too long to review. I'm about half way through, and
will not have time to complete the review before May 10th.
* In the TOC, all the OLD / NEW section names are distracting. It would be much
more readable if the TOC was limited to just two levels:
1. Introduction
* 3. UDP Options at a Glance
Add "to" :
e.g., to discover a path MTU or share timestamps
* 4. New UDP IPFIX Information Elements
The URLs in the "note" should be listed in the references. The note should say
"to be updated / removed by the RFC editor".
* 4.2. and 4.3. / Descripti
* 1.1
Add "the":
Section 3 addresses these issues. Also, the ipv6ExtensionHeaders IPFIX
IE is deprecated in favor of the new IEs defined in this document.
* 1.2
Add "the" :
The specification of the tcpOptions IPFIX IE (209) does not:
Should "option" be "options"? :
* Describe
Med,
In the new version:
4.1. The first 64 most-significant bits MUST be set to 0.
This seems to exclude reduced size encoding.
Also, "while Kind 255 corresponds to the most-significant bit of the IE." is
nolonger accurate.
4.2 udpUnsfaeOptions
Typo: udpUnsafeOptions
4.1 and 4.2:
A bit
Med,
3.3.
Extension headers observed in a Flow with varying extension header
chain MAY be aggregated in one single ipv6ExtensionHeadersFull
Information Element or be exported in separate
ipv6ExtensionHeadersFull IEs, one for each extension header chain.
Seems to contradi
Med, Joe,
- Reduced-size encoding per RFC7011 does not apply, unless you are
restricting them to 64, 32, 16, and 8.
[Med] There is no such restriction because of this part in the base spec:
This behavior is indicated by the Exporter by specifying a size in
the Template wi
Med,
* In the TOC, all the OLD / NEW section names are distracting. It would be much
more readable if the TOC was limited to just two levels:
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
3.
David, I previously reviewed as far as 6.14, provided feedback, and the author
has updated the draft accordingly.
I've now reviewed the remainder of the document, and have no further objections.
P.
On 21/05/24 21:14, David Dong via RT wrote:
Hi Paul,
Following up on the remaining review for
Med,
3.3. ipv6ExtensionHeadersFull Information Element
The value of ipv6ExtensionHeadersFull IE is encoded in fewer
octets per the guidelines in Section 6.2 of [RFC7011].
If the value "is" encoded in fewer octets, then the defined size is simply too
large. For clarity I'd say "ma
0I5adRYNMo$
>> [datatracker[.]ietf[.]org]
>> ipfix/
>>
>> Please see inline.
>>
>> Cheers,
>> Med
>>
>> De : Aitken, Paul
>> Envoyé : lundi 13 mai 2024 21:53
>> À : BOUCADAIR Mohamed INNOV/NET ;
>> drafts-expert-review-comm.
uQpdnnTOWIKaAs$>
Thanks.
Cheers,
Med
De : Aitken, Paul <mailto:pait...@ciena.com>
Envoyé : mercredi 22 mai 2024 22:25
À : BOUCADAIR Mohamed INNOV/NET
<mailto:mohamed.boucad...@orange.com>;
drafts-expert-review-comm...@iana.org<mailto:drafts-expert-review-comm...@iana.org>
pear in the
registry. U192 will at least have one IE associated with it.
If you insist to revert back to u255, please share OLD/NEW modifications you
want to see.
Thank you.
Cheers,
Med
-Message d'origine-
De : Aitken, Paul <mailto:pait...@ciena.com>
Envoyé : mercr
Sigh.
In sections 7.1 and 7.2, s/192/256/
Add this line and change the ADT:
4.1. udpSafeOptions
Name: udpSafeOptions
ElementID: TBD1
Description: Observed safe UDP options in a Flow. The information
is encoded in a set of bit fields.
Options are mapped to bits acco
David, I approve draft-ietf-opsawg-tsvwg-udp-ipfix-12.
P.
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
Herewith some review comments on draft-ietf-opsawg-ipfix-on-path-telemetry-08 :
Throughout: "TDB3" should be "TBD3".
3.1.1.3. URI / RFC EDITOR NOTE - there are no TBD to be replaced in this
section.
In section 6.2.4. since PathDelaySumDeltaMicroseconds is a sum of deltas,
should the Data T
x-on-path-teleme...@ietf.org>;
opsawg@ietf.org<mailto:opsawg@ietf.org>; Greg Mirsky
<mailto:gregimir...@gmail.com>; Aitken, Paul
<mailto:pait...@ciena.com>
Objet : Re: [OPSAWG]Re: Review of draft-ietf-opsawg-ipfix-on-path-telemetry-08
Dear Med,
See inline for the still open issu
Looks good, thanks!
P.
On 23/07/24 20:43, Alex Huang Feng wrote:
Dear Paul,
Thanks a lot for the review. I fixed these editorial typos in -11.
https://author-tools.ietf.org/diff?doc_1=draft-ietf-opsawg-ipfix-on-path-telemetry-10&url_2=https://raw.githubusercontent.com/network-analytics/draft-i
Med,
IEs defined in a WG document should not be frozen in type, number, and
description.
They are not frozen.
However, IEs defined in IANA's registry are frozen.
I’m really concerned that we are using pre-registrations to bypass the WG call.
+1
I would prefer to reject early assignment requ
Benoit,
> To me, that's a grey area (in the process). Changing an IPFIX IE
> description is non consequential (and I guess welcome, as it
> clarifies), but what if now, an IPFIX IE type is changed?
> I propose that the OPSAWG chairs discuss, engage with IANA, IPFIX IE,
> and the OPS ADs here. W
."
It was not clear that section 3 defined four templates.
7.4 "comparing the timestamps for each received packet"
It may be clearer to write, "comparing the OWD timestamps in each received
packet".
A.1.2 Figure 5, Length should be 64.
P.
__
BTW, the issue is how to ensure that IANA's IPFIX registry is kept in sync with
the ITU definition, if some of the currently "Reserved" values would be
allocated by the ITU in future.
Which assumes that we want and expect the gponGemPti IE to reflect any future
ITU updates.
*
Regarding the
; would be clearer?
Regarding the registry, yes, I received some feedback from IANA/Amanda but the
discussion ended inconclusively. I'll restart the discussion and CC you.
P.
From: thomas.g...@swisscom.com
Sent: Friday, May 16, 2025 12:48
To: Aitken, Paul
writing this in a non-pronoun way: "... for reviewing".
Are you asking me / Scott to reach out to ITU-T? I would have expected the
document authors to do that.
P.
From: thomas.g...@swisscom.com
Sent: Friday, May 16, 2025 09:30
To: Aitken, Paul
they need would be spread across many sections of the
document.
Citing "it was already done badly in another RFC" is a disappointing excuse.
Otherwise, please apply the changes.
Thanks,
P.
From: Benoit Claise
Sent: Wednesday, June 11, 2025 13:45
T
David,
1. I've been following this draft for a while, and approve the Information
Elements request in section 5.2.
2. With a separate hat I could also approve the Performance Metrics request in
section 5.1, though for visibility and tracking there should be a separate
pm-dir request for that.
P.
From: thomas.g...@swisscom.com
Sent: Wednesday, July 02, 2025 13:34
To: sarik...@ieee.org; gen-...@ietf.org; bill...@huawei.com; Aitken, Paul;
mjethanand...@gmail.com
Cc: opsawg-cha...@ietf.org; opsawg@ietf.org; i...@iana.org;
michelle.cot...@icann.org;
dr
Looks good, thanks Thomas!
P.
From: thomas.g...@swisscom.com
Sent: Wednesday, July 02, 2025 14:00
To: Aitken, Paul; sarik...@ieee.org; gen-...@ietf.org; bill...@huawei.com;
mjethanand...@gmail.com
Cc: opsawg-cha...@ietf.org; opsawg@ietf.org; i
This document seems related to the anomaly detection and incident management
work currently happening in the NMOP WG.
Please see PA: inline.
Abstract
This document defines an information model and a corresponding YANG
data model for packet discard reporting. The information model
prov
53 matches
Mail list logo
