Directory Assistance Problem and High-Level Design Proposal
RFC 7067

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

(Ted Lemon) Yes

(Jari Arkko) No Objection

(Richard Barnes) No Objection

(Stewart Bryant) No Objection

Comment (2013-08-28)
No email
send info
I agree with Joel's concern on whether this should be called a framework.

(Spencer Dawkins) (was Discuss) No Objection

Comment (2013-08-13)
No email
send info
Donald proposed the following text to clear my Discuss, and it works for me:

> I suspect it would be good to add two sentences to the paragraph at
> the beginning of Section 5. Something like:
>      "It is optional whether or not an RBridge uses Push Directory
> services, Pull Directory services, or some combination. It is optional
> whether a Directory offers Push services, Pull services, or both."

Thank you for the quick response!

Donald also responded to my comment about collecting the text that compares and contrasts the Push and Pull models into one section, by saying that the working group hasn't agreed on what advice to give on when to Push and when to Pull, and that this is more appropriate for more detailed protocol specifications anyway.

That makes sense to me. Perhaps it's worth pulling the partial description of advantages and disadvantages out of the framework doc now and including a more complete description as the working group consenses, but as before, this is not a blocking comment.

(Adrian Farrel) (was Discuss) No Objection

Comment (2013-08-19)
No email
send info
A further WG last call explicitly pointing to the IPR claim has been issued and the completion of that addresses any issue I can have claimed was worthy of a Discuss. Personally, I am surprised that the WG is happy to go ahead in the face of an IPR disclosure where the license terms are not clear, but if they are OK with that then I am not about to demand that they stop implementing.

(Stephen Farrell) No Objection

Comment (2013-08-15)
No email
send info
- Why is there no definition of directory service in
section 2? For this reader that term means an X.500 or LDAP
like service, but I'm not at all clear if that's what's

- If an LDAP-like service is what is envisaged then I don't
see how a push model can work. Perhaps if you delve deep
enough into X.500 history there is a matching model with
DSA replication though, not sure. That'd be very complex

- If what's envisaged is for the TRILL WG to develop an
entirely new directory service, then I think that should
be seriously discussed with the applications area. I'm
sure our apps ADs would take a keen interest were that
to be the case.

- Section 6 should IMO note the possibility that it may not
be possible to follow this recommendation, that is, failure
is a possible outcome. 

- The security considerations should note that any
directory service would be a fine target to attack and
could constitute a single point of failure. The current
text all seems to be saying how good all this would be,
which I don't think is right.

- Managing access control in directories is always hard and
that should be noted here.

(Brian Haberman) No Objection

Comment (2013-08-15)
No email
send info

Given some additional discussions I have had on this document, I am strongly leaning more towards Joel J.'s view of this document.  It is not a framework, but it is also not a strong problem statement document.  I am unclear what purpose this document will serve and I am not sure how it could be changed to make it worth publishing.

I am curious about the sub-sections in section 5.  There is discussion of how RBridges can learn the mappings via either a Push or Pull model (and the corresponding requirements) and what information should be in the directory.  Was there discussion of adding a section discussing how the information gets placed in the directory (and the corresponding requirements)?  Something to consider, but is more a curiosity on my part and definitely non-blocking.

Barry Leiba No Objection

Comment (2013-08-12)
No email
send info
-- Section 10.1 --

   As an Informational document, this draft has no Normative References.

I don't believe the general sentiment behind this (that Informational documents don't have normative references) is true.  I think normative references are those that must be understood in order to understand the document at hand, and that applies to documents of any status.

I think it would be helpful if the authors should sort the references with that in mind.

That said, this is a non-blocking comment.  Please consider doing that sort, but there's no need to respond to this comment.

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) (was Discuss) No Objection

Comment (2013-08-27)
No email
send info
There's a whole bunch of security considerations that affect repositories; many captured by LDAP.  But, I guess I'll save all those for the actual protocol ;)

I have to admit I'm with Joel too.

(Joel Jaeggli) Abstain

Comment (2013-08-14)
No email
send info
IMHO this isn't a framework at all. it's a problem, requirements, and two operational models and some non-specific recommendations for more work.

a framework is the structure that holds up the specification.

I am unclear what actions the working group is planning on doing on the basis of section 6.

6. Recommendation

   TRILL should provide a directory assisted approach.  This document
   describes a basic framework for directory assistance to RBridge edge
   nodes. More detailed mechanisms will be described in a separate
   document or documents.

The document appears to suggest implementing both mechanisms that it proposes, which is great I guess but normally I'd expect a document like this from a working group to arrive at a consensus solution instead of two of them.