Re: [tcpm] [IPFIX] WG LC: IPFIX documents

[[e-mail]]

Hi Paul,

Thanks for the review.

Please see inline.

Cheers,
Med

De : ipv6 <[e-mail]> De la part de Aitken, Paul
Envoyé : vendredi 19 janvier 2024 11:58
À : Joe Clarke (jclarke) <jclarke=[e-mail]>; [e-mail]
Cc : [e-mail]; [e-mail]; [e-mail]; [e-mail]
Objet : Re: [IPv6] [IPFIX] WG LC: IPFIX documents

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).

[Med] ACK.

   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 (IPFIX) Entities (iana.org)<https://www.iana.org/assignments/ipfix/ipfix.xhtml> (where unsigned8, unsigned16, unsigned32, and unsigned64 are used for IEs having data semantic of flags.


    3.  UDP Options at a Glance

    Also, Section 4.3 specifies a new IPFIX to
    export observed ExIDs in the UEXP options.

Something is missing here: "a new IPFIX IE to ...".
[Med] Fixed.

    Only 16-bits ExIDs are supported.

Clarify, "Only 16-bits ExIDs are supported in UDP."
[Med] updated to « supported in [I-D.ietf-tsvwg-udp-options]."

    The motivation for
   exporting such data is similar to the one for exporting TCP options
   (tcpOptions) or IPv6 Extension Headers (ipv6ExtensionHeaders).

Please state the motivation or include an xref where the motivation can be found.
[Med] We may simply delete that sentence.

    4.1 - 4.3

These definitions should be in the IANA section.


    5.  An Example

   Given UDP kind allocation in Section 10 of
   [I-D.ietf-tsvwg-udp-options] and the option mapping defined in
   Section 4.1,

Section 4.1 of what?
[Med] of this document.


    4.1.  udpOptions

      To cover the 0-255 kind range, up to 255 flags can be set in the
      value field.

Up to 256 flags.
[Med]  ACK.

    For example, if only option kinds =< 32 are observed

Conventionally "<=" is used.
[Med]  OK

        Abstract Data Type:  unsigned256

It's not an integer, it's a bitfield.
[Med] see above.

    4.2 and 4.3

It would be better to spell out the names in full: udpExperimentalOptionSafeExID and udpExperimentalOptionUnsafeExID
[Med] Expanded to udpSafeExperimentalOptionExID and udpUnsafeExperimentalOptionExID


I would not have understand what these measure, nor how to encode them, without having first reviewed draft-ietf-opsawg-ipfix-tcpo-v6eh. Examples in section 5 would be useful.
[Med] OK, will update the example.

The octetArray type is especially confusing as these are really hextetArrays.

[Med] Not sure we need a new data type here as octeArray is defined as follows:
   The octetArray data type has no encoding rules; it represents a raw
   array of zero or more octets, with the interpretation of the octets
   defined in the Information Element definition.

    4.3.  udpUnsafeExpOptionExID

   Description:  Observed Expermients ID (ExIDs) in the UNSAFE
      Experimental option (UEXP, Kind=254).

Typo, "Experiments".
[Med]  Fixed.

P.

On 18/12/23 19:22, Joe Clarke (jclarke) wrote:
We'd like to kick off a [rather extended] WG LC on the three IPFIX-related "fixes" documents we have in the hopper.  We've already requested some directorate reviews for these, and the authors feel they have stabilized well.

Please review:


  1.  https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh/ [datatracker.ietf.org]<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh/__;!!OSsGDw!I6YR3K0-150A1C0ElDbVuvpjkK-Ylkh69dILZCWJl3lPScov6t5X2FzyrjqruiynmXjCnHZBzRn1Gy8IthVfCMEo_jvU$>
  2.  https://datatracker.ietf.org/doc/draft-ietf-opsawg-tsvwg-udp-ipfix/ [datatracker.ietf.org]<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-opsawg-tsvwg-udp-ipfix/__;!!OSsGDw!I6YR3K0-150A1C0ElDbVuvpjkK-Ylkh69dILZCWJl3lPScov6t5X2FzyrjqruiynmXjCnHZBzRn1Gy8IthVfCG_d35-j$>
  3.  https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes/ [datatracker.ietf.org]<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes/__;!!OSsGDw!I6YR3K0-150A1C0ElDbVuvpjkK-Ylkh69dILZCWJl3lPScov6t5X2FzyrjqruiynmXjCnHZBzRn1Gy8IthVfCAzlAEMT$>

And comment as to whether or not you feel they are in the right shape to progress to the IESG.  We will run this LC until Jan 8 given that the holidays means some people will not be around.  Also note that an IPR poll was conducted prior to adoption and no known IPR has been disclosed.

Thanks.

Joe



_______________________________________________

IPFIX mailing list

[e-mail]<mailto:[e-mail]>

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipfix__;!!OSsGDw!I6YR3K0-150A1C0ElDbVuvpjkK-Ylkh69dILZCWJl3lPScov6t5X2FzyrjqruiynmXjCnHZBzRn1Gy8IthVfCO14NBgv$ [ietf[.]org]

____________________________________________________________________________________________________________
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.