Re-,
Please see inline.
Cheers,
Med
> -----Message d'origine-----
> De : Zaheduzzaman Sarker via Datatracker <nore...@ietf.org>
> Envoyé : jeudi 11 juillet 2024 12:11
> À : 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;
> thomas.g...@swisscom.com
> Objet : Zaheduzzaman Sarker's Discuss on draft-ietf-opsawg-tsvwg-
> udp-ipfix-13: (with DISCUSS and COMMENT)
>
>
> Zaheduzzaman Sarker 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:
> -----------------------------------------------------------------
>
> Thanks for working on this specification. Thanks to Tommy Pauly
> for the TSVART
> review.
>
> I would like to discuss something that might not be completely
> technical but we
> should understand that aspect better. The sub-sections of section
> 4 defines
> udpXOptions and "reference" itself.
[Med] Yes, because this is the reference of the document that specifies/request
the registration.
My understanding is that it
> should
> reference to the draft where UDP options are defined.
[Med] That's referenced in the Additional information.
I won't provide the long story here that motivated the note but the short one
is the note in the registry:
"The columns previously titled "References" and "Requester" have been
renamed "Additional Information" and "Reference", respectively."
My
> understading can be
> wrong, but this is what is done for tcpOptions in RFC5102. So, I
> would like to
> discuss if we are referencing to the correct document or not.
[Med] I confirm the current registration is correct.
>
> Another discussion - as this specification is based on
> draft-ietf-tsvwg-udp-options, that draft already defines number
> of Kind values
> for SAFE and UNSAFE options then why we are not defining IEs for
> them?
>
[Med] Not sure to get your point. We do have IEs that can exports kinds for
both SAFE and UNSAFE. We used to have these in one single IEn but abandoned
that design because it was suboptimal for an encoding compactness perspective.
____________________________________________________________________________________________________________
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
