Elwyn: many thanks for your review. Authors, do you have any responses or corrections, based on the s5 minor issue and nits listed below?
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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
