[MMUSIC] Review of draft-ietf-mmusic-latching-00

Ari Keränen <ari.keranen@ericsson.com> Wed, 24 April 2013 17:30 UTC

Message-ID: <517816B7.2070307@ericsson.com>
Date: Wed, 24 Apr 2013 20:30:31 +0300
From: Ari Keränen <ari.keranen@ericsson.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: draft-ietf-mmusic-latching@tools.ietf.org
References: <5178159E.9070405@ericsson.com>
In-Reply-To: <5178159E.9070405@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: mmusic <mmusic@ietf.org>
Subject: [MMUSIC] Review of draft-ietf-mmusic-latching-00
Precedence: list

Hi,

I reviewed the draft-ietf-mmusic-latching-00 and have a few (mainly 
editorial) comments.


Abstract: expand RTC.


1.  Introduction

    address and transport port number.  This includes consumer NAPTs,

Expand NAPT; (or alternatively, even if NAPT is more "technically 
correct" term, maybe just "consumer NAT" is more clear..)


    encoded in bodies such as SDP [RFC4566]> as well as, in the case of

Extra ">" here.


Also expand SDP, STUN, TURN, ICE, XMPP, MGCP (but SIP & RTP are OK 
without; http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt).


    [...] MGCP, H.248/MEGACO, and H.323.

Informative references for these?


2.  Terminology

You're not using RFC 2119 terminology; this section can be removed.


3.  Background

        equivalents) by NATed User Agents (UAs) are not usable across the
        Internet, because they represent the private addressing
        information of the UA rather than the addresses/ports that will

The term "private addressing information" sounds a bit strange. Maybe 
"private network addressing information" or something instead?


5.  Media Behavior, Latching

    however is not typically aware of the public mapping and would often
    advertise in the private address:port couple in signaling.

Extra "in" here?


    This way,
    when the signalling intermediary performing HNT receives the private
    addressing information from the UA it will not know what address/
    ports to send media to

Could clarify that "private addressing information of a peer behind a 
NAT from the UA" (if that's what you mean).


    UAC network and 198.51.100/24 facing towards the UAS network.

First time "UAC" and "UAS"; expand.


Figure 2:
Why are you using /port instead of :port notation here? As in "SBC 
allocates 198.51.100.2/22007". That's a bit confusing with the CIDR 
"198.51.100/24" notation in the same figure. And the latter address (and 
likewise on the other side of the SBC) are missing the last (0) octet.


            Figure 3: Latcing by a SIP SBC across two interfaces

Typo: "Latcing". Also same slash-port notation issues as in figure 2.


    address information in in offers and answers may actually completely

Extra "in" here too (and missing full stop at the end).


There's no IANA considerations section. Please add one with "This 
document has no actions for IANA." with note to RFC editor to remove the 
section before publication.


There's a bunch of idnits warning on the references; please check and 
fix these: 
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-mmusic-latching-00.txt


Cheers,
Ari (as individual)

[MMUSIC] WGLC for draft-ietf-mmusic-latching-00 Ari Keränen
[MMUSIC] Review of draft-ietf-mmusic-latching-00 Ari Keränen
Re: [MMUSIC] WGLC for draft-ietf-mmusic-latching-… Paul Kyzivat