Presence and Instant Messaging Peering Use Cases
RFC 5344

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

(Jon Peterson) Yes

(Jari Arkko) No Objection

(Ross Callon) No Objection

(Russ Housley) No Objection

(Cullen Jennings) No Objection

(Mark Townsley) No Objection

Magnus Westerlund No Objection

(Lars Eggert) Abstain

Comment (2008-02-21 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Chris Newman) Abstain

Comment (2008-02-21 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Tim Polk) Abstain

Comment (2008-02-21 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.