Hi Paolo, Thanks for the follow-up.
I trust that you are tracking all other comments in the review. Please see inline. Cheers, Med > -----Message d'origine----- > De : Paolo Lucente <pa...@ntt.net> > Envoyé : vendredi 7 février 2025 20:16 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; > draft-ietf-grow-bmp-tlv-e...@ietf.org > Cc : grow@ietf.org > Objet : Re: Review of draft-ietf-grow-bmp-tlv-ebit-06 > > > 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; [Med] Great, looking forward to see the merged version. > > * 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). > [Med] Some text is needed to better explain the rationale. For the design itself, assigning a bit (and actually a full range) is not the only option. Please refer to the design adopted by other protocols and see how they manage to address this with one single VENDOR_CLASS codepoint. The other side effect of your current design is that you artificially created a dependency on the E-bit spec for all the other TLV documents! This wouldn't be the case with a VENDOR_CLASS type/TLV is used. > 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 > > * 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
