Directory Assistance Problem and High-Level Design Proposal
draft-ietf-trill-directory-framework-07

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.

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

Updated...

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.

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.

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.

- 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
envisaged. 

- 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
though.

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

I agree with Joel's concern on whether this should be called a framework.