Re-, Thanks for the follow-up.
Great! I'm not comfortable with adding pointers to sections in the description because that content will make it to the registry. That is one of the issues we are trying to solve with the simple-fix I-D. We can add "A basicList of udpExID is used to report udpSafeExIDList and udpUnsafeExIDList values.", though. Cheers, Med De : Eric Vyncke (evyncke) <evyn...@cisco.com> Envoyé : mardi 2 juillet 2024 13:50 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; The IESG <i...@ietf.org> Cc : draft-ietf-opsawg-tsvwg-udp-ip...@ietf.org; opsawg-cha...@ietf.org; opsawg@ietf.org; thomas.g...@swisscom.com; to...@strayalpha.com Objet : Re: Éric Vyncke's No Objection on draft-ietf-opsawg-tsvwg-udp-ipfix-12: (with COMMENT) Thank you, Med, as usual for your quick reply. The changes in your github seem to improve the I-D. About my comment on section 4.3, after re-reading section 4.5 I now understand it. May I suggest some leading text in section 4.3 such as "This atomic IE MAY only be used in the udpSafeExIDList and udpUnsafeExIDList IEs specified in sections 4.4 and 4.5" ? NB: expect a very similar comment in my ballot for draft-ietf-opsawg-ipfix-tcpo-v6eh-16 ;-) Regards -éric From: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> Date: Tuesday, 2 July 2024 at 13:17 To: Eric Vyncke (evyncke) <evyn...@cisco.com<mailto:evyn...@cisco.com>>, The IESG <i...@ietf.org<mailto:i...@ietf.org>> Cc: draft-ietf-opsawg-tsvwg-udp-ip...@ietf.org<mailto:draft-ietf-opsawg-tsvwg-udp-ip...@ietf.org> <draft-ietf-opsawg-tsvwg-udp-ip...@ietf.org<mailto:draft-ietf-opsawg-tsvwg-udp-ip...@ietf.org>>, opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org> <opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>>, opsawg@ietf.org<mailto:opsawg@ietf.org> <opsawg@ietf.org<mailto:opsawg@ietf.org>>, thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com> <thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>>, to...@strayalpha.com<mailto:to...@strayalpha.com> <to...@strayalpha.com<mailto:to...@strayalpha.com>> Subject: RE: Éric Vyncke's No Objection on draft-ietf-opsawg-tsvwg-udp-ipfix-12: (with COMMENT) Hi Éric, Thank you for the review. All good points. You can track the changes made to address your review at: https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/udp-ipfix/draft-ietf-opsawg-tsvwg-udp-ipfix.txt&url_2=https://boucadair.github.io/udp-ipfix/eric-vyncke-iesg-review/draft-ietf-opsawg-tsvwg-udp-ipfix.txt. Please see inline for more context. Cheers, Med > -----Message d'origine----- > De : Éric Vyncke via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> > Envoyé : mardi 2 juillet 2024 11:27 > À : The IESG <i...@ietf.org<mailto:i...@ietf.org>> > Cc : > draft-ietf-opsawg-tsvwg-udp-ip...@ietf.org<mailto:draft-ietf-opsawg-tsvwg-udp-ip...@ietf.org>; > opsawg- > cha...@ietf.org<mailto:cha...@ietf.org>; > opsawg@ietf.org<mailto:opsawg@ietf.org>; > thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>; > thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com>; > to...@strayalpha.com<mailto:to...@strayalpha.com> > Objet : Éric Vyncke's No Objection on draft-ietf-opsawg-tsvwg- > udp-ipfix-12: (with COMMENT) > > > Éric Vyncke has entered the following ballot position for > draft-ietf-opsawg-tsvwg-udp-ipfix-12: No Objection > > When responding, please keep the subject line intact and reply to > all email addresses included in the To and CC lines. (Feel free > to cut this introductory paragraph, however.) > > > > ----------------------------------------------------------------- > COMMENT: > ----------------------------------------------------------------- > > > # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-tsvwg-udp- > ipfix-12 > > Thank you for the work put into this document. > > Thanks to Joe Touch for his int-dir reviews but also kudos to the > authors for > reacting to Joe's issue about the SAFE/UNSAFE split and the > normative reference > to draft-ietf-opsawg-ipfix-tcpo-v6eh. The I-D is now in much > better shape. > > Please find below some non-blocking COMMENT points (but replies > would be > appreciated even if only for my own education). > > Special thanks to Thomas Graf for the shepherd's detailed write- > up including > the WG consensus and the justification of the intended status. > > I hope that this review helps to improve the document, > > Regards, > > -éric > > # COMMENTS (non-blocking) > > ## Link to draft-ietf-tsvwg-udp-options > > There is a normative reference to draft-ietf-tsvwg-udp-options, > so all is good, > but it might have been better to wait for draft-ietf-tsvwg-udp- > options rather > than having to review this I-D without knowing what will be the > published > specification of UDP options. > [Med] That draft passed the WGLC in tsvwg don't expect changes to the kind structure nor the core SAFE/UNSAFE option split. > ## Section 1 > > s/widely deployed in *operators* networks/widely deployed in > networks/ IPFIX is > largely deployed outside of operators (in the sense if (I)SP) ;-) > [Med] Fair enough. > s/The IE specified in Section 4.1 uses the new abstract data type > defined/The > IE specified in Section 4.1 uses the new abstract data type > *unsigned256* > defined/ ? > [Med] OK, fixed. > ## Section 3 > > While is it nice for the reader to have a short description of > UDP options, it > does not say anything about "Kind" as in `Options indicated by > Kind values`... > So, the reader must anyway read the UDP options draft. Suggest > adding a short > description of the Kind. [Med] Added the following right before the text you quoted: NEW: UDP options are unambiguously identified by means of a 1-byte field, called "Kind". > > ## SAFE or safe > > This document uses both "safe" and "SAFE" for what seems the same > concept. > Please select one writing everywhere to reduce confusion. > [Med] ACK > ## Use of MUST w/o BCP14 > > There are a couple of "MUST" and "MUST NOT" in the text without > any BCP14 > template. This is OK, but the "MUST" is then equivalent to a > "must", so suggest > either using only lower case "must" or including BCP14 template. > The lowercase > "must" is anyway normative as it is part of a Proposed Standard > but somehow > less defined as the BCP14 "MUST". [Med] Good catch. Fixed. > > ## Section 4.1 > > s/The bit is set to 1 if the corresponding safe UDP option is > observed in the > Flow/The bit is set to 1 if the corresponding safe UDP option is > observed *at > least once* in the Flow/ > [Med] This is better. > s/The bit is set to 0 if the option is *not* observed in the > Flow./The bit is > set to 0 if the option is *never* observed in the Flow./ [Med] OK to make the change as well. > > Same comment for the unsafe options in section 4.2 [Med] ACK. > > What about "UDP option extended format" ? I.e., where the Kind is > expressed > over 2 octets. [Med] I guess you meant length. Suggest adding some text restricting the use of > this I-D to only > "normal 1-octet Kind". [Med] Kind is always 1-byte. I think this is clarified with the NEW text to address your comment about Section 3. > > ## Section 4.3 > > I am afraid that I do not understand what value to use based ont > the > Description. Are the only allowed values: 127 and 254 ? > > [Med] The IE does not export the kind values, but the ExID enclosed in an exp option (i.e., an option with kind values 127/254). CURRENT: Description: Observed ExID in an Experimental option (EXP, Kind=127) or an UNSAFE Experimental option (UEXP, Kind=254). Section 3 says the following: [I-D.ietf-tsvwg-udp-options] reserves two options for experiments: the Experimental option (EXP, Kind=127) for SAFE options and the UNSAFE Experimental option (UEXP, Kind=254). For both options, Experiment Identifiers (ExIDs) are used to differentiate concurrent use of these options. Known ExIDs are expected to be registered within IANA. Section 4.4 specifies a new IPFIX IE to export observed ExIDs in the EXP options. Also, Section 4.5 specifies a new IPFIX IE to export observed ExIDs in the UEXP options. Only 16-bit ExIDs are supported in [I-D.ietf-tsvwg-udp-options]. Please let us know if you still think some tweaking is needed. Thanks ____________________________________________________________________________________________________________ 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. ____________________________________________________________________________________________________________ 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.
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
