Transparent Interconnection of Lots of Links (TRILL): Interface Addresses APPsub-TLV
Note: This ballot was opened for revision 08 and is now closed.
(Alia Atlas) Yes
(Jari Arkko) No Objection
Deborah Brungard No Objection
(Ben Campbell) No Objection
(Benoît Claise) No Objection
As flagged by Jürgen Schönwälder in his OPS DIR review: > The document ends with "Copyright, Disclaimer, and Additional IPR > Provisions" which is a but unusual given that the more common format > has a legal blurb at the beginning of the I-D. I have not checked the > content (well to be honest, I never bother to read the boilerplate > texts). I guess the RFC editor will flag this if this is an issue. Regards, Benoit
Alissa Cooper No Objection
(Spencer Dawkins) No Objection
(Stephen Farrell) No Objection
(Joel Jaeggli) No Objection
Juergen Schoenwaelder provided the opsdir review.
(Suresh Krishnan) No Objection
* Section A.2 The length for the sub-sub-TLV seems to be wrong. Shouldn't this be "Size: 0x10 = 16" instead of "Size: 0x0A = 10" as shown in the document?
(Mirja Kühlewind) No Objection
(Terry Manderson) No Objection
(Alexey Melnikov) No Objection
(Kathleen Moriarty) No Objection
In the Security Considerations, I realize that this isn't the place for a recommendation on what to use for transport, but a pointer for the recommendation feels likes it's missing in the following text: However, this document merely describes a data format and does not provide any explicit mechanisms for securing that information, other than a few simple consistency checks that might detect some corrupted data. Security on the wire, or in storage, for this data is to be providing by the transport or storage used. For example, when transported with ESADI [RFC7357] or RBridge Channel [RFC7178], ESADI security or Channel Tunnel [ChannelTunnel] security mechanisms can be used, respectively. Also, there is a nit in the second sentence: s/providing/provided/