Subject: Re: [Gen-art] Gen-art LC review of draft-ietf-mmusic-latching-05

From: Emil Ivov <[email-masked]>
Date: Sun, 01 Jun 2014 13:10:11 +0200

Hey Elwyn,

On 30.05.14, 18:03, Elwyn Davies wrote:
> 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

Fixed.

> 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. ;-)

Well since it's Saturday why not indulge in a discussion on this :). I 
wouldn't mind adding the subnet part but the text basically says:

     If they both have the same IP address (that is, if they are on the
     same host)

So, isn't the part with the "same subnet" kind of implied already? I am 
not a native speaker though so happy to change if I am missing something

> 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/

Changed.

>>> 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.

Fixed and resubmitted!

Thanks,
Emil

-- 
https://jitsi.org

---

From: Elwyn Davies <[email-masked]>
Date: Sun, 01 Jun 2014 13:40:22 +0100

.. and now its Sunday...

> not a native speaker though so happy to change if I am missing something
Nothing to with being a native speaker.  The English is excellent.

The extremely pedantic point was that the host might have more than one
interface on different addresses (the SBC is already shown with two, of
course) so it could be that the control and media run on different
addresses but via the same host.  With IPv6 they could even be on the
same interface.

Don't feel obliged to join me in pedantry land.

Cheers,
Elwyn

---

From: Emil Ivov <[email-masked]>
Date: Sun, 01 Jun 2014 15:17:44 +0200

> addresses but via the same host.  With IPv6 they could even be on the

Yes, you are right of course. It just that, given how the sentence 
starts with "If they both have the same IP address" that was implied.

I'll made the change and for the next revision :).

Emil

-- 
https://jitsi.org