Presence and Instant Messaging Peering Use Cases
draft-ietf-speermint-consolidated-presence-im-usecases-05

[Ballot comment]
This document makes me very nervous with respect to the privacy issues.  The document
acknowledges that the privacy issues are very difficult, but the complexity and extension
of trust associated with the proposed solutions (trusting perr network for access control,
multiple documents for multiple sets fo watchers) were not particularly reassuring. 

Like Chris, I will  be reviewing protocols in this space very carefully.  Early review is
definitely a good idea.

[Ballot comment]
I'm with Chris. Some of these uses cases are very problematic, and I'm not at all convinced that the IETF should define an architecture to enable them.

[Ballot comment]
As this document does not commit the IETF to any specific action, I see
no grounds for a blocking DISCUSS.  However, given the profound security,
privacy and interoperability issues raised by these use cases it is not
clear to me that standardization of mechanisms to support these use cases
is wise.

Indeed, the use case that involves passing a complete presence document
to a foreign domain and trusting the foreign domain to parcel out the
right pieces to its users seems like a truly poor design as it
violates the least privilege principle, the end-to-end principle,
the transitive trust principle and is completely unjustified by the
efficiency argument. Efficiency can be achieved by having a small
number of presence subsets shared with other users and batching a
given subset for all the users in the foreign domain who use that
subset (e.g., like the multiple "RCPT TO" feature in SMTP).

An argument could be made that some of these use cases are
actively harmful to the Internet community.  In the event protocols that
are harmful to the Internet community came before the IESG, I'm not
likely to support those proposals.  You might want to seek early review
on this issue to avoid last minute surprises.

I would also recommend any designs looking at these use cases consider
the scalability issues of any sort of manual arrangement between peers.
It's likely any sort of multi-hop trust relationship needs a low-cost
automatic bootstrap mechanism.

PROTO Write-up

1 -
A. Who is the Document Shepherd for this document?
--> Jason Livingood

B. Has the Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this version is
ready for forwarding to the IESG for publication?
--> Yes.

2 -
A. Has the document had adequate review both from key WG members and
from key non-WG members?
--> Yes.

B. Does the Document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
--> No.

3 - Does the Document Shepherd have concerns that the document needs
more review from a particular or broader perspective, e.g., security,
operational complexity, someone familiar with AAA, internationalization,
or XML?
--> No.

4 -
A. Does the Document Shepherd have any specific concerns or issues with
this document that the Responsible Area Director and/or the IESG should
be aware of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it. In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.
--> No concerns.

B. Has an IPR disclosure related to this document been filed? If so,
please include a reference to the disclosure and summarize the WG
discussion and conclusion on this issue.
--> No, an IPR disclosure has not been filed.

5 -
A. How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?
--> Strong consensus, no outstanding objections. Any objections raised
were minor and were resolved effectively and completely.

6 - Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is entered into the ID
Tracker.)
--> No.

7 -
A. Has the Document Shepherd personally verified that the document
satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not
enough; this check needs to be thorough.
--> Yes. The only unresolved nit is that the file name is too long.
The I-D editor said they cannot change the name without a new -00 draft.
As this file name will change as the document progresses, we have left
it as-is (we are happy to take AD direction to the contrary). Also,
some of the informative references will need to be updated, as some of
those references are still I-Ds and progressing.

B. Has the document met all formal review criteria it needs to, such as
the MIB Doctor, media type, and URI type reviews?
--> Yes.

C. If the document does not already indicate its intended status at the
top of the first page, please indicate the intended status here.
--> Intended status Informational (which is shown currently).

8 -
A. Has the document split its references into normative and
informative?
--> Yes.

B. Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?
--> No.

C. If such normative references exist, what is the strategy for their
completion?
--> N/A

D. Are there normative references that are downward references, as
described in [RFC3967]?
--> No.

E. If so, list these downward references to support the Area Director
in the Last Call procedure for them [RFC3967].
--> N/A

9 -
A. Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body of the
document?
--> Yes.

B. If the document specifies protocol extensions, are reservations
requested in appropriate IANA registries?
--> N/A

C. Are the IANA registries clearly identified?
--> N/A

D. If the document creates a new registry, does it define the proposed
initial contents of the registry and an allocation procedure for future
registrations?
--> N/A

E. Does it suggest a reasonable name for the new registry? See
[RFC2434].
--> N/A

F. If the document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during IESG Evaluation?
--> N/A

10 - Has the Document Shepherd verified that sections of the document
that are written in a formal language, such as XML code, BNF rules, MIB
definitions, etc., validate correctly in an automated checker?
--> Yes, N/A in this document.

================================================================
Document Announcement Write-Up:

1 - Technical Summary
The document describes several use cases of peering of non-VoIP services
between two or more Service Providers (SP). These Service Providers
create a peering relationship between themselves thus enabling their
users to collaborate with users on the other Service Provider network.
The target of the document is to drive requirements for peering between
domains that provide the non-VoIP based collaboration services and
presence and Instant Messaging (IM) in particular.

2 - Working Group Summary
There is consensus in the WG to publish this document. WGLC was opened
on 21 May 2007, and closed on 5 June 2007. All changes suggested by the
WG have been made to this draft. A NITS review has also been performed
by our secretary, and those changes made as well.

3 - Document Quality
This document describes IM and Presence use cases for session peering.
They are intended to provide the basis for session peering requirements,
as well as a recommended best current practice architecture for session
peering.

4 - Personnel
Document Shepherd: Jason Livingood
Responsible AD: Jon Peterson
IANA Experts Required: No

================================================================
END WG PUBLICATION REQUEST
================================================================

Regards,
Jason Livingood
co-chair SPEERMINT WG in RAI