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 On 25/06/2013 02:30, Peter Saint-Andre wrote: > 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
