Skip to main content

Presence and Instant Messaging Peering Use Cases
RFC 5344

Yes

(Jon Peterson)

No Objection

(Cullen Jennings)
(Jari Arkko)
(Magnus Westerlund)
(Mark Townsley)
(Ross Callon)
(Russ Housley)

Abstain


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

Lars Eggert
Abstain
Comment (2008-02-21) Unknown
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.
Jon Peterson Former IESG member
Yes
Yes () Unknown

                            
Cullen Jennings Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection () Unknown

                            
Magnus Westerlund Former IESG member
No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Chris Newman Former IESG member
Abstain
Abstain (2008-02-21) Unknown
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 Former IESG member
Abstain
Abstain (2008-02-21) Unknown
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.