Hi, yes, we will revise the draft after the IETF LC and before the IESG review.
Cheers, Gonzalo On 25/06/2013 11:19 PM, Peter Saint-Andre wrote: > 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
