Skip to main content

Transparent Interconnection of Lots of Links (TRILL): Interface Addresses APPsub-TLV
RFC 7961

Yes

(Alia Atlas)

No Objection

Alvaro Retana
(Alexey Melnikov)
(Alissa Cooper)
(Ben Campbell)
(Deborah Brungard)
(Jari Arkko)
(Mirja Kühlewind)
(Spencer Dawkins)
(Stephen Farrell)
(Terry Manderson)

Note: This ballot was opened for revision 08 and is now closed.

Alvaro Retana No Objection

(Alia Atlas; former steering group member) Yes

Yes (for -08)

                            

(Alexey Melnikov; former steering group member) No Objection

No Objection ()

                            

(Alissa Cooper; former steering group member) No Objection

No Objection ()

                            

(Ben Campbell; former steering group member) No Objection

No Objection ()

                            

(Benoît Claise; former steering group member) No Objection

No Objection (2016-07-07)
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

(Deborah Brungard; former steering group member) No Objection

No Objection (for -08)

                            

(Jari Arkko; former steering group member) No Objection

No Objection ()

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (2016-07-07)
Juergen Schoenwaelder   provided the opsdir review.

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2016-07-06)
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/

(Mirja Kühlewind; former steering group member) No Objection

No Objection (for -08)

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection ()

                            

(Stephen Farrell; former steering group member) No Objection

No Objection ()

                            

(Suresh Krishnan; former steering group member) No Objection

No Objection (2016-07-05)
* 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?

(Terry Manderson; former steering group member) No Objection

No Objection ()