Hi Paolo, Thank for the follow-up.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Paolo Lucente <pa...@ntt.net> > Envoyé : mercredi 5 février 2025 21:29 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; > draft-ietf-grow-bmp-...@ietf.org > Cc : grow@ietf.org > Objet : Re: Review of draft-ietf-grow-bmp-tlv-15 > > > Hi Med, > > Thanks for your extensive review. I believe i have addressed all > your editorial changes in a to-be-submitted version 16 of the > draft; you can find the new text and at the end of the email (*, > **, ***). > > You raised a couple major points which are worth addressing also > here. > > One was with version bumping and version negotiation. BMP is > essentially a uni-directional protocol where the exporter speaks > and the station listens; this means there is no negotiation > process (and for good). I updated section 3 then expanded the > same concepts in Operational Considerations saying that if a > station does not support the message version it should either > ignore the message(s) and log a warning or close the session (in > which case the exporter should not try too aggressively to > reconnect). Open to different ideas. [Med] These are good considerations. Still, the remote wouldn't have any hint why the connection is reset. FWIW, if not covered at the BMP level, the TSP RST Diag discussed in TCPM might be helpful: https://mailarchive.ietf.org/arch/msg/tcpm/ZTvLkMeXM-BnvvZ3z68EmniUWls/. But, no stable spec is available though. > > About your comment on to-be-RFC9736 and changing the name of the > registry in draft-ietf-grow-bmp-tlv, thing is that doing it there > would be kind of inconsistent: we'll have a registry saying Peer > Up and Peer Down Information TLVs .. with Peer Down not > supporting TLVs (yet). Do you see harm in proceeding > incrementally and keeping the naming consistent to what the > message types actual support (until this document is RFC'd Peer > Up would support TLVs, Peer Down would not)? [Med] ACK .. > > On 4/2/25 10:11, mohamed.boucad...@orange.com wrote: > > Hi Paolo, Yunan, > > > > FWIW, you may find a review of the document at: > > > > * pdf:... > > * doc:.. > > >... > > I won't echo all the comments here but, as the peer-up doc is > in AUTH48 > > and you are requesting a change to an action of to-be-RFC9736, > I > > strongly suggest you fix that in AUTH48 and remove it from the > TLV spec. > > > > 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
