Re: [OPSAWG] draft-ietf-opsawg-tsvwg-udp-ipfix-03 shepherd review

[[e-mail]]

Dear Med,

Thanks a lot for addressing all my points.

I updated and submitted my shepherd review: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tsvwg-udp-ipfix/shepherdwriteup/

I agree with your assessment on Joe's comment that having a figure on udp options packet header and short description on SAFE and UNSAFE options helps the reader to understand the context. It is clear that they are not defined within this document.


I will track the discussion on unsigned256 vs bitfield and update the shepherd review accordingly.



Best wishes

Thomas

From: [e-mail] <[e-mail]>
Sent: Monday, January 15, 2024 11:32 AM
To: Graf Thomas, INI-NET-VNC-HCS <[e-mail]>; [e-mail]; [e-mail]
Subject: RE: draft-ietf-opsawg-tsvwg-udp-ipfix-03 shepherd review


Be aware: This is an external email.


Hi Thomas, all,

Let's me first wish you a Happy New Year !

Thank you for the careful shepherd review. A new version that addresses the review is now online: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tsvwg-udp-ipfix/05/. Please note that I didn't change to unsigned64 because in theory we need to cover up to 256 bits to map the full options range.

Cheers,
Med

De : [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Envoyé : samedi 13 janvier 2024 12:17
À : [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Objet : draft-ietf-opsawg-tsvwg-udp-ipfix-03 shepherd review

Dear Joe, Tianran and Henk,

Thanks a lot for entrusting me. I have done the first shepherd review of the 3 IPFIX drafts. Since this is my first Shepherd review, please have a brief look before submitting to the data tracker.

One clarification question. There is a OPS area review pending, the review from the Internet and Transport area needs to be addressed by the authors, I suggest to have a review from the IPFIX experts as well as described in point 6 and I have some minor editorial remarks (see below). Once all done I believe we are ready to move forward to the IESG with this document. Should I wait with the Shepherd submission or submit it now and update it later as we progress?


Dear Med and Tirumaleswar,

Thanks a lot. The document is very well written and straight forward.

I have reviewed the document. I agree with the feedback from the Transport area that the data type of udpOptions should be unsigned64 instead of unsigned since https://www.rfc-editor.org/rfc/rfc7011#section-6.2 describes that unsigned64 can be reduced-size encoded in unsigned32. I suggest to change the wording in https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-tsvwg-udp-ipfix-03#section-4.1 from "The encoding specified in" to "The reduced-size encoding specified in" to make the meaning of the reference more clear.

Regarding the abstract data type and the data type semantics of udpExpOptionExID and udpUnsafeExpOptionExID. I am unsure wherever octetArray with identifier fits or not. I tend to agree with your assessment.

I reviewed

https://datatracker.ietf.org/doc/html/rfc7012#section-3.1.13
https://datatracker.ietf.org/doc/html/rfc7012#section-3.2.4
https://datatracker.ietf.org/doc/html/rfc7012#section-3.2.5

and also checked

https://www.iana.org/assignments/ipfix/ipfix.xhtml

where I only found

IE464    internalAddressRealm
IE465    externalAddressRealm

I understand that flags won't fit according to https://datatracker.ietf.org/doc/html/rfc7012#section-3.2.5 due to "represents a set of bit fields" versus a single value we have here.

Below are some nits I found.

replace "experiements" with "experiments"
replace "Expermients" with "Experiments"
replace "less-signficant" with "less-significant"

Adjust the following references to draft-ietf-tsvwg-udp-options-28

From
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-23#section-10

To
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-28#section-12


From
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-23#section-23

To
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-28#section-25


From
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-23#section-8

To
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-28#section-10


And below the output from idnits.

Otherwise all perfect. I agree due to the draft-ietf-tsvwg-udp-options dependency the content of this document should not be part of draft-ietf-opsawg-ipfix-tcpo-v6eh. I will review draft-ietf-opsawg-ipfix-tcpo-v6eh next. I like that this document, draft-ietf-opsawg-ipfix-tcpo-v6eh and draft-ietf-tsvwg-udp-options is being submitted about the same time to IESG. From a network operator perspective, I can't ask more to have a new transport protocol RFC ready at the same time when the IPFIX entities are being defined. Well done.

Best wishes
Thomas


idnits 2.17.1

draft-ietf-opsawg-tsvwg-udp-ipfix-03.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info)
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == There are 6 instances of lines with non-ascii characters in the document.


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

  == The document doesn't use any RFC 2119 keywords, yet seems to have RFC
     2119 boilerplate text.

  -- The document date (17 October 2023) is 88 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Outdated reference: A later version (-28) exists of
     draft-ietf-tsvwg-udp-options-23

  == Outdated reference: A later version (-11) exists of
     draft-ietf-tsvwg-udp-options-dplpmtud-10


     Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

____________________________________________________________________________________________________________

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.