Hi Brian, thanks for the review. On Jun 23, 2013, at 8:01 PM, Brian E Carpenter <[email protected]> wrote:
> 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. Although that's out of scope for this document. We might address that scenario in a future document. > I would suggest > ending this sentence with "appeal to service providers and users." Good point. > > " 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.) At least in XMPP, you'd have the same contact list on all of those devices. But we can word this more carefully. > > 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. True. > > 2. Is there any reason why SIP service providers and XMPP service > 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 > in any case have to deal with any inconsistencies in provisioning. I'm not sure what actionable advice we can provide here, but I'll discuss with with my co-authors. > > 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? 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 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? 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. > > 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. Yes, that's more accurate. > 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? > IMHO that would be advisable. Good catch. Peter -- Peter Saint-Andre http://iwe.cisco.com/web/psaintan _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
