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.
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
