Hi Med,
Thanks for the extensive review, i believe i have addressed all
editorial suggestion from you. You can review diff and latest & greatest
doc here (*, **).
You also raised a couple of relevant points, let me address them here below:
* Merge ebit doc with tlv: the main reason for which there are two
documents was to avoid one (ebit) to stall the other; at the beginning
there was some criticism towards the fact of engineering a mechanism to
pass non-standard elements (in a standardization body); having those
cleared out for some time, i'd not be opposed to merge the two docs;
* On the usefulness of the document & effectiveness of the e-bit
mechanism: the experimental bits may be limiting in scope, hence i see
the need for more flexibility and an expanded scope; also, the defined
e-bit mechanism is quite effective (and simple to implement) for what it
tries to accomplish. Guess a vendor wants to implement a non-standard
TLV for a customer preventing squatting or wants to ship a standard TLV
but, say, with non-standard code points (think the path marking draft
with non-standard path types).
Paolo
(*)
https://github.com/paololucente/draft-ietf-grow-bmp-tlv-ebit/commit/7bcf309a9e273c79d7af339383ee6aa40637c0fd
(**)
https://github.com/paololucente/draft-ietf-grow-bmp-tlv-ebit/blob/master/draft-ietf-grow-bmp-tlv-ebit.txt
On 4/2/25 10:25, mohamed.boucad...@orange.com wrote:
Hi Paolo, Yunan,
FWIW, you may find a review of the document at:
* pdf:
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-grow-bmp-tlv-ebit-06-rev%20Med.pdf
<https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-grow-bmp-tlv-ebit-06-rev%20Med.pdf>
* doc:
https://github.com/boucadair/IETF-Drafts-Reviews/raw/refs/heads/master/2025/draft-ietf-grow-bmp-tlv-15-rev%20Med.doc <https://github.com/boucadair/IETF-Drafts-Reviews/raw/refs/heads/master/2025/draft-ietf-grow-bmp-tlv-15-rev%20Med.doc>
This might be discussed in the past, but I do think that this spec can
be merged with the TLV document.
On the design of the object itself, it might be worth to look at other
approaches to achieve similar goals such as
https://datatracker.ietf.org/doc/html/rfc8415#section-21.17
<https://datatracker.ietf.org/doc/html/rfc8415#section-21.17>, which
consumes one type but leave the subtype as part of the vendor-specific
data. That design allows to multiplex multiple vendor options under the
same TLV+PEN.
Feel free to grab whatever useful in the review.
Cheers,
Med
____________________________________________________________________________________________________________
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.
_______________________________________________
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org
