Hi Mahesh, I'm neural on the next step once the document is approved. If sent now to the RFC Editor, the doc will be anyway in the MISSREF state waiting for draft-ietf-tsvwg-udp-options.
Cheers, Med De : Mahesh Jethanandani <mjethanand...@gmail.com> Envoyé : lundi 22 juillet 2024 20:17 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> Cc : Roman Danyliw <r...@cert.org>; Zaheduzzaman Sarker <zahed.sarker.i...@gmail.com>; draft-ietf-opsawg-tsvwg-udp-ip...@ietf.org; opsawg-cha...@ietf.org; opsawg@ietf.org; The IESG <i...@ietf.org> Objet : Re: [OPSAWG]Re: Roman Danyliw's Discuss on draft-ietf-opsawg-tsvwg-udp-ipfix-13: (with DISCUSS and COMMENT) Hi Med, Thanks for addressing both the DISCUSS and the COMMENTS. I will wait for the DISCUSS to be cleared. That still leaves this comment that several reviewers provided. Should we wait on the publication of draft-ietf-tsvwg-udp-options, as the other document defines the values that this draft is trying to encode. Would the authors have a problem with approving the document but holding this document till the other document is approved? Cheers. On Jul 22, 2024, at 1:33 AM, mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote: Hi Roman, Zahed The changes to address Roman's DISCUSS are not public: https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-tsvwg-udp-ipfix-14. The version also addresses the comment from Zahed. Cheers, Med -----Message d'origine----- De : BOUCADAIR Mohamed INNOV/NET Envoyé : mercredi 10 juillet 2024 08:13 À : 'Roman Danyliw' <r...@cert.org<mailto:r...@cert.org>>; 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> Objet : RE: Roman Danyliw's Discuss on draft-ietf-opsawg-tsvwg- udp-ipfix-13: (with DISCUSS and COMMENT) Hi Roman, Thank you for the review. The changes to address your review can be seen at: https://github.com/boucadair/udp-ipfix/pull/12/files Please see more inline. Cheers, Med -----Message d'origine----- De : Roman Danyliw via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> Envoyé : mardi 9 juillet 2024 19:46 À : 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> Objet : Roman Danyliw's Discuss on draft-ietf-opsawg-tsvwg-udp- ipfix-13: (with DISCUSS and COMMENT) Roman Danyliw has entered the following ballot position for draft-ietf-opsawg-tsvwg-udp-ipfix-13: Discuss 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.) --------------------------------------------------------------- DISCUSS: --------------------------------------------------------------- ** Section 7.1. This section is under-specified and contains typos relevant to registration. -- The "IPFIX Information Elements" registry doesn't have a "Value" field. It is "ElementID" [Med] Thank you for catching the typos. Made this change: OLD: |Value |Name | Reference | NEW: |ElementID|Name |Specification| -- The mandatory elements of the "IPFIX Information Elements" registry defined in the registration template of Section 2.1 of RFC7012 are missing - description, datatype, and status. [Med] These are more about the content of the registry, not the content of a registration request. A template is provided here: https://datatracker.ietf.org/doc/html/rfc7013#section-9.1, fwiw. Please note that status does not need to appear in the registration request for a new IE. All newly registered IEs will have "current" as status per 7012. I confirm that IANA had that well set for the candidate actions they shared with us for this spec. I appreciate that the first two in this list are found in their respective sections. However, there is no guidance to IANA to extract those values as such. [Med] IANA had no issue to digest the current instructions, but I agree that it is better to be explicit. I added these notes for completeness: NEW: Note to IANA: : The "Specification" column points to the section with the required information to register each IE. Note to the RFC Editor: : Please remove the IANA note once IANA actions are implemented. -- Per the Reference field value, is a section number permitted? No other current entry in this registry includes a section number. The definition of references from RFC7012 doesn't seem to account for it either -- "reference - Identifies additional specifications that more precisely define this item or provide additional context for its use." [Med] The sections won't appear in the registry; these are only meant to provide a pointer to IANA where to find the required information to implement the actions. The exact reference that will appear in the registry is provided in the specific sections. I guess this is fixed with the changes above. --------------------------------------------------------------- -- COMMENT: --------------------------------------------------------------- -- Thank you to Robert Sparks for the GENART review. ____________________________________________________________________________________________________________ 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<mailto:opsawg@ietf.org> To unsubscribe send an email to opsawg-le...@ietf.org<mailto:opsawg-le...@ietf.org> Mahesh Jethanandani mjethanand...@gmail.com<mailto:mjethanand...@gmail.com> ____________________________________________________________________________________________________________ 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
