Subject: [Gen-art] Gen-ART LC review of draft-ivov-xmpp-cusax-06.txt

From: Brian E Carpenter <[email-masked]>
Date: Mon, 24 Jun 2013 14:01:46 +1200

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ivov-xmpp-cusax-06.txt
Reviewer: Brian Carpenter
Review Date: 2013-06-24
IETF LC End Date: 2013-07-16
IESG Telechat date:

Summary:  Almost ready
--------

Comment:
--------

I have some issues, but I don't know whether to classify any of them as
major.

Issues:
-------

In Introduction:

"  As a result, a number of adopters have found themselves needing
   features that are not offered by any single-protocol solution, but
   that separately exist in SIP and XMPP implementations.  The idea of
   seamlessly using both protocols together would hence often appeal to
   service providers. "

A few paragraphs later, you discuss the case of an end user who would like
to use SIP and XMPP together with *different* service providers. I would suggest
ending this sentence with "appeal to service providers and users."

"  Finally, this document makes a further simplifying assumption by
   discussing only the use of a single client, not use of and
   coordination among multiple endpoints controlled by the same user
   (e.g., user agents running simultaneously on a laptop computer,
   tablet, and mobile phone)."

Hmm. Isn't that the normal case today, and your simplifying assumption
the exception? It's certainly extremely annoying to have different
contacts lists on different devices, for example. This seems like a
big gap in the model, with no hints on how it might be filled. (As big
as the gap between POP3 and IMAP, in some ways.)

In Client Bootstrap:

"  While it should be possible for CUSAX users to manually configure
   their separate SIP and XMPP accounts, service providers offering
   CUSAX services to users of dual-stack SIP/XMPP clients ought to
   provide means of online provisioning,..."

1. I would anyway expect my CUSAX client to come with a configuration
wizard, including a path to the online provisioning if available.

2. Is there any reason why SIP service providers and XMPP service
providers shouldn't individually provide on-line provisioning? You're
describing something close to a captive-customer scenario, rather than
encouraging an open approach to provisioning. The CUSAX client would
in any case have to deal with any inconsistencies in provisioning.

In Server-Side Setup:

"  In order for CUSAX to function properly, XMPP service administrators
   should make sure that at least one of the vCard [RFC6350] "tel"
   fields for each contact is properly populated with a SIP URI or a
   phone number when an XMPP protocol for vCard storage is used (e.g.,..."

How can they do that, given that users are normally responsible for
maintaining their contacts lists?

In Summary of Suggested Practices:

"  1.   By default, prefer SIP for audio and video, and XMPP for
        messaging and presence."

At the beginning of the Operation section, this seems to be stated as
a rule, not as a default (" Audio/video features however, are disabled
in the XMPP stack..."). Which is it?

In Security Considerations:

"  ... a CUSAX client might
   successfully negotiate Transport Layer Security (TLS) [RFC5246] when
   connecting to the XMPP aspect of the service but not when connecting
   to the SIP aspect.  Such mismatches could introduce the possibility
   of downgrade attacks."

I'd say *would* introduce the possibility. It would seem possible for a
bad actor to pick up authentication data from the insecure service and
exploit it to attack the secured service. Therefore,

"  User agent developers and service providers
   ought to ensure that such mismatches are avoided as much as possible."

seems a bit weak. Shouldn't the client also be *required* to alert the user
that the session as a whole is not secured?

---

From: "Peter Saint-Andre (psaintan)" <[email-masked]>
Date: Mon, 24 Jun 2013 02:27:25 +0000

Hi Brian, thanks for the review.

On Jun 23, 2013, at 8:01 PM, Brian E Carpenter <[email-masked]>
 wrote:

> to use SIP and XMPP together with *different* service providers.

Although that's out of scope for this document. We might address that scenario in a future document.

>  I would suggest

Good point.
> as the gap between POP3 and IMAP, in some ways.)

At least in XMPP, you'd have the same contact list on all of those devices. But we can word this more carefully.

> wizard, including a path to the online provisioning if available.

True.
> providers shouldn't individually provide on-line provisioning?

No.

(Something like the technology proposed at the aggsrv BoF in Orlando might help, too, but that's just a gleam in the eye at this point.)

>  You're
> describing something close to a captive-customer scenario,

We are indeed assuming that a dual-stack user agent would interact with a combined service (i.e., CUSAX on the client side and CUSAX on the server side).  I am not sure that a customer of such a service is a captive.

> rather than
> encouraging an open approach to provisioning.

As far as I can see, no open provisioning protocol is available yet. The aforementioned aggsrv approach might fit the bill. It's too early to say, but we can at least mention the possibility that such a technology might be developed in the future.

> The CUSAX client would

I'm not sure what actionable advice we can provide here, but I'll discuss with with my co-authors.
> maintaining their contacts lists?

When a user uploads their vCard (or, say, modifies it in a web interface), the server could apply automated checks or make the "tel" field mandatory.
> in the XMPP stack..."). Which is it?

I'm not seeing a huge difference here -- the XMPP stack in the CUSAX user agent might have audio/video capabilities, but typically those would be disabled (disabled by default, but the user might be allowed to turn them on for certain kinds of contacts, etc.).

I suggest this change in the Operation section.

OLD
   Audio/video features however, are
   disabled in the XMPP stack, so any form of communication based on
   these features (e.g. direct calls, conferences, desktop streaming,
   etc.) will happen over SIP.

NEW
   Audio/video features however, would typically be
   disabled in the XMPP stack, so any form of communication based on
   these features (e.g. direct calls, conferences, desktop streaming,
   etc.) would happen over SIP.

> I'd say *would* introduce the possibility.

Yes, that's more accurate.

>  It would seem possible for a

IMHO that would be advisable. Good catch.

Peter

--
Peter Saint-Andre
http://iwe.cisco.com/web/psaintan

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 24 Jun 2013 08:30:18 -0600

> Hi Brian, thanks for the review.

Here is a provisional diff that addresses your feedback:

https://github.com/emcho/cusax/commit/1c5e9d681748685360cc6677ea2e369b352e66db#draft-ivov-xmpp-cusax-07.xml

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Jun 2013 08:03:43 +1200

Hi Peter,

Thanks, that all seems fine in the light of your comments. I would
expect to review this as "Ready" when it reaches the IESG agenda.

Regards
   Brian

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 25 Jun 2013 14:19:54 -0600

Great. I expect that we'll submit a revised I-D before IESG review.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 1 Jul 2013 09:21:56 +0300

Hi,

yes, we will revise the draft after the IETF LC and before the IESG review.

Cheers,

Gonzalo