Hey Jari, all, On Wed, May 28, 2014 at 2:19 PM, Jari Arkko <[email protected]> wrote: > Elwyn: many thanks for your review. Authors, do you have any responses or > corrections, > based on the s5 minor issue and nits listed below?
I was thinking of addressing them all in bulk once all the IESG comments were in. Apologies if that's considered a poor practice. I'll try to respond to all of them today. As for the S5 one: yes the concerns and solutions apply for XMPP the same way as they do for SIP. We will clarify that in the next revision. Emil > Jari > > On 27 May 2014, at 19:35, Elwyn Davies <[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-ietf-mmusic-latching-05.txt >> Reviewer: Elwyn Davies >> Review Date: 27 May 2014 >> IETF LC End Date: 28 May 2014 >> IESG Telechat date: 29 May 2014 >> >> Summary: Ready with nits. Generally a well argued document. In the >> light of the comment that the IETF advises the use of ICE or STUN rather >> than HNT, I wondered if it might be helpful to explain how these >> mechanisms mitigate or resolve the security issues in s5. >> >> Major issues: >> None >> >> Minor issues: >> s5: Section 4 talks about problems with XMPP but the security concerns >> in s5 are all discussed in the context of SIP/SBC. I think some words >> about the corresponding security issues in XMPP (or just a statement >> that all - or a subset - of these apply to XMPP) ought to be added. >> >> s8: <Heresy Starts> Barry Leiba in his comments in the tracker suggests >> that the references would be usefully split into Normative and >> Informative subsets. Given the number of references, splitting them up >> seems like a good idea. I am going to suggest something highly >> heretical: Split them up but call them "Key References" and "Additional >> References". "Normative" has become such a loaded word in the standards >> community that, despite its underlying English meaning, it is probably >> better to confine its usage to Standards Track documents. I feel that >> we usefully adopt this alternative classification for non-standards >> track documents as a general technique to avoid the ongoing discussions >> about split refetrence sections. <Heresy Ends> >> >> >> Nits/editorial comments: >> General: Would probably be useful to explain the "address:port" >> terminology; Also both the terms "couple" and "set" are used for the >> tuple - better to stick with one and use "address:port sets/couples" >> instead of "address:ports". >> >> General: s/e.g./e.g.,/g >> >> s1: Need to expand SDP >> >> s3, last sentence: >> OLD: >> the SBC may decide not to send media to that customer UA until a SIP 200 >> response for policy reasons, to prevent toll-fraud. >> NEW: >> the SBC may decide, for policy reasons, not to send media to that >> customer UA until a SIP 200 response has been received, [e.g., ???] to >> prevent toll-fraud. >> >> s4, para 1: s/ address:port set that once packets cross the NAT, will be >> mapped/address:port set that, once packets cross the NAT, will be >> mapped/ >> >> s4, Figure 2: The figure doesn't reflect the address mapping done in >> the NATs. the clients Alice and Bob are shown with public >> (documentation) addresses whereas they should presumably have private >> addresses that are mapped to these public addresses by the NAT. >> >> s4, Figure 3: The previous comment doesn't apply to this figure which >> shows the NAT mapping. Arguably it would be nice to use private address >> space addresses on the private side of the NAT, but I notice we never >> managed to allocate a specific private address for documentation - I >> suppose since they are private it doesn't matter! >> >> s4, Figure 3, title: Cut and paste error... this figure is about XMPP >> not SBC! >> >> s5, para 2: s/In all/All/ >> >> >> _______________________________________________ >> Gen-art mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/gen-art > -- https://jitsi.org _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
