On 6/23/13 8:27 PM, Peter Saint-Andre (psaintan) wrote: > 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 > > 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 > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
