Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol
draft-ietf-trill-esadi-09

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

(Ted Lemon; former steering group member) Yes

Yes ( for -07)
No email
send info

(Adrian Farrel; former steering group member) (was Discuss) No Objection

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

(Alia Atlas; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Alissa Cooper; former steering group member) No Objection

No Objection (2014-05-14 for -07)
No email
send info
In Section 4.4:
s/EASDI-LSP/ESADI-LSP/

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."
s/Ediotr's/Editor's/

(Barry Leiba; former steering group member) No Objection

No Objection ( for -07)
No email
send info

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

No Objection ( for -07)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection (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.

(Joel Jaeggli; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Kathleen Moriarty; former steering group member) No Objection

No Objection (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.

(Martin Stiemerling; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Pete Resnick; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Richard Barnes; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -07)
No email
send info

(Stephen Farrell; former steering group member) (was Discuss) No Objection

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

(Brian Haberman; former steering group member) Abstain

Abstain (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.