Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol
RFC 7357

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

(Ted Lemon) Yes

(Jari Arkko) No Objection

Comment (2014-05-15 for -07)
No email
send info
I believe Russ' comment below is something that should be handled:

> Section 8, the security considerations, say:
> ESADI PDUs can be authenticated through the inclusion of the
> Authentication TLV as described in Section 6.3.
> However, there seems to me something missing.  Section 6.3 tells how to derive a 256-bit authentication
> key.  It does not say how that key will be used to actually compute a message authentication code.  I would
> expect a reference to this information to be included in Section 6.3.

(Alia Atlas) No Objection

(Richard Barnes) No Objection

(Benoît Claise) No Objection

(Alissa Cooper) No Objection

Comment (2014-05-14 for -07)
No email
send info
In Section 4.4:

In Normative References section:
"[RFCfgl] - Eastlake, D., M. Zhang, P. Agarwal, R. Perlman, D. Dutt,
         "TRILL (Transparent Interconnection of Lots of Links): Fine-
         Grained Labeling", draft-ietf-trill-fine-labeling, in RFC
         Ediotr's queue."

(Spencer Dawkins) No Objection

(Adrian Farrel) (was Discuss) No Objection

Comment (2014-06-08)
No email
send info
Thanks for the work to address my Discuss

(Stephen Farrell) (was Discuss) No Objection

Comment (2014-06-13)
No email
send info
Thanks for adding the privacy considerations text.

(Joel Jaeggli) No Objection

(Barry Leiba) No Objection

(Kathleen Moriarty) No Objection

Comment (2014-05-15 for -07)
No email
send info
I support Stephen's discuss on privacy concerns and the need to elaborate on them.

For the privacy concerns, having some experience on campus networks, it can be really helpful to pin point where an end node is when it is acting up (during a security incident).  So there are clear advantages of having this tie to authenticated connections for the ESADI method as well as the ability to blackhole infected hosts.  For privacy considerations, ESADI also tracks when end nodes move around, which should be mentioned as a consideration (good for security for blackholing and tied to NAC for network hygiene).  

If this information (location of end node) is logged, (basically - as I read it) the full network map could be logged and created, as well as maintained over time as it changes.  On a campus network, privacy issues may arise when some sort of investigation is looking to identify where someone was at a particular point in time (or who did something).  This has pros and cons.  With other services (web logs in particular), some university admins have had the practice of removing logs after 30 days (by policy) to protect privacy and to avoid dealing with warrants - essentially if they don't have the data, they can't help.  An example of that is web logs and dealing with the illegal download of media.  Now we should not get into that full explanation of this example to explain the privacy issues, but a description of the risks to privacy when location over time could be pin pointed would be helpful for implementers to understand if they decide log and aggregate this information.  They will want to consider appropriate storage periods.  If it is stored at all, they could get subjected to record retention requirements as well (but I have not looked to see if any apply, I'm just highlighting that there could be requirements once they have and log this data).

I also support Russ' request from the Gen-art review and agree with the proposed solution.

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection

(Brian Haberman) Abstain

Comment (2014-05-15 for -07)
No email
send info
I support Adrian's and Stephen's DISCUSS points.  It is incredibly disconcerting that there is no interoperability discussions in this document despite the claims in section 1.1.