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.
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)?
Paolo
(*)
https://github.com/paololucente/draft-ietf-grow-bmp-tlv/blob/master/draft-ietf-grow-bmp-tlv.txt
(**)
https://github.com/paololucente/draft-ietf-grow-bmp-tlv/commit/6638bc52d4cdafb0e26fe83af7927ac662a3c1d4
(***)
https://github.com/paololucente/draft-ietf-grow-bmp-tlv/commit/6bbf196b7a1beef02ce6fe99d6788830c2a5d479
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:
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-grow-bmp-tlv-15-rev%20Med.pdf
<https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-grow-bmp-tlv-15-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>
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
