Re: [IPFIX] Review of draft-boucla-opsawg-ipfix-fixes

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

Thanks Med, this looks great. Thanks for updating so quickly. Some further feedback:


Parenthesise "Section 6" for consistency with the previous paragraphs:

1.  Introduction

         *  Miscellaneous updates that fix broken pointers, orphan section
                      references, etc.  Section 6.


This does not make sense:

4. Point to An Existing IANA Registry

  IANA is requested to update the following entries by adding the
  indicated "Additional Information" of [IANA-IPFIX]:

Possibly:

  IANA is requested to update the following entries by adding the
  indicated "Additional Information" to the [IANA-IPFIX] registry:


Section 4 says, "IANA is requested to update the following entries". Section 5 says, "IANA is requested to update [IANA-IPFIX]". Sections 3 and 6 should say something similar so they're clearly requests for IANA to update the entries.


6.3 anonymizationFlags

This is the table that needs fixed, right?


6.6. externalAddressRealm

    The detailed definition is similar to the one provided for the internalAddressRealm IE.

"similar" allows for some ambiguity. Perhaps, "See the internalAddressRealm IE for the detailed definition".


Also, at one time Benoit was strict about not using "IE", but always using "Information Element" - possibly because "IE" is not defined in the IPFIX terminology.


8. IANA Considerations

                   This document also requests IANA to update the reference clause of
                   the "IPFIX Information Elements" subregistry with teh reference to
                   this document.

Typo, "teh".


P.


On 23/01/2023 12:35, [e-mail]<mailto:[e-mail]> wrote:
Re-,  Paul,

Many thanks for the comments. All good points.

An updated version to address almost all these points is online:


URL:            https://www.ietf.org/archive/id/draft-boucla-opsawg-ipfix-fixes-03.txt

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

Html:           https://www.ietf.org/archive/id/draft-boucla-opsawg-ipfix-fixes-03.html

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

Diff:           https://author-tools.ietf.org/iddiff?url2=draft-boucla-opsawg-ipfix-fixes-03

(There is a formatting issue with a table; this will be fixed in the next iteration)

For the comment about references, I prefer to leave those to make idnits happy.

Cheers,
Med

De : Aitken, Paul <[e-mail]><mailto:[e-mail]>
Envoyé : vendredi 20 janvier 2023 23:17
À : opsawg <[e-mail]><mailto:[e-mail]>; BOUCADAIR Mohamed INNOV/NET <[e-mail]><mailto:[e-mail]>; Benoit Claise <[e-mail]><mailto:[e-mail]>
Cc : [e-mail]<mailto:[e-mail]>
Objet : Review of draft-boucla-opsawg-ipfix-fixes

This cleanup seems good and useful. Thanks for the draft. Please find some feedback below, with quoted text in black and my comments in blue.


1. Introduction

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

Consistency with ... ?


3. Update the Description

This section should propose/request updates just as section 4 does.


3.1. tcpOptions

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

The tcpOptions IE supports options 0 through 63.


4. Point to An Existing IANA Registry

I found this line difficult to parse:

    IANA is requested to update the following entries by adding the indicated pointer to an IANA registry under "Additional Information" of [IANA-IPFIX]:

I suggest:

    IANA is requested to update the following entries by adding the indicated "Additional Information".


5. Consistent Citation of Registries

Many of these changes move the relevant registry from the Description to the Additional Information, so it's presented as "See <url>" without any explanation. The general form of the Addition Information column is "See [url] for the definition...", so these updates should follow the same format. ie, say why to see that URL.

Some of the existing Additional Information entries simply cite an RFC without explanation. These should also be improved.


5.1 mplsTopLabelType / NEW

Additional Information: See [RFC3031<https://boucadair.github.io/simple-ipfix-fixes/draft-boucla-opsawg-ipfix-fixes.html#RFC3031>] for the MPLS label structure. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mpls-label-type.

Please put the IANA registry first and explain why to see it, eg:

Additional Information: See the MPLS label type registry at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mpls-label-type]. See [RFC3031<https://boucadair.github.io/simple-ipfix-fixes/draft-boucla-opsawg-ipfix-fixes.html#RFC3031>] for the MPLS label structure.


5.3. classificationEngineId / NEW

Additional Information: See the Classification Engine IDs registry [https://www.iana.org/assignments/ipfix/ipfix.xhtml#classification-engine-ids].


5.22. dataLinkFrameType

Additional Information: See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-data-link-frame-type. [IEEE802.3][IEEE802.11][ISO/IEC.7498-1:1994]

Please add some explanatory text to the IEEE + ISO/IEC links, eg:

Additional Information: See the dataLinkFrameType registry at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-data-link-frame-type]. See [IEEE802.3] for the definition of something, and [IEEE802.11] for the definition of something else. See [ISO/IEC.7498-1:1994] for further specifications."

Should "The data link layer is defined in [ISO/IEC.7498-1:1994]." also be moved into the Additional Information?


Similar comments apply for sections 5.4 through 5.25.


5.15. informationElementUnits / NEW

This field may take the values in Table 3 below

There is no Table 3.

The registry would benefit from cleanup of "below" as used in collectionTimeMilliseconds, messageMD5Checksum, selectorAlgorithm, informationElementUnits, distinctCountOfDestinationIPAddress, and "above" as used in externalAddressRealm, since these have no meaning when the element's definition is read stand-alone.

Also cleanup of "section N" without any reference which seem to refer to sections of the defining RFC and have no context in the registry:

    anonymizationFlags:

        "Stability Class: see the Stability Class table below, and section Section 5.1."

        "see Section 7.2.2 for details."

    Classification Engine IDs (Value 101) value 6:

        "based on the methods described in section 2."

    flowSelectorAlgorithm

        "as defined in the Scope (Section 1)."



8.2. Informative References

It doesn't seem necessary or useful to list each RFC which was quoted from the registry. Only cite those which pertain to the draft itself.


Thanks,
P.

On 19/01/2023 16:53, Joe Clarke (jclarke) wrote:
Forwarding to ipfix@ for more eyes on this.  Please reply to opsawg@ with any comments or questions.

Joe

From: OPSAWG <[e-mail]><mailto:[e-mail]> on behalf of Joe Clarke (jclarke) <jclarke=[e-mail]><mailto:jclarke=[e-mail]>
Date: Tuesday, January 17, 2023 at 11:24
To: [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>
Subject: [OPSAWG] CALL FOR ADOPTION: An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element
Happy new year, all.  One of the AIs that slipped through the cracks coming out of 115 was a call for adoption for draft-boucadair-opsawg-rfc7125-update.   One of the asks of Med at 115 was to look at what else might need to be done from an IE registry standpoint.  He replied on-list to that a while ago:

“Yes, I had a discussion with Benoît during the IETF meeting to see how to handle this. We agreed to proceed with at least two documents:

1.       draft-boucadair-opsawg-rfc7125-update to update the TCP IPFIX RFC.

2.       Edit a second draft to “clean” other entries in registry. This document is intended to include only simple fixes and which do not require updating existing RFCs. The candidate list of these proposed fixes can be seen at https://boucadair.github.io/simple-ipfix-fixes/draft-boucla-opsawg-ipfix-fixes.html [boucadair.github.io]<https://urldefense.com/v3/__https:/boucadair.github.io/simple-ipfix-fixes/draft-boucla-opsawg-ipfix-fixes.html__;!!OSsGDw!LkWh3arGpjhY0BhtBQQEOpjN2jc6-afzgtS4ayYuPzwMArRuEkQ2oQm0fbyN9Ahsfr7VDwsr4wHSm8sseJONI6J3rDFp$>. New IEs, if needed, will be moved to a separate document. simple-ipfix-fixes may or may not be published as an RFC.”

So, let this serve as a two-week call for adoption for the existing draft-boucadair-opsawg-rfc7125-update document.  Please reply on-list with your comments, support, or dissent by January 31, 2023.

Thanks.

Joe



_______________________________________________

IPFIX mailing list

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

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipfix__;!!OSsGDw!LkWh3arGpjhY0BhtBQQEOpjN2jc6-afzgtS4ayYuPzwMArRuEkQ2oQm0fbyN9Ahsfr7VDwsr4wHSm8sseJONI1lLXvEo$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipfix__;!!OSsGDw!LkWh3arGpjhY0BhtBQQEOpjN2jc6-afzgtS4ayYuPzwMArRuEkQ2oQm0fbyN9Ahsfr7VDwsr4wHSm8sseJONI1lLXvEo$> [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.




_______________________________________________
IPFIX mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ipfix