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?