Subject: [MMUSIC] WGLC for draft-ietf-mmusic-latching-00

From: Ari Keränen <[email-masked]>
Date: Wed, 24 Apr 2013 20:25:50 +0300

This is to start a 2-week Working Group Last Call for

draft-ietf-mmusic-latching-00

The WGLC ends on May 8th, 2013.

Please review the document send your comments both to the authors and to 
the MMUSIC mailing list. If you review the document but do not have any 
comments, please send a note to that effect as well.

The document is available here:
http://tools.ietf.org/html/draft-ietf-mmusic-latching-00

Thanks,
Ari

---

From: Ari Keränen <[email-masked]>
Date: Wed, 24 Apr 2013 20:30:31 +0300

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)

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Apr 2013 19:35:17 -0400

WGLC Comments:

I did a fresh read of this. I found a few small things:

Section 5:

    1.  After receiving an offer from a NATed UA, a signaling
        intermediary located on the public Internet would allocate a set
        of IP address:ports on a media relay.  The set would then be
        advertised to the remote party so that it would use it for all
        media it wished to send toward the UA.

The last sentence is using "it" in two different ways, and neither is 
clear. I suggest:

    1.  After receiving an offer from a NATed UA, a signaling
        intermediary located on the public Internet would allocate a set
        of IP address:ports on a media relay.  The set would then be
        advertised to the remote party so that it would use those media
        relay address:ports for all media it wished to send toward the
        UA.

Similarly for 2, I suggest:

    2.  Next, after receiving an answer to its offer, the signaling
        server would allocate a second address:port set on the media
        relay.  It would advertise this second set in the answer to the
        UA. The UA will then send to this media relay address:port.

Figure 2:

This figure is inconsistent with the steps described above. It shows 
both address/port sets being allocated when the offer is received, while 
the steps say that the second pair is allocated when the answer is received.

	Thanks,
	Paul

On 4/24/13 1:25 PM, Ari Keränen wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>