Hi Stephen, Thanks for your comments. See below and version -12 just posted.
On Thu, Jan 19, 2017 at 7:19 AM, Stephen Farrell <[email protected]> wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-trill-directory-assist-mechanisms-11: No Objection > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - 2.6: I wondered why this was useful. Is it for cases where > the secondary push service is differently connected or is it > in case the primary goes down? Might be good to say. The reasons for multiple directory servers are resilience, increase the bandwidth of directory services, and to make them more locally available reducing network load. It seems likely that in many cases the directory information would come from a data center orchestration service which would have a co-located push directory that would be used to populate other directories. It seems like you could equally well ask why the DNS has primary and secondary servers and does zone transfers to populate the secondary from a primary. People generally find this sort of thing useful in multiple-server directory applications. > - section 6: what security mechanism differences are there > between the push and pull cases? Why aren't those called out > here? Forcing the reader to delve into the various other > security mechanism RFCs and figure this out themselves seems > less good. I don't see it that way. I believe that people will choose what combination of Push, Pull, both, or no directory they are going to use and the like based on their operational and efficiency needs. Then they are going to evaluate, in the context of their network/use, how important it is to add cryptographic security. So a pointer to the security available for each type (Push or Pull) of message answers most implementer needs. That being said, it seems reasonable to add that IS-IS security, available for Push messages, provides only authentication, while RBridge Channel security, available for Pull messages, can also provide confidentiality. > - section 6: apologies if I asked this before (in which case I > forget the answer;-) but how fictional/real is the crypto > stuff with TRILL in terms of the likelihood of it being > actually used? I ask again, as if the crypto stuff is mostly > fictional, then I think you ought note that here, given the > attack surface that the directory function creates. I'm not entirely sure what you mean by the "crypto stuff with TRILL". TRILL is built on IS-IS and IS-IS security is quite widely implemented and deployed. The Push directory message security uses this IS-IS security and I would expect it to be available in almost all implementations. On the other hand, TRILL security for RBridge Channel messages, which can be used to secure Pull directory messages, was only fairly recently standardized in RFC 7978 so it is less widely implemented or deployed. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA [email protected] _______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
