Re: [IPFIX] WG LC: IPFIX documents

["Aitken, Paul" <[e-mail]>]

https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-fixes


    Abstract

    The updates are also meant to bringing some
    consistency among the entries of the registry.

Typo, "meant to bring in".


    1.  Introduction

    As the OPSAWG is currently considering

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


    not adequately specified any longer

"nolonger adequately specified"


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

Typo, "bring".


    As discussed with IANA

Say when and/or where.


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


    Additional Information:

    See RFC Errata 1738.

Please restore the xref.


      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.


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

Consider deprecating this IE in favour of ipv6ExtensionHeadersFull.


    4.2.1.  Issues

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

Conventionally, "<= 63".


    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.


    4.3.  forwardingStatus

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

Why must it be?


                   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.


    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]".


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


    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.

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


    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?


    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.


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


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

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


    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.


    6.19.  valueDistributionMethod

      -  Additional Information:  See the assigned distributed methods

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


    7.  Misc

Again, it's difficult to see what changed in each section and tedious to compare the OLD/NEW to find out.


    8.  Security Considerations

Explicitly say that there are no changes.


    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.


    a free bit is selected by IANA

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


    2  NoNxt     59     No Next Header for IPv6

The indentation of "59" is wrong.


P.