Transparent Interconnection of Lots of Links (TRILL): Vendor-Specific RBridge Channel Protocol
RFC 8381
Yes
No Objection
No Record
Note: This ballot was opened for revision 00 and is now closed.
Alvaro Retana No Objection
(Alia Atlas; former steering group member) Yes
(Adam Roach; former steering group member) No Objection
(Alexey Melnikov; former steering group member) No Objection
(Alissa Cooper; former steering group member) (was Discuss) No Objection
Thanks for answering my DISCUSS question. I agree with the Gen-ART reviewer that the text in the Acknowledgements section is not appropriate. See RFC 7322.
(Deborah Brungard; former steering group member) No Objection
(Eric Rescorla; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
Could you please expand the text in the security considerations section as to why security properties (integrity, authentication, and encryption since they are not part of RBridge Channel messages except when explicitly added on in the extension draft) were not built in? I'm assuming it is the limited scope of use for the protocol. I am glad that options exist to add it in, but wish the text were a bit more encouraging so that would actually happen. Vendors need to be motivated to provide these options for customers who may want to use them, without that motivation, the features won't be provided.
(Mirja Kühlewind; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
(Suresh Krishnan; former steering group member) No Objection
(Terry Manderson; former steering group member) No Objection
(Ben Campbell; former steering group member) No Record
Apologies, I ran out of time for this one.