Hi, Emil. A couple of points below - I have deleted the agreed ones.
I had a quick look through -06 and it looks fine to me except for a couple of mnor points noted below (and a s/i.e./i.e.,/ in the new text in s2, para 2). If I was being *really* pedantic I could argue that "(i.e. the SIP SBC and media relay are co-located on the same host)" needs to have "and using the same subnet" but that's probably a nit too far. ;-) On Thu, 2014-05-29 at 18:17 +0200, Emil Ivov wrote: > Hey Elwyin, > > Thanks for reviewing! Comments inline: > > On 27.05.14, 18:35, Elwyn Davies 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. > > Good point. How about this: > > - A common concern is that an SBC that implements HNT may latch to > - incorrect and possibly malicious sources. A malicious source could, > === > + A common concern is that an SBC that implements HNT may latch to > + incorrect and possibly malicious sources. The ICE [RFC5245] protocol > + for example, provides authentication tokens (conveyed in the ice- > + ufrag and ice-pwd attributes) that allow confirming the identity of a > + peer before engaging in media exchange with her. Without such > + authentication, a malicious source could, That looks good. Suggest: s/that allow confirming the identity of a peer/that allow the identity of a peer to be confirmed/ > > > 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. > > How about: > > > - A common concern is that an SBC that implements HNT may latch to > === > + A common concern is that an SBC (or an XMPP server, all security > + considerations apply to both) that implements HNT may latch to > > > 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> > > Sounds good to me. Fixed. WE'll see what the RFc Editor has to say about this! > > > Nits/editorial comments: > > General: Would probably be useful to explain the "address:port" > > terminology; > > OK, how about: > > - An UA behind a NAT streams media from a private address:port set that > - once packets cross the NAT, will be mapped to a public set. > === > + An UA that is behind a NAT would stream media from an address and a > + port number (an address:port couple) that are only valid in its local > + network. Once packets cross the NAT, that address:port couple will > + be mapped to a public one. Looks good. <<snip>> > > 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. > > We used to have private addresses there but were asked (I think by a > previous chair) to replace them with documentation ones because they > would be more appropriate. Could you please confirm that using typical > NATed addreses wouldn't break any policy? > > For the sake of completeness, nothing would prevent any address from > appearing behind a NAT (even public-looking ones) so this is only about > increasing the clarity of the example. > > > 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! > > I am fine either way. Ultimately it doesn't really matter whether private or documentation addresses are used... we are just more used to seeing private addresses on the non-public side of NATs. I don't know what general policy is supposed to be so I have asked my fellow gen-arters for a view. I haven't heard back yet. What I think would be useful would be to show the NAT address mapping in Figure 2 as you have done in the XMPP Figure 3. <<snip>> > Thanks again for your review! Thanks for the reponse. Regards, Elwyn > > Emil _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
