[OPSAWG]Re: advancing PCAP drafts

[Michael Richardson]

mohamed.boucad...@orange.com wrote:
>> okay, I couldn't quite understand this from the diff, but in
>> principal I have no problem with that.

> [Med] Actually, I didn't make that change in the PR as I wanted to
> discuss it first here. As you are Ok with it, so please update the
> table accordingly. Thanks.

But, your PR seems to patch every single line of the table.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-  *I*LIKE*TRAINS*





signature.asc
Description: PGP signature
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

Re: [OPSAWG] INTDIR Review of draft-ietf-opsawg-ipfix-fixes-08

[Donald Eastlake]

OK, thanks for the quick response and update.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

On Mon, May 6, 2024 at 8:16 AM  wrote:
>
> Hi Donald,
>
>
>
> Thanks for the review.
>
>
>
> All good suggestions. I went with all of the suggestions, except the refs: 
> https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/simple-ipfix-fixes/draft-ietf-opsawg-ipfix-fixes.txt_2=https://boucadair.github.io/simple-ipfix-fixes/Donald-Eastlake/draft-ietf-opsawg-ipfix-fixes.txt
>
>
>
> Cheers,
>
> Med
>
>
>
> De : Donald Eastlake 
> Envoyé : lundi 6 mai 2024 00:08
> À : int-...@ietf.org; int-...@ietf.org
> Cc : draft-ietf-opsawg-ipfix-fixes@ietf.org; opsawg-cha...@ietf.org
> Objet : INTDIR Review of draft-ietf-opsawg-ipfix-fixes-08
>
>
>
> I am an assigned INT directorate reviewer for 
> . These comments were written primarily 
> for the benefit of the Internet Area Directors. Document editors and 
> shepherd(s) should treat these comments just like they would treat comments 
> from any other IETF contributors and resolve them along with any other Last 
> Call comments that have been received. For more details on the INT 
> Directorate, see https://datatracker.ietf.org/group/intdir/about/ .
>
>
>
> Based on my review, if I was on the IESG I would ballot this document as NO 
> OBJECTION.
>
> This is a straightforward document that fixes lots of inconsistencies and 
> glitches in the IPFIX IANA Information Element registry.
>
> I did not find any significant issues or technical problems with this 
> document.
>
> The following are minor issues (typos, misspelling, minor text improvements) 
> with the document:
>
> Abstract: "a shortcoming" -> "shortcomings"
>
> Abstract & Introduction: "calling" -> "citing" or "referencing"
>
> Section 6.21.2: References to IEEE and ISO/IEC documents, if they are
> worth including, should be real references.
>
> Section 3, 2nd sentence: I think "should be" -> "is"
>
> Section 4.4.2 & 4.5.2: although DCCP is included in the "e.g." list in
> the last sentence of these sections, it is not included in their
> Description paragraph and there is no reference to RFC 4340. These
> should at least be consistent within the registry entry.
>
> Section 6.10.2: listing RFC 3022 twice seems odd.
>
> Section 9: This says to "update" the reference clause of the "IPFIX
> Information Elements" registry with "this document". Suggest using
> "add" rather than "update" as in
>
>  request IANA to add [this document] to the references for the
>  "IPFIX Information Elements" registry.
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e...@gmail.com
>
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.

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

Re: [OPSAWG] Genart last call review of draft-ietf-opsawg-ipfix-tcpo-v6eh-11

[Joel Halpern]

Thank you.  Those edits do the job nicely.

Joel

On 5/6/2024 5:49 AM, mohamed.boucad...@orange.com wrote:

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] https://mailarchive.ietf.org/arch/msg/opsawg/g-cXqAHzazaA_gOf7Woxv2SiVJ4/

[2] 
https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/ipfix-tcpoptions-and-v6eh/draft-ietf-opsawg-ipfix-tcpo-v6eh.txt_2=https://boucadair.github.io/ipfix-tcpoptions-and-v6eh/genart-review/draft-ietf-opsawg-ipfix-tcpo-v6eh.txt


-Message d'origine-
De : Joel Halpern via Datatracker 
Envoyé : vendredi 3 mai 2024 05:01
À : gen-...@ietf.org
Cc : draft-ietf-opsawg-ipfix-tcpo-v6eh@ietf.org; last-
c...@ietf.org; opsawg@ietf.org
Objet : Genart last call review of draft-ietf-opsawg-ipfix-tcpo-
v6eh-11

Reviewer: Joel Halpern
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General
Area Review Team (Gen-ART) reviews all IETF documents being
processed by the IESG for the IETF Chair.  Please treat these
comments just like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-opsawg-ipfix-tcpo-v6eh-11
Reviewer: Joel Halpern
Review Date: 2024-05-02
IETF LC End Date: 2024-05-10
IESG Telechat date: Not scheduled for a telechat

Summary: This document is ready for publication as a Proposed
Standard RFC

Major issues: None

Minor issues:
 The document uses the phrasing "If several extension header
chains are
 observed in a Flow" in several places.  While I believe I
figured out what
 was intended, it caused me difficulty.  Assuming I understood
the intent, I
 would suggest defining a term "flow with varying header
chain" as "a flow
 wherein different packets in the flow have a different
sequence of
 extension header types codes."  And then use that term in the
suitable
 places in the document.

Nits/editorial comments: None



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.



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

Re: [OPSAWG] advancing PCAP drafts

[mohamed . boucadair]

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}
> 
> mohamed.boucad...@orange.com wrote:
> > I think that it would be useful to have a new column to
> easily tag the
> > status of an assignment. Deprecated ones can be marked as
> such using
> > that new column, instead of having this in the description.
> 
> okay, I couldn't quite understand this from the diff, but in
> principal I have no problem with that.

[Med] Actually, I didn't make that change in the PR as I wanted to discuss it 
first here. As you are Ok with it, so please update the table accordingly. 
Thanks.

> 
> > For the DE guidance, I'm afraid that the first part of your
> text is redundant with what is already in 8126, especially this
> part:
> 
> > For the Specification Required policy, review and approval
> by a
> > designated expert (see Section 5) is required, and the
> values and
> > their meanings must be documented in a permanent and
> readily
> > available public specification, in sufficient detail so
> that
> > interoperability between independent implementations is
> possible.
> 
> So, a reason why I wrote that slight redundant text is so that
> the engineer who is trying to get their marketing person to put
> the document out in a sane place, would have a single place to
> point to.

[Med] Yeah. I think the text in 8126 is well enough.

> But, if the WG feels that redundant, I can go with that.
> 
> --
> Michael Richardson , Sandelman Software
> Works
>  -= IPv6 IoT consulting =-  *I*LIKE*TRAINS*


Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [OPSAWG] INTDIR Review of draft-ietf-opsawg-ipfix-fixes-08

[mohamed . boucadair]

Hi Donald,

Thanks for the review.

All good suggestions. I went with all of the suggestions, except the refs: 
https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/simple-ipfix-fixes/draft-ietf-opsawg-ipfix-fixes.txt_2=https://boucadair.github.io/simple-ipfix-fixes/Donald-Eastlake/draft-ietf-opsawg-ipfix-fixes.txt

Cheers,
Med

De : Donald Eastlake 
Envoyé : lundi 6 mai 2024 00:08
À : int-...@ietf.org; int-...@ietf.org
Cc : draft-ietf-opsawg-ipfix-fixes@ietf.org; opsawg-cha...@ietf.org
Objet : INTDIR Review of draft-ietf-opsawg-ipfix-fixes-08

I am an assigned INT directorate reviewer for 
. These comments were written primarily 
for the benefit of the Internet Area Directors. Document editors and 
shepherd(s) should treat these comments just like they would treat comments 
from any other IETF contributors and resolve them along with any other Last 
Call comments that have been received. For more details on the INT Directorate, 
see https://datatracker.ietf.org/group/intdir/about/ .


Based on my review, if I was on the IESG I would ballot this document as NO 
OBJECTION.

This is a straightforward document that fixes lots of inconsistencies and 
glitches in the IPFIX IANA Information Element registry.

I did not find any significant issues or technical problems with this document.

The following are minor issues (typos, misspelling, minor text improvements) 
with the document:

Abstract: "a shortcoming" -> "shortcomings"

Abstract & Introduction: "calling" -> "citing" or "referencing"

Section 6.21.2: References to IEEE and ISO/IEC documents, if they are
worth including, should be real references.

Section 3, 2nd sentence: I think "should be" -> "is"

Section 4.4.2 & 4.5.2: although DCCP is included in the "e.g." list in
the last sentence of these sections, it is not included in their
Description paragraph and there is no reference to RFC 4340. These
should at least be consistent within the registry entry.

Section 6.10.2: listing RFC 3022 twice seems odd.

Section 9: This says to "update" the reference clause of the "IPFIX
Information Elements" registry with "this document". Suggest using
"add" rather than "update" as in

 request IANA to add [this document] to the references for the
 "IPFIX Information Elements" registry.
Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Secdir last call review of draft-ietf-opsawg-tsvwg-udp-ipfix-08

[mohamed . boucadair]

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 23:29
> À : sec...@ietf.org
> Cc : draft-ietf-opsawg-tsvwg-udp-ipfix@ietf.org; last-
> c...@ietf.org; opsawg@ietf.org; watsonbl...@gmail.com
> Objet : Secdir last call review of draft-ietf-opsawg-tsvwg-udp-
> ipfix-08
> 
> 
> Reviewer: Watson Ladd
> Review result: Ready
> 
> I have reviewed this document as part of the security
> directorate's ongoing effort to review all IETF documents being
> processed by the IESG. These comments were written primarily for
> the benefit of the security area directors. Document editors and
> WG chairs should treat these comments just like any other last
> call comments.
> 
> The summary of the review is READY.
> 
> This document simply adds more information about a flow to IPFIX,
> that information being UDP extensions. It's no surprise that the
> securities considerations is appropriately short, and I found no
> reason to disagree.
> 
> Sincerely,
> Watson Ladd
> 


Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Genart last call review of draft-ietf-opsawg-tsvwg-udp-ipfix-08

[mohamed . boucadair]

Hi Robert,

Thanks for the review. 

The changes made to take into account your comment can be seen at: 
https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/udp-ipfix/draft-ietf-opsawg-tsvwg-udp-ipfix.txt_2=https://boucadair.github.io/udp-ipfix/Robert-Sparks-Review/draft-ietf-opsawg-tsvwg-udp-ipfix.txt.

Please see more context inline.

Cheers,
Med

> -Message d'origine-
> De : Robert Sparks via Datatracker 
> Envoyé : vendredi 3 mai 2024 17:55
> À : gen-...@ietf.org
> Cc : draft-ietf-opsawg-tsvwg-udp-ipfix@ietf.org; last-
> c...@ietf.org; opsawg@ietf.org
> Objet : Genart last call review of draft-ietf-opsawg-tsvwg-udp-
> ipfix-08
> 
> Reviewer: Robert Sparks
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General
> Area Review Team (Gen-ART) reviews all IETF documents being
> processed by the IESG for the IETF Chair.  Please treat these
> comments just like any other last call comments.
> 
> For more information, please see the FAQ at
> 
>  2Fwiki.ietf.org%2Fen%2Fgroup%2Fgen%2FGenArtFAQ=05%7C02%7Cmoh
> amed.boucadair%40orange.com%7C6d87cb3283c64ed6d19e08dc6b896870%7C
> 90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638503485103625289%7CU
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
> Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=adEyrIGMb6Q9ax9ZGQ2GzW%
> 2FsWbv2g1Dx7%2F0gUP0guH0%3D=0>.
> 
> Document: draft-ietf-opsawg-tsvwg-udp-ipfix-08
> Reviewer: Robert Sparks
> Review Date: 2024-05-03
> IETF LC End Date: 2024-05-10
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: Ready with nits
> I am the assigned Gen-ART reviewer for this draft. The General
> Area Review Team (Gen-ART) reviews all IETF documents being
> processed by the IESG for the IETF Chair.  Please treat these
> comments just like any other last call comments.
> 
> For more information, please see the FAQ at
> 
>  2Fwiki.ietf.org%2Fen%2Fgroup%2Fgen%2FGenArtFAQ=05%7C02%7Cmoh
> amed.boucadair%40orange.com%7C6d87cb3283c64ed6d19e08dc6b896870%7C
> 90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638503485103636074%7CU
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
> Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=%2FDTBvCsYxqbgHiEkXmhMU
> D9uXisLHgPnje4wrHvCanA%3D=0>.
> 
> Document: draft-ietf-opsawg-tsvwg-udp-ipfix-18
> Reviewer: Robert Sparks
> Review Date: 2024-05-03
> IETF LC End Date: 2024-05-10
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: Ready with nits
> 
> Consider discussing, or point to existing considerations about,
> what should happen when you are exporting very large udp options
> (perhaps constructed maliciously to be as large as possible) and
> you are carrying the exported values over UDP (Section 10.3 of
> RFC7011) and run out of room.
> 

[Med] These considerations are not specific to this document and fall under the 
generic considerations in base spec 7011 (Section 10.3.3). After think about 
this, I added a new section called (ops considerations) with the following 
content: 

* moved the text about reduced-size encoding to that section
* encourage the use of reduced-size encoding in the presence of EXP/UEXP (that 
is the *ExID IEs) takes precedence and thus their flags can be ignored
* add a pointer to transport (including MTU) IPFIX cons.

Also, we are not mentioning misbehaving nodes may generate large amount of 
data, etc. because that falls as well under the generic cons in RFC7011:

   Direct DoS attacks can also involve state exhaustion, whether at the
   transport layer (e.g., by creating a large number of pending
   connections) or within the IPFIX Collecting Process itself (e.g., by
   sending Flow Records pending Template or scope information, or a
   large amount of Options Template Records, etc.).

Added an explicit pointer to section 11 of 7011.

> There are several references by section number into I-D.ietf-
> tsvwg-udp-options that have become stale. For instance the
> pointer to section 22 in the security considerations should be
> pointing to section 24.
> 
> 
[Med] Good catch. Thanks.


Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email 

Re: [OPSAWG] advancing PCAP drafts

[Michael Richardson]

{please ignore unicast message I sent thirty seconds ago}

mohamed.boucad...@orange.com wrote:
> I think that it would be useful to have a new column to easily tag the
> status of an assignment. Deprecated ones can be marked as such using
> that new column, instead of having this in the description.

okay, I couldn't quite understand this from the diff, but in principal I have
no problem with that.

> For the DE guidance, I'm afraid that the first part of your text is 
redundant with what is already in 8126, especially this part:

> For the Specification Required policy, review and approval by a
> designated expert (see Section 5) is required, and the values and
> their meanings must be documented in a permanent and readily
> available public specification, in sufficient detail so that
> interoperability between independent implementations is possible.

So, a reason why I wrote that slight redundant text is so that the engineer
who is trying to get their marketing person to put the document out in a sane
place, would have a single place to point to.
But, if the WG feels that redundant, I can go with that.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-  *I*LIKE*TRAINS*



signature.asc
Description: PGP signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Genart last call review of draft-ietf-opsawg-ipfix-tcpo-v6eh-11

[mohamed . boucadair]

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] https://mailarchive.ietf.org/arch/msg/opsawg/g-cXqAHzazaA_gOf7Woxv2SiVJ4/

[2] 
https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/ipfix-tcpoptions-and-v6eh/draft-ietf-opsawg-ipfix-tcpo-v6eh.txt_2=https://boucadair.github.io/ipfix-tcpoptions-and-v6eh/genart-review/draft-ietf-opsawg-ipfix-tcpo-v6eh.txt

> -Message d'origine-
> De : Joel Halpern via Datatracker 
> Envoyé : vendredi 3 mai 2024 05:01
> À : gen-...@ietf.org
> Cc : draft-ietf-opsawg-ipfix-tcpo-v6eh@ietf.org; last-
> c...@ietf.org; opsawg@ietf.org
> Objet : Genart last call review of draft-ietf-opsawg-ipfix-tcpo-
> v6eh-11
> 
> Reviewer: Joel Halpern
> Review result: Ready with Issues
> 
> I am the assigned Gen-ART reviewer for this draft. The General
> Area Review Team (Gen-ART) reviews all IETF documents being
> processed by the IESG for the IETF Chair.  Please treat these
> comments just like any other last call comments.
> 
> For more information, please see the FAQ at
> 
>  2Fwiki.ietf.org%2Fen%2Fgroup%2Fgen%2FGenArtFAQ=05%7C02%7Cmoh
> amed.boucadair%40orange.com%7Cbfb8988782a541c5816808dc6b1d5145%7C
> 90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638503020857412204%7CU
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
> Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=WIsBdbKOD9ZyF0j%2BZKnq6
> ke79zktUZ9q%2B5n2iW34U%2Fs%3D=0>.
> 
> Document: draft-ietf-opsawg-ipfix-tcpo-v6eh-11
> Reviewer: Joel Halpern
> Review Date: 2024-05-02
> IETF LC End Date: 2024-05-10
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: This document is ready for publication as a Proposed
> Standard RFC
> 
> Major issues: None
> 
> Minor issues:
> The document uses the phrasing "If several extension header
> chains are
> observed in a Flow" in several places.  While I believe I
> figured out what
> was intended, it caused me difficulty.  Assuming I understood
> the intent, I
> would suggest defining a term "flow with varying header
> chain" as "a flow
> wherein different packets in the flow have a different
> sequence of
> extension header types codes."  And then use that term in the
> suitable
> places in the document.
> 
> Nits/editorial comments: None
> 


Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [OPSAWG] [Mud] I-D Action: draft-ietf-opsawg-ol-05.txt

[Eliot Lear]

Hi Med,

Thanks.  The impetus for this work is that some think that MUD files 
need a license statement.  As such, the augment should be sufficient in 
this case; but I will raise the question in netmod. As to this:


On 06.05.2024 11:16, mohamed.boucad...@orange.com wrote:


2. I know that you don’t use the security template in 8520, but given 
that you are introducing a reusable module I think that you should 
include it this time. In particular, please see the template of the 
reusable grouping here: 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-11#name-security-considerations-sect 
(see the last two para).



I can borrow that text no problem.  Thanks again.

Eliot


OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [Mud] I-D Action: draft-ietf-opsawg-ol-05.txt

[mohamed . boucadair]

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 you 
are introducing a reusable module I think that you should include it this time. 
In particular, please see the template of the reusable grouping here: 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-11#name-security-considerations-sect
 (see the last two para).

3. From a YANG standpoint, I think that defining an “ol” feature would be 
cleaner than the current use of “extensions”. I know that this is inherited 
from 8520, but a clarification is needed here, especially that the grouping is 
a reusable one.

4. You may check with netmod whether they have any preference about keeping the 
ol grouping as part of the mud extension or be defined as a separate module.

Cheers,
Med

De : Eliot Lear 
Envoyé : samedi 27 avril 2024 13:22
À : BOUCADAIR Mohamed INNOV/NET ; Michael 
Richardson ; opsawg@ietf.org; m...@ietf.org
Objet : Re: [Mud] [OPSAWG] I-D Action: draft-ietf-opsawg-ol-05.txt


Hi Med,

I attempted to whack your changes into the draft.  Carsten's merged the copy, 
so for ease of reading (and diffing) I'll post an update for your 
consideration.  Michael, I don't think it's necessary in this case to update 
8520 because we are indeed creating a new namespace.  However, this wasn't 
properly indicated in the draft.

Eliot
On 23.04.2024 08:40, 
mohamed.boucad...@orange.com wrote:

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 list/leaf-list thing, the 
other points are straightforward such as fixing a json example.



Cheers,

Med



-Message d'origine-

De : OPSAWG  De la 
part de Eliot Lear

Envoyé : lundi 22 avril 2024 20:02

À : Michael Richardson ; 
opsawg@ietf.org;

m...@ietf.org

Objet : Re: [OPSAWG] [Mud] I-D Action: draft-ietf-opsawg-ol-

05.txt





On 22.04.2024 19:29, Michael Richardson wrote:

0) Why is this document still kicking around the WG?

(Too bad it doesn't have the word "mud" in the filename.)



1) I find the title confusing.



2) I don't think that AUGMENT does what you want, because YANG

is not

extensible in the way we are used to doing with IANA.



3) I think that you have to revise the MUD specification

itself.



internet-dra...@ietf.org wrote:

 > Internet-Draft draft-ietf-opsawg-ol-05.txt is now

available. It is a work item

 > of the Operations and Management Area Working Group

(OPSAWG) WG of the IETF.



 > Title:   Ownership and licensing statements in YANG

 > Authors: Eliot Lear

 > Carsten Bormann

 > Name:draft-ietf-opsawg-ol-05.txt

 > Pages:   8

 > Dates:   2024-04-18



 > Abstract:



 > This memo provides for an extension to RFC 8520 that

allows MUD file

 > authors to specify ownership and licensing of MUD files

themselves.

 > This memo updates RFC 8520.  However, it can also be

used for

 > purposes outside of MUD, and the grouping is structured

as such.



 > The IETF datatracker status page for this Internet-Draft

is:

 >



https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2

Fdata

tracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-

ol%2F=05%7C02%7Cmohame



d.boucadair%40orange.com%7C92093d31adb04e54433408dc62f660b8%7C90c

7a20a



f34b40bfbc48b9253b6f5d20%7C0%7C0%7C638494057558027066%7CUnknown%7

CTWFp



bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV

CI6Mn



0%3D%7C0%7C%7C%7C=evbyUZ0QB67LVPRNDJMok1EDqirGGX3LRl5lcZBXY

%2FA%

3D=0



 > There is also an HTML version available at:

 >



https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2

Fwww.

ietf.org%2Farchive%2Fid%2Fdraft-ietf-opsawg-ol-

05.html=05%7C02%7C



mohamed.boucadair%40orange.com%7C92093d31adb04e54433408dc62f660b8

%7C90



c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638494057558035784%7CUnk

nown%



7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw

iLCJX



VCI6Mn0%3D%7C0%7C%7C%7C=ALyUu59W4HpqkNgltW2MR3tMIP0Oy7g2lx0

eMO2B

WFw%3D=0



 > A diff from the previous version is available at:

 >



https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2

Fauth

Re: [OPSAWG] advancing PCAP drafts

[mohamed . boucadair]

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 assignment. Deprecated ones can be marked as such using that new column, 
instead of having this in the description. 

For the DE guidance, I'm afraid that the first part of your text is redundant 
with what is already in 8126, especially this part:

   For the Specification Required policy, review and approval by a
   designated expert (see Section 5) is required, and the values and
   their meanings must be documented in a permanent and readily
   available public specification, in sufficient detail so that
   interoperability between independent implementations is possible.

I think that you can reuse most of the text at: 
https://datatracker.ietf.org/doc/html/rfc9445#name-guidelines-for-the-designat

Cheers,
Med

> -Message d'origine-
> De : Michael Richardson 
> Envoyé : vendredi 26 avril 2024 21:14
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : opsawg@ietf.org
> Objet : Re: [OPSAWG] advancing PCAP drafts
> 
> 
> mohamed.boucad...@orange.com wrote:
> > However, I checked
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fauthor-tools.ietf.org%2Fapi%2Fiddiff%3Fdoc_1%3Ddraft-ietf-
> opsawg-pcaplinktype%26url_2%3Dhttps%3A%2F%2FIETF-OPSAWG-
> WG.github.io%2Fdraft-ietf-opsawg-pcap%2Fdraft-ietf-opsawg-
> pcaplinktype.txt=05%7C02%7Cmohamed.boucadair%40orange.com%7C
> 26eac497038c49be9e0d08dc66250bb2%7C90c7a20af34b40bfbc48b9253b6f5d
> 20%7C0%7C0%7C638497556498067781%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%
> 7C%7C=vvCk3DYritUqEttLZS%2BjnOXfYF2p7eqjPFHjzmcvYT0%3D
> rved=0
> > and I'm afraid that your main copy override many changes
> agreed in the
> > past. May be I'm not looking in the right branch?
> 
> There is definitely a failure on my part to git push after the
> last posting.
> Guy then patched somethings, and I've just dealt with the
> conflict.
> Trailing periods on a bunch of entries.
> type 209, name changed.
> Some line wrapping changes too.
> 
> The table got broken in -02, sorry about that.
> 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fauthor-tools.ietf.org%2Fapi%2Fiddiff%3Fdoc_1%3Ddraft-ietf-
> opsawg-pcaplinktype-01%26url_2%3Dhttps%253A%252F%252FIETF-OPSAWG-
> WG.github.io%252Fdraft-ietf-opsawg-pcap%252Fdraft-ietf-opsawg-
> pcaplinktype.txt=05%7C02%7Cmohamed.boucadair%40orange.com%7C
> 26eac497038c49be9e0d08dc66250bb2%7C90c7a20af34b40bfbc48b9253b6f5d
> 20%7C0%7C0%7C638497556498078518%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%
> 7C%7C=KGLwhQ%2FjVG31N2RAY0sXpgRhRTSKRhEq8rg9jKPmb4Y%3D
> rved=0
> 
> might be a better diff.  I will post -03 now.
> 
> Let me paste in here the Designated Expert advice.
> What do you think about sentence two?  We aren't telling them not
> to accept specifications that are hard to get at, but rather to
> maybe push a bit for something more accessible.
> 
> # Guidance for Designated Experts
> 
> When processing a request for a Specification Required allocation
> the Designated Experts are expected to be able to find the
> relevant specification at a clearly stable URL.
> It is noted that many enterprise web sites do not maintain URLs
> over a long period of time, and a documented in a "wp-uploaded"
> section is highly likely to disappear.
> In addition Specifications that require a reader to click through
> any kind of marketing or legal agreement are not considered
> public.
> (This is the opinion of other corporate lawyers, who worry about
> what their employees might have agreed to)
> 
> The specification needs to be clearly written, and when the
> contents of the link type can contain an IPv4 or IPv6 header,
> then the octets between the beginning of the link type and the IP
> header needs to be very clearly specified in that document.
> 
> Specifications which are not publically available, but which may
> be obtained via liason agreements (such as to ITU-T, 3GPP, IEEE,
> etc.) are acceptable particularly if the document will be public
> eventually, but are discouraged.
> For other documents, the Designated Expert will need use their
> judgement, or consult the WG or an Area Director.
> 
> Linktypes may be allocated for specifications not publically
> available may be made within the First-Come/First-Served area.
> This includes specifications that might be classified.
> The minimal requirement is for a contact person for that link
> type.
> 


Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses,