Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-rfc4566bis-32: Local addresses

"Ali C. Begen" <> Wed, 20 February 2019 20:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98584129B88 for <>; Wed, 20 Feb 2019 12:39:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3PvaKqxlRDv9 for <>; Wed, 20 Feb 2019 12:39:17 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::b42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 56E3812950A for <>; Wed, 20 Feb 2019 12:39:17 -0800 (PST)
Received: by with SMTP id j189so10140347ybj.9 for <>; Wed, 20 Feb 2019 12:39:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VGyaU1AJm3cqHvyo0P43wnJLXPaggkRfJt5obycUn1E=; b=vCvUYDNTICopv7fJsJil9O9eOjadd3lAqL9eTOrfR+H537rfn3lphnGiy/BjP/sUx/ ikv3/OMfV9EkhQLDEd03IPvVC1GjOPUfohZvYTN1g5lZYJrmao3UiqeijKKaCCi9+ojq KvCjuYwE/TE3VBeUAFEhdYAUrLTfLKklr5ML2Rtbv/YawrvCcadZGyoB26nSl6t4cy/M 56B86mMbrFtc/I9WO/zLfdqvGmoXrFtbK70YKWiavWejlH3chynzmaV0cY8rHqo4ryrR WkAw6ERVhkhGB/Efkbj68scJndCIOZ6T1HPDyZRoRTayryct8Mhen/++70cKN99XQ7AD treQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VGyaU1AJm3cqHvyo0P43wnJLXPaggkRfJt5obycUn1E=; b=n+YJst/BQTnxBlQU+wXxWD8lJmFJKbHiFExOAdnZxyWSJax526rWBiBSQPvUq5ZlK5 mLZcDSLPtNJfvvX2lnTP6ic8ELkJXa9oHHkYkRwoGxOUh6+s+IOY3Cj0FwCj9xtaUidM he8lethIQ5zasPq1VgF3fyy+lfsoCggmyyS2nO6Er7xhnxMOnvZVWsB6IB0PN1ISTD8U rjS3+m8wgFL5z3dhefgjhR7ZZFPG41j1bAOAzr3MupI2GbruA0SblDrgzUIxQTQFtXNj cy/+rmjNEjbja3xMy2GyNBaWfmXbSd35WFdSmrziUEraCZOUq7ZSIw3r46wuLO5MNf4J Nrsw==
X-Gm-Message-State: AHQUAuZwIcXqKIRtrBuPoc95GJvVZ7ci6oRVRMdqgwStb9nULI7z3kOB Mxc5LwIkEfshjpVrjLA1RZCeGbPgaFQr6bw1OWcDRA==
X-Google-Smtp-Source: AHgI3Ib/uHAGmLKmYUbkxEm7VoUfZOyYxo+v8qKW/nxJ3yi8KEjQmrpAGjlcrJtYxNCEiwOxm/5gpFp+60RWtWkiXNU=
X-Received: by 2002:a25:bd4b:: with SMTP id p11mr30579358ybm.251.1550695156278; Wed, 20 Feb 2019 12:39:16 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: "Ali C. Begen" <>
Date: Wed, 20 Feb 2019 23:39:05 +0300
Message-ID: <>
To: Paul Kyzivat <>
Cc: Ben Campbell <>,, mmusic WG <>
Content-Type: multipart/alternative; boundary="000000000000f200d70582595919"
Archived-At: <>
Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-rfc4566bis-32: Local addresses
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Feb 2019 20:39:20 -0000

On Wed, Feb 20, 2019 at 10:10 PM Paul Kyzivat <> wrote:

> Ben,
> On 2/11/19 10:45 PM, Ben Campbell wrote:
> ...
> > §5.2: "Unless an SDP extension for NAT traversal is used
> > (e.g., ICE [RFC8445], ICE TCP [RFC6544]), a local IP address MUST
> > NOT be used in any context where the SDP description might leave
> > the scope in which the address is meaningful”
> >
> > That doesn’t apply to just any NAT traversal extension does it? It seems
> to require extensions that have scope-resolution properties similar to
> those of ICE.
> When I came back to this I realized it is talking about an address in an
> o= line, not c=. Hence there is no intent that anybody connect to this,
> and ICE doesn't apply here. The address is primarily here to add to the
> uniqueness of the o= line. And note that the <sess-id> is required to
> make up any lack of uniqueness in the combination of the other fields.
> And privacy is leading to people not wanting to put real addresses or
> names in here.
> I suggest we trim this back to:
>     <unicast-address>  is an address of the machine from which the
>        session was created.  For an address type of IP4, this is either a
>        fully qualified domain name of the machine or the dotted-decimal
>        representation of an IP version 4 address of the machine.  For an
>        address type of IP6, this is either a fully qualified domain name
>        of the machine or the compressed textual representation of an IP
>        version 6 address of the machine.  For both IP4 and IP6, the fully
>        qualified domain name is the form that SHOULD be given unless this
>        is unavailable, in which case a globally unique address MAY be
>        substituted.
> And perhaps we should recommend that something bogus may be used to
> preserve some privacy.

Maybe use RFC 7022 for the privacy goal?

> I would like some feedback here!
>         Thanks,
>         Paul