Re: [OPSAWG] AD review of draft-ietf-opsawg-ipfix-tcpo-v6eh

[mohamed . boucadair]

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 draft-ietf-opsawg-ipfix-tcpo-v6eh


Hi Med,

Thanks for addressing most of the comments. Two follow-up comments. See below 
with [mj]

On Apr 15, 2024, at 4:51 AM, 
mohamed.boucad...@orange.com wrote:

Hi Mahesh,

Thank you for the review.

The changes can be tracked at: Diff: draft-ietf-opsawg-ipfix-tcpo-v6eh.txt - 
draft-ietf-opsawg-ipfix-tcpo-v6eh.txt.

Please see more context inline.

Cheers,
Med

De : Mahesh Jethanandani 
mailto:mjethanand...@gmail.com>>
Envoyé : dimanche 14 avril 2024 21:42
À : 
draft-ietf-opsawg-ipfix-tcpo-v...@ietf.org
Cc : opsawg@ietf.org; 
pait...@ciena.com
Objet : AD review of draft-ietf-opsawg-ipfix-tcpo-v6eh

Hi Authors,

Thanks for working on this document.

Here is my AD review of draft-ietf-opsawg-ipfix-tcpo-v6eh-10 version of the 
draft. They are divided between COMMENT and NIT. I expect that the COMMENTs 
will be resolved before the document is sent to IETF Last Call.

---
COMMENT
---

Section 1, paragraph 1

Should the draft-ietf-opsawg-ipfix-fixes be referenced also?

[Med] We used to refer to that I-D till the WG decided to deprecate the IEs. No 
need to have that ref back.

How about reference to RFC 7012 which is only mentioned in the Security 
Considerations section?
[Med] That's OK as the authoritative reference for the IEs/data types is the 
IANA registry itself.

Section 1.1, paragraph 12
>Section 3 addresses these issues.  Also, ipv6ExtensionHeaders IPFIX
>IE is deprecated in favor of the new IEs defined in this document.

On the question of how a legacy client receiver receiving this new 
ipv6ExtensionHeader definition would react, I was wondering if a forward 
reference to the Operational Considerations be made. Otherwise, till one reads 
that section, it is not clear what a legacy client should do.

[Med] Not sure what you meant by "legacy client receiver", but I suspect you 
mean the collector. If that is what you had in mind, then usual rfc7011 applies 
for manipulating templates, etc.

Section 1.2, paragraph 3
>*  Describe how any observed TCP option in a Flow can be exported
>   using IPFIX.  Only TCP options having a kind <= 63 can be exported
>   in a tcpOptions IE.


Is the problem that no TCP options can be exported using IPFIX, or is that TCP 
options having a Kind value >= 64 cannot be exported? Note, the first sentence 
starts by saying "how any observed TCP option in a Flow can(not) be exported", 
the not added from the sentence above.

[Med] That's an issue because we don't have full visibility on the options 
present in flow. For example, TCP-ENO or shared option can't be reported with 
(deprecated) tcpOptions.

[mj] În that case, do you want to:

s/Describe how any observed TCP options/Describe how some observed TCP options/

[Med] Works for me. Fixed. Thanks.



Section 1.2, paragraph 4
>Section 4 addresses these issues.  Also, tcpOptions IE is deprecated
>in favor of the new IEs defined in this document.

Same comment as above on providing a forward reference.

Section 3.3, paragraph 7
>Abstract Data Type:  unsigned256

I wonder why the opinion of a Expert Reviewer was overridden on the choice of 
defining this as unsigned256 instead of a bitfield.  I understand that there is 
precedence of using unsigned values for "flags", but as Paul noted, the value 
of a unsigned number is meaningless in the case where the individual bits hold 
values, not the whole unsigned number. Was it because of reduced-encoding?
[Med] The current design is consistent with how flags are handled in IPFIX. As 
you also rightfully mentioned, support of reduced-encoding is a key feature to 
support here given the long type. Please note that RFC7011 is explicit about 
target types:


   Reduced-size encoding MAY be applied to the following integer types:

   unsigned64, signed64, unsigned32, signed32, unsigned16, and signed16.

   The signed versus unsigned property of the reported value MUST be

   preserved.  The reduction in size can be to any number of octets

   smaller than the original type if the data value still fits, i.e., so

   that only leading zeroes are dropped.  For example, an unsigned64 can

   be reduced in size to 7, 6, 5, 4, 3, 2, 

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

[internet-drafts]

Internet-Draft draft-ietf-opsawg-ipfix-fixes-07.txt is now available. It is a
work item of the Operations and Management Area Working Group (OPSAWG) WG of
the IETF.

   Title:   Simple Fixes to the IP Flow Information Export (IPFIX) IANA Registry
   Authors: Mohamed Boucadair
Benoit Claise
   Name:draft-ietf-opsawg-ipfix-fixes-07.txt
   Pages:   34
   Dates:   2024-04-15

Abstract:

   This document provides simple fixes to the IANA IP Flow Information
   Export (IPFIX) registry.  Specifically, this document provides
   updates to fix a shortcoming in the description of some Information
   Elements (IE), updates to ensure a consistent structure when calling
   an existing IANA registry, and updates to fix broken pointers,
   orphaned section references, etc.  The updates are also meant to
   bring some consistency among the entries of the registry.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-opsawg-ipfix-fixes-07.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-fixes-07

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

Re: [OPSAWG] AD review of draft-ietf-opsawg-ipfix-fixes

[mohamed . boucadair]

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 review of draft-ietf-opsawg-ipfix-fixes


Hi Med,

Thanks for addressing most of the comments. One comment and one clarification.

This might be the iddiff tool, but in the diff file you shared I see the 
following under the title of the draft:

draft-ietf-opsawg-ipfix-fixes-latest

I was expecting to see a number, not the word latest.

[Med] That's normal. "latest" will be automatically bumped when the draft will 
be published.

For the clarification, see below with [mj].


On Apr 14, 2024, at 11:07 PM, 
mohamed.boucad...@orange.com wrote:

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 - 
draft-ietf-opsawg-ipfix-fixes.txt.

Please see inline for more context.

Cheers,
Med

De : Mahesh Jethanandani 
mailto:mjethanand...@gmail.com>>
Envoyé : dimanche 14 avril 2024 05:21
À : 
draft-ietf-opsawg-ipfix-fi...@ietf.org
Cc : opsawg@ietf.org
Objet : AD review of draft-ietf-opsawg-ipfix-fixes


Hi Authors,

Thank you for working on this document, This is my review of 
draft-ietf-opsawg-ipfix-fixes-06 draft. They are roughly divided between 
COMMENT and NIT. The COMMENTs should be resolved before this document is sent 
for IETF LC for publication as a Draft Standard.

---
COMMENT
---

Section 1, paragraph 2
>When OPSAWG was considering [I-D.ietf-opsawg-rfc7125-update] which
>updates [RFC7125], the WG realized that some other parts of the IANA
>IP Flow Information Export (IPFIX) registry [IANA-IPFIX] were not up-
>to-date.  Indeed, since its initial creation in 2007, some IPFIX
>Information Elements (IEs) are no longer adequately specified (while
>they were at some point in time in the past).  This document intends
>to update the IANA registry and bring some consistency among the
>entries of the registry.


For a specification to "no longer adequately" specify an IE, the underlying 
specification for IPFIX must have changed. If that is so, can you cite what 
changed? If not, I would just remove the statement. It is not serving any 
purpose in this specification.

[Med] We used to have update to description text of other IEs but those were 
removed as the decision was to deprecate them. So, OK to remove this sentence 
as well.

Section 1, paragraph 1
>As discussed with IANA during the publication process of [RFC9487],
>the "Additional Information" entry in [IANA-IPFIX] should contain a
>link to an existing registry, when applicable, as opposed to having:


What happens to the existing registries? Does Section 6 take care of all of 
them? Should the link in existing registries not specified in Section 6, also 
move to Additional Information?

[Med] Modifications to existing entries are covered in this doc.

[mj] When you say existing entries, do you mean all existing entries currently 
in the IANA registry?

[Med] We are actually fixed all existing entries to be consistent with the text 
quoted in Section 1, par 1.



Section 3, paragraph 3

Since Sections 4-7 are really for the IANA Consideration section, why not move 
them there?

[Med] I prefer to leave them in the core document to record the OLD/NEW; not 
only the IANA actions. Thanks.

Section 4.1.2, paragraph 0
> - Description:  This Information Element describes the forwarding
> status of the flow and any attached reasons.
> IPFIX reduced-size encoding is used as required.


I know that you explain what reduced-size encoding in the other IPFIX 
documents, but it will be worth repeating it here or refer to that definition 
from here.

[Med] We do already provide the authoritative definition in the para right 
before:

==
The description is also updated to clarify the use of the reduced-size encoding 
as per Section 6.2 of 
[RFC7011].
==

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "he"; alternatives might be "they", "them", "their"

[Med] That one is correct as we 

Re: [OPSAWG]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Carlos Pignataro]

Greg,Repeating something does not make it so…You had argued that those were definitions only within the context of DetNet, and each context can have different ones. You really cannot have it both ways. This is confusing. I-Ds follow causality — lots of things were approved to then be corrected. In-band — out-of-band — what do they really mean when…There is no “band”CThumb typed by Carlos Pignataro.Excuze typofraphicak errowsOn Apr 15, 2024, at 09:03, Greg Mirsky  wrote:Hi Carlos,I have to repeat that the definitions of terms "in-band OAM", "out-of-band OAM", and "on-path telemetry"   In-band OAM:  an active OAM method that is in band within the      monitored DetNet OAM domain when it traverses the same set of      links and interfaces receiving the same QoS and Packet      Replication, Elimination, and Ordering Functions (PREOF) treatment      as the monitored DetNet flow.   Out-of-band OAM:  an active OAM method whose path through the DetNet      domain may not be topologically identical to the path of the      monitored DetNet flow, its test packets may receive different QoS      and/or PREOF treatment, or both.   On-path telemetry:  on-path telemetry can be realized as a hybrid OAM      method.  The origination of the telemetry information is      inherently in band as packets in a DetNet flow are used as      triggers.  Collection of the on-path telemetry information can be      performed using in-band or out-of-band OAM methods.have been adopted by DetNet WG, approved by IESG and published as part of RFC 9551. I believe that a constructive approach would be to use the already accepted terminology, not to attempt to negate what has already been achieved in building up the IETF dictionary, particularly in the OAM area.Regards,GregOn Mon, Apr 15, 2024 at 2:00 PM Carlos Pignataro  wrote:Dear Greg,Thank you for the input.It appears that much of what you write below was already discussed at https://mailarchive.ietf.org/arch/msg/opsawg/IVQzSSU_kvGgopCyCp-8oqK_xmg/ Am I to understand you might be keen on continuing using "in-band OAM" with different meanings depending on the WG or context?Please find some follow-ups inline below:On Sun, Apr 14, 2024 at 10:49 AM Greg Mirsky  wrote:Dear All,I've read the latest version of the draft, Please find my notes and questions below:All SDOs that standardize methods and/or protocols in the field of OAM recognize that, in the FCAPS network management model, OAM is addressing the 'F' and 'P', i.e., Fault Management and Performance Monitoring methods and protocols. Furthermore, OAM is understood as a collection of various methods and protocols, rather than a single protocol, method, or tool. Hence, it seems like the document must use the same more granular approach in characterizing this or that OAM mechanism, including the possible variance in the application of that mechanism.CMP: This document intends to Update RFC 6291, a product of the IETF about OAM language usage, with support from its lead editor.I was under the impression that the discussion about the unfortunate choice of the original extended form of IOAM, "In-band OAM", has been put to rest with the agreement to extend it as "In-situ OAM". Why bring that discussion back? To revisit the decision of the IPPM WG? If so, then, as I imagine, that must be discussed in the IPPM WG.CMP: Not really, as explained in the draft already, clearly. See https://mailarchive.ietf.org/arch/msg/opsawg/jREEH1sFOZ-uxZNky-RTggpxkuk/ "Within the IETF, the terms "in-band" and "out-of-band" cannot be reliably understood consistently and unambiguously." That is a very strong and powerful statement that, in my opinion, requires serious analysis. For example, a survey of the IETF community that undoubtedly demonstrates the existence of multiple confronting interpretations that cannot be resolved by a mere wordsmithing. Can the authors cite such a survey and its results?CMP: The document already contains that analysis. It explains why those terms cannot be reliably understood consistently and unambiguously. And closely following that statement "the terms are not self-defining any more and cannot be understood by someone exposed to them for the first time" seems to break the very foundation of IETF TAO - learn, learn, and learn. I find the expectation of a first-comer to any IETF discussion to be able to fully master all the dictionary and terminology of that group to be, in my experience, a misguided. Through years, I've been suggesting anyone interested in joining and contributing to IETF work to first read (drafts, RFCs) and, most of all, the mail archive. Probably, I've been wasting their time..CMP: I am not sure I follow what you mean here -- but, (1) https://www.ietf.org/archive/id/draft-tenoever-tao-retirement-03.html (2) **There is no band** The following passage brings additional question:The guidance in this document is to avoid the terms "*-band" and instead find finer-granularity 

Re: [OPSAWG]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Greg Mirsky]

Hi Michael,
thank you for the update. I'm glad that you found the definition in RFC
9551 working for ANIMA's Autonomic Control Plane as well. I will read RFC
8994 to educate myself about it.

Regards,
Greg

On Mon, Apr 15, 2024 at 5:54 PM Michael Richardson 
wrote:

>
> Greg Mirsky  wrote:
> > I have to repeat that the definitions of terms "in-band OAM",
> "out-of-band
> > OAM", and "on-path telemetry"
>
> > In-band OAM:  an active OAM method that is in band within the
> > monitored DetNet OAM domain when it traverses the same set of
> > links and interfaces receiving the same QoS and Packet
> > Replication, Elimination, and Ordering Functions (PREOF) treatment
> > as the monitored DetNet flow.
>
> > Out-of-band OAM:  an active OAM method whose path through the DetNet
> > domain may not be topologically identical to the path of the
> > monitored DetNet flow, its test packets may receive different QoS
> > and/or PREOF treatment, or both.
>
> On the topic of RFC8994's overlay management network, which we described as
> virtual out-of-band.  It would seem to fit into the above definition, since
> the overlay packets might go another route, and might get a different QoS
> treatment.
>
>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] AD review of draft-ietf-opsawg-ipfix-tcpo-v6eh

[Mahesh Jethanandani]

Hi Med,

Thanks for addressing most of the comments. Two follow-up comments. See below 
with [mj]

> On Apr 15, 2024, at 4:51 AM, mohamed.boucad...@orange.com wrote:
> 
> Hi Mahesh,
>  
> Thank you for the review.
>  
> The changes can be tracked at: Diff: draft-ietf-opsawg-ipfix-tcpo-v6eh.txt - 
> draft-ietf-opsawg-ipfix-tcpo-v6eh.txt 
> .
>  
> Please see more context inline.
>  
> Cheers,
> Med
>  
> De : Mahesh Jethanandani  > 
> Envoyé : dimanche 14 avril 2024 21:42
> À : draft-ietf-opsawg-ipfix-tcpo-v...@ietf.org 
> 
> Cc : opsawg@ietf.org ; pait...@ciena.com 
> 
> Objet : AD review of draft-ietf-opsawg-ipfix-tcpo-v6eh
>  
> Hi Authors,
>  
> Thanks for working on this document.
>  
> Here is my AD review of draft-ietf-opsawg-ipfix-tcpo-v6eh-10 version of the 
> draft. They are divided between COMMENT and NIT. I expect that the COMMENTs 
> will be resolved before the document is sent to IETF Last Call.
>  
> ---
> COMMENT
> ---
>  
> Section 1, paragraph 1
>  
> Should the draft-ietf-opsawg-ipfix-fixes be referenced also?
>  
> [Med] We used to refer to that I-D till the WG decided to deprecate the IEs. 
> No need to have that ref back.
>  
> How about reference to RFC 7012 which is only mentioned in the Security 
> Considerations section?
> [Med] That’s OK as the authoritative reference for the IEs/data types is the 
> IANA registry itself.
>  
> Section 1.1, paragraph 12
> >Section 3 addresses these issues.  Also, ipv6ExtensionHeaders IPFIX
> >IE is deprecated in favor of the new IEs defined in this document.
>  
> On the question of how a legacy client receiver receiving this new 
> ipv6ExtensionHeader definition would react, I was wondering if a forward 
> reference to the Operational Considerations be made. Otherwise, till one 
> reads that section, it is not clear what a legacy client should do. 
>  
> [Med] Not sure what you meant by “legacy client receiver”, but I suspect you 
> mean the collector. If that is what you had in mind, then usual rfc7011 
> applies for manipulating templates, etc.
>  
> Section 1.2, paragraph 3
> >*  Describe how any observed TCP option in a Flow can be exported
> >   using IPFIX.  Only TCP options having a kind <= 63 can be exported
> >   in a tcpOptions IE.
>  
>  
> Is the problem that no TCP options can be exported using IPFIX, or is that 
> TCP options having a Kind value >= 64 cannot be exported? Note, the first 
> sentence starts by saying “how any observed TCP option in a Flow can(not) be 
> exported”, the not added from the sentence above.
>  
> [Med] That’s an issue because we don’t have full visibility on the options 
> present in flow. For example, TCP-ENO or shared option can’t be reported with 
> (deprecated) tcpOptions.

[mj] În that case, do you want to:

s/Describe how any observed TCP options/Describe how some observed TCP options/

>  
>  
> Section 1.2, paragraph 4
> >Section 4 addresses these issues.  Also, tcpOptions IE is deprecated
> >in favor of the new IEs defined in this document.
>  
> Same comment as above on providing a forward reference.
>  
> Section 3.3, paragraph 7
> >Abstract Data Type:  unsigned256
>  
> I wonder why the opinion of a Expert Reviewer was overridden on the choice of 
> defining this as unsigned256 instead of a bitfield.  I understand that there 
> is precedence of using unsigned values for "flags", but as Paul noted, the 
> value of a unsigned number is meaningless in the case where the individual 
> bits hold values, not the whole unsigned number. Was it because of 
> reduced-encoding?
> [Med] The current design is consistent with how flags are handled in IPFIX. 
> As you also rightfully mentioned, support of reduced-encoding is a key 
> feature to support here given the long type. Please note that RFC7011 is 
> explicit about target types:
>  
>Reduced-size encoding MAY be applied to the following integer types:
>unsigned64, signed64, unsigned32, signed32, unsigned16, and signed16.
>The signed versus unsigned property of the reported value MUST be
>preserved.  The reduction in size can be to any number of octets
>smaller than the original type if the data value still fits, i.e., so
>that only leading zeroes are dropped.  For example, an unsigned64 can
>be reduced in size to 7, 6, 5, 4, 3, 2, or 1 octet(s).
>  
> As a side note, we discussed with Benoît whether we need we tag this I-D as 
> formally updating RFC7011 but we finally 

Re: [OPSAWG] AD review of draft-ietf-opsawg-ipfix-fixes

[Mahesh Jethanandani]

Hi Med,

Thanks for addressing most of the comments. One comment and one clarification.

This might be the iddiff tool, but in the diff file you shared I see the 
following under the title of the draft:

draft-ietf-opsawg-ipfix-fixes-latest

I was expecting to see a number, not the word latest.

For the clarification, see below with [mj].

> On Apr 14, 2024, at 11:07 PM, mohamed.boucad...@orange.com wrote:
> 
> 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 - draft-ietf-opsawg-ipfix-fixes.txt 
> .
>  
> Please see inline for more context.
>  
> Cheers,
> Med
>  
> De : Mahesh Jethanandani  > 
> Envoyé : dimanche 14 avril 2024 05:21
> À : draft-ietf-opsawg-ipfix-fi...@ietf.org 
> 
> Cc : opsawg@ietf.org 
> Objet : AD review of draft-ietf-opsawg-ipfix-fixes
>  
>  
> 
> Hi Authors,
>  
> Thank you for working on this document, This is my review of 
> draft-ietf-opsawg-ipfix-fixes-06 draft. They are roughly divided between 
> COMMENT and NIT. The COMMENTs should be resolved before this document is sent 
> for IETF LC for publication as a Draft Standard.
>  
> ---
> COMMENT
> ---
>  
> Section 1, paragraph 2
> >When OPSAWG was considering [I-D.ietf-opsawg-rfc7125-update] which
> >updates [RFC7125], the WG realized that some other parts of the IANA
> >IP Flow Information Export (IPFIX) registry [IANA-IPFIX] were not up-
> >to-date.  Indeed, since its initial creation in 2007, some IPFIX
> >Information Elements (IEs) are no longer adequately specified (while
> >they were at some point in time in the past).  This document intends
> >to update the IANA registry and bring some consistency among the
> >entries of the registry.
>  
>  
> For a specification to "no longer adequately" specify an IE, the underlying 
> specification for IPFIX must have changed. If that is so, can you cite what 
> changed? If not, I would just remove the statement. It is not serving any 
> purpose in this specification.
>  
> [Med] We used to have update to description text of other IEs but those were 
> removed as the decision was to deprecate them. So, OK to remove this sentence 
> as well.
>  
> Section 1, paragraph 1
> >As discussed with IANA during the publication process of [RFC9487],
> >the "Additional Information" entry in [IANA-IPFIX] should contain a
> >link to an existing registry, when applicable, as opposed to having:
>  
>  
> What happens to the existing registries? Does Section 6 take care of all of 
> them? Should the link in existing registries not specified in Section 6, also 
> move to Additional Information?
>  
> [Med] Modifications to existing entries are covered in this doc.

[mj] When you say existing entries, do you mean all existing entries currently 
in the IANA registry?

>  
> Section 3, paragraph 3
>  
> Since Sections 4-7 are really for the IANA Consideration section, why not 
> move them there?
>  
> [Med] I prefer to leave them in the core document to record the OLD/NEW; not 
> only the IANA actions. Thanks.
>  
> Section 4.1.2, paragraph 0
> > - Description:  This Information Element describes the forwarding
> > status of the flow and any attached reasons.
> > IPFIX reduced-size encoding is used as required.
>  
>  
> I know that you explain what reduced-size encoding in the other IPFIX 
> documents, but it will be worth repeating it here or refer to that definition 
> from here.
>  
> [Med] We do already provide the authoritative definition in the para right 
> before:
>  
> ==
> The description is also updated to clarify the use of the reduced-size 
> encoding as per Section 6.2  
> of [RFC7011 
> ].
> ==
>  
> Found terminology that should be reviewed for inclusivity; see
> https://www.rfc-editor.org/part2/#inclusive_language 
>  for background and more
> guidance:
>  
>  * Term "he"; alternatives might be "they", "them", "their"
>  
> [Med] That one is correct as we refer to Andrew.
>  
>  * Term "traditional"; alternatives might be "classic", "classical", "common",
>"conventional", "customary", "fixed", "habitual", "historic",
>"long-established", "popular", "prescribed", "regular", "rooted",
>"time-honored", "universal", "widely used", 

Re: [OPSAWG]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Michael Richardson]

Greg Mirsky  wrote:
> I have to repeat that the definitions of terms "in-band OAM", "out-of-band
> OAM", and "on-path telemetry"

> In-band OAM:  an active OAM method that is in band within the
> monitored DetNet OAM domain when it traverses the same set of
> links and interfaces receiving the same QoS and Packet
> Replication, Elimination, and Ordering Functions (PREOF) treatment
> as the monitored DetNet flow.

> Out-of-band OAM:  an active OAM method whose path through the DetNet
> domain may not be topologically identical to the path of the
> monitored DetNet flow, its test packets may receive different QoS
> and/or PREOF treatment, or both.

On the topic of RFC8994's overlay management network, which we described as
virtual out-of-band.  It would seem to fit into the above definition, since
the overlay packets might go another route, and might get a different QoS
treatment.


--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






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

Re: [OPSAWG]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Greg Mirsky]

Hi Carlos,
I have to repeat that the definitions of terms "in-band OAM", "out-of-band
OAM", and "on-path telemetry"
   In-band OAM:  an active OAM method that is in band within the
  monitored DetNet OAM domain when it traverses the same set of
  links and interfaces receiving the same QoS and Packet
  Replication, Elimination, and Ordering Functions (PREOF) treatment
  as the monitored DetNet flow.

   Out-of-band OAM:  an active OAM method whose path through the DetNet
  domain may not be topologically identical to the path of the
  monitored DetNet flow, its test packets may receive different QoS
  and/or PREOF treatment, or both.

   On-path telemetry:  on-path telemetry can be realized as a hybrid OAM
  method.  The origination of the telemetry information is
  inherently in band as packets in a DetNet flow are used as
  triggers.  Collection of the on-path telemetry information can be
  performed using in-band or out-of-band OAM methods.

have been adopted by DetNet WG, approved by IESG and published as part of RFC
9551 . I believe that a
constructive approach would be to use the already accepted terminology, not
to attempt to negate what has already been achieved in building up the IETF
dictionary, particularly in the OAM area.

Regards,
Greg

On Mon, Apr 15, 2024 at 2:00 PM Carlos Pignataro  wrote:

> Dear Greg,
>
> Thank you for the input.
>
> It appears that much of what you write below was already discussed at
> https://mailarchive.ietf.org/arch/msg/opsawg/IVQzSSU_kvGgopCyCp-8oqK_xmg/
>
> Am I to understand you might be keen on continuing using "in-band OAM"
> with different meanings depending on the WG or context?
>
> Please find some follow-ups inline below:
>
> On Sun, Apr 14, 2024 at 10:49 AM Greg Mirsky 
> wrote:
>
>> Dear All,
>> I've read the latest version of the draft, Please find my notes and
>> questions below:
>>
>>- All SDOs that standardize methods and/or protocols in the field of
>>OAM recognize that, in the FCAPS network management model, OAM is
>>addressing the 'F' and 'P', i.e., Fault Management and Performance
>>Monitoring methods and protocols. Furthermore, OAM is understood as a
>>collection of various methods and protocols, rather than a single 
>> protocol,
>>method, or tool. Hence, it seems like the document must use the same more
>>granular approach in characterizing this or that OAM mechanism, including
>>the possible variance in the application of that mechanism.
>>
>> CMP: This document intends to Update RFC 6291, a product of the IETF
> about OAM language usage, with support from its lead editor.
>
>>
>>- I was under the impression that the discussion about the
>>unfortunate choice of the original extended form of IOAM, "In-band OAM",
>>has been put to rest with the agreement to extend it as "In-situ OAM". Why
>>bring that discussion back? To revisit the decision of the IPPM WG? If so,
>>then, as I imagine, that must be discussed in the IPPM WG.
>>
>> CMP: Not really, as explained in the draft already, clearly. See
> https://mailarchive.ietf.org/arch/msg/opsawg/jREEH1sFOZ-uxZNky-RTggpxkuk/
>
>>
>>- "Within the IETF, the terms "in-band" and "out-of-band" cannot be
>>reliably understood consistently and unambiguously." That is a very strong
>>and powerful statement that, in my opinion, requires serious analysis. For
>>example, a survey of the IETF community that undoubtedly demonstrates the
>>existence of multiple confronting interpretations that cannot be resolved
>>by a mere wordsmithing. Can the authors cite such a survey and its 
>> results?
>>
>>
> CMP: The document already contains that analysis. It explains why those
> terms cannot be reliably understood consistently and unambiguously.
>
>>
>>- And closely following that statement "the terms are not
>>self-defining any more and cannot be understood by someone exposed to them
>>for the first time" seems to break the very foundation of IETF TAO - 
>> learn,
>>learn, and learn. I find the expectation of a first-comer to any IETF
>>discussion to be able to fully master all the dictionary and terminology 
>> of
>>that group to be, in my experience, a misguided. Through years, I've been
>>suggesting anyone interested in joining and contributing to IETF work to
>>first read (drafts, RFCs) and, most of all, the mail archive. Probably,
>>I've been wasting their time..
>>
>> CMP: I am not sure I follow what you mean here -- but, (1)
> https://www.ietf.org/archive/id/draft-tenoever-tao-retirement-03.html (2)
> **There is no band**
>
>
>>
>>- The following passage brings additional question:
>>
>> The guidance in this document is to avoid the terms "*-band" and instead
>> find finer-granularity descriptive terms. The definitions presented in this
>> document are for use in all future IETF documents that refer to OAM, 

Re: [OPSAWG]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Carlos Pignataro]

Dear Greg,

Thank you for the input.

It appears that much of what you write below was already discussed at
https://mailarchive.ietf.org/arch/msg/opsawg/IVQzSSU_kvGgopCyCp-8oqK_xmg/

Am I to understand you might be keen on continuing using "in-band OAM" with
different meanings depending on the WG or context?

Please find some follow-ups inline below:

On Sun, Apr 14, 2024 at 10:49 AM Greg Mirsky  wrote:

> Dear All,
> I've read the latest version of the draft, Please find my notes and
> questions below:
>
>- All SDOs that standardize methods and/or protocols in the field of
>OAM recognize that, in the FCAPS network management model, OAM is
>addressing the 'F' and 'P', i.e., Fault Management and Performance
>Monitoring methods and protocols. Furthermore, OAM is understood as a
>collection of various methods and protocols, rather than a single protocol,
>method, or tool. Hence, it seems like the document must use the same more
>granular approach in characterizing this or that OAM mechanism, including
>the possible variance in the application of that mechanism.
>
> CMP: This document intends to Update RFC 6291, a product of the IETF about
OAM language usage, with support from its lead editor.

>
>- I was under the impression that the discussion about the unfortunate
>choice of the original extended form of IOAM, "In-band OAM", has been put
>to rest with the agreement to extend it as "In-situ OAM". Why bring that
>discussion back? To revisit the decision of the IPPM WG? If so, then, as I
>imagine, that must be discussed in the IPPM WG.
>
> CMP: Not really, as explained in the draft already, clearly. See
https://mailarchive.ietf.org/arch/msg/opsawg/jREEH1sFOZ-uxZNky-RTggpxkuk/

>
>- "Within the IETF, the terms "in-band" and "out-of-band" cannot be
>reliably understood consistently and unambiguously." That is a very strong
>and powerful statement that, in my opinion, requires serious analysis. For
>example, a survey of the IETF community that undoubtedly demonstrates the
>existence of multiple confronting interpretations that cannot be resolved
>by a mere wordsmithing. Can the authors cite such a survey and its results?
>
>
CMP: The document already contains that analysis. It explains why those
terms cannot be reliably understood consistently and unambiguously.

>
>- And closely following that statement "the terms are not
>self-defining any more and cannot be understood by someone exposed to them
>for the first time" seems to break the very foundation of IETF TAO - learn,
>learn, and learn. I find the expectation of a first-comer to any IETF
>discussion to be able to fully master all the dictionary and terminology of
>that group to be, in my experience, a misguided. Through years, I've been
>suggesting anyone interested in joining and contributing to IETF work to
>first read (drafts, RFCs) and, most of all, the mail archive. Probably,
>I've been wasting their time..
>
> CMP: I am not sure I follow what you mean here -- but, (1)
https://www.ietf.org/archive/id/draft-tenoever-tao-retirement-03.html (2)
**There is no band**


>
>- The following passage brings additional question:
>
> The guidance in this document is to avoid the terms "*-band" and instead
> find finer-granularity descriptive terms. The definitions presented in this
> document are for use in all future IETF documents that refer to OAM, and
> the terms "in-band OAM" and "out-of-band OAM" are not to be used in future
> documents.
>
>
>- Is such an overreaching scope of the OPSAWG WG in its charter?
>
> CMP: That is a question for the chairs, but this document originating in
opsawg will need to have ietf-wide review...

>
>- I found a number of references to DetNet OAM that, regrettably,
>misinterpreted documents approved by DetNet WG and some already published
>as RFCs. I can only encourage an open communication between the proponents
>of this work and the DetNet WG rather than an attempt to force something
>foreign to the essence of Deterministic Networking and the application of
>OAM in DetNet.
>- It appears that the term "Combined OAM", introduced in this
>document, allows for a combination of "Non-Path Congruent OAM" with
>"Equal-QoS-Treatment OAM". If that is the case, what do you see as the
>value of using such "combined OAM"?
>- In my reading of Section 3 and references to RFC 7799, I find it
>getting close to benign misinterpretation of RFC 7799:
>   - Firstly, RFC 7799 appropriately discusses OAM methods and
>   metrics, i.e., elements of OAM. Hence, because of, what seems like, a
>   misunderstanding of how OAM is composed, the document dismisses RFC 7799
>   even though that is the fundamental document with 16 references by IETF
>   documents and more by documents in other SDOs.
>   - In the definition of the "Compound OAM" it is suggested that a

Re: [OPSAWG] AD review of draft-ietf-opsawg-ipfix-tcpo-v6eh

[mohamed . boucadair]

Hi Mahesh,

Thank you for the review.

The changes can be tracked at: Diff: draft-ietf-opsawg-ipfix-tcpo-v6eh.txt - 
draft-ietf-opsawg-ipfix-tcpo-v6eh.txt.

Please see more context inline.

Cheers,
Med

De : Mahesh Jethanandani 
Envoyé : dimanche 14 avril 2024 21:42
À : draft-ietf-opsawg-ipfix-tcpo-v...@ietf.org
Cc : opsawg@ietf.org; pait...@ciena.com
Objet : AD review of draft-ietf-opsawg-ipfix-tcpo-v6eh

Hi Authors,

Thanks for working on this document.

Here is my AD review of draft-ietf-opsawg-ipfix-tcpo-v6eh-10 version of the 
draft. They are divided between COMMENT and NIT. I expect that the COMMENTs 
will be resolved before the document is sent to IETF Last Call.

---
COMMENT
---

Section 1, paragraph 1

Should the draft-ietf-opsawg-ipfix-fixes be referenced also?

[Med] We used to refer to that I-D till the WG decided to deprecate the IEs. No 
need to have that ref back.

How about reference to RFC 7012 which is only mentioned in the Security 
Considerations section?
[Med] That's OK as the authoritative reference for the IEs/data types is the 
IANA registry itself.

Section 1.1, paragraph 12
>Section 3 addresses these issues.  Also, ipv6ExtensionHeaders IPFIX
>IE is deprecated in favor of the new IEs defined in this document.

On the question of how a legacy client receiver receiving this new 
ipv6ExtensionHeader definition would react, I was wondering if a forward 
reference to the Operational Considerations be made. Otherwise, till one reads 
that section, it is not clear what a legacy client should do.

[Med] Not sure what you meant by "legacy client receiver", but I suspect you 
mean the collector. If that is what you had in mind, then usual rfc7011 applies 
for manipulating templates, etc.

Section 1.2, paragraph 3
>*  Describe how any observed TCP option in a Flow can be exported
>   using IPFIX.  Only TCP options having a kind <= 63 can be exported
>   in a tcpOptions IE.


Is the problem that no TCP options can be exported using IPFIX, or is that TCP 
options having a Kind value >= 64 cannot be exported? Note, the first sentence 
starts by saying "how any observed TCP option in a Flow can(not) be exported", 
the not added from the sentence above.

[Med] That's an issue because we don't have full visibility on the options 
present in flow. For example, TCP-ENO or shared option can't be reported with 
(deprecated) tcpOptions.


Section 1.2, paragraph 4
>Section 4 addresses these issues.  Also, tcpOptions IE is deprecated
>in favor of the new IEs defined in this document.

Same comment as above on providing a forward reference.

Section 3.3, paragraph 7
>Abstract Data Type:  unsigned256

I wonder why the opinion of a Expert Reviewer was overridden on the choice of 
defining this as unsigned256 instead of a bitfield.  I understand that there is 
precedence of using unsigned values for "flags", but as Paul noted, the value 
of a unsigned number is meaningless in the case where the individual bits hold 
values, not the whole unsigned number. Was it because of reduced-encoding?
[Med] The current design is consistent with how flags are handled in IPFIX. As 
you also rightfully mentioned, support of reduced-encoding is a key feature to 
support here given the long type. Please note that RFC7011 is explicit about 
target types:


   Reduced-size encoding MAY be applied to the following integer types:

   unsigned64, signed64, unsigned32, signed32, unsigned16, and signed16.

   The signed versus unsigned property of the reported value MUST be

   preserved.  The reduction in size can be to any number of octets

   smaller than the original type if the data value still fits, i.e., so

   that only leading zeroes are dropped.  For example, an unsigned64 can

   be reduced in size to 7, 6, 5, 4, 3, 2, or 1 octet(s).

As a side note, we discussed with Benoît whether we need we tag this I-D as 
formally updating RFC7011 but we finally preferred to no do so because the 
authoritative registry for the data type is the registry.

If so, that should be stated as the reason. BTW, can a bitfield not have 
similar semantics of reduced-encoding, if all the (MSB) bits are not being used?

[Med] There is no "bitfield" data type. The only mention of "bit field" in 7011 
is the following


   "flags" is an integral value that represents a set of bit fields.
   Logical operations are appropriate on such values, but other
   mathematical operations are not.  Flags MUST always be of an unsigned
   data type.

"bit field" is used for almost all IEs with flags (IP Flow Information Export 
(IPFIX) 

Re: [OPSAWG] AD review of draft-ietf-opsawg-ipfix-fixes

[mohamed . boucadair]

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 - 
draft-ietf-opsawg-ipfix-fixes.txt.

Please see inline for more context.

Cheers,
Med

De : Mahesh Jethanandani 
Envoyé : dimanche 14 avril 2024 05:21
À : draft-ietf-opsawg-ipfix-fi...@ietf.org
Cc : opsawg@ietf.org
Objet : AD review of draft-ietf-opsawg-ipfix-fixes


Hi Authors,

Thank you for working on this document, This is my review of 
draft-ietf-opsawg-ipfix-fixes-06 draft. They are roughly divided between 
COMMENT and NIT. The COMMENTs should be resolved before this document is sent 
for IETF LC for publication as a Draft Standard.

---
COMMENT
---

Section 1, paragraph 2
>When OPSAWG was considering [I-D.ietf-opsawg-rfc7125-update] which
>updates [RFC7125], the WG realized that some other parts of the IANA
>IP Flow Information Export (IPFIX) registry [IANA-IPFIX] were not up-
>to-date.  Indeed, since its initial creation in 2007, some IPFIX
>Information Elements (IEs) are no longer adequately specified (while
>they were at some point in time in the past).  This document intends
>to update the IANA registry and bring some consistency among the
>entries of the registry.


For a specification to "no longer adequately" specify an IE, the underlying 
specification for IPFIX must have changed. If that is so, can you cite what 
changed? If not, I would just remove the statement. It is not serving any 
purpose in this specification.

[Med] We used to have update to description text of other IEs but those were 
removed as the decision was to deprecate them. So, OK to remove this sentence 
as well.

Section 1, paragraph 1
>As discussed with IANA during the publication process of [RFC9487],
>the "Additional Information" entry in [IANA-IPFIX] should contain a
>link to an existing registry, when applicable, as opposed to having:


What happens to the existing registries? Does Section 6 take care of all of 
them? Should the link in existing registries not specified in Section 6, also 
move to Additional Information?

[Med] Modifications to existing entries are covered in this doc.

Section 3, paragraph 3

Since Sections 4-7 are really for the IANA Consideration section, why not move 
them there?

[Med] I prefer to leave them in the core document to record the OLD/NEW; not 
only the IANA actions. Thanks.

Section 4.1.2, paragraph 0
> - Description:  This Information Element describes the forwarding
> status of the flow and any attached reasons.
> IPFIX reduced-size encoding is used as required.


I know that you explain what reduced-size encoding in the other IPFIX 
documents, but it will be worth repeating it here or refer to that definition 
from here.

[Med] We do already provide the authoritative definition in the para right 
before:

==
The description is also updated to clarify the use of the reduced-size encoding 
as per Section 6.2 of 
[RFC7011].
==

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "he"; alternatives might be "they", "them", "their"

[Med] That one is correct as we refer to Andrew.

 * Term "traditional"; alternatives might be "classic", "classical", "common",
   "conventional", "customary", "fixed", "habitual", "historic",
   "long-established", "popular", "prescribed", "regular", "rooted",
   "time-honored", "universal", "widely used", "widespread"

[Med] We can't do nothing here because that points to:

   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
  Address Translator (Traditional NAT)", RFC 3022,
  DOI 10.17487/RFC3022, January 2001,
  https://www.rfc-editor.org/rfc/rfc3022.


---
NIT
---

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Uncited references: [RFC_Errata_1739] and [RFC_Errata_1738].

[Med] Fixed. Thanks.

Reference [RFC2482] to RFC2482, which