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/