Great. I expect that we'll submit a revised I-D before IESG review. On 6/25/13 2:03 PM, Brian E Carpenter wrote: > 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
