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

[[e-mail]]

Hi Paul,

Thank you for the careful review and good suggestions. Went with almost all of them.

Please see inline for more context.

Cheers,
Med

De : ipv6 <[e-mail]> De la part de Aitken, Paul
Envoyé : lundi 22 janvier 2024 22:50
À : 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://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".
[Med] OK.

    1.  Introduction

    As the OPSAWG is currently considering

This will soon become outdated. Consider, "When OPSAWG was considering ..."

[Med] OK

    not adequately specified any longer

"nolonger adequately specified"

[Med] OK

    This document intends to update the IANA registry
   and bringing some consistency among the entries of the registry.

Typo, "bring".

[Med] OK

    As discussed with IANA

Say when and/or where.

[Med] updated the text to indicate that this was during the publication process of RFC9487.


   *  Miscellaneous updates that fix broken pointers, orphan section
      references, etc.  (Section 7).

Typo, "orphaned".


    4.1.2.  Updates to the ipv6ExtensionHeaders Description

Consider making "OLD" into 4.1.2.1 and "NEW" into 4.1.2.2.

Likewise for all the other OLD / NEW sections - its easier to read now, and will be easier to xref in future.

[Med] Good suggestion. Fixed.


    Additional Information:

    See RFC Errata 1738.

Please restore the xref.
[Med] OK.

      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 make that clearer.

      This IE is used only when the observed extension headers are in
      the 0-31 range.

Consider deprecating this IE in favour of ipv6ExtensionHeadersFull.
[Med]  Seems reasonable, but would like to hear more from the WG.

    4.2.1.  Issues

   Only options having a kind =< 63 can be included in a tcpOptions IE.

Conventionally, "<= 63".
[Med] OK


    4.2.2.  Update the Description of the tcpOptions IE

        This information element is used only when the observed
         kinds are within the 0-63 range.  If not, the tcpOptionsFull IE

Consider deprecating this IE in favour of tcpOptionsFull.
[Med] Seems reasonable, but would like to hear more from the WG.

    4.3.  forwardingStatus

    In particular, the registered Abstract
   Data Type is unsigned8, while it must be unsigned32.

Why must it be?
[Med] As per the definition in RFC7270.

                   Future versions may be defined to associate
                   meanings with the remaining bits.

This is an old Cisco NetFlow compatible IE. It seems unlikely that there would be any future versions. If there were, a new IE should be defined.
Therefore it seems better to leave it as an unsigned8 and correct RFC 7270.

[Med] I prefer to maintain the current text in the draft. unsigned8 will be used anyway because of the reduced-encoding.

    See the Forwarding Status sub-registries at
    https://www.iana.org/assignments/ipfix/ipfix.xhtml#forwarding-status

An xref would be shorter and neater, eg "See the Forwarding Status sub-registries at [FORWARDING-STATUS]".
[Med] Agree but we are using the same format as it appears in the IANA registry.


    - Additional Information: See "NetFlow Version 9 Flow-Record Format"
    (CCO-NF9FMT).

"CCO-NF9FMT" makes no sense here. It's an xref in the IANA registry, so make it an xref in this document.

[Med] Done.


    6.  Consistent Citation of IANA Registries

   This document requests IANA to update [IANA-IPFIX] for each of the IE
   entries listed in the following subsections.

This does not explain the changes or why they are required. It's necessary for the reader to individually compare each "old" and "new" section.

[Med] We don't repeat that here because we do already have the following in the introduction:


   *  Updates that are meant to ensure a consistent structure when

      calling an existing IANA registry (Section 6).

Rather than writing an explanation for each change as was done in each 4.x.1 sub-section, a single note here could indicate that in each case the updates move the URLs into the Additional Information section.


    6.1.  mplsTopLabelType

This text has been omitted from "NEW" :

            See the list of MPLS label types assigned by IANA at
            [https://www.iana.org/assignments/mpls-label-values].

[Med] This one was removed on purpose as the assigned values are provided in the IANA IPFIX registry and there is no explicit mapping between the two registries.


    6.2.  classificationEngineId

      -  Additional Information:  See https://www.iana.org/assignments/i
            pfix/ipfix.xhtml#classification-engine-ids.

Is it possible to prevent the URL from breaking across the "ipfix" word?

[Med] Will see how to fix that.


    6.3.  flowEndReason

   *  OLD:

      -  Additional Information:

There is no existing "Additional Information" for this IE. I appreciate that the intention may have been to indicate that the section is blank. However it misleadingly appears as though some text is missing, so it would be better not to include it at all.

Likewise for many of the subsequent sections.

[Med] You got the intent, but I think you have a fair comment. Removed all empty "Additional Information".


    6.10.  natType

Please take the opportunity to add the missing description, eg "This element identifies the type of NAT applied to packets of the flow."

[Med] Thanks. Went for: « This Information Element identifies the NAT type applied to packets of the Flow.".


      Note: This change also corrects errors in the pointers provided
      NAT46/NAT64.

Need to ensure IANA doesn't add that to the registry.

[Med] Changed to "Note to IANA". Will take care of that when reviewing IANA actions.


    6.12.  informationElementDataType

      -  Description:  A description of the abstract data type of an
            IPFIX information element.These are taken from the abstract

Please correct the "element.These" typo.

[Med] Fixed


    6.19.  valueDistributionMethod

      -  Additional Information:  See the assigned distributed methods

This should be "-  Additional Information:  See the assigned value distribution methods"

[Med] Fixed


    7.  Misc

Again, it's difficult to see what changed in each section and tedious to compare the OLD/NEW to find out.
[Med] That's covered by this generic text in the intro:

   *  Miscellaneous updates that fix broken pointers, orphaned section
      references, etc.  (Section 7).


    8.  Security Considerations

Explicitly say that there are no changes.
[Med] OK.


    9.1.  IPFIX Subregistry for IPv6 Extension Headers

It's strange to list all the required changes neatly in sections 4 through 7, then plop this into the IANA section.
[Med] That's OK as this is about new IANA actions.


    a free bit is selected by IANA

More specifically, "the next available free bit is selected by IANA" (NB also in the "Note:").
[Med] OK


    2  NoNxt     59     No Next Header for IPv6

The indentation of "59" is wrong.
[Med] Fixed



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