From nobody Mon Apr 1 07:30:52 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479B6120169; Mon, 1 Apr 2019 07:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6jcf6jDv2fC; Mon, 1 Apr 2019 07:30:48 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60063.outbound.protection.outlook.com [40.107.6.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65F62120110; Mon, 1 Apr 2019 07:30:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t0PP7v341LcR8x1ZdunMPsG3PyUfxwHZHzoTnxXGC5M=; b=Xnek1qn2nh7l7E1tovnqS4iwcElAB0FKmAPo89HiGYlnsm1+7BlnExz2IGrI3OUs/uLnUCL6GOAyfMcxLA78Q39nZCnqgwDhIZTWDu5NSQ+WQ1HwufYCkQcqHYuDnpU6lL3dF/kmxWcNQTrOizlEhVx077N7DjdZ+rzGEmZB0N4= Received: from HE1PR07MB3259.eurprd07.prod.outlook.com (10.170.246.26) by HE1PR07MB3164.eurprd07.prod.outlook.com (10.170.245.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.11; Mon, 1 Apr 2019 14:30:44 +0000 Received: from HE1PR07MB3259.eurprd07.prod.outlook.com ([fe80::5ce7:e79c:91a5:5629]) by HE1PR07MB3259.eurprd07.prod.outlook.com ([fe80::5ce7:e79c:91a5:5629%6]) with mapi id 15.20.1771.011; Mon, 1 Apr 2019 14:30:44 +0000 From: Bo Burman To: Flemming Andreasen , Martin Thomson , mmusic CC: "draft-ietf-mmusic-sdp-uks@ietf.org" Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-uks-03 Thread-Index: AQHUppKYzbL9IIoclE+lDKCXhZBCwqXxzxIAgATZAYCAB0f8gIAAVxuAgAK+34CAJtpEsA== Date: Mon, 1 Apr 2019 14:30:44 +0000 Message-ID: References: <69e1ed84-7bae-4258-897b-a6d36716c261@www.fastmail.com> <718ce899-166c-b793-c7d4-84bb5fcceea5@cisco.com> In-Reply-To: <718ce899-166c-b793-c7d4-84bb5fcceea5@cisco.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4a440061-5512-48a1-72d3-08d6b6aea021 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(4534185)(4627221)(201703031133081)(201702281549075)(5600139)(711020)(4605104)(2017052603328)(7153060)(49563074)(7193020); SRVR:HE1PR07MB3164; x-ms-traffictypediagnostic: HE1PR07MB3164: x-microsoft-antispam-prvs: x-forefront-prvs: 0994F5E0C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(376002)(346002)(396003)(136003)(199004)(189003)(51444003)(26005)(105586002)(186003)(316002)(229853002)(6346003)(6506007)(256004)(14444005)(102836004)(606006)(7736002)(53546011)(106356001)(66066001)(97736004)(7696005)(25786009)(71200400001)(71190400001)(3846002)(5660300002)(86362001)(11346002)(74316002)(6116002)(790700001)(446003)(33656002)(476003)(76176011)(6436002)(8936002)(52536014)(110136005)(8676002)(4326008)(81166006)(486006)(81156014)(68736007)(99286004)(14454004)(478600001)(93886005)(236005)(9686003)(99936001)(6246003)(2906002)(53936002)(966005)(44832011)(55016002)(6306002)(54896002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3164; H:HE1PR07MB3259.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=bo.burman@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ckU63elzCZPRO6UMg+R3BFREvM4HUNlAS49PWG/evtGtqP6GoMJqi6QlaQfg+/9MeScPUx1kwHrf0yNNFN4p9ECfCrayGQre9++IxhMoTEHDH5L104l9GWRtih288FycHgVj3bYYru4DmulKnibxR0rQAzcwn85e6bK24DOeJFLClclHeywA0P6rdBusCE2/Kho3/GbFxxW9sWJyHzLVoelYPM+l6erE8AmshFgve/5Bxi4fjwktfnNExVV5wiu99WPwn6YgnL6PXcl/0EjRpFaoQmxGMBQTcpFHzNVm3NZM+t3XxnmHdEN3913CBTGrHvOz2DDDJyKp40BYa1/dcLVqTdrWo1zCw6F9GeVf7j7owwL69WfnXaMM/CBrrfNNPoZVqUn+ggiTRlycMVG2R0fKVY3ck8Vr5rEejKoSFBY= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_009E_01D4E8A8.3C76B7B0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4a440061-5512-48a1-72d3-08d6b6aea021 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2019 14:30:44.4773 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3164 Archived-At: Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-uks-03 X-BeenThere: mmusic@ietf.org 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: Mon, 01 Apr 2019 14:30:51 -0000 ------=_NextPart_000_009E_01D4E8A8.3C76B7B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_009F_01D4E8A8.3C76B7B0" ------=_NextPart_001_009F_01D4E8A8.3C76B7B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Authors, =20 Do you have any answers to Flemming=E2=80=99s questions below? =20 When those questions are answered, please submit a new version that = addresses them and all other WGLC comments. =20 /Bo (as MMUSIC co-chair) =20 From: mmusic On Behalf Of Flemming Andreasen Sent: den 7 mars 2019 22:06 To: Martin Thomson ; mmusic Cc: draft-ietf-mmusic-sdp-uks@ietf.org Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-uks-03 =20 =20 On 3/5/19 10:10 PM, Martin Thomson wrote: Hi Flemming, =20 "For 3PCC to work with the proposed mechanisms, TLS peers need to be=20 aware of the signaling so that they can correctly generate (and check) the=20 extension. Peers need access to any identity assertions present in signaling in order to=20 perform the checks in {{external_id_hash}}. To perform the checks in {{external_session_id}}, a 3PCC system needs to ensure that guarantee=20 that peers use the same SDP `tls-id` attribute value." I'm still not clear on how this works. RFC 3725 defines four different=20 flows - does the mechanism work with all four of them ? To some extent,=20 this may be a question on SIP Authenticated Identity (RFC 8224) as it=20 is not clear to me how that works with 3PCC. An actual (high-level)=20 call flow illustratings this would be helpful.=20 =20 The problem here is that RFC 3725 doesn't really contemplate the sorts = of changes that earlier commenters observed happen in practice. All the = flows and recommendations there limit the changes made by the controller = to fixups that ensure that offers and answers from the endpoints work = effectively. On that basis, simply following the guidance in RFC 3725 = would - absent some mistake - result in a working session. Presumably, = if the controller supports tls-id, then it copies the value faithfully = and things work. That is how I would interpret the guidance in 3725. =20 But some people observed that 3PCC covers more than the fixups that 3725 = recommends, so this text hedges a little. Would it help if it were = expanded thus: =20 "For 3PCC to work with the proposed mechanisms, TLS peers need to be = aware of the signaling so that they can correctly generate (and check) the extension. = Peers need access to any identity assertions present in signaling in order to = perform the checks in {{external_id_hash}}. For a connection to be successfully established, a controller needs to forward all fields that contain = identity assertions, including any fields outside of SDP that are used, such as = the SIP Identity header field {{?SIP-ID}}. A controller that follows the best = practices in RFC 3725 is expected to forward the necessary information contained = in SDP, such as the WebRTC `identity` attribute, thus ensuring the necessary = information is present. =20 "To perform the checks in {{external_session_id}}, a 3PCC system needs = to ensure that guarantee that peers use the same SDP `tls-id` attribute value. A controller that follows the best practices in RFC 3725 will produce SDP = with consistent `tls-id` values, but other forms of modification might not. =20 "It is understood that this technique will prevent the use of 3PCC if = peers have different views of the involved identities, or the value of SDP `tls-id` attributes." =20 The text is clearer, but I still don't follow. If I understand RFC 8224 = correctly, authenticated identity is only defined for SIP requests, = however all four 3PCC flows in RFC 3725 have the controller generate the = SIP INVITE, so how do the endpoints exchange authenticated identity = information ?=20 The text reads well, but I'm still left with the same question: =20 Section 3.1, second paragraph says there are two separate sessions (I=20 take that to mean SIP sessions). It then goes on to say=20 =20 "In the first session, Patsy is presented with the option to=20 communicate with Norma " =20 If I understand correctly, this means there is a SIP INVITE sent by=20 Mallory to Patsy, however Mallory somehow asserts Norma's identity to=20 Patsy. How is Mallory able to do that if we are using SIP Authenticated=20 Identity ? I'm not sure if the above would be cleare if the flow was=20 expanded to show INVITE and 200-OK.=20 =20 Yeah, I really want to avoid adding all the SIP stuff here. There would = be lots of irrelevant messages involved and it distracts from the = message. =20 The key insight here is that SIP identity only certifies a small number = of fields and that the rest of the session is open to be modified by the = signaling server. RFC 8225 only covers the identity (sip:norma@example = or tel:+12345556789) and the a=3Dfingerprint values, everything else is = open to attack. So if we allow Mallory the ability to modify signaling, = there is a lot she can do. In practice however, this doesn't require = much of an attack on the session, other than (maybe) to substitute = transport parameters. =20 >From the perspective of SIP and SIP identity, these are largely = legitimate sessions. The attack on signaling is necessary only to the = extent that the attack also depends on=20 =20 I've added more text here, realizing that it was a little light. This = is the updated section in full: =20 "The attack requires that Mallory obtain an identity binding for her own = identity with the fingerprints presented by Patsy (P). This false binding is = then presented to Norma (Signaling1 in the figure). You mean Signaling2 in the figure (below), right ?=20 Norma Mallory Patsy (fp=3DN) ----- (fp=3DP) | | | | |<---- Signaling1 ------>| | | Norma=3DN Patsy=3DP | |<---- Signaling2 ------>| | | Norma=3DN Mallory=3DP | | | | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DDTLS = (fp=3DN,P)=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | (peer =3D Mallory!) (peer =3D Norma) Figure 1: Example Attack on Identity Bindings =20 =20 "Patsy could be similarly duped, but in this example, a correct binding = between Norma's identity and fingerprint (N) is faithfully presented by Mallory. = This session (Signaling2 in the figure) can be entirely legitimate. Signaling1 ?=20 =20 "A DTLS session is established directly between Norma and Patsy. In = order for this to happen Mallory can substitute transport-level information in = both sessions to facilitate this, though this is not necessary if Mallory is = on the network path between Norma and Patsy. =20 "As a result, Patsy correctly believes that she is communicating with = Norma. I don't follow the above sentence (just like I don't follow the sentence = I referenced originally, i.e. "In the first session, Patsy is presented = with the option to communicate with Norma". If we double-click on "Signaling1", then I believe we start with: INVITE(From: Mallory, To: Patsy, Fingerprint:Norma, = Identity:{From:Mallory, Fingerprint:Norma}) Implicit in the sentence above is an assumption that *Mallory* is = somehow able to generate an INVITE to Patsy with an Identity header that = authenticates *Norma* as the originator, i.e.: INVITE(From: Norma, To: Patsy, Fingerprint:Norma, = Identity:{From:Norma, Fingerprint:Norma}) How is that possible ? What am I missing here ?=20 =20 However, Norma incorrectly believes she is talking to Mallory." This part I understand.=20 =20 There is one last thing that I realized while writing up those changes, = and that is that the text was a little vague about the relationship = between the attacks. I'll send another email with a proposed = clarification, because I think that's important enough not to hide. Ok - thanks=20 -- Flemming=20 =20 _______________________________________________ mmusic mailing list mmusic@ietf.org =20 https://www.ietf.org/mailman/listinfo/mmusic .. =20 =20 ------=_NextPart_001_009F_01D4E8A8.3C76B7B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Authors,

 

Do you have any = answers to Flemming=E2=80=99s questions below?

 

When those questions = are answered, please submit a new version that addresses them and all = other WGLC comments.

 

/Bo (as MMUSIC = co-chair)

 

From: mmusic <mmusic-bounces@ietf.org> On = Behalf Of Flemming Andreasen
Sent: den 7 mars 2019 = 22:06
To: Martin Thomson <mt@lowentropy.net>; mmusic = <mmusic@ietf.org>
Cc: = draft-ietf-mmusic-sdp-uks@ietf.org
Subject: Re: [MMUSIC] WGLC = on draft-ietf-mmusic-sdp-uks-03

 

 

On 3/5/19 10:10 PM, Martin Thomson = wrote:

Hi =
Flemming,
 
"For 3PCC to =
work with the proposed mechanisms, TLS peers need to be =

aware of the
signaling so =
that they can correctly generate (and check) the =

extension.=C2=A0 Peers
need =
access to any identity assertions present in signaling in order to =

perform
the checks in =
{{external_id_hash}}.=C2=A0 To perform the checks =
in
{{external_session_id}}, a 3PCC system needs to =
ensure that guarantee 
that =
peers
use the same SDP `tls-id` attribute =
value."
 I'm still not clear on how this =
works. RFC 3725 defines four different 
flows - =
does the mechanism work with all four of them ? To some extent, =

this may be a question on SIP Authenticated =
Identity (RFC 8224) as it 
is not clear to me how =
that works with 3PCC. An actual (high-level) 
call =
flow illustratings this would be helpful. =

 
The =
problem here is that RFC 3725 doesn't really contemplate the sorts of =
changes that earlier commenters observed happen in practice.=C2=A0 All =
the flows and recommendations there limit the changes made by the =
controller to fixups that ensure that offers and answers from the =
endpoints work effectively.=C2=A0 On that basis, simply following the =
guidance in RFC 3725 would - absent some mistake - result in a working =
session.=C2=A0 Presumably, if the controller supports tls-id, then it =
copies the value faithfully and things work.=C2=A0 That is how I would =
interpret the guidance in =
3725.
 
But some people =
observed that 3PCC covers more than the fixups that 3725 recommends, so =
this text hedges a little.=C2=A0 Would it help if it were expanded =
thus:
 
"For 3PCC to =
work with the proposed mechanisms, TLS peers need to be aware of =
the
signaling so that they can correctly generate =
(and check) the extension.=C2=A0 Peers
need access =
to any identity assertions present in signaling in order to =
perform
the checks in {{external_id_hash}}.=C2=A0 =
For a connection to be successfully
established, a =
controller needs to forward all fields that contain =
identity
assertions, including any fields outside =
of SDP that are used, such as the SIP
Identity =
header field {{?SIP-ID}}.=C2=A0 A controller that follows the best =
practices
in RFC 3725 is expected to forward the =
necessary information contained in SDP,
such as the =
WebRTC `identity` attribute, thus ensuring the necessary =
information
is =
present.
 
"To =
perform the checks in {{external_session_id}}, a 3PCC system needs to =
ensure
that guarantee that peers use the same SDP =
`tls-id` attribute value.=C2=A0 A
controller that =
follows the best practices in RFC 3725 will produce SDP =
with
consistent `tls-id` values, but other forms of =
modification might =
not.
 
"It is =
understood that this technique will prevent the use of 3PCC if peers =
have
different views of the involved identities, or =
the value of SDP =
`tls-id`
attributes."
 

The text is = clearer, but I still don't follow. If I understand RFC 8224 correctly, = authenticated identity is only defined for SIP requests, however all = four 3PCC flows in RFC 3725 have the controller generate the SIP INVITE, = so how do the endpoints exchange authenticated identity information ? = 



=C2=A0The text reads =
well, but I'm still left with the same =
question:
 
 Section 3.1, =
second paragraph says there are two separate sessions (I =

take that to mean SIP sessions). It then goes on =
to say 
 
 "In the =
first session, Patsy is presented with the option to =

communicate with Norma =
"
 
 If I understand =
correctly, this means there is a SIP INVITE sent by =

Mallory to Patsy, however Mallory somehow asserts =
Norma's identity to 
Patsy. How is Mallory able to =
do that if we are using SIP Authenticated 
Identity =
? I'm not sure if the above would be cleare if the flow was =

expanded to show INVITE and 200-OK. =

 
Yeah, I =
really want to avoid adding all the SIP stuff here.=C2=A0 There would be =
lots of irrelevant messages involved and it distracts from the =
message.
 
The key =
insight here is that SIP identity only certifies a small number of =
fields and that the rest of the session is open to be modified by the =
signaling server.=C2=A0 RFC 8225 only covers the identity (sip:norma@example or tel:+12345556789) and the a=3Dfingerprint =
values, everything else is open to attack.=C2=A0 So if we allow Mallory =
the ability to modify signaling, there is a lot she can do.=C2=A0 In =
practice however, this doesn't require much of an attack on the session, =
other than (maybe) to substitute transport =
parameters.
 
>From =
the perspective of SIP and SIP identity, these are largely legitimate =
sessions.=C2=A0 The attack on signaling is necessary only to the extent =
that the attack also depends on =

 
I've added more text =
here, realizing that it was a little light.=C2=A0 This is the updated =
section in =
full:
 
"The attack =
requires that Mallory obtain an identity binding for her own =
identity
with the fingerprints presented by Patsy =
(P).=C2=A0 This false binding is then
presented to =
Norma (Signaling1 in the figure).

You mean Signaling2 in the figure (below), right ? =


     = Norma           &n= bsp;       = Mallory           =         Patsy
     = (fp=3DN)           = ;        = -----           &n= bsp;        = (fp=3DP)
       = |            =             = |            =             = |
       = |            =             = |<---- Signaling1 = ------>|
       = |            =             = |   Norma=3DN Patsy=3DP      = |
       |<---- Signaling2 = ------>|          &n= bsp;           &nb= sp; |
       |   = Norma=3DN Mallory=3DP    = |            =             = |
       = |            =             &= nbsp;           &n= bsp;            = |
       = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DDTLS = (fp=3DN,P)=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|       = |            =             &= nbsp;           &n= bsp;            = |
     (peer =3D = Mallory!)          &nbs= p;            = ;  (peer =3D = Norma)

        &n= bsp;      Figure 1: Example Attack on Identity = Bindings



 
 
"Patsy could be similarly duped, =
but in this example, a correct binding =
between
Norma's identity and fingerprint (N) is =
faithfully presented by Mallory.=C2=A0 This
session =
(Signaling2 in the figure) can be entirely =
legitimate.

Signaling1 = ? 


 
"A DTLS session is established directly between Norma and =
Patsy.=C2=A0 In order for
this to happen Mallory =
can substitute transport-level information in =
both
sessions to facilitate this, though this is =
not necessary if Mallory is on the
network path =
between Norma and =
Patsy.
 
"As a =
result, Patsy correctly believes that she is communicating with =
Norma.

I don't follow = the above sentence (just like I don't follow the sentence I referenced = originally, i.e. "In the first session, Patsy is presented with the = option to communicate with Norma".

If we double-click on = "Signaling1", then I believe we start = with:

    INVITE(From: Mallory, To: Patsy, = Fingerprint:Norma, Identity:{From:Mallory, = Fingerprint:Norma})

Implicit in the sentence above is an = assumption that *Mallory* is somehow able to generate an INVITE to Patsy = with an Identity header that authenticates *Norma* as the originator, = i.e.:

    INVITE(From: Norma, To: Patsy, = Fingerprint:Norma, Identity:{From:Norma, Fingerprint:Norma})

How = is that possible ? What am I missing here ? = 


 
However, Norma incorrectly believes she is talking to =
Mallory."

This = part I understand. 


 
There is one last thing that I realized while writing up those =
changes, and that is that the text was a little vague about the =
relationship between the attacks.=C2=A0 I'll send another email with a =
proposed clarification, because I think that's important enough not to =
hide.

Ok - thanks =

-- Flemming 


 
_______________________________________________
mmusic mailing list
mmusic@ietf.org
=
https://www.ietf.or=
g/mailman/listinfo/mmusic
..
 

 

------=_NextPart_001_009F_01D4E8A8.3C76B7B0-- ------=_NextPart_000_009E_01D4E8A8.3C76B7B0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVXjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF7zCCA9egAwIBAgIQ f/Mn4/Qs3Qmdp7lrbBs+RzANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTA3 MDc0MTEyWhcNMjAxMTA3MDc0MTExWjBgMREwDwYDVQQKDAhFcmljc3NvbjESMBAGA1UEAwwJQm8g QnVybWFuMSUwIwYJKoZIhvcNAQkBFhZiby5idXJtYW5AZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdl cmFiYnVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsc7/WHPCPFn8MtdlAsXwPnl7 w0tSyOiso36JZ2OOE6Ztn7+8EmlhFZXV4ThcCyeJOZJG1CM8yIfs3k74gqyblT51tF89wOBarJVi HQtcf9Jvp4OoYuhRqRda9hUeI8Z4tfqnXQ2OppGecD71Bg4nmovTzsEy3JM7Cd5A7foSGjdoDG5y szolpQxx/+CJdYF9B2EfVgahCF8MYKCQhW40EaTJFPQm4/uZIQZPbxFw8PgpEIDV/IhG7izKr3gH n/MNqtCD1yK+itPAlB7ZRAyhBR3qV/qpXU82koT8byMATE7iqmGZnx1k7XwbPE9rdli2cpTMVZ9y R3nYSL3dnG09lwIDAQABo4IBvDCCAbgwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVz dC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0 MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxo dHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5j ZXIwIQYDVR0RBBowGIEWYm8uYnVybWFuQGVyaWNzc29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQB gg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25l cmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFOqTTQsD K500lkyW3F7vkHyeBQtoMB8GA1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB /wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEAy+psdt+fJhnRrYmmLqFMtDDk9CFzkdfjEQFRBNaz KnIQmBKXGN7UevdGKMgZXjxvO1JljkvjfbPov7IycBac/6y6+kp4hHtkP6/hdPPADxFb2X5/58Wg c4lWPTCvi8mn+bRtyrH9VAT03M7qIVMOpuq+OTzWVaRZphUT9mDamtcBjsX9UfQ5UsKpFb7Pt8eP ZQf77LNHv0neNir7irCWgXdYHOksTzN0rCQG7YVyXWTaddlLiBvi2O18fsT3FgopnHhdv4HBG4LH FtAjqs3PW9W4NhxgEH/1H+U7exFe9+6ZoTaN4D209Jt05Eq74hZSa39Wfnwg+tlr9c62RJ+z97ek PDpenOo4SV0V4fL4O5d5cjdsFNIpXrrPt0pc5sXsYOTuIvsEgkdDDFP5Ezwu1IgMcX8RTvsEXai/ OIeEMq7lIzJ+h9/gd9rIn9dV4oYaY9X5u9M220+GCb0jcfWeBuQN4+2lbgevqRjU43Oa/cXYGCrQ vDfdEqT09xMvxM/X1f8HXLw/ikyYlWf0QD4vJ8vE/fVi4NnjASUB8Uge/5daZE/Bg3axh2oywVGW z8Ecx57ACKhaUUQ16B/Eq6WFalse9yoBP3pKkzkmWOAoLNPnko9TBZD1pQ1Z59AleTT6BmqKThzl i58mANeLPJQ4JYxpopY6uun7xQZ2LADRi3gwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7Ljr MA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNv bmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UE BhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFs IENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PB qjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOw mZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/ JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSg Ie8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpy aRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvo TvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZ xf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQ of5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2 hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggr BgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNv bTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3Rl bGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYI KwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAf BgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWM O7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Ha n1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pj WxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVt Lcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8 Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2 PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHe P+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B 8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M 5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC /gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQf/Mn4/Qs3Qmdp7lrbBs+RzAJBgUrDgMCGgUAoIIBfDAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTA0MDExNDMwMzZaMCMG CSqGSIb3DQEJBDEWBBSUmUwHgwFMbidYmzQ5KHYZd9gTzjBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3 EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQf/Mn4/Qs3Qmdp7lrbBs+RzBsBgsqhkiG9w0BCRACCzFd oFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBO TCBJbmRpdmlkdWFsIENBIHYzAhB/8yfj9CzdCZ2nuWtsGz5HMA0GCSqGSIb3DQEBAQUABIIBACCF KgJ6QX+/Phzuf10uZx9IaXLxcfpN6dUK+vnyL0Qs2CwVJn1wuQrJzQAvIfGEAW4G+pyA+XH1v4jV eIVQT7gtikzxiVDpw1zEwf6Bqta4FZ1/lb6R3mPZzxFT2RG7QMpKUclQul69GgGAmf+DvQKTW7U3 7dzwEf0XZInr4l8zU8blPJs1E3piL/VpcfmUuSbdcwLKaOJwV8x/CExKIJETIkCLO71RNEYOYDlN dwN/2KvKPgR2v7uwC39CC7fV864Xqn/QpZ4FfqY3j2ipmTX7V2mKkP91+YD3zNGOjEAGF+ri4krM iwk2GADeLBhyEksqOq0u9yB+mFxjnNWtwYAAAAAAAAA= ------=_NextPart_000_009E_01D4E8A8.3C76B7B0-- From nobody Tue Apr 2 14:26:48 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 130EC1202FA for ; Tue, 2 Apr 2019 14:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 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, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJjezI8-a5Q1 for ; Tue, 2 Apr 2019 14:26:44 -0700 (PDT) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1D21202E6 for ; Tue, 2 Apr 2019 14:26:44 -0700 (PDT) Received: by mail-pf1-x432.google.com with SMTP id i17so7009447pfo.6 for ; Tue, 02 Apr 2019 14:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EzxR8mmz6KhM21WUIHxpdKh+KV7LZamNVr4Iab6V+pU=; b=cugAADdhtWwOGszjeKq2ULz75fx2Z8dYbz4qcHJoK50ivw6u81kEUBQZvEgqRcF42z dEY+pw/cBZRdlb3JoaK0lgKf3sjpGwhQwNZ328b90llx7S76VMabyd8Nf8ROJOrLJMn7 mYJ7s04+ZoUYaRA1UKh6k7l9+1z+GDwX4M5Y0bgUM7ewy9P9cpUXtou8Th5mDL+dReyH DATNSL0SuJN4hWtk7kxpgefBpf1N4A6FqqP20pYbDdTb36clPI1JhualFG4xMrrk8O8K UZr8ZWjEQBHJBRhotfCz+xHGdFcbnrpa85wcxUD/x/GzP8AvRofzPOC4ctYMRL36rGzV DLPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EzxR8mmz6KhM21WUIHxpdKh+KV7LZamNVr4Iab6V+pU=; b=Z9UrxCClcK5Ck1TtfX2uLLxUUuFQ4syErkp8wD3o/W6SyZdlscfBjkGLh7cuy/nF96 DoeP6y3GMFezXjzBYU7sFSutgx123/mYpbDfoF2oWw5wEdyGPyRqqrIGib3tUL9a/EVs KpQM+v/cUDyJZqvR9XvvCDk7W5PFDvsebTiYevXnzyduZVJOqTmIFoCxd1Lbm7A8/Z18 jFzoogcSvsvUeDJFHbTRMKzs3ih3eLQu2jjUC26oMd0f/drsuCIwj8Me6Lf1i1wsltjk yon/ipZjAKJyDytiEnRwgB73GBPzk3YI4XNxThZSyXFkTsp0RDxysJcTUnX1S3NJe8pk 1T4A== X-Gm-Message-State: APjAAAXqxD41oU1UVH3XuX2zzMrWU7XLzEjsk202KH15dbYQwnFAzpiI StYiU+dAOe0VvmrRDJ6CU2y49yB1KFE= X-Google-Smtp-Source: APXvYqxk4KcdLxlNM702n+/NuRr8F13A5ZutCJuTIp0sniZ0Gev0yZvG2SG2t0lHGTIlj6fqolPEBw== X-Received: by 2002:a63:c204:: with SMTP id b4mr68326060pgd.335.1554240403127; Tue, 02 Apr 2019 14:26:43 -0700 (PDT) Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com. [209.85.210.169]) by smtp.gmail.com with ESMTPSA id y12sm37692942pgq.64.2019.04.02.14.26.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Apr 2019 14:26:42 -0700 (PDT) Received: by mail-pf1-f169.google.com with SMTP id z5so5984111pfn.3 for ; Tue, 02 Apr 2019 14:26:42 -0700 (PDT) X-Received: by 2002:a62:2a97:: with SMTP id q145mr72325643pfq.22.1554240402188; Tue, 02 Apr 2019 14:26:42 -0700 (PDT) MIME-Version: 1.0 References: <874l9ousuk.fsf@hobgoblin.ariadne.com> <24551658-0943-431C-B319-D74B5DC169B9@gmail.com> In-Reply-To: From: Roman Shpount Date: Tue, 2 Apr 2019 17:26:33 -0400 X-Gmail-Original-Message-ID: Message-ID: To: mmusic WG Cc: Justin Uberti , Christer Holmberg , Eric Rescorla Content-Type: multipart/alternative; boundary="0000000000001171d8058592cb0e" Archived-At: Subject: [MMUSIC] FQDN support in ice-sip-sdp X-BeenThere: mmusic@ietf.org 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: Tue, 02 Apr 2019 21:26:47 -0000 --0000000000001171d8058592cb0e Content-Type: text/plain; charset="UTF-8" Hi All, I have created a pull request to ice-sip-sdp ( https://github.com/suhasHere/ice-sip-sdp/pull/1), which among other things added back support for FQDN to ice-sip-sdp. In order to do this, I've done the following: 1. I have changed "IP address" to "connection address" throughout the document whenever address in c= line or ICE candidate attribute is mentioned. I hope this is not controversial since it matches ABNF. 2. I have changed the definition of Old: : :: is taken from RFC 4566 <>. It is the IP address of the candidate. When parsing this field, an agent can differentiate an IPv4 address and an IPv6 address by presence of a colon in its value -- the presence of a colon indicates IPv6. An agent MUST ignore candidate lines that include candidates with IP address versions that are not supported or recognized. New: : :: is taken from RFC 4566 <>. It is the IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and fully qualified domain names (FQDNs). When parsing this field, an agent can differentiate an IPv4 address and an IPv6 address by presence of a colon in its value - the presence of a colon indicates IPv6. An agent MUST ignore candidate lines that include candidates with IP address versions that are not supported or recognized. An IP address SHOULD be used, but an FQDN MAY be used in place of an IP address. In that case, when receiving an offer or answer containing an FQDN in an a=candidate attribute, the FQDN is looked up in the DNS first using both AAAA record (assuming the agent supports IPv6), and using an A record (assuming the agent supports IPv4). If, and only if, the DNS query returns only one IP address it is then used for the remainder of ICE processing. If DNS query returned more then one result, including situation where single IPv4 and single IPv6 results are returned, an agent MUST ignore the candidate. Handling of multiple DNS results for a candidate can be defined in the future specification. If candidate with FQDN is the default destination/candidate, the the "c=" address type MUST be set the IP address family for the FQDN DNS resolution result and the "c=" connection address MUST be set to FQDN. This change reflects what was discussed previously. I am, personally, less then happy with this change. My biggest issue is requirement for FQDN to resolve to a single address or be ignored. In practice, this is problematic when things like DNS64/NAT64 are used. When DNS64 is used, even when FQDN was supposed to only resolve to IPv4, AAAA will also return result which will point to the NAT64 gateway. Based on the current language, this will result in candidate being ignored even though it should work with either IPv4 or IPv6 address. Most immediately, this will mean FQDN resolving to IPv4 will be ignored on a lot of mobile networks. I have also added language that defines what is supposed to be placed in c= line when default candidate is an FQDN candidate. What happens when FQDN resolution result and address family in c= line do not match was not specified. To summarize, this no worse then RFC 5245, but still fairly messy. I see two possible ways to clean this up: a. Add a candidate extension which specifies candidate address type, something like addrtype which can be set to "inipv4" or "inipv6". If IP address is used and it does not match the addrtype candidate extension, this candidate is ignored. When FQDN is used, it is resolved using A DNS request when addrtype is inipv4 or not present and using AAAA DNS request when addrtype is inipv6. Address family in c= line, when FQDN is a default candidate must be IN IPV4 if addrtype is inipv4 or not present, and must be IP IPV6 if addrtype is inipv6 b. Specify that during ICE nomination all DNS resolution results for the candidate should be added as separate candidates to the candidate list. This is likely to cause more problems then option a. One of these problems that I see is priority values for these candidates. Candidate priorities should be different for all of them but only one value is specified in SDP candidate attribute. In order to simplify tracking changes, I will write different emails about other changes I've done in the pull request. I have also included people who shown previous interest in this topic. Please let me know if I need to cross post to rtcweb and ice WG. Thank you for your attention, _____________ Roman Shpount --0000000000001171d8058592cb0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,=

I have created a pull req= uest to ice-sip-sdp (https://github.com/suhasHere/ice-sip-sdp/pull/1), which among oth= er things added back support for FQDN to ice-sip-sdp.

In order to do this, I've done the followin= g:

1. I have changed "= ;IP address" to "connection address" throughout the document= whenever address in c=3D line or ICE candidate attribute is mentioned. I h= ope this is not controversial since it matches ABNF.
=
2. I have changed the definition of <connecti= on-address>=C2=A0

Old:<= /div>
<connection-address>: :: is taken from RFC = 4566 <<RFC4566>>.
It= is the IP address of the candidate. When parsing this field, an agent can = differentiate=C2=A0
an IPv4 addr= ess and an IPv6 address by presence of a colon in its value -- the presence= of=C2=A0
a colon indicates IPv6= . An agent MUST ignore candidate lines that include candidates with=C2=A0
IP address versions that are not = supported or recognized.

New:
<= div>
<connection-address>: :: is taken from RFC 45= 66 <<RFC4566>>.
It is the IP address of the candidate, allowing for IPv4 addresses, = IPv6 addresses, and fully
=
qualified domain names (FQDNs).=C2=A0 When parsing this field, an agen= t can differentiate=C2=A0
=
an IPv4 address and an IPv6 address by presence of a colon in its valu= e - the presence of a
colon indicates IPv6.=C2=A0 An agent MUST ignore candidate lines that incl= ude candidates with
I= P address versions that are not supported or recognized.=C2=A0 An IP addres= s SHOULD be used,
but= an FQDN MAY be used in place of an IP address.=C2=A0 In that case, when re= ceiving an
offer or a= nswer containing an FQDN in an a=3Dcandidate attribute, the FQDN is looked = up in
the DNS first u= sing both AAAA record (assuming the agent supports IPv6), and using an A
record (assuming the ag= ent supports IPv4). If, and only if, the DNS query returns=C2=A0
only one IP address it is then = used for the remainder of ICE processing. If DNS query
returned more then one result, including = situation where single IPv4 and single IPv6
results are returned, an agent MUST ignore the candi= date. Handling of multiple DNS
=
results for a candidate can be defined in the future specificatio= n. If candidate
with = FQDN <connection-address> is the default destination/candidate, the t= he "c=3D"
a= ddress type MUST be set the IP address family for the FQDN DNS resolution r= esult=C2=A0
and the &= quot;c=3D" connection address MUST be set to FQDN.
<= div>

This change reflects what was discussed p= reviously. I am, personally, less then happy with this change. My biggest i= ssue is requirement for FQDN to resolve to a single address or be ignored. = In practice, this is problematic when things like DNS64/NAT64 are used. Whe= n DNS64 is used, even when FQDN was supposed to only resolve to IPv4, AAAA = will also return result which will point to the NAT64 gateway. Based on the= current language, this will result in candidate being ignored even though = it should work with either IPv4 or IPv6 address. Most immediately, this wil= l mean FQDN resolving to IPv4 will be ignored on a lot of mobile networks.<= /div>

I have also added language that defines what is su= pposed to be placed in c=3D line when default candidate is an FQDN candidat= e. What happens when FQDN resolution result and address family in c=3D line= do not match was not specified.

To summarize, thi= s no worse then RFC 5245, but still fairly messy. I see two possible ways t= o clean this up:

a. Add a candidate extension whic= h specifies candidate address type, something like addrtype which can be se= t to "inipv4" or "inipv6". If IP address is used and it= does not match the addrtype candidate extension, this candidate is ignored= . When FQDN is used, it is resolved using A DNS request when addrtype is in= ipv4 or not present and using AAAA DNS request when addrtype is inipv6. Add= ress family in c=3D line, when FQDN is a default candidate must be IN IPV4 = if addrtype is inipv4 or not present, and must be IP IPV6 if addrtype is in= ipv6

b. Specify that during ICE nomination all DNS= resolution results for the candidate should be added as separate candidate= s to the candidate list. This is likely to cause more problems then option = a. One of these problems that I see is priority values for these candidates= . Candidate priorities should be different for all of them but only one val= ue is specified in SDP candidate attribute.

In ord= er to simplify tracking changes, I will write different emails about other = changes I've done in the pull request.

I have = also included people who shown previous interest in this topic. Please let = me know if I need to cross post to rtcweb and ice WG.

<= div>Thank you for your attention,
_____________
Roman Shpount
--0000000000001171d8058592cb0e-- From nobody Wed Apr 3 04:34:34 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B0C1200D6; Wed, 3 Apr 2019 04:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6x_1XJnAc-Q; Wed, 3 Apr 2019 04:34:29 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10080.outbound.protection.outlook.com [40.107.1.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4C041200D5; Wed, 3 Apr 2019 04:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LtqSlK/fBpm4hLl07M86YxrkW4pdABJSFpewCqgG3ec=; b=ZA1fkhvVVSTAKHyL0KFFkONIFXH3C//SdCzIOwUY9iO17qTqCkZ5rUh7sTRw88U3p+YUGIUCFvejn62YQn+Epf+ZAc11GctRjn8EG18urBidi4COaTVqKpKlbdh2gKEf7otBAj878m4RSnWsjH/zuO95wHun8/7t93mvTR/6olY= Received: from HE1PR07MB3259.eurprd07.prod.outlook.com (10.170.246.26) by HE1PR07MB4171.eurprd07.prod.outlook.com (20.176.166.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.6; Wed, 3 Apr 2019 11:34:25 +0000 Received: from HE1PR07MB3259.eurprd07.prod.outlook.com ([fe80::5ce7:e79c:91a5:5629]) by HE1PR07MB3259.eurprd07.prod.outlook.com ([fe80::5ce7:e79c:91a5:5629%6]) with mapi id 15.20.1771.011; Wed, 3 Apr 2019 11:34:25 +0000 From: Bo Burman To: "mmusic (mmusic@ietf.org)" CC: "mmusic-chairs@ietf.org" , "'draft-ietf-mmusic-msrp-usage-data-channel@ietf.org'" Thread-Topic: Re-adoption call for draft-ietf-mmusic-msrp-usage-data-channel Thread-Index: AdTqC9I1YycHtSl3SAauzLFz1SoKJw== Date: Wed, 3 Apr 2019 11:34:23 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bo.burman@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5c90cebe-21dc-45fb-780b-08d6b8285331 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(49563074)(7193020); SRVR:HE1PR07MB4171; x-ms-traffictypediagnostic: HE1PR07MB4171: x-microsoft-antispam-prvs: x-forefront-prvs: 0996D1900D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(396003)(136003)(366004)(199004)(189003)(86362001)(106356001)(478600001)(7736002)(74316002)(71200400001)(256004)(14444005)(53936002)(54906003)(97736004)(4744005)(486006)(71190400001)(7696005)(33656002)(6916009)(105586002)(102836004)(6506007)(476003)(44832011)(99936001)(52536014)(26005)(4326008)(186003)(55016002)(66066001)(81156014)(68736007)(25786009)(6116002)(3846002)(81166006)(790700001)(6306002)(54896002)(14454004)(9686003)(8936002)(2906002)(99286004)(450100002)(316002)(606006)(5660300002)(236005)(8676002)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4171; H:HE1PR07MB3259.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: aqJ390eXW5wXfXyZvmO5O319h97QwXxkKRZOcUvg0dtsU9LIQyn6tLWCv5ydCW6Qs+Qxa88k12NDq6YqyOyuhZ+RyfwqcP13BnKkbldoBWwQxgwANqDQpVpcncoCORGHZV/gvQW5wnC+cDYmll44/0G/h4Uni4v2woxeS6kjeRehTFo4YVqTZOBaaROro++asUiqXMrcc+xM02X0f4m5wsK34uc02il48mH07CdkkGNEPOuFV8a4wEcxsl9geMhEve3iMHnJ7Rauvh6WUEtOBMPJ26bPwp/fN4nRVuvGLgGuYSi/GP4yBGPaSFbuWGkqiDkt4WU1C0ZpX38TdWjZ+suqBpkwZjkuIqmfLmjwXFxpyFObeTOnq/k2vIggNULVOrFXxbFyRrERbuRTEwFcvKlZcKxi/GZp9oLa+N5OTI8= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0014_01D4EA21.F210BAB0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5c90cebe-21dc-45fb-780b-08d6b8285331 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2019 11:34:25.2156 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4171 Archived-At: Subject: [MMUSIC] Re-adoption call for draft-ietf-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org 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, 03 Apr 2019 11:34:33 -0000 ------=_NextPart_000_0014_01D4EA21.F210BAB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0015_01D4EA21.F210BAB0" ------=_NextPart_001_0015_01D4EA21.F210BAB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MMUSIC, This is a 1-week call to re-adopt "Submit SDP Negotiation of MSRP over Data Channels as Proposed Standard" as an MMUSIC WG milestone, reviving the expired draft-ietf-mmusic-msrp-usage-data-channel as document. We have received renewed interest in progressing this draft and a number of people have stated that they are willing to work on it. If you support that adoption, please respond to the list by Friday April 12, 23:59 UTC. If you oppose WG adoption, have comments, or concerns, please reply either to this thread or directly to the chairs/authors (if needed). Thanks, /Bo MMUSIC co-chair ------=_NextPart_001_0015_01D4EA21.F210BAB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MMUSIC,

 

This is a = 1-week call to re-adopt “Submit SDP Negotiation of MSRP over Data = Channels as Proposed Standard” as an MMUSIC WG milestone, reviving = the expired draft-ietf-mmusic-msrp-usage-data-channel as = document.

 

We have received renewed interest in progressing this = draft and a number of people have stated that they are willing to work = on it.

 

If you support that adoption, please respond to the = list by Friday April 12, 23:59 UTC. If you oppose WG adoption, have = comments, or concerns, please reply either to this thread or directly to = the chairs/authors (if needed).

 

Thanks,

/Bo

MMUSIC = co-chair

 

------=_NextPart_001_0015_01D4EA21.F210BAB0-- ------=_NextPart_000_0014_01D4EA21.F210BAB0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVXjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF7zCCA9egAwIBAgIQ f/Mn4/Qs3Qmdp7lrbBs+RzANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTA3 MDc0MTEyWhcNMjAxMTA3MDc0MTExWjBgMREwDwYDVQQKDAhFcmljc3NvbjESMBAGA1UEAwwJQm8g QnVybWFuMSUwIwYJKoZIhvcNAQkBFhZiby5idXJtYW5AZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdl cmFiYnVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsc7/WHPCPFn8MtdlAsXwPnl7 w0tSyOiso36JZ2OOE6Ztn7+8EmlhFZXV4ThcCyeJOZJG1CM8yIfs3k74gqyblT51tF89wOBarJVi HQtcf9Jvp4OoYuhRqRda9hUeI8Z4tfqnXQ2OppGecD71Bg4nmovTzsEy3JM7Cd5A7foSGjdoDG5y szolpQxx/+CJdYF9B2EfVgahCF8MYKCQhW40EaTJFPQm4/uZIQZPbxFw8PgpEIDV/IhG7izKr3gH n/MNqtCD1yK+itPAlB7ZRAyhBR3qV/qpXU82koT8byMATE7iqmGZnx1k7XwbPE9rdli2cpTMVZ9y R3nYSL3dnG09lwIDAQABo4IBvDCCAbgwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVz dC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0 MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxo dHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5j ZXIwIQYDVR0RBBowGIEWYm8uYnVybWFuQGVyaWNzc29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQB gg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25l cmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFOqTTQsD K500lkyW3F7vkHyeBQtoMB8GA1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB /wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEAy+psdt+fJhnRrYmmLqFMtDDk9CFzkdfjEQFRBNaz KnIQmBKXGN7UevdGKMgZXjxvO1JljkvjfbPov7IycBac/6y6+kp4hHtkP6/hdPPADxFb2X5/58Wg c4lWPTCvi8mn+bRtyrH9VAT03M7qIVMOpuq+OTzWVaRZphUT9mDamtcBjsX9UfQ5UsKpFb7Pt8eP ZQf77LNHv0neNir7irCWgXdYHOksTzN0rCQG7YVyXWTaddlLiBvi2O18fsT3FgopnHhdv4HBG4LH FtAjqs3PW9W4NhxgEH/1H+U7exFe9+6ZoTaN4D209Jt05Eq74hZSa39Wfnwg+tlr9c62RJ+z97ek PDpenOo4SV0V4fL4O5d5cjdsFNIpXrrPt0pc5sXsYOTuIvsEgkdDDFP5Ezwu1IgMcX8RTvsEXai/ OIeEMq7lIzJ+h9/gd9rIn9dV4oYaY9X5u9M220+GCb0jcfWeBuQN4+2lbgevqRjU43Oa/cXYGCrQ vDfdEqT09xMvxM/X1f8HXLw/ikyYlWf0QD4vJ8vE/fVi4NnjASUB8Uge/5daZE/Bg3axh2oywVGW z8Ecx57ACKhaUUQ16B/Eq6WFalse9yoBP3pKkzkmWOAoLNPnko9TBZD1pQ1Z59AleTT6BmqKThzl i58mANeLPJQ4JYxpopY6uun7xQZ2LADRi3gwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7Ljr MA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNv bmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UE BhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFs IENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PB qjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOw mZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/ JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSg Ie8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpy aRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvo TvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZ xf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQ of5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2 hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggr BgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNv bTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3Rl bGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYI KwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAf BgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWM O7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Ha n1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pj WxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVt Lcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8 Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2 PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHe P+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B 8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M 5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC /gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQf/Mn4/Qs3Qmdp7lrbBs+RzAJBgUrDgMCGgUAoIIBfDAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTA0MDMxMTM0MjFaMCMG CSqGSIb3DQEJBDEWBBQHnuvurFahJw/geoTP3TApPAMhFDBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3 EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQf/Mn4/Qs3Qmdp7lrbBs+RzBsBgsqhkiG9w0BCRACCzFd oFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBO TCBJbmRpdmlkdWFsIENBIHYzAhB/8yfj9CzdCZ2nuWtsGz5HMA0GCSqGSIb3DQEBAQUABIIBAAgr QsoxT7TSeuEiunk86QjJ2YcbgAfy1HZw8P0S9aQTnZ3AszWFe29XcjHQVBTCUovGSFZXqiy/qGLa RGXCbBNo5cXNY0WRdm3dtG39KvZS1N9zPJeZcGzDaZTSW1f6UNbVo6bwGVHDxDUTs1c9MJ1jbBtK ziR2t/MjX113k2w19phuYZUmC2wpBvUA3wPyq88j+GKmdrm52OVedvhkxRUv0YoemL2lP9dk5EWP f1/hpT9IdIypGlu4i3GubmagWyrRmoi9pU9IDEFV95yX/Ql9sYDuLl1o7Ao2iNgEjlHEcyyISUSW sMuuNR+lwKqZVX63+TY89cd4S1nZEfDNOIcAAAAAAAA= ------=_NextPart_000_0014_01D4EA21.F210BAB0-- From nobody Wed Apr 3 06:40:42 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D724C12008D for ; Wed, 3 Apr 2019 06:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbGFoZh4RDFH for ; Wed, 3 Apr 2019 06:40:39 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D1B4120003 for ; Wed, 3 Apr 2019 06:40:39 -0700 (PDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x33DeaLg003623 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 3 Apr 2019 09:40:37 -0400 To: mmusic@ietf.org References: From: Paul Kyzivat Message-ID: <16fa7d9b-3d21-c6a7-a675-dbc0cec18a43@alum.mit.edu> Date: Wed, 3 Apr 2019 09:40:35 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MMUSIC] Re-adoption call for draft-ietf-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org 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, 03 Apr 2019 13:40:41 -0000 I'm going to abstain on this because this ought to be about whether there is demand, and I don't know. I will review/comment if it is adopted. Thanks, Paul On 4/3/19 7:34 AM, Bo Burman wrote: > MMUSIC, > > This is a 1-week call to re-adopt “Submit SDP Negotiation of MSRP over > Data Channels as Proposed Standard” as an MMUSIC WG milestone, reviving > the expired draft-ietf-mmusic-msrp-usage-data-channel > > as document. > > We have received renewed interest in progressing this draft and a number > of people have stated that they are willing to work on it. > > If you support that adoption, please respond to the list by Friday April > 12, 23:59 UTC. If you oppose WG adoption, have comments, or concerns, > please reply either to this thread or directly to the chairs/authors (if > needed). > > Thanks, > > /Bo > > MMUSIC co-chair > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Wed Apr 3 09:10:06 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4713812017F; Wed, 3 Apr 2019 09:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiNhoOx55AHd; Wed, 3 Apr 2019 09:10:02 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on071d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0e::71d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A76A12017A; Wed, 3 Apr 2019 09:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lEvffcHb2pw0rqmwQHmtNHlraCEd25/1GXvZdti5rOQ=; b=FWGSsTg66/RJmHDrX5Rkv/HZewcgHdhn9llCAe81WIZ24cLc0iJhfgHmSGwt39D+REGHMuKsn27DgDI1Ad6Knc7KNz2S3PfCuGfnwOSrdQSJcl1DCji4aJxrBKHsepeFbN1CUscGPE2IIRM/xERghU9Ux9+1Q6A1xX3KT3oKW6M= Received: from DB7PR07MB5161.eurprd07.prod.outlook.com (20.178.43.27) by DB7PR07MB3900.eurprd07.prod.outlook.com (52.134.99.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.9; Wed, 3 Apr 2019 16:09:59 +0000 Received: from DB7PR07MB5161.eurprd07.prod.outlook.com ([fe80::2432:2149:2323:4f75]) by DB7PR07MB5161.eurprd07.prod.outlook.com ([fe80::2432:2149:2323:4f75%4]) with mapi id 15.20.1771.006; Wed, 3 Apr 2019 16:09:59 +0000 From: "Makaraju, Raju (Nokia - US/Naperville)" To: Bo Burman , "mmusic (mmusic@ietf.org)" CC: "mmusic-chairs@ietf.org" , "'draft-ietf-mmusic-msrp-usage-data-channel@ietf.org'" Thread-Topic: Re-adoption call for draft-ietf-mmusic-msrp-usage-data-channel Thread-Index: AdTqC9I1YycHtSl3SAauzLFz1SoKJwAK2vmg Date: Wed, 3 Apr 2019 16:09:40 +0000 Deferred-Delivery: Wed, 3 Apr 2019 16:09:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=raju.makaraju@nokia.com; x-originating-ip: [135.245.20.23] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4639226e-1039-4411-7f7c-08d6b84ed28a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DB7PR07MB3900; x-ms-traffictypediagnostic: DB7PR07MB3900: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0996D1900D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(366004)(136003)(39860400002)(199004)(189003)(54906003)(790700001)(81156014)(105586002)(476003)(11346002)(3846002)(2906002)(26005)(236005)(99286004)(81166006)(256004)(186003)(6116002)(102836004)(8936002)(76176011)(6506007)(14444005)(7696005)(53546011)(5660300002)(52536014)(7736002)(8676002)(74316002)(486006)(478600001)(86362001)(66066001)(14454004)(6666004)(71190400001)(446003)(229853002)(97736004)(33656002)(110136005)(606006)(6246003)(4326008)(54896002)(9686003)(53936002)(6306002)(55016002)(71200400001)(316002)(106356001)(25786009)(68736007)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB3900; H:DB7PR07MB5161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: IIBnLEQ+KRbgXTuEDXPv4sYzUN+gsXv2AxeinBvMHp1FJ01fPyCtKo3vvcq8DnnLhZDAg26av5B1anZQ0QmTGQ1CJDo6tA48+CgNvNvmxdrg09Eo3urZL1HUGxh9xA/joDZoGdaVGojazE1DUcpm1F2PwhR00q2aF9Xhi7xYjRip1XCTuQTH7yVB0Y0rJhUkrTBCUGsXxxmsgFdG0hU9Hp1ozha6WlVl54Atwc6TP7iDU4Ho8Pu5intsc5g+kKIPDU4hy1asZyX1VAaCf1iF4vTnaJGm0rexcFTY6lKNGGVxZT2WUJbnfPzBhsYErkxyrix8PPEZDq7mRDtcIKmaWNNy4sBciiSf1joHwREib6glJEln+aC8X7sZR9XOISR6MJlNXlcJe4LlrqHZ5pRPrzosStoL3oxIZLo905J03jc= Content-Type: multipart/alternative; boundary="_000_DB7PR07MB516117D89FE1F31FE9601E07FF570DB7PR07MB5161eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4639226e-1039-4411-7f7c-08d6b84ed28a X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2019 16:09:59.7494 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB3900 Archived-At: Subject: Re: [MMUSIC] Re-adoption call for draft-ietf-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org 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, 03 Apr 2019 16:10:05 -0000 --_000_DB7PR07MB516117D89FE1F31FE9601E07FF570DB7PR07MB5161eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am in the support of the adoption. I will contribute to the content of th= e draft, participate in discussions and provide necessary comments. Thanks Raju From: Bo Burman Sent: Wednesday, April 3, 2019 6:34 AM To: mmusic (mmusic@ietf.org) Cc: mmusic-chairs@ietf.org; 'draft-ietf-mmusic-msrp-usage-data-channel@ietf= .org' Subject: Re-adoption call for draft-ietf-mmusic-msrp-usage-data-channel MMUSIC, This is a 1-week call to re-adopt "Submit SDP Negotiation of MSRP over Data= Channels as Proposed Standard" as an MMUSIC WG milestone, reviving the exp= ired draft-ietf-mmusic-msrp-usage-data-channel as document. We have received renewed interest in progressing this draft and a number of= people have stated that they are willing to work on it. If you support that adoption, please respond to the list by Friday April 12= , 23:59 UTC. If you oppose WG adoption, have comments, or concerns, please = reply either to this thread or directly to the chairs/authors (if needed). Thanks, /Bo MMUSIC co-chair --_000_DB7PR07MB516117D89FE1F31FE9601E07FF570DB7PR07MB5161eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am in the support of the adoption. I will contribu= te to the content of the draft, participate in discussions and provide nece= ssary comments.

 

Thanks

Raju

 

From: Bo Burman <bo.burman@ericsson.com>= ;
Sent: Wednesday, April 3, 2019 6:34 AM
To: mmusic (mmusic@ietf.org) <mmusic@ietf.org>
Cc: mmusic-chairs@ietf.org; 'draft-ietf-mmusic-msrp-usage-data-chann= el@ietf.org' <draft-ietf-mmusic-msrp-usage-data-channel@ietf.org>
Subject: Re-adoption call for draft-ietf-mmusic-msrp-usage-data-chan= nel

 

MMUSIC,

 

This is a 1-week call to re-adopt “Submit SDP = Negotiation of MSRP over Data Channels as Proposed Standard” as an MM= USIC WG milestone, reviving the expired draft-ietf-mmusic-msrp-usage-data-channel as document.

 

We have received renewed interest in progressing thi= s draft and a number of people have stated that they are willing to work on= it.

 

If you support that adoption, please respond to the = list by Friday April 12, 23:59 UTC. If you oppose WG adoption, have comment= s, or concerns, please reply either to this thread or directly to the chair= s/authors (if needed).

 

Thanks,

/Bo

MMUSIC co-chair

 

--_000_DB7PR07MB516117D89FE1F31FE9601E07FF570DB7PR07MB5161eurp_-- From nobody Wed Apr 3 09:47:15 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB54120094 for ; Wed, 3 Apr 2019 09:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 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, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbeONjDwqY_G for ; Wed, 3 Apr 2019 09:47:10 -0700 (PDT) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07CAE120046 for ; Wed, 3 Apr 2019 09:47:10 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id w23so5373658ply.4 for ; Wed, 03 Apr 2019 09:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=NuUC82/O29pGtWUvBLfq2KbKeDtn+53yNiWTnxCcF5E=; b=JO8UL2iTRZr4DpSHduhCstMdi9Nxbja1QWfuPb8RS++w93p1x1YZ5JmRvvhG2omSl4 DLI72smd1i3N7Rhb2QFt1XjrO1fFGDE12Lcz/Y/gcedGWZjr5rlcC4rQq4GNg45wGUaL UKbEU+9NusVtpeOrDnxxT7HEVmazSzvvA61ktI4EdtRZnkpbMry9Awgtxe/mNt09dQo+ Lhk2SNHHL5yrTS5Tcr4lGK5VkUlbMm+MAe1kOlbW1uWAmknIEgLArXGxosv4Tz/Ek5w+ 6TOn4fBjXJeE9JH3ypnoguWE+09/jP7HsNKdoz+u5a89vagvdIp1jWdPTBOutSKqeDZw ulZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=NuUC82/O29pGtWUvBLfq2KbKeDtn+53yNiWTnxCcF5E=; b=WrX8b/lVv4CESPH29zjZoxTVVxfT0eD+5XFtWJ7tJ6Dft8dHxng91MD9u517CGYoN9 ahIgC5PSa6Y+rpYmfAzg5SdXQExYZ6eyW5nCN9Kn0AJS8oCnZpwILgrGmoOh2EO8g9RN OpQVC4ZXADBt480MMuvkcJxs673L2nDOyBNbkPDnRcBmRjvRokaA565rSryBnzuZJogJ b2y8MgxwnCOnuT0YmwGIqPMGqoviCxLPG2nkAMS5nMwrOy/24uGmWMcIlvR4nvKNY5y6 uJNNld4m0W7ffMv4Rv47rYN1aY9RSVx2E7pd5Hx5L9ZoV5M7fW+KudHuPiIeJQq7FSo4 10QA== X-Gm-Message-State: APjAAAXCK1l+CexGh6E7kTGN8Yqjm6b+oSUweX2Q2BVz+Xrc5kB09WG4 z6SsI6DOX8HLQF4u+PXoVINnswKV7aE= X-Google-Smtp-Source: APXvYqy9qC4Ozd3vf/Xexk4seKtGkgwguVXq1kbi7D+C1Wsak51d4367AemlpgVQuraKl0FCig2KzA== X-Received: by 2002:a17:902:28a7:: with SMTP id f36mr905706plb.169.1554310029191; Wed, 03 Apr 2019 09:47:09 -0700 (PDT) Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com. [209.85.210.177]) by smtp.gmail.com with ESMTPSA id x8sm5408292pgp.48.2019.04.03.09.47.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Apr 2019 09:47:08 -0700 (PDT) Received: by mail-pf1-f177.google.com with SMTP id c207so8438327pfc.7 for ; Wed, 03 Apr 2019 09:47:08 -0700 (PDT) X-Received: by 2002:a62:ab12:: with SMTP id p18mr431199pff.216.1554310027830; Wed, 03 Apr 2019 09:47:07 -0700 (PDT) MIME-Version: 1.0 From: Roman Shpount Date: Wed, 3 Apr 2019 12:46:59 -0400 X-Gmail-Original-Message-ID: Message-ID: To: mmusic WG Cc: Justin Uberti , Christer Holmberg , Eric Rescorla , Flemming Andreasen Content-Type: multipart/alternative; boundary="0000000000001469e20585a3010e" Archived-At: Subject: [MMUSIC] FQDN support in ice-sip-sdp X-BeenThere: mmusic@ietf.org 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, 03 Apr 2019 16:47:13 -0000 --0000000000001469e20585a3010e Content-Type: text/plain; charset="UTF-8" Reposting er Flemming's advise as a new thread: Hi All, I have created a pull request to ice-sip-sdp ( https://github.com/suhasHere/ice-sip-sdp/pull/1), which among other things added back support for FQDN to ice-sip-sdp. In order to do this, I've done the following: 1. I have changed "IP address" to "connection address" throughout the document whenever address in c= line or ICE candidate attribute is mentioned. I hope this is not controversial since it matches ABNF. 2. I have changed the definition of Old: : :: is taken from RFC 4566 <>. It is the IP address of the candidate. When parsing this field, an agent can differentiate an IPv4 address and an IPv6 address by presence of a colon in its value -- the presence of a colon indicates IPv6. An agent MUST ignore candidate lines that include candidates with IP address versions that are not supported or recognized. New: : :: is taken from RFC 4566 <>. It is the IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and fully qualified domain names (FQDNs). When parsing this field, an agent can differentiate an IPv4 address and an IPv6 address by presence of a colon in its value - the presence of a colon indicates IPv6. An agent MUST ignore candidate lines that include candidates with IP address versions that are not supported or recognized. An IP address SHOULD be used, but an FQDN MAY be used in place of an IP address. In that case, when receiving an offer or answer containing an FQDN in an a=candidate attribute, the FQDN is looked up in the DNS first using both AAAA record (assuming the agent supports IPv6), and using an A record (assuming the agent supports IPv4). If, and only if, the DNS query returns only one IP address it is then used for the remainder of ICE processing. If DNS query returned more then one result, including situation where single IPv4 and single IPv6 results are returned, an agent MUST ignore the candidate. Handling of multiple DNS results for a candidate can be defined in the future specification. If candidate with FQDN is the default destination/candidate, the the "c=" address type MUST be set the IP address family for the FQDN DNS resolution result and the "c=" connection address MUST be set to FQDN. This change reflects what was discussed previously. I am, personally, less then happy with this change. My biggest issue is requirement for FQDN to resolve to a single address or be ignored. In practice, this is problematic when things like DNS64/NAT64 are used. When DNS64 is used, even when FQDN was supposed to only resolve to IPv4, AAAA will also return result which will point to the NAT64 gateway. Based on the current language, this will result in candidate being ignored even though it should work with either IPv4 or IPv6 address. Most immediately, this will mean FQDN resolving to IPv4 will be ignored on a lot of mobile networks. I have also added language that defines what is supposed to be placed in c= line when default candidate is an FQDN candidate. What happens when FQDN resolution result and address family in c= line do not match was not specified. To summarize, this no worse then RFC 5245, but still fairly messy. I see two possible ways to clean this up: a. Add a candidate extension which specifies candidate address type, something like addrtype which can be set to "inipv4" or "inipv6". If IP address is used and it does not match the addrtype candidate extension, this candidate is ignored. When FQDN is used, it is resolved using A DNS request when addrtype is inipv4 or not present and using AAAA DNS request when addrtype is inipv6. Address family in c= line, when FQDN is a default candidate must be IN IPV4 if addrtype is inipv4 or not present, and must be IP IPV6 if addrtype is inipv6 b. Specify that during ICE nomination all DNS resolution results for the candidate should be added as separate candidates to the candidate list. This is likely to cause more problems then option a. One of these problems that I see is priority values for these candidates. Candidate priorities should be different for all of them but only one value is specified in SDP candidate attribute. In order to simplify tracking changes, I will write different emails about other changes I've done in the pull request. I have also included people who shown previous interest in this topic. Please let me know if I need to cross post to rtcweb and ice WG. Thank you for your attention, _____________ Roman Shpount --0000000000001469e20585a3010e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Reposting er Flemming's advise as a new thread:
<= div dir=3D"ltr">Hi All,

I = have created a pull request to ice-sip-sdp (https://github.com/suhasHere= /ice-sip-sdp/pull/1), which among other things added back support for F= QDN to ice-sip-sdp.

In ord= er to do this, I've done the following:

1. I have changed "IP address" to "connect= ion address" throughout the document whenever address in c=3D line or = ICE candidate attribute is mentioned. I hope this is not controversial sinc= e it matches ABNF.

2. I ha= ve changed the definition of <connection-address>=C2=A0

Old:
=
<connection-address>: :: is taken from RFC 4566 <&l= t;RFC4566>>.
It is the IP = address of the candidate. When parsing this field, an agent can differentia= te=C2=A0
an IPv4 address and an = IPv6 address by presence of a colon in its value -- the presence of=C2=A0
a colon indicates IPv6. An agent = MUST ignore candidate lines that include candidates with=C2=A0
<= /div>
IP address versions that are not supported o= r recognized.

Ne= w:
<connecti= on-address>: :: is taken from RFC 4566 <<RFC4566>>.
It is the IP address of the c= andidate, allowing for IPv4 addresses, IPv6 addresses, and fully
qualified domain names (FQDNs).= =C2=A0 When parsing this field, an agent can differentiate=C2=A0
an IPv4 address and an IPv6 add= ress by presence of a colon in its value - the presence of a
colon indicates IPv6.=C2=A0 An agen= t MUST ignore candidate lines that include candidates with
IP address versions that are not supp= orted or recognized.=C2=A0 An IP address SHOULD be used,
<= /div>
but an FQDN MAY be used in place of an = IP address.=C2=A0 In that case, when receiving an
offer or answer containing an FQDN in an a=3Dc= andidate attribute, the FQDN is looked up in
<= div>
the DNS first using both AAAA record (assuming the = agent supports IPv6), and using an A
record (assuming the agent supports IPv4). If, and only if,= the DNS query returns=C2=A0
only one IP address it is then used for the remainder of ICE proces= sing. If DNS query
re= turned more then one result, including situation where single IPv4 and sing= le IPv6
results are r= eturned, an agent MUST ignore the candidate. Handling of multiple DNS
=
results for a candidate ca= n be defined in the future specification. If candidate
with FQDN <connection-address> is t= he default destination/candidate, the the "c=3D"
address type MUST be set the IP addre= ss family for the FQDN DNS resolution result=C2=A0
<= /div>
and the "c=3D" connection address M= UST be set to FQDN.

<= /div>

This change reflects what was discussed previously= . I am, personally, less then happy with this change. My biggest issue is r= equirement for FQDN to resolve to a single address or be ignored. In practi= ce, this is problematic when things like DNS64/NAT64 are used. When DNS64 i= s used, even when FQDN was supposed to only resolve to IPv4, AAAA will also= return result which will point to the NAT64 gateway. Based on the current = language, this will result in candidate being ignored even though it should= work with either IPv4 or IPv6 address. Most immediately, this will mean FQ= DN resolving to IPv4 will be ignored on a lot of mobile networks.

I have also added language that defines what is supposed to= be placed in c=3D line when default candidate is an FQDN candidate. What h= appens when FQDN resolution result and address family in c=3D line do not m= atch was not specified.

To summarize, this no wors= e then RFC 5245, but still fairly messy. I see two possible ways to clean t= his up:

a. Add a candidate extension which specifi= es candidate address type, something like addrtype which can be set to &quo= t;inipv4" or "inipv6". If IP address is used and it does not= match the addrtype candidate extension, this candidate is ignored. When FQ= DN is used, it is resolved using A DNS request when addrtype is inipv4 or n= ot present and using AAAA DNS request when addrtype is inipv6. Address fami= ly in c=3D line, when FQDN is a default candidate must be IN IPV4 if addrty= pe is inipv4 or not present, and must be IP IPV6 if addrtype is inipv6

b. Specify that during ICE nomination all DNS resoluti= on results for the candidate should be added as separate candidates to the = candidate list. This is likely to cause more problems then option a. One of= these problems that I see is priority values for these candidates. Candida= te priorities should be different for all of them but only one value is spe= cified in SDP candidate attribute.

In order to sim= plify tracking changes, I will write different emails about other changes I= 've done in the pull request.

I have also incl= uded people who shown previous interest in this topic. Please let me know i= f I need to cross post to rtcweb and ice WG.

Thank= you for your attention,
_____________
Ro= man Shpount
--0000000000001469e20585a3010e-- From nobody Wed Apr 3 10:41:05 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8A1120152 for ; Wed, 3 Apr 2019 10:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awsPeomZ0IUI for ; Wed, 3 Apr 2019 10:41:02 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on0716.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0e::716]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB7271205D0 for ; Wed, 3 Apr 2019 10:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Tp4kfnOK8+P+ethWf94yvjTuuTkBbpaY2A1P1lStNig=; b=Rdc1lCNRysQo0Ulivi8wXpdckPvTzYR3we4BwelPNzoHxVoLKHFMLwWNVmpq3Kp/tEl/pisLvzGLfCyo2Yfzre5AgPovMWubpRR8Q1EeZ+Wi9VURW2PU+jxCW6HKJ3vfHK0nb3NgP5bo2V5VhRKzesd7drNazO/4m72aXLC1o5k= Received: from DB7PR07MB5178.eurprd07.prod.outlook.com (20.178.43.76) by DB7PR07MB5894.eurprd07.prod.outlook.com (20.177.194.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.6; Wed, 3 Apr 2019 17:40:58 +0000 Received: from DB7PR07MB5178.eurprd07.prod.outlook.com ([fe80::4c2a:3e02:723d:aa6b]) by DB7PR07MB5178.eurprd07.prod.outlook.com ([fe80::4c2a:3e02:723d:aa6b%3]) with mapi id 15.20.1771.006; Wed, 3 Apr 2019 17:40:58 +0000 From: "Gonzalez, Gene (Nokia - US/Naperville)" To: "mmusic@ietf.org" , Bo Burman CC: "Gonzalez, Gene (Nokia - US/Naperville)" Thread-Topic: [MMUSIC] Re-adoption call for draft-ietf-mmusic-msrp-usage-data-channel Thread-Index: AdTqRGQ1jdDyEs1cQNy3VRdee0NjDA== Date: Wed, 3 Apr 2019 17:40:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gene.gonzalez@nokia.com; x-originating-ip: [135.245.20.21] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7dfafae0-d0de-4623-11a1-08d6b85b8818 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:DB7PR07MB5894; x-ms-traffictypediagnostic: DB7PR07MB5894: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0996D1900D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(136003)(346002)(39860400002)(366004)(189003)(199004)(6246003)(71190400001)(71200400001)(53936002)(52536014)(5660300002)(107886003)(256004)(14444005)(7696005)(6306002)(55016002)(9686003)(106356001)(74316002)(478600001)(305945005)(105586002)(2501003)(7736002)(66066001)(4326008)(97736004)(14454004)(102836004)(33656002)(8676002)(99286004)(25786009)(186003)(6506007)(26005)(6436002)(229853002)(8936002)(81166006)(110136005)(81156014)(86362001)(316002)(68736007)(3846002)(6116002)(2906002)(486006)(476003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB5894; H:DB7PR07MB5178.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: R+Oe7cl3WRuXwJqDmlW2HtCDIlrir/adkefQc25coSu/J3YOVcNbVshk1QZUCQeNiyYbyapBrR5y2pWxL0fyVylXNxT4CEZOR7CwZaAcJSoVcdTiPl+pF8ocmMK8oWkwAXD1lemWvc0bvuPuxWGg4I+6AmVbWJ2spW+WSIAvCMLMhhZLcn/yyicH/qYKBuK+Qdq5wL0pVvqZ8buIyMxgRqrwVo+6ZiKxtVe0uR3tsh5Mvd8isPEqcovkgEOzobIs37US/FoHNOjvoDgOYz0T5CTxT74pSWABnxOSBU8z/e16vLA8WTWVs85OOWlZaxXGT7xadPhs6SsS7vdUkxCQbBUq1euLtlDXcEmFksXopGkheLVj+ybTvbXQrRSWzlo01KK/2/upyvdA9KYF53PnlfrVFIcCZvb3QlGdsWY/PgI= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7dfafae0-d0de-4623-11a1-08d6b85b8818 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2019 17:40:58.3166 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5894 Archived-At: Subject: Re: [MMUSIC] Re-adoption call for draft-ietf-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org 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, 03 Apr 2019 17:41:04 -0000 I support the adoption of this draft and I am willing to review, participat= e in discussions, and help to provide content as necessary. Best regards, Gene ------------------------------ Message: 2 Date: Wed, 3 Apr 2019 11:34:23 +0000 From: Bo Burman To: "mmusic (mmusic@ietf.org)" Cc: "mmusic-chairs@ietf.org" , "'draft-ietf-mmusic-msrp-usage-data-channel@ietf.org'" Subject: [MMUSIC] Re-adoption call for draft-ietf-mmusic-msrp-usage-data-channel MMUSIC, This is a 1-week call to re-adopt "Submit SDP Negotiation of MSRP over Data Channels as Proposed Standard" as an MMUSIC WG milestone, reviving the expired draft-ietf-mmusic-msrp-usage-data-channel as document. We have received renewed interest in progressing this draft and a number of people have stated that they are willing to work on it. If you support that adoption, please respond to the list by Friday April 12= , 23:59 UTC. If you oppose WG adoption, have comments, or concerns, please reply either to this thread or directly to the chairs/authors (if needed). Thanks, /Bo MMUSIC co-chair From nobody Wed Apr 3 11:48:31 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB445120163 for ; Wed, 3 Apr 2019 11:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yH0iDa3szTO4 for ; Wed, 3 Apr 2019 11:48:27 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00051.outbound.protection.outlook.com [40.107.0.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 609AC12013F for ; Wed, 3 Apr 2019 11:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QlVNgnDPVmSKLzLnMfHmK4uJbSos1O6sTar4MzG8cgI=; b=F0hweuBwM6jk3WQziK0xvs/E8bx75OZhv8YJSDcIzvL8AJX4fCR32LAZm6NnWgpMulwABjvkAMeM2BWJKNGvc0IMbSEiDKlbDh80G5wI0aHb1tD1clkLq+HgxsXtag3sMB0RC6uzuvzHV9tB1MHojlpZHE1AxfLIZSPGSS+1YkA= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4330.eurprd07.prod.outlook.com (20.176.167.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.6; Wed, 3 Apr 2019 18:48:24 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9%5]) with mapi id 15.20.1771.007; Wed, 3 Apr 2019 18:48:24 +0000 From: Christer Holmberg To: "Gonzalez, Gene (Nokia - US/Naperville)" , "mmusic@ietf.org" , Bo Burman Thread-Topic: [MMUSIC] Re-adoption call for draft-ietf-mmusic-msrp-usage-data-channel Thread-Index: AdTqRGQ1jdDyEs1cQNy3VRdee0NjDAAIpF6A Date: Wed, 3 Apr 2019 18:48:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [178.55.143.91] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c05b5483-539e-464f-3adf-08d6b864f3a1 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB4330; x-ms-traffictypediagnostic: HE1PR07MB4330: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0996D1900D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(346002)(376002)(366004)(396003)(189003)(199004)(478600001)(97736004)(6486002)(14444005)(2616005)(966005)(86362001)(26005)(25786009)(68736007)(11346002)(476003)(229853002)(6512007)(36756003)(256004)(6436002)(53936002)(6306002)(44832011)(446003)(2501003)(6246003)(486006)(83716004)(106356001)(186003)(82746002)(105586002)(102836004)(110136005)(58126008)(14454004)(71200400001)(33656002)(66066001)(71190400001)(2906002)(8676002)(6506007)(6116002)(5660300002)(3846002)(8936002)(81156014)(81166006)(99286004)(76176011)(316002)(6636002)(7736002)(296002)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4330; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 1Yq53GlZ7ju291ceCDv3q7G9EMBZtBC3pkuC4tkfoXAfjTmn26H6NCgFtn/3GpAe0AMTiUZr2ctdU1n3ckQ2SHEmdELjvmcbmMKXnrdtVr9vajY1u+UMLHS3eIFu2uJENywq9ekJfI8TNXZ78lP24RI3cyav1STBGjnO7auBCfuV6qKsuPJgvHAwP1nluzGjrQ3XuL0yOkCub7xX6w4EQC4DTozpDs9NaWxnYngA0PSeHbGXGB1ZawkQJKw8qKAt76SYtcjnnlAQAyWrI8wQDJc64LulSZqCVXyACb/YiVpuAdG4lyFBQrovl1381kLLjLBEDxvjb788NHQbVAC6gUy2r5CZAyB30RrMBmUvxk8vdVcsjSzeIfQ99icg6JGnJtikr//fEUAf+jSaHP0vIcbkW92SWlZQfP92OioEWOc= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: c05b5483-539e-464f-3adf-08d6b864f3a1 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2019 18:48:24.2143 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4330 Archived-At: Subject: Re: [MMUSIC] Re-adoption call for draft-ietf-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org 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, 03 Apr 2019 18:48:30 -0000 SGksDQoNCkkgc3VwcG9ydCBnaXZpbmcgdGhlIGRyYWZ0IGEgc2Vjb25kIGNoYW5jZSwgYW5kIEkg d2lsbCByZXZpZXcgaXQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCu+7v09uIDAzLzA0LzIw MTksIDIwLjQxLCAibW11c2ljIG9uIGJlaGFsZiBvZiBHb256YWxleiwgR2VuZSAoTm9raWEgLSBV Uy9OYXBlcnZpbGxlKSIgPG1tdXNpYy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBnZW5l LmdvbnphbGV6QG5va2lhLmNvbT4gd3JvdGU6DQoNCiAgICBJIHN1cHBvcnQgdGhlIGFkb3B0aW9u IG9mIHRoaXMgZHJhZnQgYW5kIEkgYW0gd2lsbGluZyB0byByZXZpZXcsIHBhcnRpY2lwYXRlIGlu IGRpc2N1c3Npb25zLCBhbmQgaGVscCB0byBwcm92aWRlIGNvbnRlbnQgYXMgbmVjZXNzYXJ5Lg0K ICAgIA0KICAgIEJlc3QgcmVnYXJkcywNCiAgICBHZW5lDQogICAgDQogICAgLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQogICAgDQogICAgTWVzc2FnZTogMg0KICAgIERhdGU6IFdlZCwg MyBBcHIgMjAxOSAxMTozNDoyMyArMDAwMA0KICAgIEZyb206IEJvIEJ1cm1hbiA8Ym8uYnVybWFu QGVyaWNzc29uLmNvbT4NCiAgICBUbzogIm1tdXNpYyAobW11c2ljQGlldGYub3JnKSIgPG1tdXNp Y0BpZXRmLm9yZz4NCiAgICBDYzogIm1tdXNpYy1jaGFpcnNAaWV0Zi5vcmciIDxtbXVzaWMtY2hh aXJzQGlldGYub3JnPiwNCiAgICAJIidkcmFmdC1pZXRmLW1tdXNpYy1tc3JwLXVzYWdlLWRhdGEt Y2hhbm5lbEBpZXRmLm9yZyciDQogICAgCTxkcmFmdC1pZXRmLW1tdXNpYy1tc3JwLXVzYWdlLWRh dGEtY2hhbm5lbEBpZXRmLm9yZz4NCiAgICBTdWJqZWN0OiBbTU1VU0lDXSBSZS1hZG9wdGlvbiBj YWxsIGZvcg0KICAgIAlkcmFmdC1pZXRmLW1tdXNpYy1tc3JwLXVzYWdlLWRhdGEtY2hhbm5lbA0K ICAgIA0KICAgIE1NVVNJQywNCiAgICANCiAgICBUaGlzIGlzIGEgMS13ZWVrIGNhbGwgdG8gcmUt YWRvcHQgIlN1Ym1pdCBTRFAgTmVnb3RpYXRpb24gb2YgTVNSUCBvdmVyIERhdGENCiAgICBDaGFu bmVscyBhcyBQcm9wb3NlZCBTdGFuZGFyZCIgYXMgYW4gTU1VU0lDIFdHIG1pbGVzdG9uZSwgcmV2 aXZpbmcgdGhlDQogICAgZXhwaXJlZCBkcmFmdC1pZXRmLW1tdXNpYy1tc3JwLXVzYWdlLWRhdGEt Y2hhbm5lbA0KICAgIDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LW1tdXNpYy1tc3JwLXVzYWdlLWRhdGEtY2hhbm5lbC8NCiAgICA+ICBhcyBkb2N1bWVudC4NCiAg ICANCiAgICBXZSBoYXZlIHJlY2VpdmVkIHJlbmV3ZWQgaW50ZXJlc3QgaW4gcHJvZ3Jlc3Npbmcg dGhpcyBkcmFmdCBhbmQgYSBudW1iZXIgb2YNCiAgICBwZW9wbGUgaGF2ZSBzdGF0ZWQgdGhhdCB0 aGV5IGFyZSB3aWxsaW5nIHRvIHdvcmsgb24gaXQuDQogICAgDQogICAgSWYgeW91IHN1cHBvcnQg dGhhdCBhZG9wdGlvbiwgcGxlYXNlIHJlc3BvbmQgdG8gdGhlIGxpc3QgYnkgRnJpZGF5IEFwcmls IDEyLA0KICAgIDIzOjU5IFVUQy4gSWYgeW91IG9wcG9zZSBXRyBhZG9wdGlvbiwgaGF2ZSBjb21t ZW50cywgb3IgY29uY2VybnMsIHBsZWFzZQ0KICAgIHJlcGx5IGVpdGhlciB0byB0aGlzIHRocmVh ZCBvciBkaXJlY3RseSB0byB0aGUgY2hhaXJzL2F1dGhvcnMgKGlmIG5lZWRlZCkuDQogICAgDQog ICAgVGhhbmtzLA0KICAgIC9Cbw0KICAgIE1NVVNJQyBjby1jaGFpcg0KICAgIA0KICAgIA0KICAg IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgbW11 c2ljIG1haWxpbmcgbGlzdA0KICAgIG1tdXNpY0BpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQogICAgDQoNCg== From nobody Wed Apr 3 15:33:23 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0F4120141; Wed, 3 Apr 2019 15:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzoAZawY44nH; Wed, 3 Apr 2019 15:33:19 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00101.outbound.protection.outlook.com [40.107.0.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4A61120043; Wed, 3 Apr 2019 15:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6bRDqTahLPYaTAhOQB+u85+lECve/7i6wGPWFAPzJTk=; b=pzuHolY6IJNplmVP2TMPti8ybCUlqVq7q77+Q/dc+P5w4MoBsLMiNA6MuqMyU8Wgmw5wEUefLL3XKAr9g0X6F9VC1af3KdvQ50QUkKYZH+D9M4NOkB9k4s6wX5hZcsql7lgZ1uee/ol+zGTodPfCWJ8ylxyBhjUpk2cUKZpbjos= Received: from AM6PR07MB6183.eurprd07.prod.outlook.com (20.177.191.97) by AM6PR07MB4983.eurprd07.prod.outlook.com (20.177.198.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.6; Wed, 3 Apr 2019 22:33:15 +0000 Received: from AM6PR07MB6183.eurprd07.prod.outlook.com ([fe80::3d10:347e:3ea5:d39a]) by AM6PR07MB6183.eurprd07.prod.outlook.com ([fe80::3d10:347e:3ea5:d39a%5]) with mapi id 15.20.1771.007; Wed, 3 Apr 2019 22:33:15 +0000 From: "Henrikson, Eric (Nokia - US)" To: Bo Burman , "mmusic (mmusic@ietf.org)" CC: "mmusic-chairs@ietf.org" , "'draft-ietf-mmusic-msrp-usage-data-channel@ietf.org'" Thread-Topic: Re-adoption call for draft-ietf-mmusic-msrp-usage-data-channel Thread-Index: AdTqC9I1YycHtSl3SAauzLFz1SoKJwAYPdaw Date: Wed, 3 Apr 2019 22:33:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eric.henrikson@nokia.com; x-originating-ip: [50.47.113.27] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 21980964-610c-4b19-6942-08d6b8845d2f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM6PR07MB4983; x-ms-traffictypediagnostic: AM6PR07MB4983: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0996D1900D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(136003)(39860400002)(396003)(366004)(189003)(199004)(4326008)(81166006)(81156014)(68736007)(66066001)(54906003)(14444005)(476003)(106356001)(26005)(102836004)(256004)(52536014)(105586002)(229853002)(6506007)(790700001)(3846002)(8936002)(186003)(53546011)(6116002)(316002)(478600001)(236005)(11346002)(7736002)(446003)(110136005)(486006)(5660300002)(71200400001)(54896002)(55016002)(71190400001)(86362001)(99286004)(9686003)(6306002)(76176011)(606006)(14454004)(53936002)(6436002)(8676002)(6246003)(2906002)(33656002)(74316002)(25786009)(7696005)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR07MB4983; H:AM6PR07MB6183.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: HBTvXiqLUd+QPZftZ5bc3a6Yi/w5h/O/KoqH79HPiJM3jaQ/J9wx1GiAVdaRMM9XcG63FJ5FhWmUqvHHE9W1mAu/4ap83IAgt/JetxQTovSQTMju/6N8PVkyTNchOnDxBWTAfv2d8kreGNPOpmzugaiAQid8w+Pn3q5UpFRt6Nmsk45kHy4BYjUySm87HLV4Q/7FzKMStmvsddDkP3M9pjUz18jB3pHB84xmF3yFe8YxTvRHw1N7w1rRnkcTBOyb1iPX+wj5TkXjFZUz5bKE6ORN6XoaDsied5H+/IRwG5+myD/I7Y2D7Q6AT09cnV8Fde5cAayIIYf7a3+au4dY4RUSdUEVVhFr3moFHuIDR5nuFwTroRjqgOXQlqCjHDqV/rwkaHXhyYXa/MdFcuotJnEsCrH8jGEAuD6Tg6evirs= Content-Type: multipart/alternative; boundary="_000_AM6PR07MB6183B395DAF90A14053B17E685570AM6PR07MB6183eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 21980964-610c-4b19-6942-08d6b8845d2f X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2019 22:33:15.7135 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4983 Archived-At: Subject: Re: [MMUSIC] Re-adoption call for draft-ietf-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org 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, 03 Apr 2019 22:33:22 -0000 --_000_AM6PR07MB6183B395DAF90A14053B17E685570AM6PR07MB6183eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support the adoption of this draft and I will review and provide comments= , participate in discussions, and help to provide content as necessary. Regards, Eric From: mmusic On Behalf Of Bo Burman Sent: Wednesday, April 3, 2019 4:34 AM To: mmusic (mmusic@ietf.org) Cc: mmusic-chairs@ietf.org; 'draft-ietf-mmusic-msrp-usage-data-channel@ietf= .org' Subject: [MMUSIC] Re-adoption call for draft-ietf-mmusic-msrp-usage-data-ch= annel MMUSIC, This is a 1-week call to re-adopt "Submit SDP Negotiation of MSRP over Data= Channels as Proposed Standard" as an MMUSIC WG milestone, reviving the exp= ired draft-ietf-mmusic-msrp-usage-data-channel as document. We have received renewed interest in progressing this draft and a number of= people have stated that they are willing to work on it. If you support that adoption, please respond to the list by Friday April 12= , 23:59 UTC. If you oppose WG adoption, have comments, or concerns, please = reply either to this thread or directly to the chairs/authors (if needed). Thanks, /Bo MMUSIC co-chair --_000_AM6PR07MB6183B395DAF90A14053B17E685570AM6PR07MB6183eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support the adoption of this draft and I will revi= ew and provide comments, participate in discussions, and help to provide co= ntent as necessary.

 

Regards,
Eric

 

From: mmusic <mmusic-bounces@ietf.org> = On Behalf Of Bo Burman
Sent: Wednesday, April 3, 2019 4:34 AM
To: mmusic (mmusic@ietf.org) <mmusic@ietf.org>
Cc: mmusic-chairs@ietf.org; 'draft-ietf-mmusic-msrp-usage-data-chann= el@ietf.org' <draft-ietf-mmusic-msrp-usage-data-channel@ietf.org>
Subject: [MMUSIC] Re-adoption call for draft-ietf-mmusic-msrp-usage-= data-channel

 

MMUSIC,

 

This is a 1-week call to re-adopt “Submit SDP = Negotiation of MSRP over Data Channels as Proposed Standard” as an MM= USIC WG milestone, reviving the expired draft-ietf-mmusic-msrp-usage-data-channel as document.

 

We have received renewed interest in progressing thi= s draft and a number of people have stated that they are willing to work on= it.

 

If you support that adoption, please respond to the = list by Friday April 12, 23:59 UTC. If you oppose WG adoption, have comment= s, or concerns, please reply either to this thread or directly to the chair= s/authors (if needed).

 

Thanks,

/Bo

MMUSIC co-chair

 

--_000_AM6PR07MB6183B395DAF90A14053B17E685570AM6PR07MB6183eurp_-- From nobody Wed Apr 3 19:59:53 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF2812039E for ; Wed, 3 Apr 2019 19:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwMS-GQbmNkz for ; Wed, 3 Apr 2019 19:59:49 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE28E120347 for ; Wed, 3 Apr 2019 19:59:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4972; q=dns/txt; s=iport; t=1554346788; x=1555556388; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=PBT988hYb2cyugKfT+Ll3zp2xJn8RL++ULEulNt9bhI=; b=Hp944UdPy2JT1RsjBoTuBvMaiLBqEE7WSMzAnFM7Icb2m/T6YKPLdABR etketIukCcBcVHGAtlJix3i7X1+E69ExsvW41aPZ0FudYkZ9W52+H8yjl +MJumDnQ3EjhabszNfDaelxz9NgU9R/Cmn4k3CS0xqOfY8Xg8h+og1mCk Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAABncqVc/49dJa0aAUoODAEBAQE?= =?us-ascii?q?BAgEBAQEHAgEBAQGBUgQBAQEBCwEBgg9ogQMnl0aCDYlGiQSFeIF7EBgBDIQ?= =?us-ascii?q?BRgKFRCI1CA0BAQMBAQkBAwJtHAyFSwEBAQMBARtRGwsECgouJzAGAQwGAgE?= =?us-ascii?q?Bgx4BgWgND4w3oR8fhCZBQIRtBYEwAYsyF4FAP4ERJ4JrPoJhAQEDAYc+A4p?= =?us-ascii?q?HGohYkisJh3+LdAYaggWGE4M0iH2ITYIpCUyGG415gVABNoFWTSMVO4Jsiw2?= =?us-ascii?q?FBFcjAzCQPgEB?= X-IronPort-AV: E=Sophos;i="5.60,306,1549929600"; d="scan'208,217";a="324802157" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Apr 2019 02:59:47 +0000 Received: from [10.82.214.26] (rtp-vpn4-1562.cisco.com [10.82.214.26]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTP id x342xkwW017877; Thu, 4 Apr 2019 02:59:47 GMT To: Paul Kyzivat , mmusic@ietf.org References: <16fa7d9b-3d21-c6a7-a675-dbc0cec18a43@alum.mit.edu> From: Flemming Andreasen Message-ID: <72a428f1-cd67-e36e-fd1e-74b4f96e0d1c@cisco.com> Date: Wed, 3 Apr 2019 22:59:46 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <16fa7d9b-3d21-c6a7-a675-dbc0cec18a43@alum.mit.edu> Content-Type: multipart/alternative; boundary="------------BB4EBFEE0B28B42831B21FC6" Content-Language: en-US X-Outbound-SMTP-Client: 10.82.214.26, rtp-vpn4-1562.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [MMUSIC] Re-adoption call for draft-ietf-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org 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: Thu, 04 Apr 2019 02:59:51 -0000 This is a multi-part message in MIME format. --------------BB4EBFEE0B28B42831B21FC6 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit We know there is demand (from 3GPP), but we need contributors as well as reviewers to move forward with it, so thank you Paul. If anybody else is in a similar position, please let us know on the list. Thanks -- Flemming On 4/3/19 9:40 AM, Paul Kyzivat wrote: > I'm going to abstain on this because this ought to be about whether > there is demand, and I don't know. > > I will review/comment if it is adopted. > >     Thanks, >     Paul > > On 4/3/19 7:34 AM, Bo Burman wrote: >> MMUSIC, >> >> This is a 1-week call to re-adopt “Submit SDP Negotiation of MSRP >> over Data Channels as Proposed Standard” as an MMUSIC WG milestone, >> reviving the expired draft-ietf-mmusic-msrp-usage-data-channel >> >> as document. >> >> We have received renewed interest in progressing this draft and a >> number of people have stated that they are willing to work on it. >> >> If you support that adoption, please respond to the list by Friday >> April 12, 23:59 UTC. If you oppose WG adoption, have comments, or >> concerns, please reply either to this thread or directly to the >> chairs/authors (if needed). >> >> Thanks, >> >> /Bo >> >> MMUSIC co-chair >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > --------------BB4EBFEE0B28B42831B21FC6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit We know there is demand (from 3GPP), but we need contributors as well as reviewers to move forward with it, so thank you Paul. If anybody else is in a similar position, please let us know on the list.

Thanks

-- Flemming

On 4/3/19 9:40 AM, Paul Kyzivat wrote:
I'm going to abstain on this because this ought to be about whether there is demand, and I don't know.

I will review/comment if it is adopted.

    Thanks,
    Paul

On 4/3/19 7:34 AM, Bo Burman wrote:
MMUSIC,

This is a 1-week call to re-adopt “Submit SDP Negotiation of MSRP over Data Channels as Proposed Standard” as an MMUSIC WG milestone, reviving the expired draft-ietf-mmusic-msrp-usage-data-channel <https://datatracker.ietf.org/doc/draft-ietf-mmusic-msrp-usage-data-channel/> as document.

We have received renewed interest in progressing this draft and a number of people have stated that they are willing to work on it.

If you support that adoption, please respond to the list by Friday April 12, 23:59 UTC. If you oppose WG adoption, have comments, or concerns, please reply either to this thread or directly to the chairs/authors (if needed).

Thanks,

/Bo

MMUSIC co-chair


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
.


--------------BB4EBFEE0B28B42831B21FC6-- From nobody Wed Apr 3 21:50:50 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA13412041B for ; Wed, 3 Apr 2019 21:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PY2inCHVZQCo for ; Wed, 3 Apr 2019 21:50:46 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BE3E120414 for ; Wed, 3 Apr 2019 21:50:46 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BD1A3B80101; Wed, 3 Apr 2019 21:50:45 -0700 (PDT) To: jonathan@vidyo.com, christer.holmberg@ericsson.com, barryleiba@computer.org, aamelnikov@fastmail.fm, adam@nostrum.com, bo.burman@ericsson.com, fandreas@cisco.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: dev+ietf@seantek.com, mmusic@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190404045045.BD1A3B80101@rfc-editor.org> Date: Wed, 3 Apr 2019 21:50:45 -0700 (PDT) Archived-At: Subject: [MMUSIC] [Editorial Errata Reported] RFC8122 (5683) X-BeenThere: mmusic@ietf.org 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: Thu, 04 Apr 2019 04:50:48 -0000 The following errata report has been submitted for RFC8122, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5683 -------------------------------------- Type: Editorial Reported by: Sean Leonard Section: 8 Original Text ------------- Table 1: IANA Hash Function Textual Name Registry Corrected Text -------------- Table 1: IANA Hash Function Textual Names Registry Notes ----- The name of the registry is "IANA Hash Function Textual Names Registry". Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8122 (draft-ietf-mmusic-4572-update-13) -------------------------------------- Title : Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) Publication Date : March 2017 Author(s) : J. Lennox, C. Holmberg Category : PROPOSED STANDARD Source : Multiparty Multimedia Session Control Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Thu Apr 4 05:43:27 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E0112047C; Thu, 4 Apr 2019 05:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7bBqB_2VtkA; Thu, 4 Apr 2019 05:43:23 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60091.outbound.protection.outlook.com [40.107.6.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681DC1200E0; Thu, 4 Apr 2019 05:43:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fN3ZcUAD3+D90d8npIJ679zwESERFdiOyrJ3idvZY1M=; b=qWzr4YdPMOtfhLrgiSekSXR2H/soWgrkkWtDPJ6JnZsrr9CbaszjsIxZdc3VuEhNn25g+IOvKUArjTNGsk9ByNDvh32jUuowzVqNQa5VeVQVMWaUdfWZk7ljKMf49LCnR3TOgUWSXpce2LAsNMDQbAQqovUbUIaPBM931wWRv+Y= Received: from DB6PR07MB3464.eurprd07.prod.outlook.com (10.170.219.153) by DB6PR07MB4262.eurprd07.prod.outlook.com (10.168.23.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.9; Thu, 4 Apr 2019 12:43:21 +0000 Received: from DB6PR07MB3464.eurprd07.prod.outlook.com ([fe80::a90b:fb1b:6d8e:f763]) by DB6PR07MB3464.eurprd07.prod.outlook.com ([fe80::a90b:fb1b:6d8e:f763%3]) with mapi id 15.20.1771.006; Thu, 4 Apr 2019 12:43:21 +0000 From: "Maisonneuve, Julien (Nokia - FR/Paris-Saclay)" To: Bo Burman , "mmusic (mmusic@ietf.org)" CC: "mmusic-chairs@ietf.org" , "'draft-ietf-mmusic-msrp-usage-data-channel@ietf.org'" Thread-Topic: Re-adoption call for draft-ietf-mmusic-msrp-usage-data-channel Thread-Index: AdTqC9I1YycHtSl3SAauzLFz1SoKJwA1+5vQ Date: Thu, 4 Apr 2019 12:43:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=julien.maisonneuve@nokia.com; x-originating-ip: [82.235.62.158] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b36d6455-7597-40bc-5436-08d6b8fb1ea6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DB6PR07MB4262; x-ms-traffictypediagnostic: DB6PR07MB4262: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0997523C40 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(376002)(136003)(366004)(396003)(189003)(199004)(76176011)(25786009)(316002)(476003)(186003)(99286004)(3846002)(6116002)(6506007)(33656002)(106356001)(86362001)(105586002)(2906002)(790700001)(54906003)(256004)(110136005)(14444005)(606006)(4326008)(236005)(7696005)(6306002)(9686003)(54896002)(53936002)(14454004)(71200400001)(6436002)(68736007)(66066001)(71190400001)(6246003)(53546011)(11346002)(5660300002)(8936002)(486006)(102836004)(478600001)(52536014)(26005)(446003)(7736002)(74316002)(81156014)(229853002)(55016002)(81166006)(8676002)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR07MB4262; H:DB6PR07MB3464.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: n75OM8OoV+QzA7jbuns/5qz16W8NuYdQ+csUPllRcDorHpWHnaMkqok8WEqdHckIypW0pRs9TPKAOrVEm6QRwX+rF2Qw5H58Ro/zOM4ooOOQEaHxYohpj4cQ2IOrhrQPMjzqM+3lmtP1TpnA6akiWe51BnKMooF3iwk4Gg5kxmKuUxm8mDxojVcTYh+4uFSCLJAsrbyg5o4Oan24DWxnsPYuN1/v6kzQE7wBprAY1JciPWuKYhGv/Tc4eY3NLmuVx46Md8zak1RPXqgVKYFAnJa8ZG/TkKCqISHORvIS6SKpplAADHJKmKfKOMPeAd20qDrjZ3AKaYn38nse2ef2BD7fVngob5KqtdcR/TO82On27QF+DP/w0bZfYW4wHauIA1OAoo/FBCB8atM26PCBRkrynU/CKf2DjTknKmVjGXg= Content-Type: multipart/alternative; boundary="_000_DB6PR07MB346492D9165011CA31EF54C292500DB6PR07MB3464eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: b36d6455-7597-40bc-5436-08d6b8fb1ea6 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2019 12:43:20.9002 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB4262 Archived-At: Subject: Re: [MMUSIC] Re-adoption call for draft-ietf-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org 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: Thu, 04 Apr 2019 12:43:26 -0000 --_000_DB6PR07MB346492D9165011CA31EF54C292500DB6PR07MB3464eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I support the (re)adoption of draft-ietf-mmusic-msrp-usage-data-channel and= will be providing reviews. Best regards, Julien Maisonneuve. From: mmusic On Behalf Of Bo Burman Sent: Wednesday, April 3, 2019 1:34 PM To: mmusic (mmusic@ietf.org) Cc: mmusic-chairs@ietf.org; 'draft-ietf-mmusic-msrp-usage-data-channel@ietf= .org' Subject: [MMUSIC] Re-adoption call for draft-ietf-mmusic-msrp-usage-data-ch= annel MMUSIC, This is a 1-week call to re-adopt "Submit SDP Negotiation of MSRP over Data= Channels as Proposed Standard" as an MMUSIC WG milestone, reviving the exp= ired draft-ietf-mmusic-msrp-usage-data-channel as document. We have received renewed interest in progressing this draft and a number of= people have stated that they are willing to work on it. If you support that adoption, please respond to the list by Friday April 12= , 23:59 UTC. If you oppose WG adoption, have comments, or concerns, please = reply either to this thread or directly to the chairs/authors (if needed). Thanks, /Bo MMUSIC co-chair --_000_DB6PR07MB346492D9165011CA31EF54C292500DB6PR07MB3464eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

I support the (re)adoption of draft-ietf-mmusic-msrp-usage-data-channel and w= ill be providing reviews.

Best regards,

Julien Maisonneuve.

 

From: mmusic <mmusic-bounces@ietf.org> On Behalf Of Bo Burman
Sent: Wednesday, April 3, 2019 1:34 PM
To: mmusic (mmusic@ietf.org) <mmusic@ietf.org>
Cc: mmusic-chairs@ietf.org; 'draft-ietf-mmusic-msrp-usage-data-chann= el@ietf.org' <draft-ietf-mmusic-msrp-usage-data-channel@ietf.org>
Subject: [MMUSIC] Re-adoption call for draft-ietf-mmusic-msrp-usage-= data-channel

 

MMUSIC,

 

This is a 1-week call to re-ado= pt “Submit SDP Negotiation of MSRP over Data Channels as Proposed Sta= ndard” as an MMUSIC WG milestone, reviving the expired draft-ietf-mmusic-msrp-usage-data-channel as document.

 

We have received renewed intere= st in progressing this draft and a number of people have stated that they a= re willing to work on it.

 

If you support that adoption, p= lease respond to the list by Friday April 12, 23:59 UTC. If you oppose WG a= doption, have comments, or concerns, please reply either to this thread or = directly to the chairs/authors (if needed).

 

Thanks,

/Bo

MMUSIC co-chair

 

--_000_DB6PR07MB346492D9165011CA31EF54C292500DB6PR07MB3464eurp_-- From nobody Thu Apr 4 13:03:57 2019 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 153201204B4; Thu, 4 Apr 2019 13:03:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Linda Dunbar via Datatracker To: Cc: draft-ietf-mmusic-data-channel-sdpneg.all@ietf.org, ietf@ietf.org, mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Linda Dunbar Message-ID: <155440823601.30850.520568779536183555@ietfa.amsl.com> Date: Thu, 04 Apr 2019 13:03:56 -0700 Archived-At: Subject: [MMUSIC] Genart telechat review of draft-ietf-mmusic-data-channel-sdpneg-25 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 20:03:56 -0000 Reviewer: Linda Dunbar Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-mmusic-data-channel-sdpneg-25 Reviewer: Linda Dunbar Review Date: 2019-04-04 IETF LC End Date: 2019-03-18 IESG Telechat date: 2019-04-11 Summary: The document defines the procedures that enable out of band negotiation for establishing data channels for transport of existing well-defined subprotocols. Major issues: None Minor issues: None. Nits/editorial comments: From nobody Fri Apr 5 05:04:42 2019 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF281203E9; Fri, 5 Apr 2019 05:04:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: draft-ietf-mmusic-data-channel-sdpneg@ietf.org, Bo Burman , mmusic-chairs@ietf.org, bo.burman@ericsson.com, mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <155446588097.13196.6373243259627185094.idtracker@ietfa.amsl.com> Date: Fri, 05 Apr 2019 05:04:40 -0700 Archived-At: Subject: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 12:04:41 -0000 Magnus Westerlund has entered the following ballot position for draft-ietf-mmusic-data-channel-sdpneg-25: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- There might be a serious issue in label definition. 5.1.3. Label Parameter The 'label' parameter indicates the name of the channel. It represents a label that can be used to distinguish, in the context of the WebRTC API [WebRtcAPI], an RTCDataChannel object from other RTCDataChannel objects. This parameter maps to the 'Label' parameter defined in [I-D.ietf-rtcweb-data-protocol]. The 'label' parameter is optional. If it is not present, then its value defaults to the empty string. label-opt = "label=" quoted-string quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE quoted-char = SP / quoted-visible quoted-visible = %x21 / %x23-24 / %x26-7E ; VCHAR without " or % escaped-char = "%" HEXDIG HEXDIG I interpret that as the intention is to enable the SDP Attribute to carry the label as defined in W3C API. That value is in the current candidatate specification an https://www.w3.org/TR/webrtc/ as an USVSsting (https://heycam.github.io/webidl/#idl-USVString). And in the reference version of the WebRTC API as an DOMstring. Both are not limited to ASCII and may contain any Unicode characters. Thus the escaping mechanism defined appear to be insufficient. I think the "quoted-string" need a definition of what type of string this truly are so that it is clear what a character in the string is. In addition the specification of escaping is undersspecified. I would recommend at least adding discussion of the need and how to escape DQUOTE and % that can be relatively common operations. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 5.1.3: Is it correct that there are no limiation on the lenght of the label? So it will okay if I use the more than 450k words of J.R.R.R Tolkien's Lords of the Ring as label? [WebRtcAPI] Is it really the intention to point to the very old version of the API from 2015? The current candidate specification is available here: https://www.w3.org/TR/webrtc/ and are from 2018. From nobody Fri Apr 5 09:18:23 2019 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A87BC12051F; Fri, 5 Apr 2019 09:18:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-mmusic-data-channel-sdpneg@ietf.org, Bo Burman , mmusic-chairs@ietf.org, bo.burman@ericsson.com, mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <155448109368.10029.4766956503581760917.idtracker@ietfa.amsl.com> Date: Fri, 05 Apr 2019 09:18:13 -0700 Archived-At: Subject: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-mmusic-data-channel-sdpneg-25=3A_=28with_COMMENT=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 16:18:14 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-mmusic-data-channel-sdpneg-25: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for quickly addressing the comments from the TSV-ART review regarding interactions with SCTP (and thanks Micheal T. for the review!)! One minor, more editorial comment on max-time parameter: draft-ietf-rtcweb-data-protocol says "This life-time starts when providing the user message to the protocol stack.". While a reference to draft-ietf-rtcweb-data-protocol is given respectively, I would recommend to also clarify in this draft which time frame is meant given this time frame includes and end-to-end delays. As a side note: not sure it is necessary to expand IETF (Internet Engineering Task Force) (see sec 5.2) in an IETF RFC but the RFC editor might tell you... From nobody Fri Apr 5 09:22:12 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661721204AE; Fri, 5 Apr 2019 09:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mY2Bmj0KwNKu; Fri, 5 Apr 2019 09:22:01 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4285712061E; Fri, 5 Apr 2019 09:21:53 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x35GLkdv023773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 5 Apr 2019 12:21:48 -0400 Date: Fri, 5 Apr 2019 11:21:46 -0500 From: Benjamin Kaduk To: Mirja =?iso-8859-1?Q?K=FChlewind?= Cc: The IESG , mmusic-chairs@ietf.org, bo.burman@ericsson.com, draft-ietf-mmusic-data-channel-sdpneg@ietf.org, mmusic@ietf.org Message-ID: <20190405162146.GB70202@kduck.mit.edu> References: <155448109368.10029.4766956503581760917.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <155448109368.10029.4766956503581760917.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [MMUSIC] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on__d?= =?iso-8859-1?q?raft-ietf-mmusic-data-channel-sdpneg-25=3A_=28with_COMMENT?= =?iso-8859-1?q?=29?= X-BeenThere: mmusic@ietf.org 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: Fri, 05 Apr 2019 16:22:04 -0000 On Fri, Apr 05, 2019 at 09:18:13AM -0700, Mirja Kühlewind via Datatracker wrote: > > As a side note: not sure it is necessary to expand IETF (Internet Engineering > Task Force) (see sec 5.2) in an IETF RFC but the RFC editor might tell you... It's marked as "well-known" at https://www.rfc-editor.org/materials/abbrev.expansion.txt :) -Ben From nobody Sun Apr 7 19:18:03 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C51120279; Sun, 7 Apr 2019 19:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=nFQ77Azg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kAEnPlHF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hW_i_L61-R4e; Sun, 7 Apr 2019 19:17:59 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD9D12027B; Sun, 7 Apr 2019 19:17:59 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5D4D420BBE; Sun, 7 Apr 2019 22:17:58 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Sun, 07 Apr 2019 22:17:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm1; bh=W2 DCoIcJd5BGZdTB3YODU5hS6RUQrbK6OlO2OjIS2eQ=; b=nFQ77AzgntsXGZF1a0 jyqrWFrSo00TLbNwqlLwjpOzNePHs3JOE2FO8PeXhnajBpekP22mdvx4/HSB4qnS Z7k8hpT8elAFNIYkVrX6IFprVVjH0Q0OES+f7CzeFJfbeM2BEMBs3/BGqzNP8hlH 0pTWjw3LAY8Mc2VGwYda9/Uvamecne2exK/84L58xnBRRgBNkPOfiip02G+3Rbpg 958j9d7V0H49GxwZwDzCVmThetv/58RgYFOXMP+9k5z++2RWcmdC3hVxzy/tBRra Hip48es9CQs/htajZVLAsncym6bYPQ7aQGX8WOd9HwyY9HShP0VlU6EL7eapcJns Ayjg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=W2DCoIcJd5BGZdTB3YODU5hS6RUQrbK6OlO2OjIS2 eQ=; b=kAEnPlHFipY8tXlAbGqOqUvYMpVl9ZMa2iUM2QzeOWFEDU3+x+8LiQ+aH U4UfEBdGSohWBYTNsgVqmmakLeCAR/iw/khKRDI6HXUKLY03/rCbyesMfh1DbAex S/hFk9Xd5UI8goRoxhIqgOfhSP7KKB4EAHxrbL1g1vUyzgWN4mJBWJRhVsO/7SNa V6d8OblmYMx5RcIV2byWjziOwIJHPl75m7GNuDVVWV1IgXkXrFrb7TfU6Iu4oR3y IGzqZmB2ubxxdZRxN9A1QR7t8cRBGfRon1xHZuJzu/Z/+TIfIIjvFZZBNckISfVi /7aD59mB9eC+yUjG6yvSuO4Nawrbw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddruddvgdehkeculddtuddrgedutddrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreer jeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnth hrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhht rhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5C6F77C1B9; Sun, 7 Apr 2019 22:17:57 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 92534000 Message-Id: In-Reply-To: References: <69e1ed84-7bae-4258-897b-a6d36716c261@www.fastmail.com> <718ce899-166c-b793-c7d4-84bb5fcceea5@cisco.com> Date: Sun, 07 Apr 2019 22:18:00 -0400 From: "Martin Thomson" To: "Bo Burman" , "Flemming Andreasen" , mmusic Cc: "draft-ietf-mmusic-sdp-uks@ietf.org" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-uks-03 X-BeenThere: mmusic@ietf.org 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: Mon, 08 Apr 2019 02:18:01 -0000 > The text is clearer, but I still don't follow. If I understand RFC 822= 4=20 > correctly, authenticated identity is only defined for SIP requests,=20= > however all four 3PCC flows in RFC 3725 have the controller generate=20= > the SIP INVITE, so how do the endpoints exchange authenticated identit= y=20 > information ?=20 Flows 2 and 3 show the Controller creating an offer, but in all cases it= is an offer with no media. The endpoints are still responsible for cre= ating the offer that contains media. Therefore I assume that they can c= reate offers with identity assertions. > >> =C2=A0The text reads well, but I'm still left with the same questio= n:=C2=A0 Section 3.1, second paragraph says there are two separate sessi= ons (I take that to mean SIP sessions). It then goes on to say =C2=A0 "I= n the first session, Patsy is presented with the option to communicate w= ith Norma "=C2=A0 If I understand correctly, this means there is a SIP I= NVITE sent by Mallory to Patsy, however Mallory somehow asserts Norma's = identity to Patsy. How is Mallory able to do that if we are using SIP Au= thenticated Identity ? I'm not sure if the above would be cleare if the = flow was expanded to show INVITE and 200-OK. =C2=A0Yeah, I really want t= o avoid adding all the SIP stuff here.=C2=A0 There would be lots of irre= levant messages involved and it distracts from the message.=C2=A0The key= insight here is that SIP identity only certifies a small number of fiel= ds and that the rest of the session is open to be modified by the signal= ing server.=C2=A0 RFC 8225 only covers the identity (sip:norma@example o= r tel:+12345556789) and the a=3Dfingerprint values, everything else is o= pen to attack.=C2=A0 So if we allow Mallory the ability to modify signal= ing, there is a lot she can do.=C2=A0 In practice however, this doesn't = require much of an attack on the session, other than (maybe) to substitu= te transport parameters.=C2=A0>From the perspective of SIP and SIP ident= ity, these are largely legitimate sessions.=C2=A0 The attack on signalin= g is necessary only to the extent that the attack also depends on =C2=A0= I've added more text here, realizing that it was a little light.=C2=A0 T= his is the updated section in full:=C2=A0"The attack requires that Mallo= ry obtain an identity binding for her own identitywith the fingerprints = presented by Patsy (P).=C2=A0 This false binding is thenpresented to Nor= ma (Signaling1 in the figure). > You mean Signaling2 in the figure (below), right ?=20 >=20 >=20 > Norma Mallory Patsy > (fp=3DN) ----- (fp=3DP) > | | | > | |<---- Signaling1 ------>| > | | Norma=3DN Patsy=3DP | > |<---- Signaling2 ------>| | > | Norma=3DN Mallory=3DP | | > | | > |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DDTLS (fp=3DN,P)=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| > | | > (peer =3D Mallory!) (peer =3D Norma) >=20 > Figure 1: Example Attack on Identity Bindings I swapped the two flows in the figure so that it more closely matches th= e text. > > =C2=A0=C2=A0"Patsy could be similarly duped, but in this example, a = correct binding betweenNorma's identity and fingerprint (N) is faithfull= y presented by Mallory.=C2=A0 Thissession (Signaling2 in the figure) can= be entirely legitimate. > Signaling1 ?=20 >=20 >=20 >=20 > > =C2=A0"A DTLS session is established directly between Norma and Pats= y.=C2=A0 In=20 > order forthis to happen Mallory can substitute transport-level=20 > information in bothsessions to facilitate this, though this is not=20 > necessary if Mallory is on thenetwork path between Norma and Patsy.=C2= =A0"As=20 > a result, Patsy correctly believes that she is communicating with Norm= a. > > I don't follow the above sentence (just like I don't follow the=20 > sentence I referenced originally, i.e. "In the first session, Patsy is= =20 > presented with the option to communicate with Norma". >=20 > If we double-click on "Signaling1", then I believe we start with: >=20 > INVITE(From: Mallory, To: Patsy, Fingerprint:Norma,=20 > Identity:{From:Mallory, Fingerprint:Norma}) >=20 > Implicit in the sentence above is an assumption that *Mallory* is=20 > somehow able to generate an INVITE to Patsy with an Identity header=20= > that authenticates *Norma* as the originator, i.e.: >=20 > INVITE(From: Norma, To: Patsy, Fingerprint:Norma,=20 > Identity:{From:Norma, Fingerprint:Norma}) >=20 > How is that possible ? What am I missing here ?=20 The section starts with "it is assumed that the attacker also controls t= he signaling channel." We allow this possibility because the use of an = identity assertion assumes a more capable attacker. More likely, this a= ssumes that we are defending against the signaling service itself. Once you get into that state, it's trivial for Mallory to construct the = above messages. Note that Norma will provide Mallory with an identity a= ssertion that binds the identity "Norma" to Norma's fingerprints as part= of the Norma<->Patsy session. So all that Mallory needs to do is fit t= hat into a plausible INVITE. From nobody Sun Apr 7 21:21:07 2019 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41143120048; Sun, 7 Apr 2019 21:20:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-mmusic-data-channel-sdpneg@ietf.org, Bo Burman , mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <155469725925.18284.13353229347477240382.idtracker@ietfa.amsl.com> Date: Sun, 07 Apr 2019 21:20:59 -0700 Archived-At: Subject: [MMUSIC] Barry Leiba's No Objection on draft-ietf-mmusic-data-channel-sdpneg-25: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 04:20:59 -0000 Barry Leiba has entered the following ballot position for draft-ietf-mmusic-data-channel-sdpneg-25: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Magnus’s DISCUSS. Please use the full BCP 14 boilerplate from RFC 8174, rather than abridging it. — Section 5.1.1 — Within an 'a=dcmap:' attribute line's 'dcmap-opt' value only one 'maxretr-opt' parameter or one 'maxtime-opt' parameter MAY be present. Both MUST NOT be present. Lower case “may†here, please. The MUST NOT is the normative bit. — Section 9 subsections — Instances of “IESG Chairs†should just say “IESGâ€. From nobody Sun Apr 7 23:37:30 2019 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F33451203B6; Sun, 7 Apr 2019 23:37:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Zitao Wang via Datatracker To: Cc: ietf@ietf.org, draft-ietf-mmusic-rfc4566bis.all@ietf.org, mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Zitao Wang Message-ID: <155470544191.18201.1340122970628374639@ietfa.amsl.com> Date: Sun, 07 Apr 2019 23:37:21 -0700 Archived-At: Subject: [MMUSIC] Opsdir last call review of draft-ietf-mmusic-rfc4566bis-34 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 06:37:22 -0000 Reviewer: Zitao Wang Review result: Has Issues Summary: This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566. I think the document make sense and is written very clear, except some small nits: # In Section 5, there are several terms that miss references, such as "US-ASCII subset of UTF-8", "ASN.1 or XDR", etc. # s/session- specific/session-specific/ # Suggest to add tags on "overview optional items" to identified now-obsolete items, such as "a=cat", "a=keywds", "k=". From nobody Mon Apr 8 07:36:13 2019 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 15238120421; Mon, 8 Apr 2019 07:36:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-mmusic-data-channel-sdpneg@ietf.org, Bo Burman , mmusic-chairs@ietf.org, bo.burman@ericsson.com, mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <155473417107.23255.11021918144254752327.idtracker@ietfa.amsl.com> Date: Mon, 08 Apr 2019 07:36:11 -0700 Archived-At: Subject: [MMUSIC] Alissa Cooper's No Objection on draft-ietf-mmusic-data-channel-sdpneg-25: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 14:36:12 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-mmusic-data-channel-sdpneg-25: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In Section 2, please use the exact boilerplate from RFC 8174. From nobody Mon Apr 8 07:37:23 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54AD3120026; Mon, 8 Apr 2019 07:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=jjrG6SIh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bYC+xji8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNdqBzOLFz8W; Mon, 8 Apr 2019 07:37:03 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B3ED120183; Mon, 8 Apr 2019 07:37:03 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 66A4ECF7; Mon, 8 Apr 2019 10:37:02 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Mon, 08 Apr 2019 10:37:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=h JY2ipAPltkiRek0GSljVPmTAtNKsD3+Y1Hpf+bhwps=; b=jjrG6SIhK2aWebvVD Rrwyizis0fM+j8p6OTcfMCrrDGCdYSuGnyTNt7I8R10lkL4OPkeQsvJLERvGNrC3 4ZZc1RSgtA5FtyCZyMednqL4C47lvzKmGyqJ5IegkyE944UFDSwva7IeKgxX1XWd L3zCtHgc79SLmYxs+MOyS2zbPD0ZUP1ytyxX2/pL902CPxYrgGjPW8w/o+TLDLmP bp++ajzDHPwWlaVtLy5Ur+EMbIMieR/0+5CfprH2XvWVG0jdnMU2XOv0+swuKb8c HBuehKTeF2s7zCQWiAJPT9tm53/HRVTcOCo7miqPUP9WwkZHOYvAsug0ChK3KesM u5YdQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=hJY2ipAPltkiRek0GSljVPmTAtNKsD3+Y1Hpf+bhw ps=; b=bYC+xji8lkpLPz3SLYYl2+3umg4t4qIsXlM49fCZjWD/+8opDTKf65aTL u5aqUW3UXzsxH/XSZYcrHTYBFV4flP3zetZ7Y4VKJokrrdND3QcBnFqPMLVcVflK yY9fvcmoE1tMGCB53AZ2qYQiRDecbD5fOXxq5DwHiM/yd6ieaY1dTS6HLlz28QUT +N/W0MZd0BFmLdb0yKXb8NlSWOYjfBXThQraCGQnTDv+VUnEVt3sASCDRZZ/Q1qQ 5VfMoxXE2yt22RnwWGswjqKJdB6+uSnzicxBjg3bJDvR7LiqEiWgZHU8OUQWLuX8 FW3Bc+aClokH5Kl0aduhsh736H49g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudefgdektdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdelfeenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvg hrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.93]) by mail.messagingengine.com (Postfix) with ESMTPA id 5240E10391; Mon, 8 Apr 2019 10:37:00 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <155440823601.30850.520568779536183555@ietfa.amsl.com> Date: Mon, 8 Apr 2019 10:36:58 -0400 Cc: General Area Review Team , draft-ietf-mmusic-data-channel-sdpneg.all@ietf.org, ietf@ietf.org, mmusic@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2BD2FF55-7A7A-48FE-9500-36B616E85B12@cooperw.in> References: <155440823601.30850.520568779536183555@ietfa.amsl.com> To: Linda Dunbar X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [MMUSIC] [Gen-art] Genart telechat review of draft-ietf-mmusic-data-channel-sdpneg-25 X-BeenThere: mmusic@ietf.org 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: Mon, 08 Apr 2019 14:37:06 -0000 Linda, thank you for your review. I entered a No Objection ballot. Alissa > On Apr 4, 2019, at 4:03 PM, Linda Dunbar via Datatracker = wrote: >=20 > Reviewer: Linda Dunbar > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-mmusic-data-channel-sdpneg-25 > Reviewer: Linda Dunbar > Review Date: 2019-04-04 > IETF LC End Date: 2019-03-18 > IESG Telechat date: 2019-04-11 >=20 > Summary: > The document defines the procedures that enable out of band = negotiation for > establishing data channels for transport of existing well-defined = subprotocols. >=20 > Major issues: > None >=20 > Minor issues: > None. >=20 > Nits/editorial comments: >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Mon Apr 8 08:55:46 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 592E5120026; Mon, 8 Apr 2019 08:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gMors0R94Iq; Mon, 8 Apr 2019 08:55:36 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0B9F120183; Mon, 8 Apr 2019 08:55:32 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x38FtQFo032449 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 8 Apr 2019 10:55:28 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1554738929; bh=3hH6DcdI82j6LtthakTjzz2U0aZY9sHgCQd2AppzomU=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=OxMADz5k9b/Iqfw8StG/1diqIxupEkqibhNEif1lJHqF5F88KOr/g7eWcuTBg+3bf +6pu80pHuY404OuKAuhhicdkgoLrx+WYdoiLA+JHTtQMShWIEFVjWjjDEey4fRk4+u 4P1J0zwMLUHW9vyBzmAlWFHriZ/D4cDNfgGKzuQ0= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Magnus Westerlund , The IESG Cc: mmusic-chairs@ietf.org, draft-ietf-mmusic-data-channel-sdpneg@ietf.org, mmusic@ietf.org References: <155446588097.13196.6373243259627185094.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <1afcb116-36cb-be51-81ac-e78fc52c9255@nostrum.com> Date: Mon, 8 Apr 2019 10:55:21 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <155446588097.13196.6373243259627185094.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------F0F513F38398714468D917D5" Content-Language: en-US Archived-At: Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT) X-BeenThere: mmusic@ietf.org 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: Mon, 08 Apr 2019 15:55:39 -0000 This is a multi-part message in MIME format. --------------F0F513F38398714468D917D5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 4/5/19 7:04 AM, Magnus Westerlund via Datatracker wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > There might be a serious issue in label definition. > > 5.1.3. Label Parameter > > The 'label' parameter indicates the name of the channel. It > represents a label that can be used to distinguish, in the context of > the WebRTC API [WebRtcAPI], an RTCDataChannel object from other > RTCDataChannel objects. This parameter maps to the 'Label' parameter > defined in [I-D.ietf-rtcweb-data-protocol]. The 'label' parameter is > optional. If it is not present, then its value defaults to the empty > string. > > label-opt = "label=" quoted-string > quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE > quoted-char = SP / quoted-visible > quoted-visible = %x21 / %x23-24 / %x26-7E ; VCHAR without " or % > escaped-char = "%" HEXDIG HEXDIG > > I interpret that as the intention is to enable the SDP Attribute to carry the > label as defined in W3C API. That value is in the current candidatate > specification an https://www.w3.org/TR/webrtc/ as an USVSsting > (https://heycam.github.io/webidl/#idl-USVString). And in the reference version > of the WebRTC API as an DOMstring. Both are not limited to ASCII and may > contain any Unicode characters. Thus the escaping mechanism defined appear to > be insufficient. > > I think the "quoted-string" need a definition of what type of string this truly > are so that it is clear what a character in the string is. > > In addition the specification of escaping is undersspecified. I would recommend > at least adding discussion of the need and how to escape DQUOTE and % that can > be relatively common operations. I can see that this could benefit from some explicit detail about how to convert the cited USVString string into the "quoted-string" construct defined here. I think this roughly consists of: * Serialize the WebRTC label as a UTF-8 string * Treat the UTF-8 serialization as a series of bytes * For each byte in the serialization: o If the byte can be expressed as a `quoted-char`, do so o Otherwise, express the byte as an `escaped-char`. Would including text to that effect satisfy your concern? /a --------------F0F513F38398714468D917D5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 4/5/19 7:04 AM, Magnus Westerlund via Datatracker wrote:
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

There might be a serious issue in label definition.

5.1.3.  Label Parameter

   The 'label' parameter indicates the name of the channel.  It
   represents a label that can be used to distinguish, in the context of
   the WebRTC API [WebRtcAPI], an RTCDataChannel object from other
   RTCDataChannel objects.  This parameter maps to the 'Label' parameter
   defined in [I-D.ietf-rtcweb-data-protocol].  The 'label' parameter is
   optional.  If it is not present, then its value defaults to the empty
   string.

  label-opt       = "label=" quoted-string
  quoted-string   = DQUOTE *(quoted-char / escaped-char) DQUOTE
  quoted-char     = SP / quoted-visible
  quoted-visible  = %x21 / %x23-24 / %x26-7E ; VCHAR without " or %
  escaped-char    = "%" HEXDIG HEXDIG

I interpret that as the intention is to enable the SDP Attribute to carry the
label as defined in W3C API. That value is in the current candidatate
specification an https://www.w3.org/TR/webrtc/ as an USVSsting
(https://heycam.github.io/webidl/#idl-USVString). And in the reference version
of the WebRTC API as an DOMstring. Both are not limited to ASCII and may
contain any Unicode characters. Thus the escaping mechanism defined appear to
be insufficient.

I think the "quoted-string" need a definition of what type of string this truly
are so that it is clear what a character in the string is.

In addition the specification of escaping is undersspecified. I would recommend
at least adding discussion of the need and how to escape DQUOTE and % that can
be relatively common operations.


I can see that this could benefit from some explicit detail about how to convert the cited USVString string into the "quoted-string" construct defined here. I think this roughly consists of:

  • Serialize the WebRTC label as a UTF-8 string
  • Treat the UTF-8 serialization as a series of bytes
  • For each byte in the serialization:
    • If the byte can be expressed as a `quoted-char`, do so
    • Otherwise, express the byte as an `escaped-char`.

Would including text to that effect satisfy your concern?

/a

--------------F0F513F38398714468D917D5-- From nobody Mon Apr 8 09:55:30 2019 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC2B1200FA; Mon, 8 Apr 2019 09:55:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ignas Bagdonas via Datatracker To: "The IESG" Cc: draft-ietf-mmusic-data-channel-sdpneg@ietf.org, Bo Burman , mmusic-chairs@ietf.org, bo.burman@ericsson.com, mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Ignas Bagdonas Message-ID: <155474252775.3101.13106356106673699503.idtracker@ietfa.amsl.com> Date: Mon, 08 Apr 2019 09:55:27 -0700 Archived-At: Subject: [MMUSIC] Ignas Bagdonas' No Objection on draft-ietf-mmusic-data-channel-sdpneg-25: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 16:55:28 -0000 Ignas Bagdonas has entered the following ballot position for draft-ietf-mmusic-data-channel-sdpneg-25: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A couple of nits: s7: are examples for SDP offer correct? c= addrtype IP6 is listed twice there. s9.2.1, s9.2.2: s/IESG Chairs/IESG From nobody Mon Apr 8 13:48:22 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C3A12066A; Mon, 8 Apr 2019 13:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKU3TjvAp1sM; Mon, 8 Apr 2019 13:48:18 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB14120668; Mon, 8 Apr 2019 13:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17750; q=dns/txt; s=iport; t=1554756498; x=1555966098; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=3XrdHLk/AqV356RW0TPS5zK6yPyU6O/bIFZw32A4Qk0=; b=gjq/vScCoCArYcJqB3AWLFuaNm64jTuk+HaLKXDax7c+Dgl9YSYP30yt uX9I/xxSUDeUJfScwOuK9BkBJHpXJ8P+3fwV/v693RSHJRAoetl/29nze 1gznzm0o7DmsH4bhXiWzMj8ku+VA4+K1q8i33HBF8QoCI/2aXlsWBu+9x 0=; X-IronPort-AV: E=Sophos;i="5.60,326,1549929600"; d="scan'208,217";a="459716419" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Apr 2019 20:48:17 +0000 Received: from [10.155.64.213] ([10.155.64.213]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTP id x38KmGf7007784; Mon, 8 Apr 2019 20:48:16 GMT To: Martin Thomson , Bo Burman , mmusic , Jon Peterson , Cullen Jennings , Eric Rescorla Cc: "draft-ietf-mmusic-sdp-uks@ietf.org" References: <69e1ed84-7bae-4258-897b-a6d36716c261@www.fastmail.com> <718ce899-166c-b793-c7d4-84bb5fcceea5@cisco.com> From: Flemming Andreasen Message-ID: <4a6a7d47-bd49-ed20-561e-ed4223f2d190@cisco.com> Date: Mon, 8 Apr 2019 16:48:14 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0F0AF69C93F72CF2BFE27F0F" Content-Language: en-US X-Outbound-SMTP-Client: 10.155.64.213, [10.155.64.213] X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-uks-03 X-BeenThere: mmusic@ietf.org 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: Mon, 08 Apr 2019 20:48:21 -0000 This is a multi-part message in MIME format. --------------0F0AF69C93F72CF2BFE27F0F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 4/7/19 10:18 PM, Martin Thomson wrote: >> The text is clearer, but I still don't follow. If I understand RFC 822= 4 >> correctly, authenticated identity is only defined for SIP requests, >> however all four 3PCC flows in RFC 3725 have the controller generate >> the SIP INVITE, so how do the endpoints exchange authenticated identit= y >> information ? > Flows 2 and 3 show the Controller creating an offer, but in all cases i= t is an offer with no media. The endpoints are still responsible for cre= ating the offer that contains media. Therefore I assume that they can cr= eate offers with identity assertions. Offers and SIP Requests are not the same. In RFC 3725 Flow 2 and 3, it=20 is the controller that generates the SIP Requests and the endpoints that = generate the SIP Responses and to quote RFC 8224, Section 3: =C2=A0=C2=A0 Note that the scope of this document is limited to providin= g an =C2=A0=C2=A0 identity assurance for SIP requests; solving this problem f= or SIP =C2=A0=C2=A0 responses is outside the scope of this work (see [RFC4916])= =2E Thus, I still don't see how you get these endpoint Identity assertions=20 sent across with 3PCC. Maybe we need somebody else to chime in at this=20 point. Jon/Cullen/Ekr: As authors of RFC 8224, can you help shed light on this=20 part of the thread ? >>>> =C2=A0The text reads well, but I'm still left with the same questio= n:=C2=A0 Section 3.1, second paragraph says there are two separate sessio= ns (I take that to mean SIP sessions). It then goes on to say =C2=A0 "In = the first session, Patsy is presented with the option to communicate with= Norma "=C2=A0 If I understand correctly, this means there is a SIP INVIT= E sent by Mallory to Patsy, however Mallory somehow asserts Norma's ident= ity to Patsy. How is Mallory able to do that if we are using SIP Authenti= cated Identity ? I'm not sure if the above would be cleare if the flow wa= s expanded to show INVITE and 200-OK. =C2=A0Yeah, I really want to avoid = adding all the SIP stuff here.=C2=A0 There would be lots of irrelevant me= ssages involved and it distracts from the message.=C2=A0The key insight h= ere is that SIP identity only certifies a small number of fields and that= the rest of the session is open to be modified by the signaling server.=C2= =A0 RFC 8225 only covers the identity (sip:norma@example or tel:+12345556= 789) and the a=3Dfingerprint values, everything else is open to attack.=C2= =A0 So if we allow Mallory the ability to modify signaling, there is a lo= t she can do.=C2=A0 In practice however, this doesn't require much of an = attack on the session, other than (maybe) to substitute transport paramet= ers.=C2=A0>From the perspective of SIP and SIP identity, these are largel= y legitimate sessions.=C2=A0 The attack on signaling is necessary only to= the extent that the attack also depends on =C2=A0I've added more text he= re, realizing that it was a little light.=C2=A0 This is the updated secti= on in full:=C2=A0"The attack requires that Mallory obtain an identity bin= ding for her own identitywith the fingerprints presented by Patsy (P).=C2= =A0 This false binding is thenpresented to Norma (Signaling1 in the figur= e). >> You mean Signaling2 in the figure (below), right ? >> >> >> Norma Mallory Patsy >> (fp=3DN) ----- (fp=3DP) >> | | | >> | |<---- Signaling1 ------>| >> | | Norma=3DN Patsy=3DP | >> |<---- Signaling2 ------>| | >> | Norma=3DN Mallory=3DP | | >> | | >> |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DDTLS (fp=3DN,P)= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| >> | | >> (peer =3D Mallory!) (peer =3D Norma) >> >> Figure 1: Example Attack on Identity Bindings > I swapped the two flows in the figure so that it more closely matches t= he text. Ok. >>> =C2=A0=C2=A0"Patsy could be similarly duped, but in this example, a = correct binding betweenNorma's identity and fingerprint (N) is faithfully= presented by Mallory.=C2=A0 Thissession (Signaling2 in the figure) can b= e entirely legitimate. >> Signaling1 ? >> >> >> >>> =C2=A0"A DTLS session is established directly between Norma and Pats= y.=C2=A0 In >> order forthis to happen Mallory can substitute transport-level >> information in bothsessions to facilitate this, though this is not >> necessary if Mallory is on thenetwork path between Norma and Patsy.=C2= =A0"As >> a result, Patsy correctly believes that she is communicating with Norm= a. >> >> I don't follow the above sentence (just like I don't follow the >> sentence I referenced originally, i.e. "In the first session, Patsy is= >> presented with the option to communicate with Norma". >> >> If we double-click on "Signaling1", then I believe we start with: >> >> INVITE(From: Mallory, To: Patsy, Fingerprint:Norma, >> Identity:{From:Mallory, Fingerprint:Norma}) >> >> Implicit in the sentence above is an assumption that *Mallory* is >> somehow able to generate an INVITE to Patsy with an Identity header >> that authenticates *Norma* as the originator, i.e.: >> >> INVITE(From: Norma, To: Patsy, Fingerprint:Norma, >> Identity:{From:Norma, Fingerprint:Norma}) >> >> How is that possible ? What am I missing here ? > The section starts with "it is assumed that the attacker also controls = the signaling channel." We allow this possibility because the use of an = identity assertion assumes a more capable attacker. More likely, this as= sumes that we are defending against the signaling service itself. > > Once you get into that state, it's trivial for Mallory to construct the= above messages. Note that Norma will provide Mallory with an identity a= ssertion that binds the identity "Norma" to Norma's fingerprints as part = of the Norma<->Patsy session. So all that Mallory needs to do is fit tha= t into a plausible INVITE. Ok - I think you are saying a bit more actually. Using the terminology=20 of RFC 8224, I believe you are assuming that the attacker controls the=20 Authentication Service (which I see as more than the signaling channel). = If that is the case, then I would suggest clarifying that in the text. Thanks -- Flemming > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------0F0AF69C93F72CF2BFE27F0F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+CiAgPGhlYWQ+CiAgICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCI+CiAgPC9oZWFkPgogIDxib2R5IHRl eHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYiPgogICAgPGJyPgogICAgPGJyPgogICAg PGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiA0LzcvMTkgMTA6MTggUE0sIE1hcnRp biBUaG9tc29uCiAgICAgIHdyb3RlOjxicj4KICAgIDwvZGl2PgogICAgPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIKICAgICAgY2l0ZT0ibWlkOmVhODBkNTBiLTk0NjMtNGJiNC1hYzg5LTg2 Mjk4N2E5NDU4NUB3d3cuZmFzdG1haWwuY29tIj4KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+CiAgICAgICAgPHByZSBjbGFzcz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj5UaGUg dGV4dCBpcyBjbGVhcmVyLCBidXQgSSBzdGlsbCBkb24ndCBmb2xsb3cuIElmIEkgdW5kZXJz dGFuZCBSRkMgODIyNCAKY29ycmVjdGx5LCBhdXRoZW50aWNhdGVkIGlkZW50aXR5IGlzIG9u bHkgZGVmaW5lZCBmb3IgU0lQIHJlcXVlc3RzLCAKaG93ZXZlciBhbGwgZm91ciAzUENDIGZs b3dzIGluIFJGQyAzNzI1IGhhdmUgdGhlIGNvbnRyb2xsZXIgZ2VuZXJhdGUgCnRoZSBTSVAg SU5WSVRFLCBzbyBob3cgZG8gdGhlIGVuZHBvaW50cyBleGNoYW5nZSBhdXRoZW50aWNhdGVk IGlkZW50aXR5IAppbmZvcm1hdGlvbiA/IAo8L3ByZT4KICAgICAgPC9ibG9ja3F1b3RlPgog ICAgICA8cHJlIGNsYXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIiPgpGbG93cyAyIGFuZCAz IHNob3cgdGhlIENvbnRyb2xsZXIgY3JlYXRpbmcgYW4gb2ZmZXIsIGJ1dCBpbiBhbGwgY2Fz ZXMgaXQgaXMgYW4gb2ZmZXIgd2l0aCBubyBtZWRpYS4gIFRoZSBlbmRwb2ludHMgYXJlIHN0 aWxsIHJlc3BvbnNpYmxlIGZvciBjcmVhdGluZyB0aGUgb2ZmZXIgdGhhdCBjb250YWlucyBt ZWRpYS4gIFRoZXJlZm9yZSBJIGFzc3VtZSB0aGF0IHRoZXkgY2FuIGNyZWF0ZSBvZmZlcnMg d2l0aCBpZGVudGl0eSBhc3NlcnRpb25zLgo8L3ByZT4KICAgIDwvYmxvY2txdW90ZT4KICAg IE9mZmVycyBhbmQgU0lQIFJlcXVlc3RzIGFyZSBub3QgdGhlIHNhbWUuIEluIFJGQyAzNzI1 IEZsb3cgMiBhbmQgMywKICAgIGl0IGlzIHRoZSBjb250cm9sbGVyIHRoYXQgZ2VuZXJhdGVz IHRoZSBTSVAgUmVxdWVzdHMgYW5kIHRoZQogICAgZW5kcG9pbnRzIHRoYXQgZ2VuZXJhdGUg dGhlIFNJUCBSZXNwb25zZXMgYW5kIHRvIHF1b3RlIFJGQyA4MjI0LAogICAgU2VjdGlvbiAz Ojxicj4KICAgIDxicj4KICAgIMKgwqAgTm90ZSB0aGF0IHRoZSBzY29wZSBvZiB0aGlzIGRv Y3VtZW50IGlzIGxpbWl0ZWQgdG8gcHJvdmlkaW5nIGFuPGJyPgogICAgwqDCoCBpZGVudGl0 eSBhc3N1cmFuY2UgZm9yIFNJUCByZXF1ZXN0czsgc29sdmluZyB0aGlzIHByb2JsZW0gZm9y IFNJUDxicj4KICAgIMKgwqAgcmVzcG9uc2VzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRo aXMgd29yayAoc2VlIFtSRkM0OTE2XSkuIDxicj4KICAgIDxicj4KICAgIFRodXMsIEkgc3Rp bGwgZG9uJ3Qgc2VlIGhvdyB5b3UgZ2V0IHRoZXNlIGVuZHBvaW50IElkZW50aXR5CiAgICBh c3NlcnRpb25zIHNlbnQgYWNyb3NzIHdpdGggM1BDQy4gTWF5YmUgd2UgbmVlZCBzb21lYm9k eSBlbHNlIHRvCiAgICBjaGltZSBpbiBhdCB0aGlzIHBvaW50LiA8YnI+CiAgICA8YnI+CiAg ICBKb24vQ3VsbGVuL0VrcjogQXMgYXV0aG9ycyBvZiBSRkMgODIyNCwgY2FuIHlvdSBoZWxw IHNoZWQgbGlnaHQgb24KICAgIHRoaXMgcGFydCBvZiB0aGUgdGhyZWFkID8gPGJyPgogICAg PGJyPgogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIKICAgICAgY2l0ZT0ibWlkOmVhODBk NTBiLTk0NjMtNGJiNC1hYzg5LTg2Mjk4N2E5NDU4NUB3d3cuZmFzdG1haWwuY29tIj4KICAg ICAgPHByZSBjbGFzcz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj4KPC9wcmU+CiAgICAgIDxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPgogICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PgogICAgICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+CiAgICAgICAgICAgIDxwcmUg Y2xhc3M9Im1vei1xdW90ZS1wcmUiIHdyYXA9IiI+wqBUaGUgdGV4dCByZWFkcyB3ZWxsLCBi dXQgSSdtIHN0aWxsIGxlZnQgd2l0aCB0aGUgc2FtZSBxdWVzdGlvbjrCoCBTZWN0aW9uIDMu MSwgc2Vjb25kIHBhcmFncmFwaCBzYXlzIHRoZXJlIGFyZSB0d28gc2VwYXJhdGUgc2Vzc2lv bnMgKEkgdGFrZSB0aGF0IHRvIG1lYW4gU0lQIHNlc3Npb25zKS4gSXQgdGhlbiBnb2VzIG9u IHRvIHNheSDCoCAiSW4gdGhlIGZpcnN0IHNlc3Npb24sIFBhdHN5IGlzIHByZXNlbnRlZCB3 aXRoIHRoZSBvcHRpb24gdG8gY29tbXVuaWNhdGUgd2l0aCBOb3JtYSAiwqAgSWYgSSB1bmRl cnN0YW5kIGNvcnJlY3RseSwgdGhpcyBtZWFucyB0aGVyZSBpcyBhIFNJUCBJTlZJVEUgc2Vu dCBieSBNYWxsb3J5IHRvIFBhdHN5LCBob3dldmVyIE1hbGxvcnkgc29tZWhvdyBhc3NlcnRz IE5vcm1hJ3MgaWRlbnRpdHkgdG8gUGF0c3kuIEhvdyBpcyBNYWxsb3J5IGFibGUgdG8gZG8g dGhhdCBpZiB3ZSBhcmUgdXNpbmcgU0lQIEF1dGhlbnRpY2F0ZWQgSWRlbnRpdHkgPyBJJ20g bm90IHN1cmUgaWYgdGhlIGFib3ZlIHdvdWxkIGJlIGNsZWFyZSBpZiB0aGUgZmxvdyB3YXMg ZXhwYW5kZWQgdG8gc2hvdyBJTlZJVEUgYW5kIDIwMC1PSy4gwqBZZWFoLCBJIHJlYWxseSB3 YW50IHRvIGF2b2lkIGFkZGluZyBhbGwgdGhlIFNJUCBzdHVmZiBoZXJlLsKgIFRoZXJlIHdv dWxkIGJlIGxvdHMgb2YgaXJyZWxldmFudCBtZXNzYWdlcyBpbnZvbHZlZCBhbmQgaXQgZGlz dHJhY3RzIGZyb20gdGhlIG1lc3NhZ2UuwqBUaGUga2V5IGluc2lnaHQgaGVyZSBpcyB0aGF0 IFNJUCBpZGVudGl0eSBvbmx5IGNlcnRpZmllcyBhIHNtYWxsIG51bWJlciBvZiBmaWVsZHMg YW5kIHRoYXQgdGhlIHJlc3Qgb2YgdGhlIHNlc3Npb24gaXMgb3BlbiB0byBiZSBtb2RpZmll ZCBieSB0aGUgc2lnbmFsaW5nIHNlcnZlci7CoCBSRkMgODIyNSBvbmx5IGNvdmVycyB0aGUg aWRlbnRpdHkgKDxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9InNpcDpu b3JtYUBleGFtcGxlIj5zaXA6bm9ybWFAZXhhbXBsZTwvYT4gb3IgPGEgY2xhc3M9Im1vei10 eHQtbGluay1mcmVldGV4dCIgaHJlZj0idGVsOisxMjM0NTU1Njc4OSI+dGVsOisxMjM0NTU1 Njc4OTwvYT4pIGFuZCB0aGUgYT1maW5nZXJwcmludCB2YWx1ZXMsIGV2ZXJ5dGhpbmcgZWxz ZSBpcyBvcGVuIHRvIGF0dGFjay7CoCBTbyBpZiB3ZSBhbGxvdyBNYWxsb3J5IHRoZSBhYmls aXR5IHRvIG1vZGlmeSBzaWduYWxpbmcsIHRoZXJlIGlzIGEgbG90IHNoZSBjYW4gZG8uwqAg SW4gcHJhY3RpY2UgaG93ZXZlciwgdGhpcyBkb2Vzbid0IHJlcXVpcmUgbXVjaCBvZiBhbiBh dHRhY2sgb24gdGhlIHNlc3Npb24sIG90aGVyIHRoYW4gKG1heWJlKSB0byBzdWJzdGl0dXRl IHRyYW5zcG9ydCBwYXJhbWV0ZXJzLsKgJmd0O0Zyb20gdGhlIHBlcnNwZWN0aXZlIG9mIFNJ UCBhbmQgU0lQIGlkZW50aXR5LCB0aGVzZSBhcmUgbGFyZ2VseSBsZWdpdGltYXRlIHNlc3Np b25zLsKgIFRoZSBhdHRhY2sgb24gc2lnbmFsaW5nIGlzIG5lY2Vzc2FyeSBvbmx5IHRvIHRo ZSBleHRlbnQgdGhhdCB0aGUgYXR0YWNrIGFsc28gZGVwZW5kcyBvbiDCoEkndmUgYWRkZWQg bW9yZSB0ZXh0IGhlcmUsIHJlYWxpemluZyB0aGF0IGl0IHdhcyBhIGxpdHRsZSBsaWdodC7C oCBUaGlzIGlzIHRoZSB1cGRhdGVkIHNlY3Rpb24gaW4gZnVsbDrCoCJUaGUgYXR0YWNrIHJl cXVpcmVzIHRoYXQgTWFsbG9yeSBvYnRhaW4gYW4gaWRlbnRpdHkgYmluZGluZyBmb3IgaGVy IG93biBpZGVudGl0eXdpdGggdGhlIGZpbmdlcnByaW50cyBwcmVzZW50ZWQgYnkgUGF0c3kg KFApLsKgIFRoaXMgZmFsc2UgYmluZGluZyBpcyB0aGVucHJlc2VudGVkIHRvIE5vcm1hIChT aWduYWxpbmcxIGluIHRoZSBmaWd1cmUpLgo8L3ByZT4KICAgICAgICAgIDwvYmxvY2txdW90 ZT4KICAgICAgICA8L2Jsb2NrcXVvdGU+CiAgICAgICAgPHByZSBjbGFzcz0ibW96LXF1b3Rl LXByZSIgd3JhcD0iIj5Zb3UgbWVhbiBTaWduYWxpbmcyIGluIHRoZSBmaWd1cmUgKGJlbG93 KSwgcmlnaHQgPyAKCgogTm9ybWEgTWFsbG9yeSBQYXRzeQogKGZwPU4pIC0tLS0tIChmcD1Q KQogfCB8IHwKIHwgfCZsdDstLS0tIFNpZ25hbGluZzEgLS0tLS0tJmd0O3wKIHwgfCBOb3Jt YT1OIFBhdHN5PVAgfAogfCZsdDstLS0tIFNpZ25hbGluZzIgLS0tLS0tJmd0O3wgfAogfCBO b3JtYT1OIE1hbGxvcnk9UCB8IHwKIHwgfAogfCZsdDs9PT09PT09PT09PT09PT09PURUTFMg KGZwPU4sUCk9PT09PT09PT09PT09PT09PSZndDt8CiB8IHwKIChwZWVyID0gTWFsbG9yeSEp IChwZWVyID0gTm9ybWEpCgogRmlndXJlIDE6IEV4YW1wbGUgQXR0YWNrIG9uIElkZW50aXR5 IEJpbmRpbmdzCjwvcHJlPgogICAgICA8L2Jsb2NrcXVvdGU+CiAgICAgIDxwcmUgY2xhc3M9 Im1vei1xdW90ZS1wcmUiIHdyYXA9IiI+Ckkgc3dhcHBlZCB0aGUgdHdvIGZsb3dzIGluIHRo ZSBmaWd1cmUgc28gdGhhdCBpdCBtb3JlIGNsb3NlbHkgbWF0Y2hlcyB0aGUgdGV4dC4KPC9w cmU+CiAgICA8L2Jsb2NrcXVvdGU+CiAgICBPay4gPGJyPgogICAgPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIKICAgICAgY2l0ZT0ibWlkOmVhODBkNTBiLTk0NjMtNGJiNC1hYzg5LTg2Mjk4 N2E5NDU4NUB3d3cuZmFzdG1haWwuY29tIj4KICAgICAgPHByZSBjbGFzcz0ibW96LXF1b3Rl LXByZSIgd3JhcD0iIj4KPC9wcmU+CiAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPgog ICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPgogICAgICAgICAgPHByZSBjbGFzcz0i bW96LXF1b3RlLXByZSIgd3JhcD0iIj7CoMKgIlBhdHN5IGNvdWxkIGJlIHNpbWlsYXJseSBk dXBlZCwgYnV0IGluIHRoaXMgZXhhbXBsZSwgYSBjb3JyZWN0IGJpbmRpbmcgYmV0d2Vlbk5v cm1hJ3MgaWRlbnRpdHkgYW5kIGZpbmdlcnByaW50IChOKSBpcyBmYWl0aGZ1bGx5IHByZXNl bnRlZCBieSBNYWxsb3J5LsKgIFRoaXNzZXNzaW9uIChTaWduYWxpbmcyIGluIHRoZSBmaWd1 cmUpIGNhbiBiZSBlbnRpcmVseSBsZWdpdGltYXRlLgo8L3ByZT4KICAgICAgICA8L2Jsb2Nr cXVvdGU+CiAgICAgICAgPHByZSBjbGFzcz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj5TaWdu YWxpbmcxID8gCgoKCjwvcHJlPgogICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPgog ICAgICAgICAgPHByZSBjbGFzcz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj7CoCJBIERUTFMg c2Vzc2lvbiBpcyBlc3RhYmxpc2hlZCBkaXJlY3RseSBiZXR3ZWVuIE5vcm1hIGFuZCBQYXRz eS7CoCBJbiAKPC9wcmU+CiAgICAgICAgPC9ibG9ja3F1b3RlPgogICAgICAgIDxwcmUgY2xh c3M9Im1vei1xdW90ZS1wcmUiIHdyYXA9IiI+b3JkZXIgZm9ydGhpcyB0byBoYXBwZW4gTWFs bG9yeSBjYW4gc3Vic3RpdHV0ZSB0cmFuc3BvcnQtbGV2ZWwgCmluZm9ybWF0aW9uIGluIGJv dGhzZXNzaW9ucyB0byBmYWNpbGl0YXRlIHRoaXMsIHRob3VnaCB0aGlzIGlzIG5vdCAKbmVj ZXNzYXJ5IGlmIE1hbGxvcnkgaXMgb24gdGhlbmV0d29yayBwYXRoIGJldHdlZW4gTm9ybWEg YW5kIFBhdHN5LsKgIkFzIAphIHJlc3VsdCwgUGF0c3kgY29ycmVjdGx5IGJlbGlldmVzIHRo YXQgc2hlIGlzIGNvbW11bmljYXRpbmcgd2l0aCBOb3JtYS4KCkkgZG9uJ3QgZm9sbG93IHRo ZSBhYm92ZSBzZW50ZW5jZSAoanVzdCBsaWtlIEkgZG9uJ3QgZm9sbG93IHRoZSAKc2VudGVu Y2UgSSByZWZlcmVuY2VkIG9yaWdpbmFsbHksIGkuZS4gIkluIHRoZSBmaXJzdCBzZXNzaW9u LCBQYXRzeSBpcyAKcHJlc2VudGVkIHdpdGggdGhlIG9wdGlvbiB0byBjb21tdW5pY2F0ZSB3 aXRoIE5vcm1hIi4KCklmIHdlIGRvdWJsZS1jbGljayBvbiAiU2lnbmFsaW5nMSIsIHRoZW4g SSBiZWxpZXZlIHdlIHN0YXJ0IHdpdGg6CgogSU5WSVRFKEZyb206IE1hbGxvcnksIFRvOiBQ YXRzeSwgRmluZ2VycHJpbnQ6Tm9ybWEsIApJZGVudGl0eTp7RnJvbTpNYWxsb3J5LCBGaW5n ZXJwcmludDpOb3JtYX0pCgpJbXBsaWNpdCBpbiB0aGUgc2VudGVuY2UgYWJvdmUgaXMgYW4g YXNzdW1wdGlvbiB0aGF0ICpNYWxsb3J5KiBpcyAKc29tZWhvdyBhYmxlIHRvIGdlbmVyYXRl IGFuIElOVklURSB0byBQYXRzeSB3aXRoIGFuIElkZW50aXR5IGhlYWRlciAKdGhhdCBhdXRo ZW50aWNhdGVzICpOb3JtYSogYXMgdGhlIG9yaWdpbmF0b3IsIGkuZS46CgogSU5WSVRFKEZy b206IE5vcm1hLCBUbzogUGF0c3ksIEZpbmdlcnByaW50Ok5vcm1hLCAKSWRlbnRpdHk6e0Zy b206Tm9ybWEsIEZpbmdlcnByaW50Ok5vcm1hfSkKCkhvdyBpcyB0aGF0IHBvc3NpYmxlID8g V2hhdCBhbSBJIG1pc3NpbmcgaGVyZSA/IAo8L3ByZT4KICAgICAgPC9ibG9ja3F1b3RlPgog ICAgICA8cHJlIGNsYXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIiPgpUaGUgc2VjdGlvbiBz dGFydHMgd2l0aCAiaXQgaXMgYXNzdW1lZCB0aGF0IHRoZSBhdHRhY2tlciBhbHNvIGNvbnRy b2xzIHRoZSBzaWduYWxpbmcgY2hhbm5lbC4iICBXZSBhbGxvdyB0aGlzIHBvc3NpYmlsaXR5 IGJlY2F1c2UgdGhlIHVzZSBvZiBhbiBpZGVudGl0eSBhc3NlcnRpb24gYXNzdW1lcyBhIG1v cmUgY2FwYWJsZSBhdHRhY2tlci4gIE1vcmUgbGlrZWx5LCB0aGlzIGFzc3VtZXMgdGhhdCB3 ZSBhcmUgZGVmZW5kaW5nIGFnYWluc3QgdGhlIHNpZ25hbGluZyBzZXJ2aWNlIGl0c2VsZi4K Ck9uY2UgeW91IGdldCBpbnRvIHRoYXQgc3RhdGUsIGl0J3MgdHJpdmlhbCBmb3IgTWFsbG9y eSB0byBjb25zdHJ1Y3QgdGhlIGFib3ZlIG1lc3NhZ2VzLiAgTm90ZSB0aGF0IE5vcm1hIHdp bGwgcHJvdmlkZSBNYWxsb3J5IHdpdGggYW4gaWRlbnRpdHkgYXNzZXJ0aW9uIHRoYXQgYmlu ZHMgdGhlIGlkZW50aXR5ICJOb3JtYSIgdG8gTm9ybWEncyBmaW5nZXJwcmludHMgYXMgcGFy dCBvZiB0aGUgTm9ybWEmbHQ7LSZndDtQYXRzeSBzZXNzaW9uLiAgU28gYWxsIHRoYXQgTWFs bG9yeSBuZWVkcyB0byBkbyBpcyBmaXQgdGhhdCBpbnRvIGEgcGxhdXNpYmxlIElOVklURS48 L3ByZT4KICAgIDwvYmxvY2txdW90ZT4KICAgIE9rIC0gSSB0aGluayB5b3UgYXJlIHNheWlu ZyBhIGJpdCBtb3JlIGFjdHVhbGx5LiBVc2luZyB0aGUKICAgIHRlcm1pbm9sb2d5IG9mIFJG QyA4MjI0LCBJIGJlbGlldmUgeW91IGFyZSBhc3N1bWluZyB0aGF0IHRoZQogICAgYXR0YWNr ZXIgY29udHJvbHMgdGhlIEF1dGhlbnRpY2F0aW9uIFNlcnZpY2UgKHdoaWNoIEkgc2VlIGFz IG1vcmUKICAgIHRoYW4gdGhlIHNpZ25hbGluZyBjaGFubmVsKS4gSWYgdGhhdCBpcyB0aGUg Y2FzZSwgdGhlbiBJIHdvdWxkCiAgICBzdWdnZXN0IGNsYXJpZnlpbmcgdGhhdCBpbiB0aGUg dGV4dC4gPGJyPgogICAgPGJyPgogICAgVGhhbmtzIDxicj4KICAgIDxicj4KICAgIC0tIEZs ZW1taW5nIDxicj4KICAgIDxicj4KICAgIDxicj4KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNp dGUiCiAgICAgIGNpdGU9Im1pZDplYTgwZDUwYi05NDYzLTRiYjQtYWM4OS04NjI5ODdhOTQ1 ODVAd3d3LmZhc3RtYWlsLmNvbSI+CiAgICAgIDxwcmUgY2xhc3M9Im1vei1xdW90ZS1wcmUi IHdyYXA9IiI+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwptbXVzaWMgbWFpbGluZyBsaXN0CjxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2 aWF0ZWQiIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciPm1tdXNpY0BpZXRmLm9yZzwv YT4KPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9hPgo8L3ByZT4KICAgIDwvYmxvY2txdW90ZT4K ICAgIDxicj4KICA8L2JvZHk+CjwvaHRtbD4K --------------0F0AF69C93F72CF2BFE27F0F-- From nobody Mon Apr 8 17:20:20 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A17A1200DE; Mon, 8 Apr 2019 17:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=LRgLfoYI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SVCNK8wX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UOJwg0HglQ9; Mon, 8 Apr 2019 17:20:16 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9251A1200C7; Mon, 8 Apr 2019 17:20:16 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 6DF75A12; Mon, 8 Apr 2019 20:20:15 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Mon, 08 Apr 2019 20:20:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=Ol+dO9q//kNGLoN0XVk2t530huwj 7+MisswxyiCbTYE=; b=LRgLfoYIr2MO7RfG3sK32l/Pvs67A2xZz2vmUjb0CD7g 0ZcDB7ts9yd8wxIC0kEC3qMEmm4IBdPABG2TOYbQmoT7OgJzwPZ+EELligpcDFTP yDLXnbCKiAF8Ol3i7MrzlZW4tVi0LkjpIaP4uMwz2/POWqkk1pU/uNPlW4Mlf0KT iQu/ZU0r2lOsldLhhkUZyhrCE4Y+1tGpEtDKGh8WLirHL+U2iEEcnjgY4/Z94ftb JdlqsQRrlheH86h8RZPVZK46I9+DnnXW7iPHWmws2bCprvdBwlKdhZGIwUU7cX1p ZRiM4+Q6Y08P2Ta5JPtn93KQDGP5U1SCjCmZxr/Q6w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Ol+dO9 q//kNGLoN0XVk2t530huwj7+MisswxyiCbTYE=; b=SVCNK8wX9n7MZhEd+/av+g dG2vBFVf12VYnHGTSPqiQGkrtYtCLDp+mP6QLWlVn9uHrP5XytH3EQ+1upmPFNdn A3wRR03IIolwkQdkUsI7kDvhOKgTC2SzZb2DA7rhHN8GMixFN/521qQkqwlCttfL AWvQXAIALTE5qdLKPnd92m9eI17igEjXCLLsb40QBJNiHh6NXTt5QJMwV7u97FDT PwFRQOejw5b66u502w48WUjPO8O0YVkoqfNeKl5Eo7zpMmF2ov17pAJl+671fvCa 8yYPKIfXKITb0VHNaiy3bOFe1h/zxUrGEySUK2TLuW5DGayctPQknUqsBbr1JCVA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeggdefudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucfrrg hrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhu shhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2C83B7C1B9; Mon, 8 Apr 2019 20:20:14 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 92534000 Message-Id: <0de3648b-e750-41a7-819d-59d1bbf5ad70@www.fastmail.com> In-Reply-To: <4a6a7d47-bd49-ed20-561e-ed4223f2d190@cisco.com> References: <69e1ed84-7bae-4258-897b-a6d36716c261@www.fastmail.com> <718ce899-166c-b793-c7d4-84bb5fcceea5@cisco.com> <4a6a7d47-bd49-ed20-561e-ed4223f2d190@cisco.com> Date: Mon, 08 Apr 2019 20:20:14 -0400 From: "Martin Thomson" To: "Flemming Andreasen" , "Bo Burman" , mmusic , "Jon Peterson" , "Cullen Jennings" , "'Eric Rescorla'" Cc: "draft-ietf-mmusic-sdp-uks@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-uks-03 X-BeenThere: mmusic@ietf.org 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: Tue, 09 Apr 2019 00:20:18 -0000 On Tue, Apr 9, 2019, at 06:48, Flemming Andreasen wrote: > Offers and SIP Requests are not the same. In RFC 3725 Flow 2 and 3, it > is the controller that generates the SIP Requests and the endpoints > that generate the SIP Responses and to quote RFC 8224, Section 3: > > Note that the scope of this document is limited to providing an > identity assurance for SIP requests; solving this problem for SIP > responses is outside the scope of this work (see [RFC4916]). Right. What is relevant here is the offers and answers, not the SIP requests. RFC 3725 shows only inconsequential offers being generated by the controller. In the RFC 8224 context, this remains true, but it is hard to see why (more on that below). > Thus, I still don't see how you get these endpoint Identity assertions > sent across with 3PCC. Maybe we need somebody else to chime in at this > point. > > Jon/Cullen/Ekr: As authors of RFC 8224, can you help shed light on > this part of the thread ? [...] > Ok - I think you are saying a bit > more actually. Using the terminology of RFC 8224, I believe you are > assuming that the attacker controls the Authentication Service (which I > see as more than the signaling channel). If that is the case, then I > would suggest clarifying that in the text. I don't believe that is the case. But I see now the angle you are concerned about. Because RFC 8224 doesn't consider 3PCC, we might have a problem in the sense that 3PCC doesn't work at all with SIP Identity, but let's see if we can work out what it looks like. Note that "signing" as imagined in RFC 8224 depends on there being SDP to sign. If there is SDP and it is not bogus, then there is potentially a binding between the a=fingerprint attributes and some identity. Whether that is in the SIP Identity header field (RFC 8224) or the SDP itself (WebRTC), the result is the same. For 3PCC with RFC 8224, either the controller is responsible for signing, the signing is performed by proxies near A and B (proxies that are not shown in the figure), or by A and B directly. The point of the signature is to protect against attack between the point that the signature is added and where it is removed. If the controller is both signing and consuming signatures, that would be pointless because they would be trusted by both A and B, so we'll ignore that case. Therefore, we assume that signatures happen closer to A or B (or both) so that the signatures serve a purpose. So we have: A---AuthSvcA---...---AuthSvcB---B with a controller somewhere on the signaling path between the two ends. Generally, RFC 8224 assumes that the path from A to its Authentication Service is "trusted", so the attack is on the path between the two Authentication Services. The controller can be anywhere, because we're not assuming anything about that. You might wonder whether the controller can generate bogus SDP that can be signed, but that is a constraint on deployment, not on security. Bogus SDP generated by a controller that sits on the "untrusted" portion of the signaling path won't be signed and therefore might be rejected, but that just limits the choices the controller has. If the controller is on a "trusted" segment, then it might generate SDP for the endpoint nearest to it and have a valid signature over that content. The attack that we're contemplating acts on the "untrusted" segment of the signaling path. It operates without collaboration with any of the "trusted" entities. It relies on being able to intercept and modify signaling on that path segment. That's all. In all cases other than the nonsensical one where the controller acts as Authentication Service for both parties, the attack we're considering doesn't depend on the Authentication Service being compromised. In the extreme case, say that A and B sign their own SDP/signaling and assert their own identities. If the controller is the attacker, they control when sessions are established and how. They can copy-paste signatures between the different messages they receive. From nobody Mon Apr 8 17:51:32 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14ACB12018E; Mon, 8 Apr 2019 17:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ch3m4.com header.b=SulWV3xS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gmF61y/T Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJS3Hy5FlLo8; Mon, 8 Apr 2019 17:51:28 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B976D12003E; Mon, 8 Apr 2019 17:51:28 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id C60C12389A; Mon, 8 Apr 2019 20:51:27 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 08 Apr 2019 20:51:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ch3m4.com; h= from:to:cc:date:message-id:in-reply-to:references:subject :mime-version:content-type; s=fm3; bh=LVQvBHFMFZsrb2K4wiZAjbjY7D ulR0rv8DzurS/C1l4=; b=SulWV3xSjw5Ut/tfHUz7iZUskeYpVUNx8elzqBVL1e Nsz0FWkfGDe1oyei1GsRs6FrGXOlbIPxhSeqfMGOtncyvXmNixZA5NJ3faf8pvtM LWnuRMZ7zZ30gtXWJiHnbQw2mQcK6agS4ciGOiiOH7fjjKLVhOv9KQP8hu11wVbw eSD6DU04cDli8ZOdJhvt5HaMSV8nKtgS3BeJ4Uc6iVudCMVs7iWX1G2/n8XjAD5w Xka4lKukTyJe8iaSMybI39ESiYaz8lrXSSeT4hi92zWzDR1jXZrYxhAS4hL46sUu dvxCrLLB0XYkz0cOr9MQ0nBJj0qK2UCT19Wu1bCNW4Zg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=LVQvBH FMFZsrb2K4wiZAjbjY7DulR0rv8DzurS/C1l4=; b=gmF61y/TCieh1QUkg3Ycdi qDk8TXeWGBuDkB6jm+ZxbjRrtHIbWorvLwaXz8QWKZCBeegyo6xGaOJ7QdDvqlua CwhbFhNcGdyzSRn/v85DlAO3U8hel50DEkswr4m0QyKsbee7xrDnYFu3a/ENiW6b +rboGgjmoxg6n+hUL74T71UwcOZR/UHzCbcZLyABhU6EigY3HQLiRR0f3tBu8Q9c JVUwWs3awA+HtGbMG50RmVbeuzRGXgDQG0DzCJoSuA/vyWn7mgTFCdlVgwmP2R+l 6895HTAiq3ux7smwo7wdbgYMqUsTzkKZBXQOiwSoqVY+JzjCZDn8zkn4I003WHVw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudeggdefkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfffkfgjfhgfufggtgesrgdtgiertderjeenucfhrhhomheplfhoshgvuceo jhhoshgvsegthhefmhegrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecukf hppeekkedrvdeirddvgedtrddvgedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehjohhs vgestghhfehmgedrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from [172.26.2.33] (240.red-88-26-240.staticip.rima-tde.net [88.26.240.240]) by mail.messagingengine.com (Postfix) with ESMTPA id 34E5110390; Mon, 8 Apr 2019 20:51:26 -0400 (EDT) From: Jose To: Bo Burman , "mmusic (mmusic@ietf.org)" CC: , "'draft-ietf-mmusic-msrp-usage-data-channel@ietf.org'" Date: Tue, 09 Apr 2019 02:51:23 +0200 Message-ID: <169ff93fb10.27b0.02c1a8dc550b72ede4852a844e2c4166@ch3m4.com> In-Reply-To: References: User-Agent: AquaMail/1.19.0-1434 (build: 101900002) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------169ff93ff3c48d327b07408a2" Archived-At: Subject: Re: [MMUSIC] Re-adoption call for draft-ietf-mmusic-msrp-usage-data-channel X-BeenThere: mmusic@ietf.org 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: Tue, 09 Apr 2019 00:51:31 -0000 This is a multi-part message in MIME format. ------------169ff93ff3c48d327b07408a2 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit I support draft re-adoption, I will review, provide content and continue serving as editor. JM On April 3, 2019 13:34:40 Bo Burman wrote: > MMUSIC, > > This is a 1-week call to re-adopt “Submit SDP Negotiation of MSRP over Data > Channels as Proposed Standard†as an MMUSIC WG milestone, reviving the > expired draft-ietf-mmusic-msrp-usage-data-channel as document. > > We have received renewed interest in progressing this draft and a number of > people have stated that they are willing to work on it. > > If you support that adoption, please respond to the list by Friday April > 12, 23:59 UTC. If you oppose WG adoption, have comments, or concerns, > please reply either to this thread or directly to the chairs/authors (if > needed). > > Thanks, > /Bo > MMUSIC co-chair > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic ------------169ff93ff3c48d327b07408a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support draft re-adoption, I will review, provide conte= nt and continue serving as editor.

JM


On April 3, 2019 13:34:40 Bo Burman <bo.burman@ericsson.com>= wrote:

MMUSIC,

 

This is a = 1-week call to re-adopt =E2=80=9CSubmit SDP Negotiation of MSRP over Data C= hannels as Proposed Standard=E2=80=9D as an MMUSIC WG milestone, reviving t= he expired draft-ietf-mmusic-msrp-usage-data-channel as do= cument.

 

We have received renewed interest in progressing this draft = and a number of people have stated that they are willing to work on it.

 

If you support that adoption, please respond to the list by Friday April= 12, 23:59 UTC. If you oppose WG adoption, have comments, or concerns, plea= se reply either to this thread or directly to the chairs/authors (if needed= ).

 

Thanks,

/Bo

MMUSIC co-chair

 

_______________________________________________
mmusic mailing list

------------169ff93ff3c48d327b07408a2-- From nobody Tue Apr 9 02:00:33 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7CA7120195; Tue, 9 Apr 2019 02:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RmkxLwbf3aA; Tue, 9 Apr 2019 02:00:22 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30046.outbound.protection.outlook.com [40.107.3.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12966120044; Tue, 9 Apr 2019 02:00:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Dq/7YU0NfNhSdOvPDA/cxaltODwch1AQGyRXY5ivu5c=; b=CUtGGidZdFhsVR+mLvfKnmFWFc/rizorKDEv7LimFAIVJC3o6HtXPBSU974aINA2lNkfSXAgy0LumH+2loTNi2y5XrnRyRL0ijno8QdDPpYWzh3UkZLqMsJ8InJ58/AmChNqzPkshcI8eiQ/hRkdYJC3wMEVL3gVO4HBN+2sBig= Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2537.eurprd07.prod.outlook.com (10.168.128.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.11; Tue, 9 Apr 2019 09:00:19 +0000 Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::107c:5f27:2ef:8505]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::107c:5f27:2ef:8505%5]) with mapi id 15.20.1792.009; Tue, 9 Apr 2019 09:00:19 +0000 From: Magnus Westerlund To: Adam Roach , The IESG CC: "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-data-channel-sdpneg@ietf.org" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT) Thread-Index: AQHU66fNA40h4UsP7kq3a/Vv5QT6wQ== Date: Tue, 9 Apr 2019 09:00:18 +0000 Message-ID: References: <155446588097.13196.6373243259627185094.idtracker@ietfa.amsl.com> <1afcb116-36cb-be51-81ac-e78fc52c9255@nostrum.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.81] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 17f37535-e8b0-4adc-f8fb-08d6bcc9ca71 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2537; x-ms-traffictypediagnostic: HE1PR0701MB2537: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(366004)(346002)(136003)(396003)(189003)(199004)(966005)(256004)(229853002)(14454004)(6436002)(99286004)(478600001)(74316002)(86362001)(7736002)(66066001)(5660300002)(97736004)(44832011)(3846002)(52536014)(25786009)(606006)(6116002)(110136005)(316002)(54906003)(102836004)(106356001)(6506007)(7696005)(26005)(76176011)(53546011)(54896002)(2906002)(53936002)(6246003)(446003)(486006)(186003)(71190400001)(71200400001)(9686003)(33656002)(68736007)(476003)(105586002)(8676002)(55016002)(81166006)(81156014)(6306002)(8936002)(236005)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2537; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: SaQdmhmULx/noP3kI9OV9V1PWnBYKQgWBgEIPyMDS71KJRn5RQXDq6vpOOMPFvICG5LGUY7Fr7WaBkNWRJJ0Y8ls+KlCC0As3bi7f05zbcafAzbj9JKxIT7QsgTKHXXq19GKTZa0hAPMfRQFWZOSDedyYr6ZR0jSuOFWy9yZQgqQETNRnV/72JDUQxV/05DUmX3UbTJ+ycSQmdGiBJubNgz1FNxjg8e1NfjSJiMbnw8EAr4YqfQ4VHk0X43lFFwN277rwpSQkwH/S990S1Q6mZnZM197IOpNHzc8fbGRuHfMyK2HfMG4oplBW0tQVMotlIBjZLF5QP6Gpq/LfFcvfk5NvDMBzXU4ASa/9PCgrPFz5+w09XN+K5xO0AOfRdFDnxQpuC0vQZ3JQIit0jL5OeSmVq7tuiZcIlVcb9V4+6A= Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB252226AB6D1CBCD2DFEFB4AB952D0HE1PR0701MB2522_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 17f37535-e8b0-4adc-f8fb-08d6bcc9ca71 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2019 09:00:18.8577 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2537 Archived-At: Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT) X-BeenThere: mmusic@ietf.org 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: Tue, 09 Apr 2019 09:00:25 -0000 --_000_HE1PR0701MB252226AB6D1CBCD2DFEFB4AB952D0HE1PR0701MB2522_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 2019-04-08 17:55, Adam Roach wrote: On 4/5/19 7:04 AM, Magnus Westerlund via Datatracker wrote: ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- There might be a serious issue in label definition. 5.1.3. Label Parameter The 'label' parameter indicates the name of the channel. It represents a label that can be used to distinguish, in the context of the WebRTC API [WebRtcAPI], an RTCDataChannel object from other RTCDataChannel objects. This parameter maps to the 'Label' parameter defined in [I-D.ietf-rtcweb-data-protocol]. The 'label' parameter is optional. If it is not present, then its value defaults to the empty string. label-opt =3D "label=3D" quoted-string quoted-string =3D DQUOTE *(quoted-char / escaped-char) DQUOTE quoted-char =3D SP / quoted-visible quoted-visible =3D %x21 / %x23-24 / %x26-7E ; VCHAR without " or % escaped-char =3D "%" HEXDIG HEXDIG I interpret that as the intention is to enable the SDP Attribute to carry t= he label as defined in W3C API. That value is in the current candidatate specification an https://www.w3.org/TR/webrtc/ as an USVSsting (https://heycam.github.io/webidl/#idl-USVString). And in the reference vers= ion of the WebRTC API as an DOMstring. Both are not limited to ASCII and may contain any Unicode characters. Thus the escaping mechanism defined appear = to be insufficient. I think the "quoted-string" need a definition of what type of string this t= ruly are so that it is clear what a character in the string is. In addition the specification of escaping is undersspecified. I would recom= mend at least adding discussion of the need and how to escape DQUOTE and % that = can be relatively common operations. I can see that this could benefit from some explicit detail about how to co= nvert the cited USVString string into the "quoted-string" construct defined= here. I think this roughly consists of: * Serialize the WebRTC label as a UTF-8 string * Treat the UTF-8 serialization as a series of bytes * For each byte in the serialization: * If the byte can be expressed as a `quoted-char`, do so * Otherwise, express the byte as an `escaped-char`. Would including text to that effect satisfy your concern? Yes it would be clear what is expected. However, I fail to understand why o= ne need to ASCIIify and escape the UTF-8 encoded characters where one could= simply define the label value as an UTF-8 string something that is compati= ble with SDP specification. Wouldn't that reduce the set of characters need= ing escaping to a much smaller set. Cheers Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --_000_HE1PR0701MB252226AB6D1CBCD2DFEFB4AB952D0HE1PR0701MB2522_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On 2019-04-08 17:55, Adam Roach wrote:
On 4/5/19 7:04 AM, Magnus Westerlund via Dat= atracker wrote:
------------------------------------=
----------------------------------=0A=
DISCUSS:=0A=
----------------------------------------------------------------------=0A=
=0A=
There might be a serious issue in label definition.=0A=
=0A=
5.1.3.  Label Parameter=0A=
=0A=
   The 'label' parameter indicates the name of the channel.  It=0A=
   represents a label that can be used to distinguish, in the context of=0A=
   the WebRTC API [WebRtcAPI], an RTCDataChannel object from other=0A=
   RTCDataChannel objects.  This parameter maps to the 'Label' parameter=0A=
   defined in [I-D.ietf-rtcweb-data-protocol].  The 'label' parameter is=0A=
   optional.  If it is not present, then its value defaults to the empty=0A=
   string.=0A=
=0A=
  label-opt       =3D "label=3D" quoted-string=0A=
  quoted-string   =3D DQUOTE *(quoted-char / escaped-char) DQUOTE=0A=
  quoted-char     =3D SP / quoted-visible=0A=
  quoted-visible  =3D %x21 / %x23-24 / %x26-7E ; VCHAR without " or %=
=0A=
  escaped-char    =3D "%" HEXDIG HEXDIG=0A=
=0A=
I interpret that as the intention is to enable the SDP Attribute to carry t=
he=0A=
label as defined in W3C API. That value is in the current candidatate=0A=
specification an https://www.w3.org/TR/webrtc/ =
as an USVSsting=0A=
(https://heycam.github.io/webidl/#=
idl-USVString). And in the reference version=0A=
of the WebRTC API as an DOMstring. Both are not limited to ASCII and may=0A=
contain any Unicode characters. Thus the escaping mechanism defined appear =
to=0A=
be insufficient.=0A=
=0A=
I think the "quoted-string" need a definition of what type of str=
ing this truly=0A=
are so that it is clear what a character in the string is.=0A=
=0A=
In addition the specification of escaping is undersspecified. I would recom=
mend=0A=
at least adding discussion of the need and how to escape DQUOTE and % that =
can=0A=
be relatively common operations.


I can see that this could benefit from some explicit detail about how to= convert the cited USVString string into the "quoted-string" cons= truct defined here. I think this roughly consists of:

  • Serialize the WebRTC label as a UTF-8 string
  • Treat the UTF-8 se= rialization as a series of bytes
  • For each byte in the serialization= :
    • If the byte can be expressed as a `quoted-char`, do so
    • Otherwis= e, express the byte as an `escaped-char`.

Would including text to that effect satisfy your concern?

Yes it would be clear what is expected. However, I fail to understand wh= y one need to ASCIIify and escape the UTF-8 encoded characters where one co= uld simply define the label value as an UTF-8 string something that is comp= atible with SDP specification. Wouldn't that reduce the set of characters needing escaping to a much smaller set. =

Cheers

=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.=
com=0A=
----------------------------------------------------------------------



--_000_HE1PR0701MB252226AB6D1CBCD2DFEFB4AB952D0HE1PR0701MB2522_--


From nobody Tue Apr  9 09:51:10 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F33C120899; Tue,  9 Apr 2019 09:50:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZ1xtsE5ZXnN; Tue,  9 Apr 2019 09:50:54 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6726120885; Tue,  9 Apr 2019 09:50:41 -0700 (PDT)
Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x39GoYf4078176 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 9 Apr 2019 11:50:36 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1554828637; bh=R93NQEFIm/SGxvQKoAVth7Hh+DBAR3RzbyPdwazWCjQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=W1MQX9tB/qNvqc+cou1NnxukBlXUyXbCUFNXpTJRjZ2YTgkNUskgcxZY/TqTcp29u kXAsLRiwbIrRmAfAgmD2xIzUjIp6ga1v+vQjSiI8VUJ0uV26qTr2V/rDp5uTs/QR9V 32ey5Jx5Sukhg1hcCkZhxan4DWBEWXfruUXzDAoE=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at
To: Magnus Westerlund , The IESG 
Cc: "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-data-channel-sdpneg@ietf.org" , "mmusic@ietf.org" 
References: <155446588097.13196.6373243259627185094.idtracker@ietfa.amsl.com> <1afcb116-36cb-be51-81ac-e78fc52c9255@nostrum.com> 
From: Adam Roach 
Message-ID: 
Date: Tue, 9 Apr 2019 11:50:29 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------9C9991A020B5A28C0B289A71"
Content-Language: en-US
Archived-At: 
Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)
X-BeenThere: mmusic@ietf.org
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: Tue, 09 Apr 2019 16:50:57 -0000

This is a multi-part message in MIME format.
--------------9C9991A020B5A28C0B289A71
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 4/9/19 4:00 AM, Magnus Westerlund wrote:
> On 2019-04-08 17:55, Adam Roach wrote:
>> On 4/5/19 7:04 AM, Magnus Westerlund via Datatracker wrote:
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>> There might be a serious issue in label definition.
>>>
>>> 5.1.3.  Label Parameter
>>>
>>>     The 'label' parameter indicates the name of the channel.  It
>>>     represents a label that can be used to distinguish, in the context of
>>>     the WebRTC API [WebRtcAPI], an RTCDataChannel object from other
>>>     RTCDataChannel objects.  This parameter maps to the 'Label' parameter
>>>     defined in [I-D.ietf-rtcweb-data-protocol].  The 'label' parameter is
>>>     optional.  If it is not present, then its value defaults to the empty
>>>     string.
>>>
>>>    label-opt       = "label=" quoted-string
>>>    quoted-string   = DQUOTE *(quoted-char / escaped-char) DQUOTE
>>>    quoted-char     = SP / quoted-visible
>>>    quoted-visible  = %x21 / %x23-24 / %x26-7E ; VCHAR without " or %
>>>    escaped-char    = "%" HEXDIG HEXDIG
>>>
>>> I interpret that as the intention is to enable the SDP Attribute to carry the
>>> label as defined in W3C API. That value is in the current candidatate
>>> specification anhttps://www.w3.org/TR/webrtc/  as an USVSsting
>>> (https://heycam.github.io/webidl/#idl-USVString). And in the reference version
>>> of the WebRTC API as an DOMstring. Both are not limited to ASCII and may
>>> contain any Unicode characters. Thus the escaping mechanism defined appear to
>>> be insufficient.
>>>
>>> I think the "quoted-string" need a definition of what type of string this truly
>>> are so that it is clear what a character in the string is.
>>>
>>> In addition the specification of escaping is undersspecified. I would recommend
>>> at least adding discussion of the need and how to escape DQUOTE and % that can
>>> be relatively common operations.
>>
>>
>> I can see that this could benefit from some explicit detail about how 
>> to convert the cited USVString string into the "quoted-string" 
>> construct defined here. I think this roughly consists of:
>>
>>   * Serialize the WebRTC label as a UTF-8 string
>>   * Treat the UTF-8 serialization as a series of bytes
>>   * For each byte in the serialization:
>>       o If the byte can be expressed as a `quoted-char`, do so
>>       o Otherwise, express the byte as an `escaped-char`.
>>
>> Would including text to that effect satisfy your concern?
>>
> Yes it would be clear what is expected. However, I fail to understand 
> why one need to ASCIIify and escape the UTF-8 encoded characters where 
> one could simply define the label value as an UTF-8 string something 
> that is compatible with SDP specification. Wouldn't that reduce the 
> set of characters needing escaping to a much smaller set.
>

That's a little tricky. RFC 4566: "SDP also allows other character sets 
such as ISO 8859-1 to be used when desired."

Even if we just constrain this to SIP, RFC 3261: "When no explicit 
charset parameter is provided by the sender, media subtypes of the 
'text' type are defined to have a default charset value of 'UTF-8'."

So there's a bias towards UTF-8, but no strict requirement.

I'd support a short document that deprecated non-UTF-8 encodings of SDP 
so that specifications like this one could simply assume that the full 
character set can be used directly, but that's not the current state of 
affairs.

/a


--------------9C9991A020B5A28C0B289A71
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 4/9/19 4:00 AM, Magnus Westerlund
      wrote:

    

    

      
      
On 2019-04-08 17:55, Adam Roach
        wrote:

      

      

        
On 4/5/19 7:04 AM, Magnus
          Westerlund via Datatracker wrote:

        

        

          
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

There might be a serious issue in label definition.

5.1.3.  Label Parameter

   The 'label' parameter indicates the name of the channel.  It
   represents a label that can be used to distinguish, in the context of
   the WebRTC API [WebRtcAPI], an RTCDataChannel object from other
   RTCDataChannel objects.  This parameter maps to the 'Label' parameter
   defined in [I-D.ietf-rtcweb-data-protocol].  The 'label' parameter is
   optional.  If it is not present, then its value defaults to the empty
   string.

  label-opt       = "label=" quoted-string
  quoted-string   = DQUOTE *(quoted-char / escaped-char) DQUOTE
  quoted-char     = SP / quoted-visible
  quoted-visible  = %x21 / %x23-24 / %x26-7E ; VCHAR without " or %
  escaped-char    = "%" HEXDIG HEXDIG

I interpret that as the intention is to enable the SDP Attribute to carry the
label as defined in W3C API. That value is in the current candidatate
specification an https://www.w3.org/TR/webrtc/ as an USVSsting
(https://heycam.github.io/webidl/#idl-USVString). And in the reference version
of the WebRTC API as an DOMstring. Both are not limited to ASCII and may
contain any Unicode characters. Thus the escaping mechanism defined appear to
be insufficient.

I think the "quoted-string" need a definition of what type of string this truly
are so that it is clear what a character in the string is.

In addition the specification of escaping is undersspecified. I would recommend
at least adding discussion of the need and how to escape DQUOTE and % that can
be relatively common operations.

        

        


        

        
I can see that this could benefit from some explicit detail
          about how to convert the cited USVString string into the
          "quoted-string" construct defined here. I think this roughly
          consists of:

        
    
          
  • Serialize the WebRTC label as a UTF-8 string
    • 
          
  • Treat the UTF-8 serialization as a series of bytes
    • 
          
  • For each byte in the serialization:
    • 
          
      
            
    • If the byte can be expressed as a `quoted-char`, do so
      • 
            
    • Otherwise, express the byte as an `escaped-char`.
      • 
          
    
        

        
Would including text to that effect satisfy your concern?

      

      
Yes it would be clear what is expected. However, I fail to
        understand why one need to ASCIIify and escape the UTF-8 encoded
        characters where one could simply define the label value as an
        UTF-8 string something that is compatible with SDP
        specification. Wouldn't that reduce the set of characters
        needing escaping to a much smaller set. 

      

    

    


    

    
That's a little tricky. RFC 4566: "SDP also allows other
      character sets such as ISO 8859-1 to be used when desired." 

    

    
Even if we just constrain this to SIP, RFC 3261: "When no
      explicit charset parameter is provided by the sender, media
      subtypes of the 'text' type are defined to have a default charset
      value of 'UTF-8'."

    
So there's a bias towards UTF-8, but no strict requirement.

    
I'd support a short document that deprecated non-UTF-8 encodings
      of SDP so that specifications like this one could simply assume
      that the full character set can be used directly, but that's not
      the current state of affairs.

    
/a

    

  


--------------9C9991A020B5A28C0B289A71--


From nobody Tue Apr  9 10:10:17 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA781200C3; Tue,  9 Apr 2019 10:10:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3l2akAdazbf; Tue,  9 Apr 2019 10:10:00 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946BE12008C; Tue,  9 Apr 2019 10:10:00 -0700 (PDT)
Received: from 50-207-252-210-static.hfc.comcastbusiness.net (50-207-252-210-static.hfc.comcastbusiness.net [50.207.252.210]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x39H9at0005737 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 9 Apr 2019 13:09:37 -0400
To: Zitao Wang , ops-dir@ietf.org
Cc: ietf@ietf.org, draft-ietf-mmusic-rfc4566bis.all@ietf.org, mmusic@ietf.org
References: <155470544191.18201.1340122970628374639@ietfa.amsl.com>
From: Paul Kyzivat 
Message-ID: 
Date: Tue, 9 Apr 2019 13:10:58 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <155470544191.18201.1340122970628374639@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [MMUSIC] Opsdir last call review of draft-ietf-mmusic-rfc4566bis-34
X-BeenThere: mmusic@ietf.org
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: Tue, 09 Apr 2019 17:10:03 -0000

Thank you for the comments. I have some questions:

On 4/8/19 2:37 AM, Zitao Wang via Datatracker wrote:
> Reviewer: Zitao Wang
> Review result: Has Issues
> 
> Summary:    This memo defines the Session Description Protocol (SDP).  SDP is
> intended for describing multimedia sessions for the purposes of session
> announcement, session invitation, and other forms of multimedia session
> initiation.  This document obsoletes RFC 4566. I think the document make sense
> and is written very clear, except some small nits: 


> # In Section 5, there are
> several terms that miss references, such as "US-ASCII subset of UTF-8",  "ASN.1
> or XDR", etc. 

There is already a reference to the definition of UTF-8 [RFC3629] in 
section 4.5. Do you think the reference needs to be included with every 
use? The US-ASCII subset of UTF-8 is also defined in RFC3629, so I am 
inclined to use the same reference for that. There are also a couple of 
uses of US-ASCII without mention of UTF-8. I'm inclined to change those 
to "the US-ASCII subset of UTF-8".

Regarding ASN.1 and XDR, I can add references if you think it important. 
But their use is very peripheral, and it isn't necessary to know what 
they are to read the text.

# s/session- specific/session-specific/

Regarding "session- specific" vs. "session-specific":

The context for this is:

"Attribute scopes in addition to media- and session- specific may also..."

The space was intentional so that there are equivalent constructions for 
"media" and "session". The intent is as a shorthand for:

"Attribute scopes in addition to media-specific and session-specific may 
also..."

To avoid confusion I think I'll just change to the latter.

# Suggest to add tags on
> "overview optional items" to identified now-obsolete items, such as "a=cat",
> "a=keywds", "k=".

I'm not clear what you want me to do. I guess you are suggesting adding 
something to the first figure in section 5.

I don't see how that would be possible for a=cat and a=keywds, since the 
figure doesn't mention individual attributes. While it is possible to 
add something for k=, IMO it is better to leave that level of detail to 
the complete description in section 5.12.

	Thanks,
	Paul Kyzivat


From nobody Tue Apr  9 10:54:38 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9131203A6; Tue,  9 Apr 2019 10:54:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.679
X-Spam-Level: 
X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZ4FK9733HlH; Tue,  9 Apr 2019 10:54:28 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77A491200EA; Tue,  9 Apr 2019 10:54:28 -0700 (PDT)
Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x39HsH6J088734 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 9 Apr 2019 12:54:18 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1554832460; bh=/r3Ui/f5P54nFIAN2gouCMda74cn9JKG43kOPoFgbKg=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=DOGPwx6dHH2WbwcGSuk9PXQ4DWFf0LYY+XNf+stpwMNb9aPG6PoBxpS5Tm8XVoToN bijxxwP8wEzMufDNoe/q/9ZV3hFNytWQWC3HnQy1C/mVaGYw/I/5IAX2SyyXNviD+6 iMBoPQI6KyV9CcjdTtbuUGrMRpwR8ieEw4mDVj+s=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at
To: Paul Kyzivat , Zitao Wang , ops-dir@ietf.org
Cc: ietf@ietf.org, draft-ietf-mmusic-rfc4566bis.all@ietf.org, mmusic@ietf.org
References: <155470544191.18201.1340122970628374639@ietfa.amsl.com> 
From: Adam Roach 
Message-ID: <97d84d2a-62f5-bfee-a2c2-ccca9394d3a1@nostrum.com>
Date: Tue, 9 Apr 2019 12:54:12 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------A96C64951084B1082C98DAB2"
Content-Language: en-US
Archived-At: 
Subject: Re: [MMUSIC] Opsdir last call review of draft-ietf-mmusic-rfc4566bis-34
X-BeenThere: mmusic@ietf.org
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: Tue, 09 Apr 2019 17:54:30 -0000

This is a multi-part message in MIME format.
--------------A96C64951084B1082C98DAB2
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 4/9/19 12:10 PM, Paul Kyzivat wrote:
> The context for this is:
>
> "Attribute scopes in addition to media- and session- specific may 
> also..."
>
> The space was intentional so that there are equivalent constructions 
> for "media" and "session". The intent is as a shorthand for:
>
> "Attribute scopes in addition to media-specific and session-specific 
> may also..."


For what it's worth, Zitao is correct.

RFC 7322 §1:

    The world of technical publishing has generally accepted rules for
    grammar, punctuation, capitalization, sentence length and complexity,
    parallelism, etc.  The RFC Editor generally follows these accepted
    rules as defined by the Chicago Manual of Style (CMOS) [CMOS]...


CMOS 15th ed §7.89:

    "When the second part of a hyphenated expression is omitted, the
    hyphen is retained, followed by a word space.

    "/fifteen- and twenty-year mortgages/

    "/Chicago- or Milwaukee-bound passengers/"


> To avoid confusion I think I'll just change to the latter.


That works too.

/a


--------------A96C64951084B1082C98DAB2
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 4/9/19 12:10 PM, Paul Kyzivat wrote:

    

    
The
      context for this is:
      

      

      "Attribute scopes in addition to media- and session- specific may
      also..."
      

      

      The space was intentional so that there are equivalent
      constructions for "media" and "session". The intent is as a
      shorthand for:
      

      

      "Attribute scopes in addition to media-specific and
      session-specific may also..."
      

    

    


    

    
For what it's worth, Zitao is correct.

    

    
RFC 7322 §1:

    
   The world of technical publishing has generally accepted rules
      for

         grammar, punctuation, capitalization, sentence length and
      complexity,

         parallelism, etc.  The RFC Editor generally follows these
      accepted

         rules as defined by the Chicago Manual of Style (CMOS)
      [CMOS]...

    


    

    
CMOS 15th ed §7.89:

    

      
"When the second part of a hyphenated expression is omitted,
        the hyphen is retained, followed by a word space.

      
"fifteen- and twenty-year mortgages

      
"Chicago- or Milwaukee-bound passengers"

    

    


    

    

      To avoid confusion I think I'll just change to the latter.

    


    

    
That works too.

    
/a

    

  


--------------A96C64951084B1082C98DAB2--


From nobody Tue Apr  9 13:00:11 2019
Return-Path: 
X-Original-To: mmusic@ietf.org
Delivered-To: mmusic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2AD120222; Tue,  9 Apr 2019 13:00:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker 
To: "The IESG" 
Cc: draft-ietf-mmusic-data-channel-sdpneg@ietf.org, Bo Burman , mmusic-chairs@ietf.org, bo.burman@ericsson.com, mmusic@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw 
Message-ID: <155484000356.19554.8395796686893872238.idtracker@ietfa.amsl.com>
Date: Tue, 09 Apr 2019 13:00:03 -0700
Archived-At: 
Subject: [MMUSIC] Roman Danyliw's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 Apr 2019 20:00:04 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-mmusic-data-channel-sdpneg-25: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) Section 5.2.1.  The ABNF of stream-id of “dcsa-value = stream-id …†does
not appear to be defined explicitly or by reference in the draft.

(2) Section 6.6, “… the offerer SHALL include previously negotiated SDP
attributes … associated with the channelâ€.  What is the behavior of the
receiver if the attributes included by the offerer are NOT those that were
previously negotiated?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) Section 1.  Editorial Nits.
s/The concept of establishing a bi-directional data channel running on top of
the Stream Control Transmission Protocol (SCTP) is in
[I-D.ietf-rtcweb-data-channel] allowing applications to use data    channels./
The concept of establishing a bi-directional data channel running on top of the
Stream Control Transmission Protocol (SCTP) in [I-D.ietf-rtcweb-data-channel]
allows applications to use data channels./

s/An in-band Data Channel Establishment Protocol (DCEP) is in
[I-D.ietf-rtcweb-data-protocol], however other in-band or out-of-band protocols
may be used for establishing data channels./ In addition to the in-band Data
Channel Establishment Protocol (DCEP), other in-band and out-of-band protocols
may be used for establishing data channels/

(2) Section 1.  Typo (extra space between close bracket and period)
s/For MSRP they are documented in [I-D.ietf-mmusic-msrp-usage-data-channel] ./
For MSRP they are documented in [I-D.ietf-mmusic-msrp-usage-data-channel]./

(3) Section 3.  Editorial Nit.
old: "delivery... )."; new: "delivery, etc.)."

(4) Section 6.1.  Editorial Nit.
There appears to be two instances of the sentence, “SCTP stream identifiers
associated with data channels that have been negotiated using DCEP MUST NOT be
included in SDP offers and answers.â€

(5) Section 6.5.  The sentence “Note: DCEP is not used, that is neither the SDP
offerer nor the SDP answerer send an in-band DCEP DATA_CHANNEL_OPEN messageâ€
uses a triple negative so the guidance is not clear.

(6) Section 6.7, Per “SDP offer or answer has an "a=dcsa" attribute, whose
subprotocol attribute is known, but whose subprotocol attribute semantic is not
known for the data channel transport caseâ€, consider a case where the
sub-protocol attribute is known but the value is invalid.  Is that case a
sub-set of what is meant by the “attribute semantic is not known�



From nobody Tue Apr  9 20:04:18 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED64120143; Tue,  9 Apr 2019 20:03:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzGYKXcHHJzz; Tue,  9 Apr 2019 20:03:56 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F6691200B3; Tue,  9 Apr 2019 20:03:56 -0700 (PDT)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id A21FE43011F2E397E630; Wed, 10 Apr 2019 04:03:54 +0100 (IST)
Received: from lhreml707-chm.china.huawei.com (10.201.108.56) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 10 Apr 2019 04:03:51 +0100
Received: from lhreml707-chm.china.huawei.com (10.201.108.56) by lhreml707-chm.china.huawei.com (10.201.108.56) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Wed, 10 Apr 2019 04:03:51 +0100
Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml707-chm.china.huawei.com (10.201.108.56) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Wed, 10 Apr 2019 04:03:51 +0100
Received: from DGGEMM527-MBX.china.huawei.com ([169.254.6.122]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0415.000; Wed, 10 Apr 2019 11:03:42 +0800
From: wangzitao 
To: Paul Kyzivat , "ops-dir@ietf.org" 
CC: "ietf@ietf.org" , "draft-ietf-mmusic-rfc4566bis.all@ietf.org" , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] Opsdir last call review of draft-ietf-mmusic-rfc4566bis-34
Thread-Index: AdTvRvhYZIMUjF3YT5uvMjWfubvzkw==
Date: Wed, 10 Apr 2019 03:03:42 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.134.142.117]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [MMUSIC] Opsdir last call review of draft-ietf-mmusic-rfc4566bis-34
X-BeenThere: mmusic@ietf.org
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, 10 Apr 2019 03:03:59 -0000

SGkgUGF1bCwNCg0KUGxlYXNlIGZpbmQgbXkgY29tbWVudHMgYXQgW01XXS4NCg0KQi5SLg0KLU1p
Y2hhZWwgDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogUGF1bCBLeXppdmF0
IFttYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1XSANCuWPkemAgeaXtumXtDogMjAxOeW5tDTm
nIgxMOaXpSAxOjExDQrmlLbku7bkuro6IHdhbmd6aXRhbyA8d2FuZ3ppdGFvQGh1YXdlaS5jb20+
OyBvcHMtZGlyQGlldGYub3JnDQrmioTpgIE6IGlldGZAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbW11
c2ljLXJmYzQ1NjZiaXMuYWxsQGlldGYub3JnOyBtbXVzaWNAaWV0Zi5vcmcNCuS4u+mimDogUmU6
IFtNTVVTSUNdIE9wc2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbW11c2ljLXJm
YzQ1NjZiaXMtMzQNCg0KVGhhbmsgeW91IGZvciB0aGUgY29tbWVudHMuIEkgaGF2ZSBzb21lIHF1
ZXN0aW9uczoNCg0KT24gNC84LzE5IDI6MzcgQU0sIFppdGFvIFdhbmcgdmlhIERhdGF0cmFja2Vy
IHdyb3RlOg0KPiBSZXZpZXdlcjogWml0YW8gV2FuZw0KPiBSZXZpZXcgcmVzdWx0OiBIYXMgSXNz
dWVzDQo+IA0KPiBTdW1tYXJ5OiAgICBUaGlzIG1lbW8gZGVmaW5lcyB0aGUgU2Vzc2lvbiBEZXNj
cmlwdGlvbiBQcm90b2NvbCAoU0RQKS4gIFNEUCBpcw0KPiBpbnRlbmRlZCBmb3IgZGVzY3JpYmlu
ZyBtdWx0aW1lZGlhIHNlc3Npb25zIGZvciB0aGUgcHVycG9zZXMgb2YgDQo+IHNlc3Npb24gYW5u
b3VuY2VtZW50LCBzZXNzaW9uIGludml0YXRpb24sIGFuZCBvdGhlciBmb3JtcyBvZiANCj4gbXVs
dGltZWRpYSBzZXNzaW9uIGluaXRpYXRpb24uICBUaGlzIGRvY3VtZW50IG9ic29sZXRlcyBSRkMg
NDU2Ni4gSSANCj4gdGhpbmsgdGhlIGRvY3VtZW50IG1ha2Ugc2Vuc2UgYW5kIGlzIHdyaXR0ZW4g
dmVyeSBjbGVhciwgZXhjZXB0IHNvbWUgc21hbGwgbml0czoNCg0KDQo+ICMgSW4gU2VjdGlvbiA1
LCB0aGVyZSBhcmUNCj4gc2V2ZXJhbCB0ZXJtcyB0aGF0IG1pc3MgcmVmZXJlbmNlcywgc3VjaCBh
cyAiVVMtQVNDSUkgc3Vic2V0IG9mIA0KPiBVVEYtOCIsICAiQVNOLjEgb3IgWERSIiwgZXRjLg0K
DQpUaGVyZSBpcyBhbHJlYWR5IGEgcmVmZXJlbmNlIHRvIHRoZSBkZWZpbml0aW9uIG9mIFVURi04
IFtSRkMzNjI5XSBpbiBzZWN0aW9uIDQuNS4gRG8geW91IHRoaW5rIHRoZSByZWZlcmVuY2UgbmVl
ZHMgdG8gYmUgaW5jbHVkZWQgd2l0aCBldmVyeSB1c2U/IFRoZSBVUy1BU0NJSSBzdWJzZXQgb2Yg
VVRGLTggaXMgYWxzbyBkZWZpbmVkIGluIFJGQzM2MjksIHNvIEkgYW0gaW5jbGluZWQgdG8gdXNl
IHRoZSBzYW1lIHJlZmVyZW5jZSBmb3IgdGhhdC4gVGhlcmUgYXJlIGFsc28gYSBjb3VwbGUgb2Yg
dXNlcyBvZiBVUy1BU0NJSSB3aXRob3V0IG1lbnRpb24gb2YgVVRGLTguIEknbSBpbmNsaW5lZCB0
byBjaGFuZ2UgdGhvc2UgdG8gInRoZSBVUy1BU0NJSSBzdWJzZXQgb2YgVVRGLTgiLg0KDQpSZWdh
cmRpbmcgQVNOLjEgYW5kIFhEUiwgSSBjYW4gYWRkIHJlZmVyZW5jZXMgaWYgeW91IHRoaW5rIGl0
IGltcG9ydGFudC4gDQpCdXQgdGhlaXIgdXNlIGlzIHZlcnkgcGVyaXBoZXJhbCwgYW5kIGl0IGlz
bid0IG5lY2Vzc2FyeSB0byBrbm93IHdoYXQgdGhleSBhcmUgdG8gcmVhZCB0aGUgdGV4dC4NCltN
V106IEkgYW0gT0sgaWYgaXQgaXMgbm90IGNvbW1vbmx5IHVzZWQuDQoNCiMgcy9zZXNzaW9uLSBz
cGVjaWZpYy9zZXNzaW9uLXNwZWNpZmljLw0KDQpSZWdhcmRpbmcgInNlc3Npb24tIHNwZWNpZmlj
IiB2cy4gInNlc3Npb24tc3BlY2lmaWMiOg0KDQpUaGUgY29udGV4dCBmb3IgdGhpcyBpczoNCg0K
IkF0dHJpYnV0ZSBzY29wZXMgaW4gYWRkaXRpb24gdG8gbWVkaWEtIGFuZCBzZXNzaW9uLSBzcGVj
aWZpYyBtYXkgYWxzby4uLiINCg0KVGhlIHNwYWNlIHdhcyBpbnRlbnRpb25hbCBzbyB0aGF0IHRo
ZXJlIGFyZSBlcXVpdmFsZW50IGNvbnN0cnVjdGlvbnMgZm9yICJtZWRpYSIgYW5kICJzZXNzaW9u
Ii4gVGhlIGludGVudCBpcyBhcyBhIHNob3J0aGFuZCBmb3I6DQoNCiJBdHRyaWJ1dGUgc2NvcGVz
IGluIGFkZGl0aW9uIHRvIG1lZGlhLXNwZWNpZmljIGFuZCBzZXNzaW9uLXNwZWNpZmljIG1heSBh
bHNvLi4uIg0KDQpUbyBhdm9pZCBjb25mdXNpb24gSSB0aGluayBJJ2xsIGp1c3QgY2hhbmdlIHRv
IHRoZSBsYXR0ZXIuDQpbTVddOiBJIGFncmVlLg0KDQojIFN1Z2dlc3QgdG8gYWRkIHRhZ3Mgb24N
Cj4gIm92ZXJ2aWV3IG9wdGlvbmFsIGl0ZW1zIiB0byBpZGVudGlmaWVkIG5vdy1vYnNvbGV0ZSBp
dGVtcywgc3VjaCBhcyANCj4gImE9Y2F0IiwgImE9a2V5d2RzIiwgIms9Ii4NCg0KSSdtIG5vdCBj
bGVhciB3aGF0IHlvdSB3YW50IG1lIHRvIGRvLiANCg0KSSBndWVzcyB5b3UgYXJlIHN1Z2dlc3Rp
bmcgYWRkaW5nIHNvbWV0aGluZyB0byB0aGUgZmlyc3QgZmlndXJlIGluIHNlY3Rpb24gNS4NCltN
V106IFllcywgSU1PLCBhZGRpbmcgc29tZSB0YWcvZGVzY3JpcHRpb24gdG8gdGhlIGZpZ3VyZSBp
cyBiZXR0ZXIuDQoNCkkgZG9uJ3Qgc2VlIGhvdyB0aGF0IHdvdWxkIGJlIHBvc3NpYmxlIGZvciBh
PWNhdCBhbmQgYT1rZXl3ZHMsIHNpbmNlIHRoZSBmaWd1cmUgZG9lc24ndCBtZW50aW9uIGluZGl2
aWR1YWwgYXR0cmlidXRlcy4gDQpbTVddOiBBZ3JlZS4gRm9yIGE9Y2F0IGFuZCBhPWtleXdkcywg
aXQgaXMgZGlmZmljdWx0IHRvIHNob3cgb24gdGhlIGZpZ3VyZS4NCg0KV2hpbGUgaXQgaXMgcG9z
c2libGUgdG8gYWRkIHNvbWV0aGluZyBmb3Igaz0sIElNTyBpdCBpcyBiZXR0ZXIgdG8gbGVhdmUg
dGhhdCBsZXZlbCBvZiBkZXRhaWwgdG8gdGhlIGNvbXBsZXRlIGRlc2NyaXB0aW9uIGluIHNlY3Rp
b24gNS4xMi4NCltNV106IE1heWJlIGl0IGNhbiBiZSB1cGRhdGVkIGFzIGZvbGxvd2luZzoNCg0K
ICAgICAgQmVmb3JlIDoNCiAgICAgICBrPSogKGVuY3J5cHRpb24ga2V5KQ0KICAgICAgQWZ0ZXI6
DQogICAgICAgaz0qIChlbmNyeXB0aW9uIGtleSwgdGhpcyBsaW5lIGlzIG9ic29sZXRlZCkNCg0K
CVRoYW5rcywNCglQYXVsIEt5eml2YXQNCg==


From nobody Tue Apr  9 22:40:40 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CD2120155 for ; Tue,  9 Apr 2019 22:40:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9amWwKbMU1NI for ; Tue,  9 Apr 2019 22:40:36 -0700 (PDT)
Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E387B120137 for ; Tue,  9 Apr 2019 22:40:35 -0700 (PDT)
Received: by mail-vs1-xe30.google.com with SMTP id n4so652068vsm.3 for ; Tue, 09 Apr 2019 22:40:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4Lm9xJZbVV6Tj/iaKCy6Uscwbhg4eE8Hk6P/lSMD3Gg=; b=ATitx8qzg2WCkPOS6ZFsrX2Q8d56Z3xXhCjeK7okTR+QPKlkEawLRQ2mLBCtmmjUzP L113aw7k44UQGh4yyqBk1PIWvllfhCdWmGCUZf1RDIbjiMcm93oVPaE+ndq6zHymbKWY WpVtZvcvFHzUufbOzMNKqCDRPNssF+XQzPy2lk38SuFxHOxMRDpeBwoqgLP/lxNuo1t+ vIxbw3lb1JPKhONlUw3q2m6cdhKqO787k1pbzb0GBnnNUPRZf3OO0RT99TGOZqXeDT5R gu8FclOc95sy/JQ/n2+5/uZa8Kko7v/VCtNMU5tCmUtJWWwPWAs+Kk7R8sdhvAba+krq 7AmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4Lm9xJZbVV6Tj/iaKCy6Uscwbhg4eE8Hk6P/lSMD3Gg=; b=m2KXiCqmG2piT5DfJtrsDt6dxds8hernjDab3WYZ50obEAPC11eekLzWZgVIjBs6og 1+1627XYBzWEpxFr5NSXw/lvksdDjZ+WzSqIPQBKwOkHUxpdfWq1LATKT/1D6GIt9TzD ATg/ijUi+lMdYwAld0wZP5JKzRtLOx0D5EkFNQkgWDlITygK4rhqKBcUdAr7I7RKRRas umDGE7G7tE612zOtfv7u5+xED9PPjv1bHjDnwrRNk5W++FM36GSMLkqm2ymL1fbBJogH Kdu2Og/LLxPfh2r9dsW6XsRzFp4QPbRZQXeT3mssci7ouDMP4HYnxPfjBh9rpGZ758A5 RgAQ==
X-Gm-Message-State: APjAAAWWPn41giBd42uYjqH0zuoyeCkNTSIEyJh0z31dQAUkQzDeZS/P GsXEs1KXOU5kTHJnAvOxvdmB3dHdmNXEO+dbeEY=
X-Google-Smtp-Source: APXvYqylnNLY9wlKDJbUsuvUDk459rIdzFl1R9SKrrRYzMeOUO+/dDYv14VC7ti9hfNpSJdnOsZLJML3vau5lLkUW8o=
X-Received: by 2002:a05:6102:147:: with SMTP id a7mr17520342vsr.210.1554874834922;  Tue, 09 Apr 2019 22:40:34 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Suhas Nandakumar 
Date: Tue, 9 Apr 2019 22:40:23 -0700
Message-ID: 
To: Roman Shpount 
Cc: mmusic WG , Flemming Andreasen ,  Christer Holmberg 
Content-Type: multipart/alternative; boundary="00000000000034b0c10586268270"
Archived-At: 
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp
X-BeenThere: mmusic@ietf.org
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, 10 Apr 2019 05:40:39 -0000

--00000000000034b0c10586268270
Content-Type: text/plain; charset="UTF-8"

Hi Roman & Chairs

Thanks for the text

I feel we should restrict the scope for FQDN resolution to just one address
for this specification. Future specifications may define handling of
multiple resolutions (or  DNS64/NAT64 ) scenarios

If others are fine with this, I would want to get an updated draft and move
this forward


Please let  me know

Thanks
Suhas

On Wed, Apr 3, 2019 at 9:47 AM Roman Shpount  wrote:

> Reposting er Flemming's advise as a new thread:
>
> Hi All,
>
> I have created a pull request to ice-sip-sdp (
> https://github.com/suhasHere/ice-sip-sdp/pull/1), which among other
> things added back support for FQDN to ice-sip-sdp.
>
> In order to do this, I've done the following:
>
> 1. I have changed "IP address" to "connection address" throughout the
> document whenever address in c= line or ICE candidate attribute is
> mentioned. I hope this is not controversial since it matches ABNF.
>
> 2. I have changed the definition of 
>
> Old:
>
> : :: is taken from RFC 4566 <>.
> It is the IP address of the candidate. When parsing this field, an agent
> can differentiate
> an IPv4 address and an IPv6 address by presence of a colon in its value --
> the presence of
> a colon indicates IPv6. An agent MUST ignore candidate lines that include
> candidates with
> IP address versions that are not supported or recognized.
>
>
> New:
>
> : :: is taken from RFC 4566 <>.
> It is the IP address of the candidate, allowing for IPv4 addresses, IPv6
> addresses, and fully
> qualified domain names (FQDNs).  When parsing this field, an agent can
> differentiate
> an IPv4 address and an IPv6 address by presence of a colon in its value -
> the presence of a
> colon indicates IPv6.  An agent MUST ignore candidate lines that include
> candidates with
> IP address versions that are not supported or recognized.  An IP address
> SHOULD be used,
> but an FQDN MAY be used in place of an IP address.  In that case, when
> receiving an
> offer or answer containing an FQDN in an a=candidate attribute, the FQDN
> is looked up in
> the DNS first using both AAAA record (assuming the agent supports IPv6),
> and using an A
> record (assuming the agent supports IPv4). If, and only if, the DNS query
> returns
> only one IP address it is then used for the remainder of ICE processing.
> If DNS query
> returned more then one result, including situation where single IPv4 and
> single IPv6
> results are returned, an agent MUST ignore the candidate. Handling of
> multiple DNS
> results for a candidate can be defined in the future specification. If
> candidate
> with FQDN  is the default destination/candidate, the
> the "c="
> address type MUST be set the IP address family for the FQDN DNS resolution
> result
> and the "c=" connection address MUST be set to FQDN.
>
>
>
> This change reflects what was discussed previously.. I am, personally,
> less then happy with this change. My biggest issue is requirement for FQDN
> to resolve to a single address or be ignored. In practice, this is
> problematic when things like DNS64/NAT64 are used. When DNS64 is used, even
> when FQDN was supposed to only resolve to IPv4, AAAA will also return
> result which will point to the NAT64 gateway. Based on the current
> language, this will result in candidate being ignored even though it should
> work with either IPv4 or IPv6 address. Most immediately, this will mean
> FQDN resolving to IPv4 will be ignored on a lot of mobile networks.
>
> I have also added language that defines what is supposed to be placed in
> c= line when default candidate is an FQDN candidate. What happens when FQDN
> resolution result and address family in c= line do not match was not
> specified.
>
> To summarize, this no worse then RFC 5245, but still fairly messy. I see
> two possible ways to clean this up:
>
> a. Add a candidate extension which specifies candidate address type,
> something like addrtype which can be set to "inipv4" or "inipv6". If IP
> address is used and it does not match the addrtype candidate extension,
> this candidate is ignored. When FQDN is used, it is resolved using A DNS
> request when addrtype is inipv4 or not present and using AAAA DNS request
> when addrtype is inipv6. Address family in c= line, when FQDN is a default
> candidate must be IN IPV4 if addrtype is inipv4 or not present, and must be
> IP IPV6 if addrtype is inipv6
>
> b. Specify that during ICE nomination all DNS resolution results for the
> candidate should be added as separate candidates to the candidate list.
> This is likely to cause more problems then option a. One of these problems
> that I see is priority values for these candidates. Candidate priorities
> should be different for all of them but only one value is specified in SDP
> candidate attribute.
>
> In order to simplify tracking changes, I will write different emails about
> other changes I've done in the pull request.
>
> I have also included people who shown previous interest in this topic.
> Please let me know if I need to cross post to rtcweb and ice WG.
>
> Thank you for your attention,
> _____________
> Roman Shpount
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

--00000000000034b0c10586268270
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Roman & Chairs
=C2=A0
Thanks for the =
text=C2=A0

I feel we should restrict the scope for=
 FQDN resolution to just one address for this specification. Future specifi=
cations may define handling of multiple resolutions (or=C2=A0=C2=A0DNS64/NAT6=
4=C2=A0) scenarios

If others are fine with this, I would want to get an updated =
draft and move this=C2=A0forward


<=
/div>
Please let=C2=A0 me know<=
/div>

Thanks
Suhas

On Wed, Apr 3, 2019 at 9:47 AM Roman Shpount <roman@telurix.com> wrote:
Reposti=
ng er Flemming's advise as a new thread:

Hi All,<=
/div>

I have created a pull requ=
est to ice-sip-sdp (https://github.com/suhasHere/ice-sip-sdp/pull/1)=
, which among other things added back support for FQDN to ice-sip-sdp.

In order to do this, I've =
done the following:

1. I h=
ave changed "IP address" to "connection address" throug=
hout the document whenever address in c=3D line or ICE candidate attribute =
is mentioned. I hope this is not controversial since it matches ABNF.
=


2. I have changed the definitio=
n of <connection-address>=C2=A0

Old:
<conne=
ction-address>: :: is taken from RFC 4566 <<RFC4566>>.
=

It is the IP address of the candidate=
. When parsing this field, an agent can differentiate=C2=A0
an IPv4 address and an IPv6 address by presence=
 of a colon in its value -- the presence of=C2=A0
a colon indicates IPv6. An agent MUST ignore candidate li=
nes that include candidates with=C2=A0
IP address versions that are not supported or recognized.

New:
<connection-address>: :: is ta=
ken from RFC 4566 <<RFC4566>>.
It is the IP address of the candidate, allowing for I=
Pv4 addresses, IPv6 addresses, and fully
=

qualified domain names (FQDNs).=C2=A0 When parsing this=
 field, an agent can differentiate=C2=A0
=

an IPv4 address and an IPv6 address by presence of a co=
lon in its value - the presence of a
colon indicates IPv6.=C2=A0 An agent MUST ignore candidate =
lines that include candidates with
<=
div>
IP address versions that are not supported or recognized.=C2=
=A0 An IP address SHOULD be used,
but an FQDN MAY be used in place of an IP address.=C2=A0 In th=
at case, when receiving an
offer or answer containing an FQDN in an a=3Dcandidate attribute, the=
 FQDN is looked up in
the DNS first using both AAAA record (assuming the agent supports IPv6), a=
nd using an A
record =
(assuming the agent supports IPv4). If, and only if, the DNS query returns=
=C2=A0
only one IP ad=
dress it is then used for the remainder of ICE processing. If DNS query
returned more then one r=
esult, including situation where single IPv4 and single IPv6
results are returned, an agent MUST=
 ignore the candidate. Handling of multiple DNS
results for a candidate can be defined in the fu=
ture specification. If candidate
with FQDN <connection-address> is the default destination=
/candidate, the the "c=3D"
address type MUST be set the IP address family for the FQDN=
 DNS resolution result=C2=A0
and the "c=3D" connection address MUST be set to FQDN.


This change reflects what was discussed previously.. I am, personally, l=
ess then happy with this change. My biggest issue is requirement for FQDN t=
o resolve to a single address or be ignored. In practice, this is problemat=
ic when things like DNS64/NAT64 are used. When DNS64 is used, even when FQD=
N was supposed to only resolve to IPv4, AAAA will also return result which =
will point to the NAT64 gateway. Based on the current language, this will r=
esult in candidate being ignored even though it should work with either IPv=
4 or IPv6 address. Most immediately, this will mean FQDN resolving to IPv4 =
will be ignored on a lot of mobile networks.

I hav=
e also added language that defines what is supposed to be placed in c=3D li=
ne when default candidate is an FQDN candidate. What happens when FQDN reso=
lution result and address family in c=3D line do not match was not specifie=
d.

To summarize, this no worse then RFC 5245, but =
still fairly messy. I see two possible ways to clean this up:
a. Add a candidate extension which specifies candidate address =
type, something like addrtype which can be set to "inipv4" or &qu=
ot;inipv6". If IP address is used and it does not match the addrtype c=
andidate extension, this candidate is ignored. When FQDN is used, it is res=
olved using A DNS request when addrtype is inipv4 or not present and using =
AAAA DNS request when addrtype is inipv6. Address family in c=3D line, when=
 FQDN is a default candidate must be IN IPV4 if addrtype is inipv4 or not p=
resent, and must be IP IPV6 if addrtype is inipv6

=
b. Specify that during ICE nomination all DNS resolution results for the ca=
ndidate should be added as separate candidates to the candidate list. This =
is likely to cause more problems then option a. One of these problems that =
I see is priority values for these candidates. Candidate priorities should =
be different for all of them but only one value is specified in SDP candida=
te attribute.

In order to simplify tracking change=
s, I will write different emails about other changes I've done in the p=
ull request.

I have also included people who shown=
 previous interest in this topic. Please let me know if I need to cross pos=
t to rtcweb and ice WG.

Thank you for your attenti=
on,
_____________
Roman Shpount

_______________________________________________

mmusic mailing list

mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic




--00000000000034b0c10586268270--


From nobody Wed Apr 10 01:18:31 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D93B91200FE; Wed, 10 Apr 2019 01:18:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGM9z2sFxgoA; Wed, 10 Apr 2019 01:18:27 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70047.outbound.protection.outlook.com [40.107.7.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CB6A120198; Wed, 10 Apr 2019 01:18:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U+NGe/D2fMwFbsl5Ldeb4FGPB0uD/H79qpqosNR6ZpU=; b=nHQJSW8NM+Q5jtnPuqtlH2eLy+/tCHr9JVb9TxxbsCDytvSlsdvdkucKresu2MnFc2Wuqt9FjQaZVX0qJo/qIPxsTFxM2ECDXMnqDm3LTrFQP8ZBGBXM57d+ET5eaLcUtE4qL7gKJZ0jVnO4qtUduTZGCicaOLuaNqkOyhde9go=
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2412.eurprd07.prod.outlook.com (10.168.128.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.8; Wed, 10 Apr 2019 08:18:23 +0000
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::107c:5f27:2ef:8505]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::107c:5f27:2ef:8505%5]) with mapi id 15.20.1792.009; Wed, 10 Apr 2019 08:18:23 +0000
From: Magnus Westerlund 
To: Adam Roach , The IESG 
CC: "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-data-channel-sdpneg@ietf.org" , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)
Thread-Index: AQHU66fNA40h4UsP7kq3a/Vv5QT6wQ==
Date: Wed, 10 Apr 2019 08:18:23 +0000
Message-ID: 
References: <155446588097.13196.6373243259627185094.idtracker@ietfa.amsl.com> <1afcb116-36cb-be51-81ac-e78fc52c9255@nostrum.com>  
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; 
x-originating-ip: [193.180.17.5]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: fdf8d6ae-00e5-4f2e-295e-08d6bd8d19ae
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2412; 
x-ms-traffictypediagnostic: HE1PR0701MB2412:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: 
x-forefront-prvs: 00032065B2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(136003)(366004)(396003)(52314003)(199004)(189003)(52536014)(71200400001)(71190400001)(236005)(6506007)(81166006)(25786009)(4326008)(6306002)(54896002)(53546011)(110136005)(229853002)(93886005)(8676002)(8936002)(9686003)(86362001)(7736002)(966005)(55016002)(81156014)(478600001)(5660300002)(105586002)(3846002)(6116002)(316002)(97736004)(606006)(68736007)(256004)(6436002)(99286004)(6246003)(74316002)(26005)(476003)(54906003)(76176011)(446003)(186003)(2906002)(53936002)(7696005)(33656002)(66066001)(44832011)(102836004)(486006)(14454004)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2412; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: r2quPq6cgQo2441WylLHvGh3kF2pHIXNJVeb+/NTxi6KJAWeba4d25A+HN2H9CvxM9UFEguxPqDr1rfXcZ0aY4JYzVw3WsFTnQibsAA0rqyEJAin3E/wjySCeugluc9DZ48ABjz0NMS89df8gApSRoqzVaYnUbcBXgyESk+UHInWORkyf9oh12mUchJFLCilrki1dMCwJbkWz0qSDGixK8jHAZxzj6x3fr7PTDdjVPIi0GsndMVTCwAZ2n9oSewk9coZAFQXbZSUHe89BYyrPXTli57XXXz3Jl4PKEa+6IuGEyQsMl3m+td57A67HWKoJ7QoGznJUzX/g4evyTujtEvVl7O/bX/7Ogy4uMR28sNUKkEV54fZPTOO6/KLJ2UhEZG5Tra79JpDOuxldKWQt3XkbroqrozMbdkJthe5810=
Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB2522ADFF02F9BF4CA7EBAB72952E0HE1PR0701MB2522_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fdf8d6ae-00e5-4f2e-295e-08d6bd8d19ae
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2019 08:18:23.6735 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2412
Archived-At: 
Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)
X-BeenThere: mmusic@ietf.org
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, 10 Apr 2019 08:18:30 -0000

--_000_HE1PR0701MB2522ADFF02F9BF4CA7EBAB72952E0HE1PR0701MB2522_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

On 2019-04-09 18:51, Adam Roach wrote:
On 4/9/19 4:00 AM, Magnus Westerlund wrote:
On 2019-04-08 17:55, Adam Roach wrote:
On 4/5/19 7:04 AM, Magnus Westerlund via Datatracker wrote:

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

There might be a serious issue in label definition.

5.1.3.  Label Parameter

   The 'label' parameter indicates the name of the channel.  It
   represents a label that can be used to distinguish, in the context of
   the WebRTC API [WebRtcAPI], an RTCDataChannel object from other
   RTCDataChannel objects.  This parameter maps to the 'Label' parameter
   defined in [I-D.ietf-rtcweb-data-protocol].  The 'label' parameter is
   optional.  If it is not present, then its value defaults to the empty
   string.

  label-opt       =3D "label=3D" quoted-string
  quoted-string   =3D DQUOTE *(quoted-char / escaped-char) DQUOTE
  quoted-char     =3D SP / quoted-visible
  quoted-visible  =3D %x21 / %x23-24 / %x26-7E ; VCHAR without " or %
  escaped-char    =3D "%" HEXDIG HEXDIG

I interpret that as the intention is to enable the SDP Attribute to carry t=
he
label as defined in W3C API. That value is in the current candidatate
specification an https://www.w3.org/TR/webrtc/ as an USVSsting
(https://heycam.github.io/webidl/#idl-USVString). And in the reference vers=
ion
of the WebRTC API as an DOMstring. Both are not limited to ASCII and may
contain any Unicode characters. Thus the escaping mechanism defined appear =
to
be insufficient.

I think the "quoted-string" need a definition of what type of string this t=
ruly
are so that it is clear what a character in the string is.

In addition the specification of escaping is undersspecified. I would recom=
mend
at least adding discussion of the need and how to escape DQUOTE and % that =
can
be relatively common operations.


I can see that this could benefit from some explicit detail about how to co=
nvert the cited USVString string into the "quoted-string" construct defined=
 here. I think this roughly consists of:

  *   Serialize the WebRTC label as a UTF-8 string
  *   Treat the UTF-8 serialization as a series of bytes
  *   For each byte in the serialization:
     *   If the byte can be expressed as a `quoted-char`, do so
     *   Otherwise, express the byte as an `escaped-char`.

Would including text to that effect satisfy your concern?

Yes it would be clear what is expected. However, I fail to understand why o=
ne need to ASCIIify and escape the UTF-8 encoded characters where one could=
 simply define the label value as an UTF-8 string something that is compati=
ble with SDP specification. Wouldn't that reduce the set of characters need=
ing escaping to a much smaller set.


That's a little tricky. RFC 4566: "SDP also allows other character sets suc=
h as ISO 8859-1 to be used when desired."

Even if we just constrain this to SIP, RFC 3261: "When no explicit charset =
parameter is provided by the sender, media subtypes of the 'text' type are =
defined to have a default charset value of 'UTF-8'."

So there's a bias towards UTF-8, but no strict requirement.

I'd support a short document that deprecated non-UTF-8 encodings of SDP so =
that specifications like this one could simply assume that the full charact=
er set can be used directly, but that's not the current state of affairs.

Is this something that actually should be addressed in4566bis?

Anyway, I am fine with the previous outline for solution as my issue was th=
at it was not clear how to get the intended labels into the SDP when desire=
d in a way that is interoperable. So I will remove my discuss when the docu=
ment has been addressed.

cheers

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

--_000_HE1PR0701MB2522ADFF02F9BF4CA7EBAB72952E0HE1PR0701MB2522_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







On 2019-04-09 18:51, Adam Roach wrote:






On 4/9/19 4:00 AM, Magnus Westerlund wrote:<=
br>





On 2019-04-08 17:55, Adam Roach wrote:






On 4/5/19 7:04 AM, Magnus Westerlund via Dat=
atracker wrote:






------------------------------------=
----------------------------------=0A=
DISCUSS:=0A=
----------------------------------------------------------------------=0A=
=0A=
There might be a serious issue in label definition.=0A=
=0A=
5.1.3.  Label Parameter=0A=
=0A=
   The 'label' parameter indicates the name of the channel.  It=0A=
   represents a label that can be used to distinguish, in the context of=0A=
   the WebRTC API [WebRtcAPI], an RTCDataChannel object from other=0A=
   RTCDataChannel objects.  This parameter maps to the 'Label' parameter=0A=
   defined in [I-D.ietf-rtcweb-data-protocol].  The 'label' parameter is=0A=
   optional.  If it is not present, then its value defaults to the empty=0A=
   string.=0A=
=0A=
  label-opt       =3D "label=3D" quoted-string=0A=
  quoted-string   =3D DQUOTE *(quoted-char / escaped-char) DQUOTE=0A=
  quoted-char     =3D SP / quoted-visible=0A=
  quoted-visible  =3D %x21 / %x23-24 / %x26-7E ; VCHAR without " or %=
=0A=
  escaped-char    =3D "%" HEXDIG HEXDIG=0A=
=0A=
I interpret that as the intention is to enable the SDP Attribute to carry t=
he=0A=
label as defined in W3C API. That value is in the current candidatate=0A=
specification an https://www.w3.org/TR/webrtc/ =
as an USVSsting=0A=
(https://heycam.github.io/webidl/#=
idl-USVString). And in the reference version=0A=
of the WebRTC API as an DOMstring. Both are not limited to ASCII and may=0A=
contain any Unicode characters. Thus the escaping mechanism defined appear =
to=0A=
be insufficient.=0A=
=0A=
I think the "quoted-string" need a definition of what type of str=
ing this truly=0A=
are so that it is clear what a character in the string is.=0A=
=0A=
In addition the specification of escaping is undersspecified. I would recom=
mend=0A=
at least adding discussion of the need and how to escape DQUOTE and % that =
can=0A=
be relatively common operations.









I can see that this could benefit from some explicit detail about how to=
 convert the cited USVString string into the "quoted-string" cons=
truct defined here. I think this roughly consists of:


    

  • Serialize the WebRTC label as a UTF-8 string
  • Treat the UTF-8 se=
rialization as a series of bytes
  • For each byte in the serialization=
:
      • 

    • If the byte can be expressed as a `quoted-char`, do so
    • Otherwis=
e, express the byte as an `escaped-char`.
    



Would including text to that effect satisfy your concern?




Yes it would be clear what is expected. However, I fail to understand wh=
y one need to ASCIIify and escape the UTF-8 encoded characters where one co=
uld simply define the label value as an UTF-8 string something that is comp=
atible with SDP specification. Wouldn't
 that reduce the set of characters needing escaping to a much smaller set. =












That's a little tricky. RFC 4566: "SDP also allows other character =
sets such as ISO 8859-1 to be used when desired."





Even if we just constrain this to SIP, RFC 3261: "When no explicit =
charset parameter is provided by the sender, media subtypes of the 'text' t=
ype are defined to have a default charset value of 'UTF-8'."


So there's a bias towards UTF-8, but no strict requirement.


I'd support a short document that deprecated non-UTF-8 encodings of SDP =
so that specifications like this one could simply assume that the full char=
acter set can be used directly, but that's not the current state of affairs=
.




Is this something that actually should be addressed in4566bis? 




Anyway, I am fine with the previous outline for solution as my issue was=
 that it was not clear how to get the intended labels into the SDP when des=
ired in a way that is interoperable. So I will remove my discuss when the d=
ocument has been addressed.





cheers =0A=
=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.=
com=0A=
----------------------------------------------------------------------



--_000_HE1PR0701MB2522ADFF02F9BF4CA7EBAB72952E0HE1PR0701MB2522_--


From nobody Wed Apr 10 10:29:55 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366FE12061E; Wed, 10 Apr 2019 10:29:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.68
X-Spam-Level: 
X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkVnr2TIx3Zj; Wed, 10 Apr 2019 10:29:52 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E711C120614; Wed, 10 Apr 2019 10:29:50 -0700 (PDT)
Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x3AHTj3d027403 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 10 Apr 2019 12:29:47 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1554917388; bh=7zqVLHwci6sIylmkrotmFJkxJR30fPuF9hysw2uVJlA=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=n0uOyyU0bV7+tDVsKUbF+aJTOJr4VGyay0Z106kJey8IuEhMC0akdsf3cPtX0JkGc LPeO0wOrq4NXV61WS75x4PewR/LBvYCcxZ5xZFPPq3EnjB3PWqmSVp+Tsu3qUMVslB UmZc5e3nKoHTBfF9mDSMUwo4atgOGxBAhX3gM4uQ=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at
To: Magnus Westerlund , The IESG 
Cc: "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-data-channel-sdpneg@ietf.org" , "mmusic@ietf.org" 
References: <155446588097.13196.6373243259627185094.idtracker@ietfa.amsl.com> <1afcb116-36cb-be51-81ac-e78fc52c9255@nostrum.com>   
From: Adam Roach 
Message-ID: 
Date: Wed, 10 Apr 2019 12:29:40 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)
X-BeenThere: mmusic@ietf.org
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, 10 Apr 2019 17:29:54 -0000

On 4/10/19 3:18 AM, Magnus Westerlund wrote:
> Is this something that actually should be addressed in4566bis? 


It's in IETF last call, but we can pause processing until the WG has 
time to consider the issue. Do you want me to ask the MMUSIC chairs to 
take this question to the working group?

/a


From nobody Wed Apr 10 11:24:12 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3AC612004E for ; Wed, 10 Apr 2019 11:24:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpUUYjAC1Ah6 for ; Wed, 10 Apr 2019 11:24:07 -0700 (PDT)
Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3289120049 for ; Wed, 10 Apr 2019 11:24:07 -0700 (PDT)
Received: by mail-pg1-x52e.google.com with SMTP id i2so2028299pgj.11 for ; Wed, 10 Apr 2019 11:24:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S5jaImk6Q5LpOkhlXctuu9ua03gMXWvCeXkVXcSc7A4=; b=R1PoL9aIcXBvV+wLppWVwBgeOubm+gOrF5pseAcXRyD6FiY9uKizT5doWDnAV++uV5 oiOlGV9s6QXA2PW/wpb+cgyBbONKSWJItLlamcE+imuYhFo2cIC3NX18MUApOOqyNq5P JlhnnWr6LUjTKYQ3uhReXHCFw8TBMM85YTiK+yU1mNPCZusI3mbU/U7Jo23jQ418ANV+ 39OdJggZz7009Y2GdyEOEwqhx4zH6nme5XJBJ675ar6fCLJe9TQzw/Gwiv0I0zN45Lnk ivso/7T2HcOpDcpv/8us8rlWE2FsPKVCAWlCIbKT68+zPCOqI79YKMY2IwTAn/+MeV+R 8huw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=S5jaImk6Q5LpOkhlXctuu9ua03gMXWvCeXkVXcSc7A4=; b=ewUMcXADgQgGJ9Xp0JJA5VgHBUt1f/tE46LoMjXxL2Q6XD+wCFCy8xUP1oPX9eFDjk amyNNhouuJL4Pz1k5+04D53IsUCMoWDZxtLIhZOqUh1CmNYjoXkue/itusTiurVxTxcQ 1T3i72EAoLBoU8mQ5a8wYerUIhCTQkjL+a+JAzHNAzuKHxulswz75Y49wlmNb93GM7Dd sXMHwal99MdiqVNxsMvJ8c/KGyQKiNrw6LuUZlGtirrTY3riTkucZkhIDKq6SGNiSsdQ ze0yvQCv8pjzPxVjj90AIn0UT9AT0dVQVPLk6kiQVDZnRqd6aKLwyWOSqOPJMtO5Fexw C/+A==
X-Gm-Message-State: APjAAAXplNJxeoKgjoMIHaj0/JWG+f9e2YVzWZzd1oo0Bbtwd+dpwt4O IGGeBhEfgK3k1+jsXvrbhVAowMtYcBg=
X-Google-Smtp-Source: APXvYqy3eSANmTcnvxUxjquP2iqcLSQy9G5W3ZDMeAxbL6hDNf23VnA9mrAkVUkbVm056mQIveNpgw==
X-Received: by 2002:a63:ff26:: with SMTP id k38mr42265475pgi.123.1554920646786;  Wed, 10 Apr 2019 11:24:06 -0700 (PDT)
Received: from mail-pg1-f173.google.com (mail-pg1-f173.google.com. [209.85.215.173]) by smtp.gmail.com with ESMTPSA id c3sm69864119pfg.88.2019.04.10.11.24.05 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Apr 2019 11:24:05 -0700 (PDT)
Received: by mail-pg1-f173.google.com with SMTP id y3so2025235pgk.12 for ; Wed, 10 Apr 2019 11:24:05 -0700 (PDT)
X-Received: by 2002:a62:4602:: with SMTP id t2mr44716647pfa.26.1554920645517;  Wed, 10 Apr 2019 11:24:05 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Roman Shpount 
Date: Wed, 10 Apr 2019 14:23:51 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Suhas Nandakumar 
Cc: mmusic WG , Flemming Andreasen ,  Christer Holmberg 
Content-Type: multipart/alternative; boundary="000000000000bae8a60586312c6c"
Archived-At: 
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp
X-BeenThere: mmusic@ietf.org
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, 10 Apr 2019 18:24:11 -0000

--000000000000bae8a60586312c6c
Content-Type: text/plain; charset="UTF-8"

Hi Suhas & Chairs,

Limiting FQDN scope to resolving to just one address is an unimplementable
requirement. Currently on large number of devices, FQDN which is supposed
to resolve to IPv4 address only, will resolve to both IPv6 and IPv4
addresses. For instance on virtually all IOS and most of the Android
devices on mobile networks FQDN pointing to IPv4 returns results for IPv6
as well. Essentially what we are specifying now is that ICE candidates with
FQDN address MUST be ignored.

I think if no feedback is provided regarding this issue this is exactly
what we should do in the specification and say something like:

: :: is taken from RFC 4566 <>.
It is the IP address of the candidate, allowing for IPv4 addresses, IPv6
addresses, and fully
qualified domain names (FQDNs).  When parsing this field, an agent can
differentiate
an IPv4 address and an IPv6 address by presence of a colon in its value -
the presence of a
colon indicates IPv6.  An agent MUST ignore candidate lines that include
candidates with

FQDN or IP address versions that are not supported or recognized.  Handling
of FQDN addresses
in candidate can be defined in the future specification.


Regards,
_____________
Roman Shpount


On Wed, Apr 10, 2019 at 1:40 AM Suhas Nandakumar 
wrote:

> Hi Roman & Chairs
>
> Thanks for the text
>
> I feel we should restrict the scope for FQDN resolution to just one
> address for this specification. Future specifications may define handling
> of multiple resolutions (or  DNS64/NAT64 ) scenarios
>
> If others are fine with this, I would want to get an updated draft and
> move this forward
>
>
> Please let  me know
>
> Thanks
> Suhas
>
> On Wed, Apr 3, 2019 at 9:47 AM Roman Shpount  wrote:
>
>> Reposting er Flemming's advise as a new thread:
>>
>> Hi All,
>>
>> I have created a pull request to ice-sip-sdp (
>> https://github.com/suhasHere/ice-sip-sdp/pull/1), which among other
>> things added back support for FQDN to ice-sip-sdp.
>>
>> In order to do this, I've done the following:
>>
>> 1. I have changed "IP address" to "connection address" throughout the
>> document whenever address in c= line or ICE candidate attribute is
>> mentioned. I hope this is not controversial since it matches ABNF.
>>
>> 2. I have changed the definition of 
>>
>> Old:
>>
>> : :: is taken from RFC 4566 <>.
>> It is the IP address of the candidate. When parsing this field, an agent
>> can differentiate
>> an IPv4 address and an IPv6 address by presence of a colon in its value
>> -- the presence of
>> a colon indicates IPv6. An agent MUST ignore candidate lines that include
>> candidates with
>> IP address versions that are not supported or recognized.
>>
>>
>> New:
>>
>> : :: is taken from RFC 4566 <>.
>> It is the IP address of the candidate, allowing for IPv4 addresses, IPv6
>> addresses, and fully
>> qualified domain names (FQDNs).  When parsing this field, an agent can
>> differentiate
>> an IPv4 address and an IPv6 address by presence of a colon in its value -
>> the presence of a
>> colon indicates IPv6.  An agent MUST ignore candidate lines that include
>> candidates with
>> IP address versions that are not supported or recognized.  An IP address
>> SHOULD be used,
>> but an FQDN MAY be used in place of an IP address.  In that case, when
>> receiving an
>> offer or answer containing an FQDN in an a=candidate attribute, the FQDN
>> is looked up in
>> the DNS first using both AAAA record (assuming the agent supports IPv6),
>> and using an A
>> record (assuming the agent supports IPv4). If, and only if, the DNS query
>> returns
>> only one IP address it is then used for the remainder of ICE processing.
>> If DNS query
>> returned more then one result, including situation where single IPv4 and
>> single IPv6
>> results are returned, an agent MUST ignore the candidate. Handling of
>> multiple DNS
>> results for a candidate can be defined in the future specification. If
>> candidate
>> with FQDN  is the default destination/candidate, the
>> the "c="
>> address type MUST be set the IP address family for the FQDN DNS
>> resolution result
>> and the "c=" connection address MUST be set to FQDN.
>>
>>
>>
>> This change reflects what was discussed previously.. I am, personally,
>> less then happy with this change. My biggest issue is requirement for FQDN
>> to resolve to a single address or be ignored. In practice, this is
>> problematic when things like DNS64/NAT64 are used. When DNS64 is used, even
>> when FQDN was supposed to only resolve to IPv4, AAAA will also return
>> result which will point to the NAT64 gateway. Based on the current
>> language, this will result in candidate being ignored even though it should
>> work with either IPv4 or IPv6 address. Most immediately, this will mean
>> FQDN resolving to IPv4 will be ignored on a lot of mobile networks.
>>
>> I have also added language that defines what is supposed to be placed in
>> c= line when default candidate is an FQDN candidate. What happens when FQDN
>> resolution result and address family in c= line do not match was not
>> specified.
>>
>> To summarize, this no worse then RFC 5245, but still fairly messy. I see
>> two possible ways to clean this up:
>>
>> a. Add a candidate extension which specifies candidate address type,
>> something like addrtype which can be set to "inipv4" or "inipv6". If IP
>> address is used and it does not match the addrtype candidate extension,
>> this candidate is ignored. When FQDN is used, it is resolved using A DNS
>> request when addrtype is inipv4 or not present and using AAAA DNS request
>> when addrtype is inipv6. Address family in c= line, when FQDN is a default
>> candidate must be IN IPV4 if addrtype is inipv4 or not present, and must be
>> IP IPV6 if addrtype is inipv6
>>
>> b. Specify that during ICE nomination all DNS resolution results for the
>> candidate should be added as separate candidates to the candidate list.
>> This is likely to cause more problems then option a. One of these problems
>> that I see is priority values for these candidates. Candidate priorities
>> should be different for all of them but only one value is specified in SDP
>> candidate attribute.
>>
>> In order to simplify tracking changes, I will write different emails
>> about other changes I've done in the pull request.
>>
>> I have also included people who shown previous interest in this topic.
>> Please let me know if I need to cross post to rtcweb and ice WG.
>>
>> Thank you for your attention,
>> _____________
>> Roman Shpount
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>

--000000000000bae8a60586312c6c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Suhas & Chairs,

Limiting FQDN sc=
ope to resolving to just one address is an unimplementable requirement. Cur=
rently on large number of devices, FQDN which is supposed to resolve to IPv=
4 address only, will resolve to both IPv6 and IPv4 addresses. For instance =
on virtually all IOS and most of the Android devices on mobile networks FQD=
N pointing to IPv4 returns results for IPv6 as well. Essentially what we ar=
e specifying now is that ICE candidates with FQDN address MUST be ignored.<=
/div>

I think if no feedback is provided regarding this =
issue this is exactly what we should do in the specification and say someth=
ing like:

<=
;connection-address>: :: is taken from RFC 4566 <<RFC4566>>.=

It is the IP address=
 of the candidate, allowing for IPv4 addresses, IPv6 addresses, and fully
qualified domain names=
 (FQDNs).=C2=A0 When parsing this field, an agent can differentiate=C2=A0
an IPv4 address and an=
 IPv6 address by presence of a colon in its value - the presence of a
=

colon indicates IPv6.=C2=
=A0 An agent MUST ignore candidate lines that include candidates with
=

F=
QDN or IP address versions that are not supported or recognized.=C2=A0 Hand=
ling of FQDN addresses
in candidate can be defined in the future =
specification.

Regards,
_____________
Roman Shpount


On Wed, Apr 10, 2019=
 at 1:40 AM Suhas Nandakumar <suh=
asietf@gmail.com> wrote:
Hi Roman & Chairs
=C2=A0
Thanks for the text=C2=A0

I feel we should restri=
ct the scope for FQDN resolution to just one address for this specification=
. Future specifications may define handling of multiple resolutions (or=C2=
=A0=C2=A0DNS64/NAT64=C2=A0) scenarios=


If others are fine with this, I would want t=
o get an updated draft and move this=C2=A0forward


Please let=C2=
=A0 me know

Thanks
Suhas

On Wed, Apr 3, 2019 at 9:47 AM Ro=
man Shpount <roma=
n@telurix.com> wrote:
Reposting er Flemming's advise as a new t=
hread:

Hi All,

I have created a pull request to ice-sip-sdp (https://github.=
com/suhasHere/ice-sip-sdp/pull/1), which among other things added back =
support for FQDN to ice-sip-sdp.

In order to do this, I've done the following:

1. I have changed "IP address" t=
o "connection address" throughout the document whenever address i=
n c=3D line or ICE candidate attribute is mentioned. I hope this is not con=
troversial since it matches ABNF.

2. I have changed the definition of <connection-address>=C2=
=A0

Old:
=

<connection-address>: :: is taken fro=
m RFC 4566 <<RFC4566>>.
<=
div>It is the IP address of the candidate. When parsing this field, an agen=
t can differentiate=C2=A0
an IPv=
4 address and an IPv6 address by presence of a colon in its value -- the pr=
esence of=C2=A0
a colon indicate=
s IPv6. An agent MUST ignore candidate lines that include candidates with=
=C2=A0
IP address versions that =
are not supported or recognized.

New:
<connection-address>: :: is taken from RFC 4566 <<RFC456=
6>>.
It is the =
IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses, a=
nd fully
qualified do=
main names (FQDNs).=C2=A0 When parsing this field, an agent can differentia=
te=C2=A0
an IPv4 addr=
ess and an IPv6 address by presence of a colon in its value - the presence =
of a
colon indicates =
IPv6.=C2=A0 An agent MUST ignore candidate lines that include candidates wi=
th
IP address version=
s that are not supported or recognized.=C2=A0 An IP address SHOULD be used,=

but an FQDN MAY be u=
sed in place of an IP address.=C2=A0 In that case, when receiving an
<=
/div>
offer or answer containing =
an FQDN in an a=3Dcandidate attribute, the FQDN is looked up in
=

the DNS first using both AAAA re=
cord (assuming the agent supports IPv6), and using an A
record (assuming the agent supports IPv4=
). If, and only if, the DNS query returns=C2=A0
only one IP address it is then used for the rema=
inder of ICE processing. If DNS query
returned more then one result, including situation where s=
ingle IPv4 and single IPv6
results are returned, an agent MUST ignore the candidate. Handling of=
 multiple DNS
results=
 for a candidate can be defined in the future specification. If candidate
with FQDN <connecti=
on-address> is the default destination/candidate, the the "c=3D&quo=
t;
address type MUST =
be set the IP address family for the FQDN DNS resolution result=C2=A0
=

and the "c=3D" c=
onnection address MUST be set to FQDN.


This change reflects what was d=
iscussed previously.. I am, personally, less then happy with this change. M=
y biggest issue is requirement for FQDN to resolve to a single address or b=
e ignored. In practice, this is problematic when things like DNS64/NAT64 ar=
e used. When DNS64 is used, even when FQDN was supposed to only resolve to =
IPv4, AAAA will also return result which will point to the NAT64 gateway. B=
ased on the current language, this will result in candidate being ignored e=
ven though it should work with either IPv4 or IPv6 address. Most immediatel=
y, this will mean FQDN resolving to IPv4 will be ignored on a lot of mobile=
 networks.

I have also added language that defines=
 what is supposed to be placed in c=3D line when default candidate is an FQ=
DN candidate. What happens when FQDN resolution result and address family i=
n c=3D line do not match was not specified.

To sum=
marize, this no worse then RFC 5245, but still fairly messy. I see two poss=
ible ways to clean this up:

a. Add a candidate ext=
ension which specifies candidate address type, something like addrtype whic=
h can be set to "inipv4" or "inipv6". If IP address is =
used and it does not match the addrtype candidate extension, this candidate=
 is ignored. When FQDN is used, it is resolved using A DNS request when add=
rtype is inipv4 or not present and using AAAA DNS request when addrtype is =
inipv6. Address family in c=3D line, when FQDN is a default candidate must =
be IN IPV4 if addrtype is inipv4 or not present, and must be IP IPV6 if add=
rtype is inipv6

b. Specify that during ICE nominat=
ion all DNS resolution results for the candidate should be added as separat=
e candidates to the candidate list. This is likely to cause more problems t=
hen option a. One of these problems that I see is priority values for these=
 candidates. Candidate priorities should be different for all of them but o=
nly one value is specified in SDP candidate attribute.

=

In order to simplify tracking changes, I will write different emails a=
bout other changes I've done in the pull request.

<=
div>I have also included people who shown previous interest in this topic. =
Please let me know if I need to cross post to rtcweb and ice WG.
=

Thank you for your attention,
_____________
Roman Shpount
_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
--000000000000bae8a60586312c6c-- From nobody Wed Apr 10 12:13:22 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75BD1203B5 for ; Wed, 10 Apr 2019 12:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjVfvwDuW7F6 for ; Wed, 10 Apr 2019 12:13:18 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10083.outbound.protection.outlook.com [40.107.1.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E9D51203E1 for ; Wed, 10 Apr 2019 12:13:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oDMI2jmAwFv0lgLmideMrK2urW7QSgVD2AGHAeQxsCQ=; b=V7juxbIRV6fEi6Hn3fx9oGsoD6uE2zRXNLfhDIIw96+nsr0WmTNMaY6kBhvDEAHKtfNsRaLp6DBqbf/AJVbWMpoOG0YSKbB3h9B0YrzemruHMKaT2JZaYXWaGaBH200tQkA/nhkOrq8EPOncN2bFf+lLubo/X7ue2V5w2DVBrMM= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4265.eurprd07.prod.outlook.com (20.176.166.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.9; Wed, 10 Apr 2019 19:13:13 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9%5]) with mapi id 15.20.1792.007; Wed, 10 Apr 2019 19:13:13 +0000 From: Christer Holmberg To: Roman Shpount , Suhas Nandakumar CC: mmusic WG , Flemming Andreasen Thread-Topic: [MMUSIC] FQDN support in ice-sip-sdp Thread-Index: AQHU6jzz/50YAJx2kEqY4siuQ2NZYqY0606AgADVT4CAAEAVAA== Date: Wed, 10 Apr 2019 19:13:13 +0000 Message-ID: <3DD3D8D6-9B13-4F9D-80DD-F89B69240708@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [178.55.193.218] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cc0c7832-0e82-482e-b8ad-08d6bde89460 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB4265; x-ms-traffictypediagnostic: HE1PR07MB4265: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 00032065B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(136003)(346002)(376002)(39860400002)(189003)(53754006)(199004)(51914003)(316002)(110136005)(54906003)(58126008)(8936002)(86362001)(81156014)(81166006)(8676002)(6246003)(53936002)(5660300002)(229853002)(236005)(33656002)(6486002)(54896002)(105586002)(6436002)(6512007)(6306002)(106356001)(36756003)(97736004)(44832011)(66066001)(14454004)(14444005)(256004)(478600001)(83716004)(71190400001)(71200400001)(4326008)(6116002)(606006)(102836004)(26005)(53546011)(966005)(6506007)(99286004)(68736007)(3846002)(2906002)(486006)(82746002)(7736002)(25786009)(2616005)(446003)(476003)(11346002)(186003)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4265; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: DS+xA100HV0eSUIhwOWl2HY1JqMXXKqpx5xBmVx3CPaVfY+grXPslvMTqaWpnnKDdDjGnKN4oKdEAH0Kd2hUc7V/Q0RpDoZlGJhnA0zScx062vumCA3co2mDWvwMyJBeMCVvD1zW+F1ozte9QBQm6fPoajwYkQnB/hO+RoWuu4iWEU4Z0uORZQr6CL2pQOpBiG+V2RX1Bte4JY0JTHr5TDOzYvbKaG7/h/fbANiX8gckSB/1qqWeGHx71PBuOns9T7SgLTh/gGEkhuXuz2Jg1ZuBdOOH3kwqdg7O8sIoQ5saerimvRZUMhRbbTRYzZj8Uundhsk7M7ExTqDci8eN++cmS4wDZx4qKV8kdSYlIR2MYNCbUWAF407FBPTfOQ5NxRKCVov4CepnPr6asJNXd+xZ6jgZ97BD5ZiMJNv4up8= Content-Type: multipart/alternative; boundary="_000_3DD3D8D69B134F9D80DDF89B69240708ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: cc0c7832-0e82-482e-b8ad-08d6bde89460 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2019 19:13:13.7621 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4265 Archived-At: Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp X-BeenThere: mmusic@ietf.org 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, 10 Apr 2019 19:13:21 -0000 --_000_3DD3D8D69B134F9D80DDF89B69240708ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5MaW1pdGluZyBGUUROIHNjb3BlIHRvIHJlc29sdmluZyB0byBqdXN0IG9uZSBhZGRy ZXNzIGlzIGFuIHVuaW1wbGVtZW50YWJsZSByZXF1aXJlbWVudC4gQ3VycmVudGx5IG9uIGxhcmdl IG51bWJlciBvZiBkZXZpY2VzLCBGUURODQo+d2hpY2ggaXMgc3VwcG9zZWQgdG8gcmVzb2x2ZSB0 byBJUHY0IGFkZHJlc3Mgb25seSwgd2lsbCByZXNvbHZlIHRvIGJvdGggSVB2NiBhbmQgSVB2NCBh ZGRyZXNzZXMuIEZvciBpbnN0YW5jZSBvbiB2aXJ0dWFsbHkgYWxsIElPUyBhbmQgbW9zdA0KPm9m IHRoZSBBbmRyb2lkIGRldmljZXMgb24gbW9iaWxlIG5ldHdvcmtzIEZRRE4gcG9pbnRpbmcgdG8g SVB2NCByZXR1cm5zIHJlc3VsdHMgZm9yIElQdjYgYXMgd2VsbC4gRXNzZW50aWFsbHkgd2hhdCB3 ZSBhcmUgc3BlY2lmeWluZyBub3cgaXMNCj50aGF0IElDRSBjYW5kaWRhdGVzIHdpdGggRlFETiBh ZGRyZXNzIE1VU1QgYmUgaWdub3JlZC4NCg0KSXNu4oCZdCB0aGUgbWFpbiByZWFzb24gZm9yIGFs bG93aW5nIEZRRE4gdG8gZW5hYmxlIHVzYWdlIG9mIG1ETlM/DQoNCkluIG15IG9waW5pb24sIHRo ZSBjdXJyZW50IElDRSBwcm9jZWR1cmVzIGFzc3VtZXMgb25lIElQIGFkZHJlc3M6cG9ydCBwZXIg Y2FuZGlkYXRlLiBJZiB3ZSBhbGxvdyBhIGNhbmRpZGF0ZSB0byBiZSBhc3NvY2lhdGVkIHdpdGgg bXVsdGlwbGUgSVAgYWRkcmVzc2VzOnBvcnRzLCB3ZSB3b3VsZCBoYXZlIHRvIG1vZGlmeSB0aGUg SUNFIHByb2NlZHVyZXMgaW4gb3JkZXIgdG8gaGFuZGxlIHRoYXQ6IGhvdyBhIGNhbmRpZGF0ZSBj YW4gYmUgcGFydCBvZiBtdWx0aXBsZSBmb3VuZGF0aW9ucyAob25lIGZvciBlYWNoIHJlc29sdmVk IElQIGFkZHJlc3M6cG9ydCksIGhvdyB0aGUgZnJlZXppbmcvdW5mcmVlemluZyBwcm9jZWR1cmUg d29yaywgd2hldGhlciBjb25uZWN0aXZpdHkgY2hlY2tzIGFyZSBzZW50IHRvIGFsbCByZXNvbHZl ZCBhZGRyZXNzZXMsIGhvdyB0aGUgc3RhdGUgb2YgdGhlIGNhbmRpZGF0ZSBpcyBzZXQgaWYgb25l IElQIGFkZHJlc3M6cG9ydCBzdWNjZWVkcyBidXQgYW5vdGhlciBkb2VzbuKAmXQuIE9yLCBzaG91 bGQgdGhlIGNhbmRpZGF0ZSBiZSBzcGxpdCBpbnRvIG11bHRpcGxlIGNhbmRpZGF0ZXMgKG9uZSBm b3IgZWFjaCByZXNvbHZlZCBJUCBhZGRyZXNzOnBvcnQpPyBFdGMgZXRjIGV0YyBldGMgZXRjLiBB bGwgb2YgdGhhdCBjb3VsZCBwcm9iYWJseSBiZSBkb25lLCBidXQgSSB0aGluayBpdCB3b3VsZCBi ZSBxdWl0ZSBhIGJpdCBvZiB3b3JrLSBhbiB1cGRhdGUgKG9yIGV2ZW4gYSBiaXMpIHRvIFJGQyA4 NDQ1LiBJdCBpcyAqTk9UKiBhbiBpY2Utc2lwLXNkcCBzcGVjaWZpYyBpc3N1ZSBpbiBteSBvcGlu aW9uLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KT24gV2VkLCBBcHIgMTAsIDIwMTkg YXQgMTo0MCBBTSBTdWhhcyBOYW5kYWt1bWFyIDxzdWhhc2lldGZAZ21haWwuY29tPG1haWx0bzpz dWhhc2lldGZAZ21haWwuY29tPj4gd3JvdGU6DQpIaSBSb21hbiAmIENoYWlycw0KDQpUaGFua3Mg Zm9yIHRoZSB0ZXh0DQoNCkkgZmVlbCB3ZSBzaG91bGQgcmVzdHJpY3QgdGhlIHNjb3BlIGZvciBG UUROIHJlc29sdXRpb24gdG8ganVzdCBvbmUgYWRkcmVzcyBmb3IgdGhpcyBzcGVjaWZpY2F0aW9u LiBGdXR1cmUgc3BlY2lmaWNhdGlvbnMgbWF5IGRlZmluZSBoYW5kbGluZyBvZiBtdWx0aXBsZSBy ZXNvbHV0aW9ucyAob3IgIEROUzY0L05BVDY0ICkgc2NlbmFyaW9zDQoNCklmIG90aGVycyBhcmUg ZmluZSB3aXRoIHRoaXMsIEkgd291bGQgd2FudCB0byBnZXQgYW4gdXBkYXRlZCBkcmFmdCBhbmQg bW92ZSB0aGlzIGZvcndhcmQNCg0KDQpQbGVhc2UgbGV0ICBtZSBrbm93DQoNClRoYW5rcw0KU3Vo YXMNCg0KT24gV2VkLCBBcHIgMywgMjAxOSBhdCA5OjQ3IEFNIFJvbWFuIFNocG91bnQgPHJvbWFu QHRlbHVyaXguY29tPG1haWx0bzpyb21hbkB0ZWx1cml4LmNvbT4+IHdyb3RlOg0KUmVwb3N0aW5n IGVyIEZsZW1taW5nJ3MgYWR2aXNlIGFzIGEgbmV3IHRocmVhZDoNCg0KSGkgQWxsLA0KDQpJIGhh dmUgY3JlYXRlZCBhIHB1bGwgcmVxdWVzdCB0byBpY2Utc2lwLXNkcCAoaHR0cHM6Ly9naXRodWIu Y29tL3N1aGFzSGVyZS9pY2Utc2lwLXNkcC9wdWxsLzEpLCB3aGljaCBhbW9uZyBvdGhlciB0aGlu Z3MgYWRkZWQgYmFjayBzdXBwb3J0IGZvciBGUUROIHRvIGljZS1zaXAtc2RwLg0KDQpJbiBvcmRl ciB0byBkbyB0aGlzLCBJJ3ZlIGRvbmUgdGhlIGZvbGxvd2luZzoNCg0KMS4gSSBoYXZlIGNoYW5n ZWQgIklQIGFkZHJlc3MiIHRvICJjb25uZWN0aW9uIGFkZHJlc3MiIHRocm91Z2hvdXQgdGhlIGRv Y3VtZW50IHdoZW5ldmVyIGFkZHJlc3MgaW4gYz0gbGluZSBvciBJQ0UgY2FuZGlkYXRlIGF0dHJp YnV0ZSBpcyBtZW50aW9uZWQuIEkgaG9wZSB0aGlzIGlzIG5vdCBjb250cm92ZXJzaWFsIHNpbmNl IGl0IG1hdGNoZXMgQUJORi4NCg0KMi4gSSBoYXZlIGNoYW5nZWQgdGhlIGRlZmluaXRpb24gb2Yg PGNvbm5lY3Rpb24tYWRkcmVzcz4NCg0KT2xkOg0KPGNvbm5lY3Rpb24tYWRkcmVzcz46IDo6IGlz IHRha2VuIGZyb20gUkZDIDQ1NjYgPDxSRkM0NTY2Pj4uDQpJdCBpcyB0aGUgSVAgYWRkcmVzcyBv ZiB0aGUgY2FuZGlkYXRlLiBXaGVuIHBhcnNpbmcgdGhpcyBmaWVsZCwgYW4gYWdlbnQgY2FuIGRp ZmZlcmVudGlhdGUNCmFuIElQdjQgYWRkcmVzcyBhbmQgYW4gSVB2NiBhZGRyZXNzIGJ5IHByZXNl bmNlIG9mIGEgY29sb24gaW4gaXRzIHZhbHVlIC0tIHRoZSBwcmVzZW5jZSBvZg0KYSBjb2xvbiBp bmRpY2F0ZXMgSVB2Ni4gQW4gYWdlbnQgTVVTVCBpZ25vcmUgY2FuZGlkYXRlIGxpbmVzIHRoYXQg aW5jbHVkZSBjYW5kaWRhdGVzIHdpdGgNCklQIGFkZHJlc3MgdmVyc2lvbnMgdGhhdCBhcmUgbm90 IHN1cHBvcnRlZCBvciByZWNvZ25pemVkLg0KDQpOZXc6DQo8Y29ubmVjdGlvbi1hZGRyZXNzPjog OjogaXMgdGFrZW4gZnJvbSBSRkMgNDU2NiA8PFJGQzQ1NjY+Pi4NCkl0IGlzIHRoZSBJUCBhZGRy ZXNzIG9mIHRoZSBjYW5kaWRhdGUsIGFsbG93aW5nIGZvciBJUHY0IGFkZHJlc3NlcywgSVB2NiBh ZGRyZXNzZXMsIGFuZCBmdWxseQ0KcXVhbGlmaWVkIGRvbWFpbiBuYW1lcyAoRlFETnMpLiAgV2hl biBwYXJzaW5nIHRoaXMgZmllbGQsIGFuIGFnZW50IGNhbiBkaWZmZXJlbnRpYXRlDQphbiBJUHY0 IGFkZHJlc3MgYW5kIGFuIElQdjYgYWRkcmVzcyBieSBwcmVzZW5jZSBvZiBhIGNvbG9uIGluIGl0 cyB2YWx1ZSAtIHRoZSBwcmVzZW5jZSBvZiBhDQpjb2xvbiBpbmRpY2F0ZXMgSVB2Ni4gIEFuIGFn ZW50IE1VU1QgaWdub3JlIGNhbmRpZGF0ZSBsaW5lcyB0aGF0IGluY2x1ZGUgY2FuZGlkYXRlcyB3 aXRoDQpJUCBhZGRyZXNzIHZlcnNpb25zIHRoYXQgYXJlIG5vdCBzdXBwb3J0ZWQgb3IgcmVjb2du aXplZC4gIEFuIElQIGFkZHJlc3MgU0hPVUxEIGJlIHVzZWQsDQpidXQgYW4gRlFETiBNQVkgYmUg dXNlZCBpbiBwbGFjZSBvZiBhbiBJUCBhZGRyZXNzLiAgSW4gdGhhdCBjYXNlLCB3aGVuIHJlY2Vp dmluZyBhbg0Kb2ZmZXIgb3IgYW5zd2VyIGNvbnRhaW5pbmcgYW4gRlFETiBpbiBhbiBhPWNhbmRp ZGF0ZSBhdHRyaWJ1dGUsIHRoZSBGUUROIGlzIGxvb2tlZCB1cCBpbg0KdGhlIEROUyBmaXJzdCB1 c2luZyBib3RoIEFBQUEgcmVjb3JkIChhc3N1bWluZyB0aGUgYWdlbnQgc3VwcG9ydHMgSVB2Niks IGFuZCB1c2luZyBhbiBBDQpyZWNvcmQgKGFzc3VtaW5nIHRoZSBhZ2VudCBzdXBwb3J0cyBJUHY0 KS4gSWYsIGFuZCBvbmx5IGlmLCB0aGUgRE5TIHF1ZXJ5IHJldHVybnMNCm9ubHkgb25lIElQIGFk ZHJlc3MgaXQgaXMgdGhlbiB1c2VkIGZvciB0aGUgcmVtYWluZGVyIG9mIElDRSBwcm9jZXNzaW5n LiBJZiBETlMgcXVlcnkNCnJldHVybmVkIG1vcmUgdGhlbiBvbmUgcmVzdWx0LCBpbmNsdWRpbmcg c2l0dWF0aW9uIHdoZXJlIHNpbmdsZSBJUHY0IGFuZCBzaW5nbGUgSVB2Ng0KcmVzdWx0cyBhcmUg cmV0dXJuZWQsIGFuIGFnZW50IE1VU1QgaWdub3JlIHRoZSBjYW5kaWRhdGUuIEhhbmRsaW5nIG9m IG11bHRpcGxlIEROUw0KcmVzdWx0cyBmb3IgYSBjYW5kaWRhdGUgY2FuIGJlIGRlZmluZWQgaW4g dGhlIGZ1dHVyZSBzcGVjaWZpY2F0aW9uLiBJZiBjYW5kaWRhdGUNCndpdGggRlFETiA8Y29ubmVj dGlvbi1hZGRyZXNzPiBpcyB0aGUgZGVmYXVsdCBkZXN0aW5hdGlvbi9jYW5kaWRhdGUsIHRoZSB0 aGUgImM9Ig0KYWRkcmVzcyB0eXBlIE1VU1QgYmUgc2V0IHRoZSBJUCBhZGRyZXNzIGZhbWlseSBm b3IgdGhlIEZRRE4gRE5TIHJlc29sdXRpb24gcmVzdWx0DQphbmQgdGhlICJjPSIgY29ubmVjdGlv biBhZGRyZXNzIE1VU1QgYmUgc2V0IHRvIEZRRE4uDQoNCg0KVGhpcyBjaGFuZ2UgcmVmbGVjdHMg d2hhdCB3YXMgZGlzY3Vzc2VkIHByZXZpb3VzbHkuLiBJIGFtLCBwZXJzb25hbGx5LCBsZXNzIHRo ZW4gaGFwcHkgd2l0aCB0aGlzIGNoYW5nZS4gTXkgYmlnZ2VzdCBpc3N1ZSBpcyByZXF1aXJlbWVu dCBmb3IgRlFETiB0byByZXNvbHZlIHRvIGEgc2luZ2xlIGFkZHJlc3Mgb3IgYmUgaWdub3JlZC4g SW4gcHJhY3RpY2UsIHRoaXMgaXMgcHJvYmxlbWF0aWMgd2hlbiB0aGluZ3MgbGlrZSBETlM2NC9O QVQ2NCBhcmUgdXNlZC4gV2hlbiBETlM2NCBpcyB1c2VkLCBldmVuIHdoZW4gRlFETiB3YXMgc3Vw cG9zZWQgdG8gb25seSByZXNvbHZlIHRvIElQdjQsIEFBQUEgd2lsbCBhbHNvIHJldHVybiByZXN1 bHQgd2hpY2ggd2lsbCBwb2ludCB0byB0aGUgTkFUNjQgZ2F0ZXdheS4gQmFzZWQgb24gdGhlIGN1 cnJlbnQgbGFuZ3VhZ2UsIHRoaXMgd2lsbCByZXN1bHQgaW4gY2FuZGlkYXRlIGJlaW5nIGlnbm9y ZWQgZXZlbiB0aG91Z2ggaXQgc2hvdWxkIHdvcmsgd2l0aCBlaXRoZXIgSVB2NCBvciBJUHY2IGFk ZHJlc3MuIE1vc3QgaW1tZWRpYXRlbHksIHRoaXMgd2lsbCBtZWFuIEZRRE4gcmVzb2x2aW5nIHRv IElQdjQgd2lsbCBiZSBpZ25vcmVkIG9uIGEgbG90IG9mIG1vYmlsZSBuZXR3b3Jrcy4NCg0KSSBo YXZlIGFsc28gYWRkZWQgbGFuZ3VhZ2UgdGhhdCBkZWZpbmVzIHdoYXQgaXMgc3VwcG9zZWQgdG8g YmUgcGxhY2VkIGluIGM9IGxpbmUgd2hlbiBkZWZhdWx0IGNhbmRpZGF0ZSBpcyBhbiBGUUROIGNh bmRpZGF0ZS4gV2hhdCBoYXBwZW5zIHdoZW4gRlFETiByZXNvbHV0aW9uIHJlc3VsdCBhbmQgYWRk cmVzcyBmYW1pbHkgaW4gYz0gbGluZSBkbyBub3QgbWF0Y2ggd2FzIG5vdCBzcGVjaWZpZWQuDQoN ClRvIHN1bW1hcml6ZSwgdGhpcyBubyB3b3JzZSB0aGVuIFJGQyA1MjQ1LCBidXQgc3RpbGwgZmFp cmx5IG1lc3N5LiBJIHNlZSB0d28gcG9zc2libGUgd2F5cyB0byBjbGVhbiB0aGlzIHVwOg0KDQph LiBBZGQgYSBjYW5kaWRhdGUgZXh0ZW5zaW9uIHdoaWNoIHNwZWNpZmllcyBjYW5kaWRhdGUgYWRk cmVzcyB0eXBlLCBzb21ldGhpbmcgbGlrZSBhZGRydHlwZSB3aGljaCBjYW4gYmUgc2V0IHRvICJp bmlwdjQiIG9yICJpbmlwdjYiLiBJZiBJUCBhZGRyZXNzIGlzIHVzZWQgYW5kIGl0IGRvZXMgbm90 IG1hdGNoIHRoZSBhZGRydHlwZSBjYW5kaWRhdGUgZXh0ZW5zaW9uLCB0aGlzIGNhbmRpZGF0ZSBp cyBpZ25vcmVkLiBXaGVuIEZRRE4gaXMgdXNlZCwgaXQgaXMgcmVzb2x2ZWQgdXNpbmcgQSBETlMg cmVxdWVzdCB3aGVuIGFkZHJ0eXBlIGlzIGluaXB2NCBvciBub3QgcHJlc2VudCBhbmQgdXNpbmcg QUFBQSBETlMgcmVxdWVzdCB3aGVuIGFkZHJ0eXBlIGlzIGluaXB2Ni4gQWRkcmVzcyBmYW1pbHkg aW4gYz0gbGluZSwgd2hlbiBGUUROIGlzIGEgZGVmYXVsdCBjYW5kaWRhdGUgbXVzdCBiZSBJTiBJ UFY0IGlmIGFkZHJ0eXBlIGlzIGluaXB2NCBvciBub3QgcHJlc2VudCwgYW5kIG11c3QgYmUgSVAg SVBWNiBpZiBhZGRydHlwZSBpcyBpbmlwdjYNCg0KYi4gU3BlY2lmeSB0aGF0IGR1cmluZyBJQ0Ug bm9taW5hdGlvbiBhbGwgRE5TIHJlc29sdXRpb24gcmVzdWx0cyBmb3IgdGhlIGNhbmRpZGF0ZSBz aG91bGQgYmUgYWRkZWQgYXMgc2VwYXJhdGUgY2FuZGlkYXRlcyB0byB0aGUgY2FuZGlkYXRlIGxp c3QuIFRoaXMgaXMgbGlrZWx5IHRvIGNhdXNlIG1vcmUgcHJvYmxlbXMgdGhlbiBvcHRpb24gYS4g T25lIG9mIHRoZXNlIHByb2JsZW1zIHRoYXQgSSBzZWUgaXMgcHJpb3JpdHkgdmFsdWVzIGZvciB0 aGVzZSBjYW5kaWRhdGVzLiBDYW5kaWRhdGUgcHJpb3JpdGllcyBzaG91bGQgYmUgZGlmZmVyZW50 IGZvciBhbGwgb2YgdGhlbSBidXQgb25seSBvbmUgdmFsdWUgaXMgc3BlY2lmaWVkIGluIFNEUCBj YW5kaWRhdGUgYXR0cmlidXRlLg0KDQpJbiBvcmRlciB0byBzaW1wbGlmeSB0cmFja2luZyBjaGFu Z2VzLCBJIHdpbGwgd3JpdGUgZGlmZmVyZW50IGVtYWlscyBhYm91dCBvdGhlciBjaGFuZ2VzIEkn dmUgZG9uZSBpbiB0aGUgcHVsbCByZXF1ZXN0Lg0KDQpJIGhhdmUgYWxzbyBpbmNsdWRlZCBwZW9w bGUgd2hvIHNob3duIHByZXZpb3VzIGludGVyZXN0IGluIHRoaXMgdG9waWMuIFBsZWFzZSBsZXQg bWUga25vdyBpZiBJIG5lZWQgdG8gY3Jvc3MgcG9zdCB0byBydGN3ZWIgYW5kIGljZSBXRy4NCg0K VGhhbmsgeW91IGZvciB5b3VyIGF0dGVudGlvbiwNCl9fX19fX19fX19fX18NClJvbWFuIFNocG91 bnQNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptbXVz aWMgbWFpbGluZyBsaXN0DQptbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQo= --_000_3DD3D8D69B134F9D80DDF89B69240708ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <738E028BED41184CAAB021B5FB308F58@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCAyLjBjbSA3MC44NXB0IDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZJIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0O0xpbWl0aW5nIEZRRE4gc2NvcGUg dG8gcmVzb2x2aW5nIHRvIGp1c3Qgb25lIGFkZHJlc3MgaXMgYW4gdW5pbXBsZW1lbnRhYmxlIHJl cXVpcmVtZW50LiBDdXJyZW50bHkgb24gbGFyZ2UgbnVtYmVyIG9mIGRldmljZXMsIEZRRE4NCjxi cj4NCiZndDt3aGljaCBpcyBzdXBwb3NlZCB0byByZXNvbHZlIHRvIElQdjQgYWRkcmVzcyBvbmx5 LCB3aWxsIHJlc29sdmUgdG8gYm90aCBJUHY2IGFuZCBJUHY0IGFkZHJlc3Nlcy4gRm9yIGluc3Rh bmNlIG9uIHZpcnR1YWxseSBhbGwgSU9TIGFuZCBtb3N0DQo8YnI+DQomZ3Q7b2YgdGhlIEFuZHJv aWQgZGV2aWNlcyBvbiBtb2JpbGUgbmV0d29ya3MgRlFETiBwb2ludGluZyB0byBJUHY0IHJldHVy bnMgcmVzdWx0cyBmb3IgSVB2NiBhcyB3ZWxsLiBFc3NlbnRpYWxseSB3aGF0IHdlIGFyZSBzcGVj aWZ5aW5nIG5vdyBpcw0KPGJyPg0KJmd0O3RoYXQgSUNFIGNhbmRpZGF0ZXMgd2l0aCBGUUROIGFk ZHJlc3MgTVVTVCBiZSBpZ25vcmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ SXNu4oCZdCB0aGUgbWFpbiByZWFzb24gZm9yIGFsbG93aW5nIEZRRE4gdG8gZW5hYmxlIHVzYWdl IG9mIG1ETlM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiBteSBvcGluaW9uLCB0aGUgY3VycmVudCBJ Q0UgcHJvY2VkdXJlcyBhc3N1bWVzIG9uZSBJUCBhZGRyZXNzOnBvcnQgcGVyIGNhbmRpZGF0ZS4g SWYgd2UgYWxsb3cgYSBjYW5kaWRhdGUgdG8gYmUgYXNzb2NpYXRlZCB3aXRoIG11bHRpcGxlIElQ IGFkZHJlc3Nlczpwb3J0cywgd2Ugd291bGQgaGF2ZSB0byBtb2RpZnkgdGhlIElDRSBwcm9jZWR1 cmVzIGluIG9yZGVyIHRvIGhhbmRsZQ0KIHRoYXQ6IGhvdyBhIGNhbmRpZGF0ZSBjYW4gYmUgcGFy dCBvZiBtdWx0aXBsZSBmb3VuZGF0aW9ucyAob25lIGZvciBlYWNoIHJlc29sdmVkIElQIGFkZHJl c3M6cG9ydCksIGhvdyB0aGUgZnJlZXppbmcvdW5mcmVlemluZyBwcm9jZWR1cmUgd29yaywgd2hl dGhlciBjb25uZWN0aXZpdHkgY2hlY2tzIGFyZSBzZW50IHRvIGFsbCByZXNvbHZlZCBhZGRyZXNz ZXMsIGhvdyB0aGUgc3RhdGUgb2YgdGhlIGNhbmRpZGF0ZSBpcyBzZXQgaWYgb25lIElQIGFkZHJl c3M6cG9ydA0KIHN1Y2NlZWRzIGJ1dCBhbm90aGVyIGRvZXNu4oCZdC4gT3IsIHNob3VsZCB0aGUg Y2FuZGlkYXRlIGJlIHNwbGl0IGludG8gbXVsdGlwbGUgY2FuZGlkYXRlcyAob25lIGZvciBlYWNo IHJlc29sdmVkIElQIGFkZHJlc3M6cG9ydCk/IEV0YyBldGMgZXRjIGV0YyBldGMuIEFsbCBvZiB0 aGF0IGNvdWxkIHByb2JhYmx5IGJlIGRvbmUsIGJ1dCBJIHRoaW5rIGl0IHdvdWxkIGJlIHF1aXRl IGEgYml0IG9mIHdvcmstIGFuIHVwZGF0ZSAob3IgZXZlbiBhIGJpcykNCiB0byBSRkMgODQ0NS4g SXQgaXMgKjxiPk5PVDwvYj4qIGFuIGljZS1zaXAtc2RwIHNwZWNpZmljIGlzc3VlIGluIG15IG9w aW5pb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q2hy aXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gV2VkLCBBcHIgMTAsIDIwMTkgYXQgMTo0MCBBTSBT dWhhcyBOYW5kYWt1bWFyICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnN1aGFzaWV0ZkBnbWFp bC5jb20iPjxzcGFuIGxhbmc9IkVOLVVTIj5zdWhhc2lldGZAZ21haWwuY29tPC9zcGFuPjwvYT48 c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgUm9tYW4gJmFt cDsgQ2hhaXJzIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhhbmtzIGZvciB0aGUgdGV4dCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGZlZWwgd2Ugc2hvdWxkIHJlc3RyaWN0IHRoZSBzY29w ZSBmb3IgRlFETiByZXNvbHV0aW9uIHRvIGp1c3Qgb25lIGFkZHJlc3MgZm9yIHRoaXMgc3BlY2lm aWNhdGlvbi4gRnV0dXJlIHNwZWNpZmljYXRpb25zIG1heSBkZWZpbmUgaGFuZGxpbmcgb2YgbXVs dGlwbGUgcmVzb2x1dGlvbnMgKG9yJm5ic3A7PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDtETlM2NC9OQVQ2NCZuYnNwOykgc2NlbmFyaW9zPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPklmIG90aGVycyBhcmUgZmluZSB3aXRoIHRoaXMsIEkgd291bGQgd2FudCB0byBnZXQgYW4g dXBkYXRlZCBkcmFmdCBhbmQgbW92ZSB0aGlzJm5ic3A7Zm9yd2FyZDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPlBsZWFzZSBsZXQmbmJzcDsgbWUga25vdzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5UaGFua3M8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlN1aGFzPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBXZWQsIEFwciAzLCAyMDE5IGF0IDk6NDcgQU0gUm9tYW4gU2hwb3VudCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnJvbWFuQHRlbHVyaXguY29tIiB0YXJnZXQ9Il9ibGFuayI+cm9tYW5AdGVsdXJp eC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZXBvc3RpbmcgZXIgRmxlbW1pbmcncyBhZHZp c2UgYXMgYSBuZXcgdGhyZWFkOiA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ SGkgQWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5JIGhhdmUgY3JlYXRlZCBhIHB1bGwgcmVxdWVzdCB0byBpY2Utc2lwLXNk cCAoPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3N1aGFzSGVyZS9pY2Utc2lwLXNkcC9wdWxs LzEiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20vc3VoYXNIZXJlL2ljZS1zaXAt c2RwL3B1bGwvMTwvYT4pLCB3aGljaCBhbW9uZyBvdGhlciB0aGluZ3MgYWRkZWQgYmFjaw0KIHN1 cHBvcnQgZm9yIEZRRE4gdG8gaWNlLXNpcC1zZHAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkluIG9yZGVyIHRvIGRvIHRoaXMs IEkndmUgZG9uZSB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4xLiBJIGhhdmUgY2hhbmdlZCAmcXVvdDtJ UCBhZGRyZXNzJnF1b3Q7IHRvICZxdW90O2Nvbm5lY3Rpb24gYWRkcmVzcyZxdW90OyB0aHJvdWdo b3V0IHRoZSBkb2N1bWVudCB3aGVuZXZlciBhZGRyZXNzIGluIGM9IGxpbmUgb3IgSUNFIGNhbmRp ZGF0ZSBhdHRyaWJ1dGUgaXMgbWVudGlvbmVkLiBJIGhvcGUgdGhpcyBpcyBub3QgY29udHJvdmVy c2lhbCBzaW5jZSBpdCBtYXRjaGVzIEFCTkYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjIuIEkgaGF2ZSBjaGFuZ2VkIHRoZSBk ZWZpbml0aW9uIG9mICZsdDtjb25uZWN0aW9uLWFkZHJlc3MmZ3Q7Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk9sZDo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzAuMHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jmx0O2Nvbm5lY3Rpb24tYWRkcmVzcyZndDs6IDo6IGlzIHRha2VuIGZyb20gUkZD IDQ1NjYgJmx0OyZsdDtSRkM0NTY2Jmd0OyZndDsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JdCBpcyB0aGUg SVAgYWRkcmVzcyBvZiB0aGUgY2FuZGlkYXRlLiBXaGVuIHBhcnNpbmcgdGhpcyBmaWVsZCwgYW4g YWdlbnQgY2FuIGRpZmZlcmVudGlhdGUmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPmFuIElQdjQgYWRk cmVzcyBhbmQgYW4gSVB2NiBhZGRyZXNzIGJ5IHByZXNlbmNlIG9mIGEgY29sb24gaW4gaXRzIHZh bHVlIC0tIHRoZSBwcmVzZW5jZSBvZiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+YSBjb2xvbiBpbmRp Y2F0ZXMgSVB2Ni4gQW4gYWdlbnQgTVVTVCBpZ25vcmUgY2FuZGlkYXRlIGxpbmVzIHRoYXQgaW5j bHVkZSBjYW5kaWRhdGVzIHdpdGgmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPklQIGFkZHJlc3MgdmVy c2lvbnMgdGhhdCBhcmUgbm90IHN1cHBvcnRlZCBvciByZWNvZ25pemVkLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5OZXc6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzAuMHB0O21hcmdpbi1yaWdodDowY20iPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZsdDtjb25uZWN0aW9uLWFkZHJlc3MmZ3Q7OiA6OiBp cyB0YWtlbiBmcm9tIFJGQyA0NTY2ICZsdDsmbHQ7UkZDNDU2NiZndDsmZ3Q7LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+SXQgaXMgdGhlIElQIGFkZHJlc3Mgb2YgdGhlIGNhbmRpZGF0 ZSwgYWxsb3dpbmcgZm9yIElQdjQgYWRkcmVzc2VzLCBJUHY2IGFkZHJlc3NlcywgYW5kIGZ1bGx5 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5xdWFsaWZpZWQgZG9tYWluIG5hbWVzIChG UUROcykuJm5ic3A7IFdoZW4gcGFyc2luZyB0aGlzIGZpZWxkLCBhbiBhZ2VudCBjYW4gZGlmZmVy ZW50aWF0ZSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+YW4gSVB2NCBhZGRy ZXNzIGFuZCBhbiBJUHY2IGFkZHJlc3MgYnkgcHJlc2VuY2Ugb2YgYSBjb2xvbiBpbiBpdHMgdmFs dWUgLSB0aGUgcHJlc2VuY2Ugb2YgYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Y29s b24gaW5kaWNhdGVzIElQdjYuJm5ic3A7IEFuIGFnZW50IE1VU1QgaWdub3JlIGNhbmRpZGF0ZSBs aW5lcyB0aGF0IGluY2x1ZGUgY2FuZGlkYXRlcyB3aXRoPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5JUCBhZGRyZXNzIHZlcnNpb25zIHRoYXQgYXJlIG5vdCBzdXBwb3J0ZWQgb3IgcmVj b2duaXplZC4mbmJzcDsgQW4gSVAgYWRkcmVzcyBTSE9VTEQgYmUgdXNlZCw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPmJ1dCBhbiBGUUROIE1BWSBiZSB1c2VkIGluIHBsYWNlIG9mIGFu IElQIGFkZHJlc3MuJm5ic3A7IEluIHRoYXQgY2FzZSwgd2hlbiByZWNlaXZpbmcgYW48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPm9mZmVyIG9yIGFuc3dlciBjb250YWluaW5nIGFuIEZR RE4gaW4gYW4gYT1jYW5kaWRhdGUgYXR0cmlidXRlLCB0aGUgRlFETiBpcyBsb29rZWQgdXAgaW48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnRoZSBETlMgZmlyc3QgdXNpbmcgYm90aCBB QUFBIHJlY29yZCAoYXNzdW1pbmcgdGhlIGFnZW50IHN1cHBvcnRzIElQdjYpLCBhbmQgdXNpbmcg YW4gQTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+cmVjb3JkIChhc3N1bWluZyB0aGUg YWdlbnQgc3VwcG9ydHMgSVB2NCkuIElmLCBhbmQgb25seSBpZiwgdGhlIEROUyBxdWVyeSByZXR1 cm5zJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5vbmx5IG9uZSBJUCBhZGRy ZXNzIGl0IGlzIHRoZW4gdXNlZCBmb3IgdGhlIHJlbWFpbmRlciBvZiBJQ0UgcHJvY2Vzc2luZy4g SWYgRE5TIHF1ZXJ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5yZXR1cm5lZCBtb3Jl IHRoZW4gb25lIHJlc3VsdCwgaW5jbHVkaW5nIHNpdHVhdGlvbiB3aGVyZSBzaW5nbGUgSVB2NCBh bmQgc2luZ2xlIElQdjY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnJlc3VsdHMgYXJl IHJldHVybmVkLCBhbiBhZ2VudCBNVVNUIGlnbm9yZSB0aGUgY2FuZGlkYXRlLiBIYW5kbGluZyBv ZiBtdWx0aXBsZSBETlM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnJlc3VsdHMgZm9y IGEgY2FuZGlkYXRlIGNhbiBiZSBkZWZpbmVkIGluIHRoZSBmdXR1cmUgc3BlY2lmaWNhdGlvbi4g SWYgY2FuZGlkYXRlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj53aXRoIEZRRE4gJmx0 O2Nvbm5lY3Rpb24tYWRkcmVzcyZndDsgaXMgdGhlIGRlZmF1bHQgZGVzdGluYXRpb24vY2FuZGlk YXRlLCB0aGUgdGhlICZxdW90O2M9JnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5hZGRyZXNzIHR5cGUgTVVTVCBiZSBzZXQgdGhlIElQIGFkZHJlc3MgZmFtaWx5IGZvciB0aGUg RlFETiBETlMgcmVzb2x1dGlvbiByZXN1bHQmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPmFuZCB0aGUgJnF1b3Q7Yz0mcXVvdDsgY29ubmVjdGlvbiBhZGRyZXNzIE1VU1QgYmUg c2V0IHRvIEZRRE4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5UaGlzIGNoYW5nZSByZWZsZWN0cyB3aGF0IHdhcyBkaXNjdXNzZWQgcHJldmlvdXNs eS4uIEkgYW0sIHBlcnNvbmFsbHksIGxlc3MgdGhlbiBoYXBweSB3aXRoIHRoaXMgY2hhbmdlLiBN eSBiaWdnZXN0IGlzc3VlIGlzIHJlcXVpcmVtZW50IGZvciBGUUROIHRvIHJlc29sdmUgdG8gYSBz aW5nbGUgYWRkcmVzcyBvciBiZSBpZ25vcmVkLiBJbiBwcmFjdGljZSwgdGhpcw0KIGlzIHByb2Js ZW1hdGljIHdoZW4gdGhpbmdzIGxpa2UgRE5TNjQvTkFUNjQgYXJlIHVzZWQuIFdoZW4gRE5TNjQg aXMgdXNlZCwgZXZlbiB3aGVuIEZRRE4gd2FzIHN1cHBvc2VkIHRvIG9ubHkgcmVzb2x2ZSB0byBJ UHY0LCBBQUFBIHdpbGwgYWxzbyByZXR1cm4gcmVzdWx0IHdoaWNoIHdpbGwgcG9pbnQgdG8gdGhl IE5BVDY0IGdhdGV3YXkuIEJhc2VkIG9uIHRoZSBjdXJyZW50IGxhbmd1YWdlLCB0aGlzIHdpbGwg cmVzdWx0IGluIGNhbmRpZGF0ZQ0KIGJlaW5nIGlnbm9yZWQgZXZlbiB0aG91Z2ggaXQgc2hvdWxk IHdvcmsgd2l0aCBlaXRoZXIgSVB2NCBvciBJUHY2IGFkZHJlc3MuIE1vc3QgaW1tZWRpYXRlbHks IHRoaXMgd2lsbCBtZWFuIEZRRE4gcmVzb2x2aW5nIHRvIElQdjQgd2lsbCBiZSBpZ25vcmVkIG9u IGEgbG90IG9mIG1vYmlsZSBuZXR3b3Jrcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SSBoYXZlIGFsc28gYWRkZWQgbGFuZ3Vh Z2UgdGhhdCBkZWZpbmVzIHdoYXQgaXMgc3VwcG9zZWQgdG8gYmUgcGxhY2VkIGluIGM9IGxpbmUg d2hlbiBkZWZhdWx0IGNhbmRpZGF0ZSBpcyBhbiBGUUROIGNhbmRpZGF0ZS4gV2hhdCBoYXBwZW5z IHdoZW4gRlFETiByZXNvbHV0aW9uIHJlc3VsdCBhbmQgYWRkcmVzcyBmYW1pbHkgaW4gYz0gbGlu ZSBkbyBub3QgbWF0Y2gNCiB3YXMgbm90IHNwZWNpZmllZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VG8gc3VtbWFyaXplLCB0 aGlzIG5vIHdvcnNlIHRoZW4gUkZDIDUyNDUsIGJ1dCBzdGlsbCBmYWlybHkgbWVzc3kuIEkgc2Vl IHR3byBwb3NzaWJsZSB3YXlzIHRvIGNsZWFuIHRoaXMgdXA6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPmEuIEFkZCBhIGNhbmRp ZGF0ZSBleHRlbnNpb24gd2hpY2ggc3BlY2lmaWVzIGNhbmRpZGF0ZSBhZGRyZXNzIHR5cGUsIHNv bWV0aGluZyBsaWtlIGFkZHJ0eXBlIHdoaWNoIGNhbiBiZSBzZXQgdG8gJnF1b3Q7aW5pcHY0JnF1 b3Q7IG9yICZxdW90O2luaXB2NiZxdW90Oy4gSWYgSVAgYWRkcmVzcyBpcyB1c2VkIGFuZCBpdCBk b2VzIG5vdCBtYXRjaCB0aGUgYWRkcnR5cGUgY2FuZGlkYXRlIGV4dGVuc2lvbiwNCiB0aGlzIGNh bmRpZGF0ZSBpcyBpZ25vcmVkLiBXaGVuIEZRRE4gaXMgdXNlZCwgaXQgaXMgcmVzb2x2ZWQgdXNp bmcgQSBETlMgcmVxdWVzdCB3aGVuIGFkZHJ0eXBlIGlzIGluaXB2NCBvciBub3QgcHJlc2VudCBh bmQgdXNpbmcgQUFBQSBETlMgcmVxdWVzdCB3aGVuIGFkZHJ0eXBlIGlzIGluaXB2Ni4gQWRkcmVz cyBmYW1pbHkgaW4gYz0gbGluZSwgd2hlbiBGUUROIGlzIGEgZGVmYXVsdCBjYW5kaWRhdGUgbXVz dCBiZSBJTiBJUFY0IGlmIGFkZHJ0eXBlDQogaXMgaW5pcHY0IG9yIG5vdCBwcmVzZW50LCBhbmQg bXVzdCBiZSBJUCBJUFY2IGlmIGFkZHJ0eXBlIGlzIGluaXB2NjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5iLiBTcGVjaWZ5IHRo YXQgZHVyaW5nIElDRSBub21pbmF0aW9uIGFsbCBETlMgcmVzb2x1dGlvbiByZXN1bHRzIGZvciB0 aGUgY2FuZGlkYXRlIHNob3VsZCBiZSBhZGRlZCBhcyBzZXBhcmF0ZSBjYW5kaWRhdGVzIHRvIHRo ZSBjYW5kaWRhdGUgbGlzdC4gVGhpcyBpcyBsaWtlbHkgdG8gY2F1c2UgbW9yZSBwcm9ibGVtcyB0 aGVuIG9wdGlvbiBhLiBPbmUgb2YgdGhlc2UNCiBwcm9ibGVtcyB0aGF0IEkgc2VlIGlzIHByaW9y aXR5IHZhbHVlcyBmb3IgdGhlc2UgY2FuZGlkYXRlcy4gQ2FuZGlkYXRlIHByaW9yaXRpZXMgc2hv dWxkIGJlIGRpZmZlcmVudCBmb3IgYWxsIG9mIHRoZW0gYnV0IG9ubHkgb25lIHZhbHVlIGlzIHNw ZWNpZmllZCBpbiBTRFAgY2FuZGlkYXRlIGF0dHJpYnV0ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SW4gb3JkZXIgdG8gc2lt cGxpZnkgdHJhY2tpbmcgY2hhbmdlcywgSSB3aWxsIHdyaXRlIGRpZmZlcmVudCBlbWFpbHMgYWJv dXQgb3RoZXIgY2hhbmdlcyBJJ3ZlIGRvbmUgaW4gdGhlIHB1bGwgcmVxdWVzdC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SSBo YXZlIGFsc28gaW5jbHVkZWQgcGVvcGxlIHdobyBzaG93biBwcmV2aW91cyBpbnRlcmVzdCBpbiB0 aGlzIHRvcGljLiBQbGVhc2UgbGV0IG1lIGtub3cgaWYgSSBuZWVkIHRvIGNyb3NzIHBvc3QgdG8g cnRjd2ViIGFuZCBpY2UgV0cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoYW5rIHlvdSBmb3IgeW91ciBhdHRlbnRpb24sPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX188YnI+DQpSb21hbiBT aHBvdW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KbW11c2ljIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpt bXVzaWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNp YzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_3DD3D8D69B134F9D80DDF89B69240708ericssoncom_-- From nobody Wed Apr 10 12:36:18 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3CC1205E2 for ; Wed, 10 Apr 2019 12:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a26aVlRBdVC4 for ; Wed, 10 Apr 2019 12:36:08 -0700 (PDT) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C0451205CD for ; Wed, 10 Apr 2019 12:36:05 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id j26so2151625pgl.5 for ; Wed, 10 Apr 2019 12:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vMZPgsy4LyxC4rDAsT70WvnfDXVoc86SN1cg/Bg7Sko=; b=LS1w21404tl2R5EtwMUtP86ulT7qxin/HYt5P/LuuTiFrAoKJoHgjkl+qi0DbLNenC YYOQ9UhnmfKrlNZVVoEvAQnhmyKAnG9KIJcyZDPXIDVI9asRi3BIbZ8zhWCCv/hF4olv zvdE+eIlWTZzdNe1BNjNrH2IzXDHp9yw5gFEYKAeKTFGcH7rLXfayq+da50KP4dxL6/H PJipLQASJkzu3FdSWaiYvdOgJgo2MIy685MbLq8LpNGa6XR75551d9dak0xiyDdF5H8c 537ZeCIeYdiyxtCg/OdH9n7TWg+WI67xMFXfsjrVzLXI1GWtcT7f99mq63lMABrwPqO6 gung== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vMZPgsy4LyxC4rDAsT70WvnfDXVoc86SN1cg/Bg7Sko=; b=qL7o+ohOB87o4HNL2ZUIllJDdBgtEnAyWf32C1jEfsg9H2DpE8vNybrkMJjsMKVqkO vDWEXBOYOr0/bsBsnk7zGq+6zxPP5Gy6C14TcPK9SX1G3MdXAmwg6V4ool/yg0ApwgJ1 WQbD6dzZsaqz6iOioGSSUg9m2HU4fUjND0B4Jc0GhJgeX0wjuPgnFk1cPNRODOG/PrA1 +EXZ7zsFr2pashzjj0vqhOtKlEw2PkYTkQSYJLwzFziV5E8KLCqybMtLO6uQMPPmKkqb 7jdUcOVmxca38jYs2Dbc+vEYkVbZoxpM9TGe8U9edNXJDLIP24m/13wUNcH3vm8dBlEh iN9w== X-Gm-Message-State: APjAAAUT4CmUX+DA+R9XfFx+qQFpnMX7CIjieAyqb0iYpzmHmydNtHgT PnhZwc7pOgGSyZErfZYNjkP9x7kbJ2g= X-Google-Smtp-Source: APXvYqwWzqurK2fGhK3un1om8+AYUGzAcBorSqAR9gIk2h29BZfc4k7YFqQFFha3QYp/3er/F9dB7Q== X-Received: by 2002:a63:ed10:: with SMTP id d16mr42588841pgi.75.1554924964735; Wed, 10 Apr 2019 12:36:04 -0700 (PDT) Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com. [209.85.214.170]) by smtp.gmail.com with ESMTPSA id v12sm48670355pfe.148.2019.04.10.12.36.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Apr 2019 12:36:03 -0700 (PDT) Received: by mail-pl1-f170.google.com with SMTP id t16so2036567plo.0 for ; Wed, 10 Apr 2019 12:36:03 -0700 (PDT) X-Received: by 2002:a17:902:b686:: with SMTP id c6mr45967095pls.14.1554924963307; Wed, 10 Apr 2019 12:36:03 -0700 (PDT) MIME-Version: 1.0 References: <3DD3D8D6-9B13-4F9D-80DD-F89B69240708@ericsson.com> In-Reply-To: <3DD3D8D6-9B13-4F9D-80DD-F89B69240708@ericsson.com> From: Roman Shpount Date: Wed, 10 Apr 2019 15:35:49 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Suhas Nandakumar , mmusic WG , Flemming Andreasen Content-Type: multipart/alternative; boundary="0000000000001725c80586322ec7" Archived-At: Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp X-BeenThere: mmusic@ietf.org 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, 10 Apr 2019 19:36:17 -0000 --0000000000001725c80586322ec7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 10, 2019 at 3:13 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > >Limiting FQDN scope to resolving to just one address is an > unimplementable requirement. Currently on large number of devices, FQDN > > >which is supposed to resolve to IPv4 address only, will resolve to both > IPv6 and IPv4 addresses. For instance on virtually all IOS and most > >of the Android devices on mobile networks FQDN pointing to IPv4 returns > results for IPv6 as well. Essentially what we are specifying now is > >that ICE candidates with FQDN address MUST be ignored. > > > > Isn=E2=80=99t the main reason for allowing FQDN to enable usage of mDNS? > It is now. Nothing in the latest language that I propose prohibits mDNS draft define how FQDN are supposed to work when mDNS is used. All my language states that default treatment for FQDN is to ignore it which keeps mDNS backwards compatible. I would also suggest adding an ICE option to specify that mDNS is supported. This being said, I am not sure mDNS prevents IPv4 address being resolved as IPv6 through DNS64, so mDNS is likely going to end up with two addresses for a single candidate. In my opinion, the current ICE procedures assumes one IP address:port per > candidate. If we allow a candidate to be associated with multiple IP > addresses:ports, we would have to modify the ICE procedures in order to > handle that: how a candidate can be part of multiple foundations (one for > each resolved IP address:port), how the freezing/unfreezing procedure wor= k, > whether connectivity checks are sent to all resolved addresses, how the > state of the candidate is set if one IP address:port succeeds but another > doesn=E2=80=99t. Or, should the candidate be split into multiple candidat= es (one > for each resolved IP address:port)? Etc etc etc etc etc. All of that coul= d > probably be done, but I think it would be quite a bit of work- an update > (or even a bis) to RFC 8445. It is **NOT** an ice-sip-sdp specific issue > in my opinion. > I am not suggesting changing that only one address is supported per candidate. What I am suggesting is that candidate needs some sort of hint when FQDN is used to specify how address should be resolved. Here is my proposed solution: Add a candidate extension which specifies candidate address type, something like addrtype which can be set to "inipv4" or "inipv6". If IP address is used and it does not match the addrtype candidate extension, this candidate is ignored. When FQDN is used, it is resolved using A DNS request when addrtype is inipv4 or not present and using AAAA DNS request when addrtype is inipv6. Address family in c=3D line, when FQDN is a default candidate mu= st be IN IPV4 if addrtype is inipv4 or not present, and must be IP IPV6 if addrtype is inipv6 Example: a=3Dcandidate:2319437384 1 udp 2122260223 8a2fd7b5-41d5-4c15-ad83-d33a0d66a75a.local 60454 typ host *inipv4* a=3Dcandidate:2319437384 1 udp 2122260223 8a2fd7b5-41d5-4c15-ad83-d33a0d66a78b.local 60454 typ host *inipv6* This keeps each candidate line to one address and works in cases when FQDN resolves to one IPv4 and one IPv6 address due to something like DNS64. Regards, _____________ Roman Shpount --0000000000001725c80586322ec7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Apr = 10, 2019 at 3:13 PM Christer Holmberg <christer.holmberg@ericsson.com> w= rote:

>Limiting FQDN scope to resolving to just one add= ress is an unimplementable requirement. Currently on large number of device= s, FQDN=C2=A0

>which is supposed to resolve to IPv4 address only, will resolve to both= IPv6 and IPv4 addresses. For instance on virtually all IOS and most
>of the Android devices on mobile networks FQDN pointing to IPv4 returns= results for IPv6 as well. Essentially what we are specifying now is
>that ICE candidates with FQDN address MUST be ignored.

=C2=A0

Isn=E2=80=99t the main reason f= or allowing FQDN to enable usage of mDNS?


=C2=A0It is now. Nothing in the latest la= nguage that I propose prohibits mDNS draft define how FQDN are supposed to = work when mDNS is used. All my language states that default treatment for F= QDN is to ignore it which keeps mDNS backwards compatible. I would also sug= gest adding an ICE option to specify that mDNS is supported. This being sai= d, I am not sure mDNS prevents IPv4 address being resolved as IPv6 through = DNS64, so mDNS is likely going to end up with two addresses for a single ca= ndidate.

<= u>

In my opinion, the current ICE procedures assumes on= e IP address:port per candidate. If we allow a candidate to be associated w= ith multiple IP addresses:ports, we would have to modify the ICE procedures= in order to handle that: how a candidate can be part of multiple foundations (one for each re= solved IP address:port), how the freezing/unfreezing procedure work, whethe= r connectivity checks are sent to all resolved addresses, how the state of = the candidate is set if one IP address:port succeeds but another doesn=E2=80=99t. Or, should the candidate be split in= to multiple candidates (one for each resolved IP address:port)? Etc etc etc= etc etc. All of that could probably be done, but I think it would be quite= a bit of work- an update (or even a bis) to RFC 8445. It is *NOT* an ice-sip-sdp specific issue in my opinio= n.


I am not suggesting chan= ging that only one address is supported per candidate. What I am suggesting= is that candidate needs some sort of hint when FQDN is used to specify how= address should be resolved. Here is my proposed solution:

<= div class=3D"gmail_quote">
Add a candidate extension which specifies ca= ndidate address type, something like addrtype which can be set to "ini= pv4" or "inipv6". If IP address is used and it does not matc= h the addrtype candidate extension, this candidate is ignored. When FQDN is= used, it is resolved using A DNS request when addrtype is inipv4 or not pr= esent and using AAAA DNS request when addrtype is inipv6. Address family in= c=3D line, when FQDN is a default candidate must be IN IPV4 if addrtype is= inipv4 or not present, and must be IP IPV6 if addrtype is inipv6=C2=A0

Example:
a=3Dcandidate:2319437384 1 udp 2122260223= 8a2fd7b5-41d5-4c15-ad83-d33a0d66a7= 5a.local 60454 typ host=C2=A0inipv4
a=3Dcandidate:2319437384 1 udp 2122260223 8a2fd7b5-41= d5-4c15-ad83-d33a0d66a78b.local 604= 54 typ host=C2=A0inipv6=C2=A0=C2=A0

=
This keeps each candidate line to one address and = works in cases when FQDN resolves to one IPv4 and one IPv6 address due to s= omething like DNS64.

Regards,
=C2=A0_____________
Roman Shpount
=C2=A0
--0000000000001725c80586322ec7-- From nobody Wed Apr 10 13:23:39 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B622C12021D; Wed, 10 Apr 2019 13:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EY46DygoMXsR; Wed, 10 Apr 2019 13:23:36 -0700 (PDT) Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8360120165; Wed, 10 Apr 2019 13:23:35 -0700 (PDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x3AKNRgx021968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 10 Apr 2019 16:23:27 -0400 To: wangzitao , "ops-dir@ietf.org" Cc: "ietf@ietf.org" , "draft-ietf-mmusic-rfc4566bis.all@ietf.org" , "mmusic@ietf.org" References: From: Paul Kyzivat Message-ID: <7541a94f-e539-f78b-fc92-5b0dbed22da1@alum.mit.edu> Date: Wed, 10 Apr 2019 16:24:53 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MMUSIC] Opsdir last call review of draft-ietf-mmusic-rfc4566bis-34 X-BeenThere: mmusic@ietf.org 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, 10 Apr 2019 20:23:38 -0000 Please see inline. On 4/9/19 11:03 PM, wangzitao wrote: > Hi Paul, > > Please find my comments at [MW]. > > B.R. > -Michael > > -----邮件原件----- > å‘件人: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > å‘é€æ—¶é—´: 2019å¹´4月10æ—¥ 1:11 > 收件人: wangzitao ; ops-dir@ietf.org > 抄é€: ietf@ietf.org; draft-ietf-mmusic-rfc4566bis.all@ietf.org; mmusic@ietf.org > 主题: Re: [MMUSIC] Opsdir last call review of draft-ietf-mmusic-rfc4566bis-34 > > Thank you for the comments. I have some questions: > > On 4/8/19 2:37 AM, Zitao Wang via Datatracker wrote: >> Reviewer: Zitao Wang >> Review result: Has Issues >> >> Summary: This memo defines the Session Description Protocol (SDP). SDP is >> intended for describing multimedia sessions for the purposes of >> session announcement, session invitation, and other forms of >> multimedia session initiation. This document obsoletes RFC 4566. I >> think the document make sense and is written very clear, except some small nits: > > >> # In Section 5, there are >> several terms that miss references, such as "US-ASCII subset of >> UTF-8", "ASN.1 or XDR", etc. > > There is already a reference to the definition of UTF-8 [RFC3629] in section 4.5. Do you think the reference needs to be included with every use? The US-ASCII subset of UTF-8 is also defined in RFC3629, so I am inclined to use the same reference for that. There are also a couple of uses of US-ASCII without mention of UTF-8. I'm inclined to change those to "the US-ASCII subset of UTF-8". I changed the naked uses of US-ASCII to reference the US-ASCII subset of UTF-8. I also added another reference to RFC3629 to the *first* use of "US-ASCII subset of UTF-8". I haven't added references to other places with the same usage. > Regarding ASN.1 and XDR, I can add references if you think it important. > But their use is very peripheral, and it isn't necessary to know what they are to read the text. > [MW]: I am OK if it is not commonly used. > > # s/session- specific/session-specific/ > > Regarding "session- specific" vs. "session-specific": > > The context for this is: > > "Attribute scopes in addition to media- and session- specific may also..." > > The space was intentional so that there are equivalent constructions for "media" and "session". The intent is as a shorthand for: > > "Attribute scopes in addition to media-specific and session-specific may also..." > > To avoid confusion I think I'll just change to the latter. > [MW]: I agree. Done. > # Suggest to add tags on >> "overview optional items" to identified now-obsolete items, such as >> "a=cat", "a=keywds", "k=". > > I'm not clear what you want me to do. > > I guess you are suggesting adding something to the first figure in section 5. > [MW]: Yes, IMO, adding some tag/description to the figure is better. > > I don't see how that would be possible for a=cat and a=keywds, since the figure doesn't mention individual attributes. > [MW]: Agree. For a=cat and a=keywds, it is difficult to show on the figure. > > While it is possible to add something for k=, IMO it is better to leave that level of detail to the complete description in section 5.12. > [MW]: Maybe it can be updated as following: > > Before : > k=* (encryption key) > After: > k=* (encryption key, this line is obsoleted) I changed these to k=* (obsolete) I have these changes in my working copy for inclusion the next time I submit a revision. Thanks, Paul From nobody Wed Apr 10 19:53:08 2019 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C8012046F; Wed, 10 Apr 2019 19:53:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-mmusic-data-channel-sdpneg@ietf.org, Bo Burman , mmusic-chairs@ietf.org, bo.burman@ericsson.com, mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <155495118561.22741.226184336926630062.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2019 19:53:05 -0700 Archived-At: Subject: [MMUSIC] Benjamin Kaduk's No Objection on draft-ietf-mmusic-data-channel-sdpneg-25: (with COMMENT) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.29 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 02:53:06 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-mmusic-data-channel-sdpneg-25: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 4 The mechanism in this document only applies to the Session Description Protocol (SDP) [I-D.ietf-mmusic-rfc4566bis] when used together with the SDP offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of scope of this document, and is thus undefined. nit: this text doesn't actually scope itself to "this mechanism" or the RTCWeb data channel, and seems to be saying that all declarative SDP is undefined, globally. Section 5.1.7 The ordered parameter is optional and takes two values: "true" for ordered and "false" for unordered delivery with "true" as the default value. Any other value is ignored and default "ordered=true" is assumed. [...] This seems to be saying that offers or answers that do not conform to the ABNF will be special-cased as being ignored (instead of rejected) when they appear where ordering-value should appear. It's not clear to me why we need a special case here, since in Section 8 we explicitly say that peers MUST close the relevant data channel when such error cases occur. Section 5.1.8 If we chase links to draft-ietf-rtcweb-data-channel we find that larger values indicate higher priority. Do we want to short-circuit that and say so explicitly here? Section 5.2 Each of these attributes is represented by one new attribute line, and it includes the contents of a media-level SDP attribute already defined for use with this (sub)protocol in another IETF (Internet Engineering Task Force) document. [...] Do we need to limit the data-channel subprotocols to those specified by the IETF? Or is it just the media-level SDP attributes that we are trying to maintain change control over? The detailed offer/answer procedures for the dcsa attribute are dependent on the associated sub-protocol. If no offer/answer procedures exist for the sub-protocol when used outside of the dcsa attribute, no specification is needed for use with dcsa. The IANA registration procedures for the WebSocket Subprotocol Name Registry (Section 9.1) do not strictly require a specification of the offer/ answer procedures for the sub-protocol when used with dcsa. If the sub-protocol has defined offer/answer procedures when used outside of dcsa, such a specification is encouraged to ensure interoperability. If the sub-protocol has defined offer/answer procedures when used outside of dcsa, but no specification exists for the offer/answer procedures for the sub-protocol when used with dcsa, implementations SHOULD assume the use of the default values for all otherwise- negotiable and applicable sub-protocol parameters. I'm not entirely sure I understand what this paragraph is trying to say. The first sentence is clear, but the second sentence seems to be saying that if there are no O/A procedures for a given subprotocol outside the datachannel, it's just a free for all and I can use it in the data channel and make up my own procedures for using the dcsa attribute. I understand that IANA doesn't require a specification for the subprotocol when allocating the subprotocol name, but that just means that there may not be a specification available whether or not I want to use it with dcsa -- the IANA registry doesn't care directly about use with dcsa. If a subprotocol has defined O/A procedures outside of dcsa, doesn't that basically mean there's a specification? Why do we need to go out of our way to encourage a specification in that case (and is it a specification of the O/A semantics when the subprotocol is used outside dcsa or with dcsa)? In the last sentence, I think we're talking about using defaults for parameters that are not explicitly negotiated using dcsa, but we don't actually say that. Section 5.2.1 Note however that not all SDP attributes are suitable as a "a=dcsa:" parameter. IANA SDP parameters contains the lists of IANA (Internet Assigned Numbers Authority) registered session and media level or media level only SDP attributes. Am I supposed to infer that these are the attributes that are suitable for a=dcsa: parameters? As opposed to the data channel "a=dcmap:" attribute parameters, these parameters are subject to offer/answer negotiation following the procedures defined in the subprotocol specific documents. I am not sure where we really say that the a=dcmap: parameters are not subject to O/A negotiation. Section 6.1 SCTP stream identifiers associated with data channels that have been negotiated using DCEP MUST NOT be included in SDP offers and answers. This sentence appears as a dedicated paragraph and is duplicated at the end of the previous paragraph; presumably we only need one copy thereof... Section 6.2 If an SDP answer contains both of these parameters then the offerer MUST treat the associated SDP offer/answer failed. nit: "as failed", I think. Section 6.4 We only mention that the dcmap-stream-id, max-retr, and max-time values need to match the offer, leaving the ordering/subprotocol/label/priority to be omitted because they are conveyed at the SCTP layer? Perhaps we should state explicitly that they need to be absent... Section 6.6 Do we want to say anything about the appropriate response to receiving changed values for the SDP attributes/attribute values is to close the corresponding data channel? Section 6.6.1 It seems like the second bullet point only makes sense after the first has completed, as the tsvart reviewer noted? Specifically, the "; or" at the end of the first bullet point doesn't seem to make much sense. Section 9.3 If existing media attributes are used in a datachannel subprotocol specific way (Section 5.2.1), then a new dcsa usage level MUST be defined for the existing media attribute. [...] I'm not entirely sure that I understand what this means, though I'm not really an expert in SDP. Appendix A.1 I'm not sure that I know what "glare situations" are; is there a reasonable reference to include? Which set of stream identifiers is owned by which endpoint is determined by convention or other means. (specific to the application?) Note:For data channels negotiated via different protocol from DCEP, no convention is defined by default. That seems a bit misleading, since Section 6.1 says that the even/odd split applies to the SDP O/A negotiation case. From nobody Thu Apr 11 00:29:27 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2AB12007A; Thu, 11 Apr 2019 00:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygszvW3e4RRc; Thu, 11 Apr 2019 00:29:23 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 347C412017D; Thu, 11 Apr 2019 00:29:23 -0700 (PDT) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 0EF8398C3FC3A375A446; Thu, 11 Apr 2019 08:29:21 +0100 (IST) Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 11 Apr 2019 08:29:20 +0100 Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 11 Apr 2019 08:29:20 +0100 Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Thu, 11 Apr 2019 08:29:20 +0100 Received: from DGGEMM527-MBX.china.huawei.com ([169.254.6.122]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0415.000; Thu, 11 Apr 2019 15:29:04 +0800 From: wangzitao To: Paul Kyzivat , "ops-dir@ietf.org" CC: "ietf@ietf.org" , "draft-ietf-mmusic-rfc4566bis.all@ietf.org" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Opsdir last call review of draft-ietf-mmusic-rfc4566bis-34 Thread-Index: AdTwOA+WHtBjfNJUSRGniaW2r1dQNw== Date: Thu, 11 Apr 2019 07:29:04 +0000 Message-ID: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.142.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [MMUSIC] Opsdir last call review of draft-ietf-mmusic-rfc4566bis-34 X-BeenThere: mmusic@ietf.org 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: Thu, 11 Apr 2019 07:29:25 -0000 VGhhbmsgeW91IGZvciB1cGRhdGluZy4gSXQgbWFrZSBzZW5zZSB0byBtZS4NCg0KQmVzdCBSZWdh cmRzIQ0KLU1pY2hhZWwgDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogUGF1 bCBLeXppdmF0IFttYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1XSANCuWPkemAgeaXtumXtDog MjAxOeW5tDTmnIgxMeaXpSA0OjI1DQrmlLbku7bkuro6IHdhbmd6aXRhbyA8d2FuZ3ppdGFvQGh1 YXdlaS5jb20+OyBvcHMtZGlyQGlldGYub3JnDQrmioTpgIE6IGlldGZAaWV0Zi5vcmc7IGRyYWZ0 LWlldGYtbW11c2ljLXJmYzQ1NjZiaXMuYWxsQGlldGYub3JnOyBtbXVzaWNAaWV0Zi5vcmcNCuS4 u+mimDogUmU6IFtNTVVTSUNdIE9wc2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYt bW11c2ljLXJmYzQ1NjZiaXMtMzQNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCk9uIDQvOS8xOSAx MTowMyBQTSwgd2FuZ3ppdGFvIHdyb3RlOg0KPiBIaSBQYXVsLA0KPiANCj4gUGxlYXNlIGZpbmQg bXkgY29tbWVudHMgYXQgW01XXS4NCj4gDQo+IEIuUi4NCj4gLU1pY2hhZWwNCj4gDQo+IC0tLS0t 6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBQYXVsIEt5eml2YXQgW21haWx0bzpwa3l6 aXZhdEBhbHVtLm1pdC5lZHVdDQo+IOWPkemAgeaXtumXtDogMjAxOeW5tDTmnIgxMOaXpSAxOjEx DQo+IOaUtuS7tuS6ujogd2FuZ3ppdGFvIDx3YW5neml0YW9AaHVhd2VpLmNvbT47IG9wcy1kaXJA aWV0Zi5vcmcNCj4g5oqE6YCBOiBpZXRmQGlldGYub3JnOyBkcmFmdC1pZXRmLW1tdXNpYy1yZmM0 NTY2YmlzLmFsbEBpZXRmLm9yZzsgDQo+IG1tdXNpY0BpZXRmLm9yZw0KPiDkuLvpopg6IFJlOiBb TU1VU0lDXSBPcHNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiANCj4gZHJhZnQtaWV0Zi1tbXVzaWMt cmZjNDU2NmJpcy0zNA0KPiANCj4gVGhhbmsgeW91IGZvciB0aGUgY29tbWVudHMuIEkgaGF2ZSBz b21lIHF1ZXN0aW9uczoNCj4gDQo+IE9uIDQvOC8xOSAyOjM3IEFNLCBaaXRhbyBXYW5nIHZpYSBE YXRhdHJhY2tlciB3cm90ZToNCj4+IFJldmlld2VyOiBaaXRhbyBXYW5nDQo+PiBSZXZpZXcgcmVz dWx0OiBIYXMgSXNzdWVzDQo+Pg0KPj4gU3VtbWFyeTogICAgVGhpcyBtZW1vIGRlZmluZXMgdGhl IFNlc3Npb24gRGVzY3JpcHRpb24gUHJvdG9jb2wgKFNEUCkuICBTRFAgaXMNCj4+IGludGVuZGVk IGZvciBkZXNjcmliaW5nIG11bHRpbWVkaWEgc2Vzc2lvbnMgZm9yIHRoZSBwdXJwb3NlcyBvZiAN Cj4+IHNlc3Npb24gYW5ub3VuY2VtZW50LCBzZXNzaW9uIGludml0YXRpb24sIGFuZCBvdGhlciBm b3JtcyBvZiANCj4+IG11bHRpbWVkaWEgc2Vzc2lvbiBpbml0aWF0aW9uLiAgVGhpcyBkb2N1bWVu dCBvYnNvbGV0ZXMgUkZDIDQ1NjYuIEkgDQo+PiB0aGluayB0aGUgZG9jdW1lbnQgbWFrZSBzZW5z ZSBhbmQgaXMgd3JpdHRlbiB2ZXJ5IGNsZWFyLCBleGNlcHQgc29tZSBzbWFsbCBuaXRzOg0KPiAN Cj4gDQo+PiAjIEluIFNlY3Rpb24gNSwgdGhlcmUgYXJlDQo+PiBzZXZlcmFsIHRlcm1zIHRoYXQg bWlzcyByZWZlcmVuY2VzLCBzdWNoIGFzICJVUy1BU0NJSSBzdWJzZXQgb2YgDQo+PiBVVEYtOCIs ICAiQVNOLjEgb3IgWERSIiwgZXRjLg0KPiANCj4gVGhlcmUgaXMgYWxyZWFkeSBhIHJlZmVyZW5j ZSB0byB0aGUgZGVmaW5pdGlvbiBvZiBVVEYtOCBbUkZDMzYyOV0gaW4gc2VjdGlvbiA0LjUuIERv IHlvdSB0aGluayB0aGUgcmVmZXJlbmNlIG5lZWRzIHRvIGJlIGluY2x1ZGVkIHdpdGggZXZlcnkg dXNlPyBUaGUgVVMtQVNDSUkgc3Vic2V0IG9mIFVURi04IGlzIGFsc28gZGVmaW5lZCBpbiBSRkMz NjI5LCBzbyBJIGFtIGluY2xpbmVkIHRvIHVzZSB0aGUgc2FtZSByZWZlcmVuY2UgZm9yIHRoYXQu IFRoZXJlIGFyZSBhbHNvIGEgY291cGxlIG9mIHVzZXMgb2YgVVMtQVNDSUkgd2l0aG91dCBtZW50 aW9uIG9mIFVURi04LiBJJ20gaW5jbGluZWQgdG8gY2hhbmdlIHRob3NlIHRvICJ0aGUgVVMtQVND SUkgc3Vic2V0IG9mIFVURi04Ii4NCg0KSSBjaGFuZ2VkIHRoZSBuYWtlZCB1c2VzIG9mIFVTLUFT Q0lJIHRvIHJlZmVyZW5jZSB0aGUgVVMtQVNDSUkgc3Vic2V0IG9mIFVURi04LiBJIGFsc28gYWRk ZWQgYW5vdGhlciByZWZlcmVuY2UgdG8gUkZDMzYyOSB0byB0aGUgKmZpcnN0KiB1c2Ugb2YgIlVT LUFTQ0lJIHN1YnNldCBvZiBVVEYtOCIuIEkgaGF2ZW4ndCBhZGRlZCByZWZlcmVuY2VzIHRvIG90 aGVyIHBsYWNlcyB3aXRoIHRoZSBzYW1lIHVzYWdlLg0KDQo+IFJlZ2FyZGluZyBBU04uMSBhbmQg WERSLCBJIGNhbiBhZGQgcmVmZXJlbmNlcyBpZiB5b3UgdGhpbmsgaXQgaW1wb3J0YW50Lg0KPiBC dXQgdGhlaXIgdXNlIGlzIHZlcnkgcGVyaXBoZXJhbCwgYW5kIGl0IGlzbid0IG5lY2Vzc2FyeSB0 byBrbm93IHdoYXQgdGhleSBhcmUgdG8gcmVhZCB0aGUgdGV4dC4NCj4gW01XXTogSSBhbSBPSyBp ZiBpdCBpcyBub3QgY29tbW9ubHkgdXNlZC4NCj4gDQo+ICMgcy9zZXNzaW9uLSBzcGVjaWZpYy9z ZXNzaW9uLXNwZWNpZmljLw0KPiANCj4gUmVnYXJkaW5nICJzZXNzaW9uLSBzcGVjaWZpYyIgdnMu ICJzZXNzaW9uLXNwZWNpZmljIjoNCj4gDQo+IFRoZSBjb250ZXh0IGZvciB0aGlzIGlzOg0KPiAN Cj4gIkF0dHJpYnV0ZSBzY29wZXMgaW4gYWRkaXRpb24gdG8gbWVkaWEtIGFuZCBzZXNzaW9uLSBz cGVjaWZpYyBtYXkgYWxzby4uLiINCj4gDQo+IFRoZSBzcGFjZSB3YXMgaW50ZW50aW9uYWwgc28g dGhhdCB0aGVyZSBhcmUgZXF1aXZhbGVudCBjb25zdHJ1Y3Rpb25zIGZvciAibWVkaWEiIGFuZCAi c2Vzc2lvbiIuIFRoZSBpbnRlbnQgaXMgYXMgYSBzaG9ydGhhbmQgZm9yOg0KPiANCj4gIkF0dHJp YnV0ZSBzY29wZXMgaW4gYWRkaXRpb24gdG8gbWVkaWEtc3BlY2lmaWMgYW5kIHNlc3Npb24tc3Bl Y2lmaWMgbWF5IGFsc28uLi4iDQo+IA0KPiBUbyBhdm9pZCBjb25mdXNpb24gSSB0aGluayBJJ2xs IGp1c3QgY2hhbmdlIHRvIHRoZSBsYXR0ZXIuDQo+IFtNV106IEkgYWdyZWUuDQoNCkRvbmUuDQoN Cj4gIyBTdWdnZXN0IHRvIGFkZCB0YWdzIG9uDQo+PiAib3ZlcnZpZXcgb3B0aW9uYWwgaXRlbXMi IHRvIGlkZW50aWZpZWQgbm93LW9ic29sZXRlIGl0ZW1zLCBzdWNoIGFzIA0KPj4gImE9Y2F0Iiwg ImE9a2V5d2RzIiwgIms9Ii4NCj4gDQo+IEknbSBub3QgY2xlYXIgd2hhdCB5b3Ugd2FudCBtZSB0 byBkby4NCj4gDQo+IEkgZ3Vlc3MgeW91IGFyZSBzdWdnZXN0aW5nIGFkZGluZyBzb21ldGhpbmcg dG8gdGhlIGZpcnN0IGZpZ3VyZSBpbiBzZWN0aW9uIDUuDQo+IFtNV106IFllcywgSU1PLCBhZGRp bmcgc29tZSB0YWcvZGVzY3JpcHRpb24gdG8gdGhlIGZpZ3VyZSBpcyBiZXR0ZXIuDQo+IA0KPiBJ IGRvbid0IHNlZSBob3cgdGhhdCB3b3VsZCBiZSBwb3NzaWJsZSBmb3IgYT1jYXQgYW5kIGE9a2V5 d2RzLCBzaW5jZSB0aGUgZmlndXJlIGRvZXNuJ3QgbWVudGlvbiBpbmRpdmlkdWFsIGF0dHJpYnV0 ZXMuDQo+IFtNV106IEFncmVlLiBGb3IgYT1jYXQgYW5kIGE9a2V5d2RzLCBpdCBpcyBkaWZmaWN1 bHQgdG8gc2hvdyBvbiB0aGUgZmlndXJlLg0KPiANCj4gV2hpbGUgaXQgaXMgcG9zc2libGUgdG8g YWRkIHNvbWV0aGluZyBmb3Igaz0sIElNTyBpdCBpcyBiZXR0ZXIgdG8gbGVhdmUgdGhhdCBsZXZl bCBvZiBkZXRhaWwgdG8gdGhlIGNvbXBsZXRlIGRlc2NyaXB0aW9uIGluIHNlY3Rpb24gNS4xMi4N Cj4gW01XXTogTWF5YmUgaXQgY2FuIGJlIHVwZGF0ZWQgYXMgZm9sbG93aW5nOg0KPiANCj4gICAg ICAgIEJlZm9yZSA6DQo+ICAgICAgICAgaz0qIChlbmNyeXB0aW9uIGtleSkNCj4gICAgICAgIEFm dGVyOg0KPiAgICAgICAgIGs9KiAoZW5jcnlwdGlvbiBrZXksIHRoaXMgbGluZSBpcyBvYnNvbGV0 ZWQpDQoNCkkgY2hhbmdlZCB0aGVzZSB0bw0KDQogICAgICAgICAgIGs9KiAob2Jzb2xldGUpDQoN CkkgaGF2ZSB0aGVzZSBjaGFuZ2VzIGluIG15IHdvcmtpbmcgY29weSBmb3IgaW5jbHVzaW9uIHRo ZSBuZXh0IHRpbWUgSSBzdWJtaXQgYSByZXZpc2lvbi4NCg0KCVRoYW5rcywNCglQYXVsDQo= From nobody Thu Apr 11 00:57:38 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24EFD12017D; Thu, 11 Apr 2019 00:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MrCp_AZzob0; Thu, 11 Apr 2019 00:57:34 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70044.outbound.protection.outlook.com [40.107.7.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A2C0120003; Thu, 11 Apr 2019 00:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=euaWBLPgBKw3zyF+fpR1IpOiJeaXV1smbIzHBEbHUmg=; b=AobiXLXOCzMSJRSZMQqHDMMp/Cdgo12HcbxOlWcWIcKtv1St3TZxUt0iEUSW9qdmUGja2AywWjwqWWqGH/+sKXgQuul61L1Ws+mnth9CabYoLJtdCcdIfUyg09wWpgTbjTIJ9VDpEac4kNfNDLS9s6zZOc41nD+WkIfSvBn+Rh8= Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2331.eurprd07.prod.outlook.com (10.168.129.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.11; Thu, 11 Apr 2019 07:57:30 +0000 Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::107c:5f27:2ef:8505]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::107c:5f27:2ef:8505%5]) with mapi id 15.20.1792.009; Thu, 11 Apr 2019 07:57:30 +0000 From: Magnus Westerlund To: Adam Roach , The IESG CC: "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-data-channel-sdpneg@ietf.org" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT) Thread-Index: AQHU66fNA40h4UsP7kq3a/Vv5QT6wQ== Date: Thu, 11 Apr 2019 07:57:30 +0000 Message-ID: References: <155446588097.13196.6373243259627185094.idtracker@ietfa.amsl.com> <1afcb116-36cb-be51-81ac-e78fc52c9255@nostrum.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.82] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 289688f1-ccfa-4c16-f9ab-08d6be53594a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2331; x-ms-traffictypediagnostic: HE1PR0701MB2331: x-microsoft-antispam-prvs: x-forefront-prvs: 00046D390F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(136003)(346002)(376002)(366004)(199004)(189003)(8936002)(53936002)(478600001)(81166006)(81156014)(93886005)(8676002)(33656002)(5660300002)(9686003)(44832011)(55016002)(6116002)(97736004)(2906002)(52536014)(256004)(446003)(76176011)(6506007)(53546011)(26005)(186003)(66066001)(102836004)(3846002)(86362001)(105586002)(305945005)(486006)(106356001)(316002)(68736007)(6246003)(7736002)(99286004)(54906003)(71200400001)(71190400001)(110136005)(476003)(74316002)(6436002)(25786009)(229853002)(4326008)(7696005)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2331; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: lyK5xIbL2hfGP1Y1oQhB0yRLOCEwgawDH4QnJCNnYc5vZQADflHNDGOg0u5GQh6bZOTclohXKK/9/DsU1hi4Wsdzi/VIi0wm3b5r9BMk86IaXr0BYQFwTW90VgH/bSsf9rDn3Kuu7t5lPYe4NnRQPWehFgkrioXMHb3XhwrM+lRGHvSTCL4Qs2txR3rTEz7UXFU7lOxJe/19nUxcWaAFD+qlGqThjTic4K0DMv+YmjCbYB4tPdhYJoazmmk58u0pQ+z3LZmytz6q76QQCVlT9i2RAnWC81fh2+pryFQZO+iuPdGp+6tu/t9dENrzNCwW3MOT1l/l4UXrDrl9Fb8GGhrjcw+lMc5bhSpoX0K19PwyEtUgyPChQ1BpUenmQHz1jQusIeQPQKKVPDWlYGKfsOSXf0AMFJMBQjV+VAgYm2c= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 289688f1-ccfa-4c16-f9ab-08d6be53594a X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2019 07:57:30.8171 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2331 Archived-At: Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT) X-BeenThere: mmusic@ietf.org 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: Thu, 11 Apr 2019 07:57:36 -0000 On 2019-04-10 19:30, Adam Roach wrote:=0A= > On 4/10/19 3:18 AM, Magnus Westerlund wrote:=0A= >> Is this something that actually should be addressed in4566bis? =0A= >=0A= > It's in IETF last call, but we can pause processing until the WG has =0A= > time to consider the issue. Do you want me to ask the MMUSIC chairs to = =0A= > take this question to the working group?=0A= >=0A= For 4566bis I hope the WG could discuss this before the IETF last call=0A= ends. It will run for another 2 week isn't it so there is time for that.=0A= =0A= I don't have a strong view if holding up the data-channel-sdpneg doc for=0A= a week or two while this is discussed is the right answer or not. I=0A= think the major point here is there actual problems of using UTF-8 text=0A= fields in SDP Attributes in the relevant deployment environments. And=0A= for this particular document will a change create significant=0A= interoperability issues?=0A= =0A= I see some benefit is letting the WG provide input into this matter=0A= before it is to late and it can be done with only minor delay in=0A= progressing the data channel document.=0A= =0A= I will send a separate email as IETF last call comment on 4566bis.=0A= =0A= Cheers=0A= =0A= Magnus=0A= =0A= From nobody Thu Apr 11 01:01:42 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B693120003; Thu, 11 Apr 2019 01:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpmiJdsABgTX; Thu, 11 Apr 2019 01:01:29 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BD9312017D; Thu, 11 Apr 2019 01:01:29 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id A850DCE1592DA6C564A3; Thu, 11 Apr 2019 09:01:27 +0100 (IST) Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 11 Apr 2019 09:01:27 +0100 Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.138]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0415.000; Thu, 11 Apr 2019 16:01:05 +0800 From: "Roni Even (A)" To: Magnus Westerlund , Adam Roach , The IESG CC: "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-data-channel-sdpneg@ietf.org" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT) Thread-Index: AQHU66fNA40h4UsP7kq3a/Vv5QT6waY2nvKg Date: Thu, 11 Apr 2019 08:01:05 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18CDB506@dggemm526-mbx.china.huawei.com> References: <155446588097.13196.6373243259627185094.idtracker@ietfa.amsl.com> <1afcb116-36cb-be51-81ac-e78fc52c9255@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.102] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD18CDB506dggemm526mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT) X-BeenThere: mmusic@ietf.org 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: Thu, 11 Apr 2019 08:01:35 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD18CDB506dggemm526mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I looked at https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-09 = there label is defined Label: Variable Length (sequence of characters) The name of the Data Channel as a UTF-8 encoded string as specified in [RFC3629]. This ma= y be an empty string. Also protocol is specified there as Protocol: Variable Length (sequence of characters) If this is an empty string the protocol is unspecified. If it is a non-empty string, it specifies a protocol registered in the 'WebSocket Subprotocol Name Registry' created in [RFC6455]. This string is UTF-8 encoded as specified in [RFC3629]. This will map to w3c https://www.w3.org/TR/webrtc/ USVString defined for b= oth protocol and label. This made me wonder since the sub-protocol identif= ier in RFC6455 defines as a token (RFC2616) which in my understanding is AS= CII. draft-ietf-mmusic-data-channel-sdpneg-25 defies both as quoted string . Not= e that the mmusic document is referenced by CLUE data channel using SDP. I think that taking Adam's suggestion make sense. I also think that specify= ing SDP values to only use UTF-8 may have issues with registration in IANA So we can add to section 5.1.3 "In order to communicate with WEbRTC API the label attribute should * Serialize the WebRTC label as a UTF-8 string * Treat the UTF-8 serialization as a series of bytes * For each byte in the serialization: * If the byte can be expressed as a `quoted-char`, do so * Otherwise, express the byte as an `escaped-char`. " Is this OK? Roni From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] Sent: Wednesday, April 10, 2019 11:18 AM To: Adam Roach; The IESG Cc: mmusic-chairs@ietf.org; draft-ietf-mmusic-data-channel-sdpneg@ietf.org;= mmusic@ietf.org Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data= -channel-sdpneg-25: (with DISCUSS and COMMENT) On 2019-04-09 18:51, Adam Roach wrote: On 4/9/19 4:00 AM, Magnus Westerlund wrote: On 2019-04-08 17:55, Adam Roach wrote: On 4/5/19 7:04 AM, Magnus Westerlund via Datatracker wrote: ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- There might be a serious issue in label definition. 5.1.3. Label Parameter The 'label' parameter indicates the name of the channel. It represents a label that can be used to distinguish, in the context of the WebRTC API [WebRtcAPI], an RTCDataChannel object from other RTCDataChannel objects. This parameter maps to the 'Label' parameter defined in [I-D.ietf-rtcweb-data-protocol]. The 'label' parameter is optional. If it is not present, then its value defaults to the empty string. label-opt =3D "label=3D" quoted-string quoted-string =3D DQUOTE *(quoted-char / escaped-char) DQUOTE quoted-char =3D SP / quoted-visible quoted-visible =3D %x21 / %x23-24 / %x26-7E ; VCHAR without " or % escaped-char =3D "%" HEXDIG HEXDIG I interpret that as the intention is to enable the SDP Attribute to carry t= he label as defined in W3C API. That value is in the current candidatate specification an https://www.w3.org/TR/webrtc/ as an USVSsting (https://heycam.github.io/webidl/#idl-USVString). And in the reference vers= ion of the WebRTC API as an DOMstring. Both are not limited to ASCII and may contain any Unicode characters. Thus the escaping mechanism defined appear = to be insufficient. I think the "quoted-string" need a definition of what type of string this t= ruly are so that it is clear what a character in the string is. In addition the specification of escaping is undersspecified. I would recom= mend at least adding discussion of the need and how to escape DQUOTE and % that = can be relatively common operations. I can see that this could benefit from some explicit detail about how to co= nvert the cited USVString string into the "quoted-string" construct defined= here. I think this roughly consists of: * Serialize the WebRTC label as a UTF-8 string * Treat the UTF-8 serialization as a series of bytes * For each byte in the serialization: * If the byte can be expressed as a `quoted-char`, do so * Otherwise, express the byte as an `escaped-char`. Would including text to that effect satisfy your concern? Yes it would be clear what is expected. However, I fail to understand why o= ne need to ASCIIify and escape the UTF-8 encoded characters where one could= simply define the label value as an UTF-8 string something that is compati= ble with SDP specification. Wouldn't that reduce the set of characters need= ing escaping to a much smaller set. That's a little tricky. RFC 4566: "SDP also allows other character sets suc= h as ISO 8859-1 to be used when desired." Even if we just constrain this to SIP, RFC 3261: "When no explicit charset = parameter is provided by the sender, media subtypes of the 'text' type are = defined to have a default charset value of 'UTF-8'." So there's a bias towards UTF-8, but no strict requirement. I'd support a short document that deprecated non-UTF-8 encodings of SDP so = that specifications like this one could simply assume that the full charact= er set can be used directly, but that's not the current state of affairs. Is this something that actually should be addressed in4566bis? Anyway, I am fine with the previous outline for solution as my issue was th= at it was not clear how to get the intended labels into the SDP when desire= d in a way that is interoperable. So I will remove my discuss when the docu= ment has been addressed. cheers Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --_000_6E58094ECC8D8344914996DAD28F1CCD18CDB506dggemm526mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I looked at https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-09 t= here label is defined

 

Label: Variable Length (sequence of characters)=

      The name of the Data Channe= l as a UTF-8 encoded string as

      specified in [RFC3629].  This may be an empty string.<= o:p>

 <= /p>

Also protocol is specifie= d there as

  Protocol: Variable Length (sequence of charact= ers)

      If this is an empty string = the protocol is unspecified.  If it is

      a non-empty string, it spec= ifies a protocol registered in the

      'WebSocket Subprotocol Name= Registry' created in [RFC6455].  This

      string is UTF-8 encoded as = specified in [RFC3629].

 

This will map to w3c https://www.w3.org/TR/webr= tc/  USVString defined for both protocol and label.  This mad= e me wonder since the sub-protocol identifier in RFC6455 defines as a token= (RFC2616) which in my understanding is ASCII.

 

draft-ietf-mmusic-data-channel-sdpneg-25 defies both= as quoted string . Note that the mmusic document is referenced by CLUE dat= a channel using SDP.

 

I think that taking Adam’s suggestion make sen= se. I also think that specifying SDP values to only use UTF-8 may have issu= es with registration in IANA

 

So we can add to section 5.1.3

 

“In order to communicate with WEbRTC API the l= abel attribute should

  • Serialize the WebRTC label as a UTF-8 string
  • Treat the UTF-8 serialization as a series of bytes
  • For each byte in the serialization:
    • If the byte can be expressed as a `quoted-char`, do so
    • Otherwise, express the byte as an `escaped-char`.

 

“

 

 

Is this OK?

 

 

Roni

 

 <= /p>

 <= /p>

From: Magnus Westerlund [mailto:magnus.westerlund@erics= son.com]
Sent: Wednesday, April 10, 2019 11:18 AM
To: Adam Roach; The IESG
Cc: mmusic-chairs@ietf.org; draft-ietf-mmusic-data-channel-sdpneg@ie= tf.org; mmusic@ietf.org
Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmus= ic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)

 

On 2019-04-09 18:51, Adam Roach wrote:

On 4/9/19 4:00 AM, Magnus Westerlund wrote:

On 2019-04-08 17:55, Adam Roach wrote:

On 4/5/19 7:04 AM, Magnus Westerlund via Datatracker= wrote:

----------------------------------------------------------------------=

DISCUSS:
----------------------------------------------------------------------=

 
There might be a serious issue in label definition.
 
5.1.3.  Label Parameter
 
   The 'label' parameter indicates the name of the channel.&=
nbsp; It
   represents a label that can be used to distinguish, in th=
e context of
   the WebRTC API [WebRtcAPI], an RTCDataChannel object from=
 other
   RTCDataChannel objects.  This parameter maps to the =
'Label' parameter
   defined in [I-D.ietf-rtcweb-data-protocol].  The 'la=
bel' parameter is
   optional.  If it is not present, then its value defa=
ults to the empty
   string.
 
  label-opt       =3D "label=
=3D" quoted-string
  quoted-string   =3D DQUOTE *(quoted-char / escaped-ch=
ar) DQUOTE
  quoted-char     =3D SP / quoted-visible
  quoted-visible  =3D %x21 / %x23-24 / %x26-7E ; VCHAR witho=
ut " or %
  escaped-char    =3D "%" HEXDIG HEXDIG<=
o:p>
 
I interpret that as the intention is to enable the SDP Attribute to ca=
rry the
label as defined in W3C API. That value is in the current candidatate<=
o:p>
specification an https://www=
.w3.org/TR/webrtc/ as an USVSsting
(https://he=
ycam.github.io/webidl/#idl-USVString). And in the reference version
of the WebRTC API as an DOMstring. Both are not limited to ASCII and m=
ay
contain any Unicode characters. Thus the escaping mechanism defined ap=
pear to
be insufficient.
 
I think the "quoted-string" need a definition of what type o=
f string this truly
are so that it is clear what a character in the string is.<=
/pre>

 


In addition the specification of escaping is undersspecified. I would =
recommend


at least adding discussion of the need and how to escape DQUOTE and % =
that can


be relatively common operations.

 

I can see that this could benefit from some explicit detail about how to= convert the cited USVString string into the "quoted-string" cons= truct defined here. I think this roughly consists of:

  • Serialize the WebRTC label as a UTF-8 string
  • Treat the UTF-8 serialization as a series of bytes
  • For each byte in the serialization:
    • If the byte can be expressed as a `quoted-char`, do so
    • Otherwise, express the byte as an `escaped-char`.

Would including text to that effect satisfy your concern?

Yes it would be clear what is expected. However, I fail to understand wh= y one need to ASCIIify and escape the UTF-8 encoded characters where one co= uld simply define the label value as an UTF-8 string something that is comp= atible with SDP specification. Wouldn't that reduce the set of characters needing escaping to a much smaller set. =

 

That's a little tricky. RFC 4566: "SDP also allows other character = sets such as ISO 8859-1 to be used when desired."

Even if we just constrain this to SIP, RFC 3261: "When no explicit = charset parameter is provided by the sender, media subtypes of the 'text' t= ype are defined to have a default charset value of 'UTF-8'."

So there's a bias towards UTF-8, but no strict requirement.

I'd support a short document that deprecated non-UTF-8 encodings of SDP = so that specifications like this one could simply assume that the full char= acter set can be used directly, but that's not the current state of affairs= .

Is this something that actually should be addressed in4566bis?

Anyway, I am fine with the previous outline for solution as my issue was= that it was not clear how to get the intended labels into the SDP when des= ired in a way that is interoperable. So I will remove my discuss when the d= ocument has been addressed. 

cheers 
 
Magnus Westerlund 
 
----------------------------------------------------------------------=

Network Architecture & Protocols, Ericsson Research

----------------------------------------------------------------------=



Ericsson AB          =
;       | Phone  +46 10 7148287=



Torshamnsgatan 23         =
;  | Mobile +46 73 0949079


SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com


----------------------------------------------------------------------=
--_000_6E58094ECC8D8344914996DAD28F1CCD18CDB506dggemm526mbxchi_-- From nobody Thu Apr 11 01:03:37 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658AC12029B for ; Thu, 11 Apr 2019 01:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcAr1hoywtSi for ; Thu, 11 Apr 2019 01:03:30 -0700 (PDT) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C25601202AD for ; Thu, 11 Apr 2019 01:03:28 -0700 (PDT) Received: by mail-vs1-xe2a.google.com with SMTP id n4so2967340vsm.3 for ; Thu, 11 Apr 2019 01:03:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rsWukwhmvaf7CamjeLYtDRZZhotxpD+ZuAIrMqd77xs=; b=QYgCcRl2idK+SZ4HpcA3dw/PAUDOKBQBhAawMLu15dASSV5wMlBHuoJtA0no0VWKT/ klv4bpot0E2pD9YgBN8ipLSViia4V43JegbX7WijzaVTFuFTHOEouDYi/v6YQhL2OHBD voAFINTWchEMqsXPunxCqfq8MtcD69mEAx4cUIxTCoSGLY5z4AN3cLdXfOiBXtQoa/z+ BxVFL1/pHKKrj+3Zn3xgQDha9Q5KEpQvaN3S1AkTdvvi/stTO24fvVAFJPLa7uP0IA6L enNbJqD9LNUhkBhU/NEt5JC/gPFIkNs7MF2Rm1gRwx/Yq7dics/k39/uYrL+Uf5HJYAy C0HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rsWukwhmvaf7CamjeLYtDRZZhotxpD+ZuAIrMqd77xs=; b=d4LxGAaP/IiduGM6vdfyCDirBFqzaMbKiSZYLbrWQCVAFijLQ8uGYvNwwv7zNPRl8i NtzB4dhSmPdRi7gvFSNHDHRTrB41c1+WxBauFNpxaVrilRc/t2tv4GPdBRMdsI2Mb3Zk e8eS1Id/v2wL48U2tofqs0el4fjvowgdUNu+Ir/Lgffpb6gdFbgSxx/aHccFjo3LiyYQ VYyNnquA9IDPTiaPZoKlLCvDMRbnMyGXXyUFm2OXctNIRpbxM/THIWaKGAObU6hb8G7m KpxexNnPjcFGsuU9UlBcH59AtvVWvY5D1ZNugaBv4f7WIzAj55aVOBw3DszQGZ/qDoe8 cJFA== X-Gm-Message-State: APjAAAWId//3fEHcc4a0tgSt/bAv/Vms1JXE2Nq29FyfSoTtwndkhvAK yRQ5hprFawzI35JV1KL36BlIIF0M87ou2WDQdsw= X-Google-Smtp-Source: APXvYqzBnTdxdVHcB7mNO1dijLc8nsfNVO4onU/5K85u+MCP1lY7Ya02muoOPmeywLLhzBPwUH/UX9H7LzxYGXeWEhQ= X-Received: by 2002:a67:80c8:: with SMTP id b191mr26298141vsd.184.1554969807868; Thu, 11 Apr 2019 01:03:27 -0700 (PDT) MIME-Version: 1.0 References: <3DD3D8D6-9B13-4F9D-80DD-F89B69240708@ericsson.com> In-Reply-To: From: Suhas Nandakumar Date: Thu, 11 Apr 2019 01:03:17 -0700 Message-ID: To: Roman Shpount Cc: Christer Holmberg , Suhas Nandakumar , mmusic WG , Flemming Andreasen Content-Type: multipart/alternative; boundary="00000000000008d78b05863c9fa8" Archived-At: Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp X-BeenThere: mmusic@ietf.org 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: Thu, 11 Apr 2019 08:03:36 -0000 --00000000000008d78b05863c9fa8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 10, 2019 at 12:36 PM Roman Shpount wrote: > On Wed, Apr 10, 2019 at 3:13 PM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> >Limiting FQDN scope to resolving to just one address is an >> unimplementable requirement. Currently on large number of devices, FQDN >> >> >which is supposed to resolve to IPv4 address only, will resolve to both >> IPv6 and IPv4 addresses. For instance on virtually all IOS and most >> >of the Android devices on mobile networks FQDN pointing to IPv4 returns >> results for IPv6 as well. Essentially what we are specifying now is >> >that ICE candidates with FQDN address MUST be ignored. >> >> >> >> Isn=E2=80=99t the main reason for allowing FQDN to enable usage of mDNS? >> > > It is now. Nothing in the latest language that I propose prohibits mDNS > draft define how FQDN are supposed to work when mDNS is used. All my > language states that default treatment for FQDN is to ignore it which kee= ps > mDNS backwards compatible. I would also suggest adding an ICE option to > specify that mDNS is supported. This being said, I am not sure mDNS > prevents IPv4 address being resolved as IPv6 through DNS64, so mDNS is > likely going to end up with two addresses for a single candidate. > > In my opinion, the current ICE procedures assumes one IP address:port per >> candidate. If we allow a candidate to be associated with multiple IP >> addresses:ports, we would have to modify the ICE procedures in order to >> handle that: how a candidate can be part of multiple foundations (one fo= r >> each resolved IP address:port), how the freezing/unfreezing procedure wo= rk, >> whether connectivity checks are sent to all resolved addresses, how the >> state of the candidate is set if one IP address:port succeeds but anothe= r >> doesn=E2=80=99t. Or, should the candidate be split into multiple candida= tes (one >> for each resolved IP address:port)? Etc etc etc etc etc. All of that cou= ld >> probably be done, but I think it would be quite a bit of work- an update >> (or even a bis) to RFC 8445. It is **NOT** an ice-sip-sdp specific issue >> in my opinion. >> > > I am not suggesting changing that only one address is supported per > candidate. What I am suggesting is that candidate needs some sort of hint > when FQDN is used to specify how address should be resolved. Here is my > proposed solution: > > Add a candidate extension which specifies candidate address type, > something like addrtype which can be set to "inipv4" or "inipv6". If IP > address is used and it does not match the addrtype candidate extension, > this candidate is ignored. When FQDN is used, it is resolved using A DNS > request when addrtype is inipv4 or not present and using AAAA DNS request > when addrtype is inipv6. Address family in c=3D line, when FQDN is a defa= ult > candidate must be IN IPV4 if addrtype is inipv4 or not present, and must = be > IP IPV6 if addrtype is inipv6 > > Example: > a=3Dcandidate:2319437384 1 udp 2122260223 8a2fd7b5-41d5-4c15-ad83-d33a0d6= 6a75a.local > 60454 typ host *inipv4* > a=3Dcandidate:2319437384 1 udp 2122260223 8a2fd7b5-41d5-4c15-ad83-d33a0d6= 6a78b.local > 60454 typ host *inipv6* > > I am not for or against the proposal. I am sure its fine. I am concerned about the scope of this change and current implementations who are willing to support this new extension. Why can't this be in a total new draft ? > > > This keeps each candidate line to one address and works in cases when FQD= N > resolves to one IPv4 and one IPv6 address due to something like DNS64. > > Regards, > _____________ > Roman Shpount > > --00000000000008d78b05863c9fa8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Apr 10, 2019 at 12:36 PM Roman Sh= pount <roman@telurix.com> wr= ote:
On Wed, Apr 10, 2019 at 3:13 PM= Christer Holmberg <christer.holmberg@ericsson.com> wrote:

>Limiting FQDN scope to resolving to just one add= ress is an unimplementable requirement. Currently on large number of device= s, FQDN=C2=A0

>which is supposed to resolve to IPv4 address only, will resolve to both= IPv6 and IPv4 addresses. For instance on virtually all IOS and most
>of the Android devices on mobile networks FQDN pointing to IPv4 returns= results for IPv6 as well. Essentially what we are specifying now is
>that ICE candidates with FQDN address MUST be ignored.

=C2=A0

Isn=E2=80=99t the main reason f= or allowing FQDN to enable usage of mDNS?


=C2=A0It is now. Nothing in the latest la= nguage that I propose prohibits mDNS draft define how FQDN are supposed to = work when mDNS is used. All my language states that default treatment for F= QDN is to ignore it which keeps mDNS backwards compatible. I would also sug= gest adding an ICE option to specify that mDNS is supported. This being sai= d, I am not sure mDNS prevents IPv4 address being resolved as IPv6 through = DNS64, so mDNS is likely going to end up with two addresses for a single ca= ndidate.

In my opinion, the current ICE procedures assumes on= e IP address:port per candidate. If we allow a candidate to be associated w= ith multiple IP addresses:ports, we would have to modify the ICE procedures= in order to handle that: how a candidate can be part of multiple foundations (one for each re= solved IP address:port), how the freezing/unfreezing procedure work, whethe= r connectivity checks are sent to all resolved addresses, how the state of = the candidate is set if one IP address:port succeeds but another doesn=E2=80=99t. Or, should the candidate be split in= to multiple candidates (one for each resolved IP address:port)? Etc etc etc= etc etc. All of that could probably be done, but I think it would be quite= a bit of work- an update (or even a bis) to RFC 8445. It is *NOT* an ice-sip-sdp specific issue in my opinio= n.


I am not suggesting chan= ging that only one address is supported per candidate. What I am suggesting= is that candidate needs some sort of hint when FQDN is used to specify how= address should be resolved. Here is my proposed solution:

Add a candidate extension which specif= ies candidate address type, something like addrtype which can be set to &qu= ot;inipv4" or "inipv6". If IP address is used and it does no= t match the addrtype candidate extension, this candidate is ignored. When F= QDN is used, it is resolved using A DNS request when addrtype is inipv4 or = not present and using AAAA DNS request when addrtype is inipv6. Address fam= ily in c=3D line, when FQDN is a default candidate must be IN IPV4 if addrt= ype is inipv4 or not present, and must be IP IPV6 if addrtype is inipv6=C2= =A0

Examp= le:
a=3Dcandidate:2319437384 1 u= dp 2122260223 8a2fd7b5-41d5-4c15-ad83-d33a0d66a75a.local 60454 typ host=C2=A0inipv4
a=3Dcandidate:2319437384 1 udp 212226022= 3 8a2fd7b5-41d5-4c15-ad83-d33a0d66a= 78b.local 60454 typ host=C2=A0inipv6=C2=A0=C2=A0
<= /blockquote>

I am not for or against = the proposal. I am sure its fine.=C2=A0 I am concerned about the scope of t= his change and current implementations who are willing to support this new = extension. Why can't this be in a total new draft ?=C2=A0
=C2= =A0


This keeps each candidate line to one address and works in cases when F= QDN resolves to one IPv4 and one IPv6 address due to something like DNS64.<= div>
Regards,
=C2=A0______= _______
Roman Shpount
=C2=A0
--00000000000008d78b05863c9fa8-- From nobody Thu Apr 11 01:06:02 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE7412013E for ; Thu, 11 Apr 2019 01:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyaABf8Y7ZUc for ; Thu, 11 Apr 2019 01:05:57 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20050.outbound.protection.outlook.com [40.107.2.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5983A12011D for ; Thu, 11 Apr 2019 01:05:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Azy1WdXlCrg68Yw2lbjluGpVLzE+uoLF4DJjHKw5hHg=; b=gIvuYb9pbfcxwEpSZnYXteRGBr2NSn5vhuRzU17TDV98wv1VIxS+3/V8Du50FS8EstrLHt0balR/NJzVmba3Sw1ocmjQqhnP9w7ILCTSiUOyYTEJZNulSmSLi1ZSsmSckOM2rnwwxN78WZCu9dMmQe9ZGDSj99t0nnychq618Is= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3339.eurprd07.prod.outlook.com (10.170.247.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.8; Thu, 11 Apr 2019 08:05:54 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9%5]) with mapi id 15.20.1792.007; Thu, 11 Apr 2019 08:05:54 +0000 From: Christer Holmberg To: Roman Shpount CC: Suhas Nandakumar , mmusic WG , Flemming Andreasen Thread-Topic: [MMUSIC] FQDN support in ice-sip-sdp Thread-Index: AQHU6jzz/50YAJx2kEqY4siuQ2NZYqY0606AgADVT4CAAEAVAP//1AeAgAED24A= Date: Thu, 11 Apr 2019 08:05:54 +0000 Message-ID: References: <3DD3D8D6-9B13-4F9D-80DD-F89B69240708@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 41e6d50b-b94a-4fc5-6a12-08d6be54857c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3339; x-ms-traffictypediagnostic: HE1PR07MB3339: x-microsoft-antispam-prvs: x-forefront-prvs: 00046D390F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(136003)(396003)(376002)(39860400002)(199004)(189003)(8936002)(82746002)(6916009)(2906002)(44832011)(316002)(68736007)(229853002)(8676002)(6486002)(6512007)(81156014)(81166006)(6436002)(76176011)(3846002)(14444005)(97736004)(4326008)(25786009)(58126008)(6116002)(6246003)(33656002)(54906003)(66066001)(99286004)(53936002)(256004)(478600001)(14454004)(93886005)(5660300002)(105586002)(106356001)(26005)(186003)(36756003)(102836004)(86362001)(6506007)(7736002)(305945005)(71190400001)(71200400001)(83716004)(2616005)(11346002)(446003)(476003)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3339; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 1+kuCQ7tUaTC7tjX/Ddwv+7w19kEpKwpk2et2gBvHl6VfD0+a/fSHGV41nblUU8NwYA3bqkXvzCXTuR4KdsbxIvDfghdxjThESRJdzRZBv4Crp7J6VMqaJqWyD98bEYDLArVifhoiACp6Ddbmwm2+Cwq9ql9JJj+Nn0mUBEP3bsRkdxnhryWHermoKqcJPgcEvlY6AlumJlyrNqORgY34S8xcZtB1cmCQ53gI2udhvGoIK+RALsRFfYoHv0hYIWP1JXUeC6+NAqLYmBNM8ZCaQo2BLjJzL8VdJT7AVDYHVzgND+afXBaySsBkY6R1aj+6JgIhP+MDN4mdrmKutul5XUya8ITcXlcfeso2oXNzk4bgYjAFYeZuhvoBa3g4SpYsTn90PNZR6pj1LskTIhbjvNmJycV3mKCAVtpFLJg9Go= Content-Type: text/plain; charset="utf-8" Content-ID: <9B626B33F74C0C4B88207295D9190541@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 41e6d50b-b94a-4fc5-6a12-08d6be54857c X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2019 08:05:54.3896 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3339 Archived-At: Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp X-BeenThere: mmusic@ietf.org 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: Thu, 11 Apr 2019 08:06:00 -0000 SGksDQoNCj4+PkxpbWl0aW5nIEZRRE4gc2NvcGUgdG8gcmVzb2x2aW5nIHRvIGp1c3Qgb25lIGFk ZHJlc3MgaXMgYW4gdW5pbXBsZW1lbnRhYmxlIHJlcXVpcmVtZW50LiBDdXJyZW50bHkgb24gbGFy Z2UgbnVtYmVyIG9mIGRldmljZXMsIEZRRE7CoA0KPj4+d2hpY2ggaXMgc3VwcG9zZWQgdG8gcmVz b2x2ZSB0byBJUHY0IGFkZHJlc3Mgb25seSwgd2lsbCByZXNvbHZlIHRvIGJvdGggSVB2NiBhbmQg SVB2NCBhZGRyZXNzZXMuIEZvciBpbnN0YW5jZSBvbiB2aXJ0dWFsbHkgYWxsIElPUyBhbmQgbW9z dCANCj4+Pm9mIHRoZSBBbmRyb2lkIGRldmljZXMgb24gbW9iaWxlIG5ldHdvcmtzIEZRRE4gcG9p bnRpbmcgdG8gSVB2NCByZXR1cm5zIHJlc3VsdHMgZm9yIElQdjYgYXMgd2VsbC4gRXNzZW50aWFs bHkgd2hhdCB3ZSBhcmUgc3BlY2lmeWluZyBub3cgaXMgDQo+Pj50aGF0IElDRSBjYW5kaWRhdGVz IHdpdGggRlFETiBhZGRyZXNzIE1VU1QgYmUgaWdub3JlZC4NCj4+wqANCj4+SXNu4oCZdCB0aGUg bWFpbiByZWFzb24gZm9yIGFsbG93aW5nIEZRRE4gdG8gZW5hYmxlIHVzYWdlIG9mIG1ETlM/DQo+ Pg0KPsKgSXQgaXMgbm93LiBOb3RoaW5nIGluIHRoZSBsYXRlc3QgbGFuZ3VhZ2UgdGhhdCBJIHBy b3Bvc2UgcHJvaGliaXRzIG1ETlMgZHJhZnQgZGVmaW5lIGhvdyBGUUROIGFyZSBzdXBwb3NlZCB0 byANCj4gd29yayB3aGVuIG1ETlMgaXMgdXNlZC4gQWxsIG15IGxhbmd1YWdlIHN0YXRlcyB0aGF0 IGRlZmF1bHQgdHJlYXRtZW50IGZvciBGUUROIGlzIHRvIGlnbm9yZSBpdCB3aGljaCBrZWVwcyAN Cj4gbUROUyBiYWNrd2FyZHMgY29tcGF0aWJsZS4gSSB3b3VsZCBhbHNvIHN1Z2dlc3QgYWRkaW5n IGFuIElDRSA+IG9wdGlvbiB0byBzcGVjaWZ5IHRoYXQgbUROUyBpcyBzdXBwb3J0ZWQuIA0KPiBU aGlzIGJlaW5nIHNhaWQsIEkgYW0gbm90IHN1cmUgbUROUyBwcmV2ZW50cyBJUHY0IGFkZHJlc3Mg YmVpbmcgcmVzb2x2ZWQgYXMgSVB2NiB0aHJvdWdoIEROUzY0LCBzbyBtRE5TIGlzIA0KPiBsaWtl bHkgZ29pbmcgdG8gZW5kIHVwIHdpdGggdHdvIGFkZHJlc3NlcyBmb3IgYSBzaW5nbGUgY2FuZGlk YXRlLg0KPg0KPj4gSW4gbXkgb3BpbmlvbiwgdGhlIGN1cnJlbnQgSUNFIHByb2NlZHVyZXMgYXNz dW1lcyBvbmUgSVAgYWRkcmVzczpwb3J0IHBlciBjYW5kaWRhdGUuIElmIHdlIGFsbG93IGEgY2Fu ZGlkYXRlIHRvIA0KPj4gYmUgYXNzb2NpYXRlZCB3aXRoIG11bHRpcGxlIElQIGFkZHJlc3Nlczpw b3J0cywgd2Ugd291bGQgaGF2ZSB0byBtb2RpZnkgdGhlIElDRSBwcm9jZWR1cmVzIGluIG9yZGVy IHRvIGhhbmRsZSANCj4+IHRoYXQ6IGhvdyBhIGNhbmRpZGF0ZSBjYW4gYmUgcGFydCBvZiBtdWx0 aXBsZSBmb3VuZGF0aW9ucyAob25lIGZvciBlYWNoIHJlc29sdmVkIElQIGFkZHJlc3M6cG9ydCks IGhvdyB0aGUgDQo+PiBmcmVlemluZy91bmZyZWV6aW5nIHByb2NlZHVyZSB3b3JrLCB3aGV0aGVy IGNvbm5lY3Rpdml0eSBjaGVja3MgYXJlIHNlbnQgdG8gYWxsIHJlc29sdmVkIGFkZHJlc3Nlcywg aG93IHRoZSANCj4+IHN0YXRlIG9mIHRoZSBjYW5kaWRhdGUgaXMgc2V0IGlmIG9uZSBJUCBhZGRy ZXNzOnBvcnQgc3VjY2VlZHMgYnV0IGFub3RoZXIgZG9lc27igJl0LiBPciwgc2hvdWxkIHRoZSBj YW5kaWRhdGUgYmUgDQo+PiBzcGxpdCBpbnRvIG11bHRpcGxlIGNhbmRpZGF0ZXMgKG9uZSBmb3Ig ZWFjaCByZXNvbHZlZCBJUCBhZGRyZXNzOnBvcnQpPyBFdGMgZXRjIGV0YyBldGMgZXRjLiBBbGwg b2YgdGhhdCBjb3VsZCBwcm9iYWJseSANCj4+IGJlIGRvbmUsIGJ1dCBJIHRoaW5rIGl0IHdvdWxk IGJlIHF1aXRlIGEgYml0IG9mIHdvcmstIGFuIHVwZGF0ZSAob3IgZXZlbiBhIGJpcykgdG8gUkZD IDg0NDUuIEl0IGlzICpOT1QqIGFuIGljZS1zaXAtc2RwIA0KPj4gc3BlY2lmaWMgaXNzdWUgaW4g bXkgb3Bpbmlvbi4NCj4NCj4gSSBhbSBub3Qgc3VnZ2VzdGluZyBjaGFuZ2luZyB0aGF0IG9ubHkg b25lIGFkZHJlc3MgaXMgc3VwcG9ydGVkIHBlciBjYW5kaWRhdGUuIFdoYXQgSSBhbSBzdWdnZXN0 aW5nIGlzIHRoYXQgY2FuZGlkYXRlIA0KPiBuZWVkcyBzb21lIHNvcnQgb2YgaGludCB3aGVuIEZR RE4gaXMgdXNlZCB0byBzcGVjaWZ5IGhvdyBhZGRyZXNzIHNob3VsZCBiZSByZXNvbHZlZC4gSGVy ZSBpcyBteSBwcm9wb3NlZCBzb2x1dGlvbjoNCj4NCj4gQWRkIGEgY2FuZGlkYXRlIGV4dGVuc2lv biB3aGljaCBzcGVjaWZpZXMgY2FuZGlkYXRlIGFkZHJlc3MgdHlwZSwgc29tZXRoaW5nIGxpa2Ug YWRkcnR5cGUgd2hpY2ggY2FuIGJlIHNldCB0byANCj4gImluaXB2NCIgb3IgImluaXB2NiIuIElm IElQIGFkZHJlc3MgaXMgdXNlZCBhbmQgaXQgZG9lcyBub3QgbWF0Y2ggdGhlIGFkZHJ0eXBlIGNh bmRpZGF0ZSBleHRlbnNpb24sIHRoaXMgY2FuZGlkYXRlIGlzIA0KPiBpZ25vcmVkLiBXaGVuIEZR RE4gaXMgdXNlZCwgaXQgaXMgcmVzb2x2ZWQgdXNpbmcgQSBETlMgcmVxdWVzdCB3aGVuIGFkZHJ0 eXBlIGlzIGluaXB2NCBvciBub3QgcHJlc2VudCBhbmQgdXNpbmcgDQo+IEFBQUEgRE5TIHJlcXVl c3Qgd2hlbiBhZGRydHlwZSBpcyBpbmlwdjYuIEFkZHJlc3MgZmFtaWx5IGluIGM9IGxpbmUsIHdo ZW4gRlFETiBpcyBhIGRlZmF1bHQgY2FuZGlkYXRlIG11c3QgYmUgDQo+IElOIElQVjQgaWYgYWRk cnR5cGUgaXMgaW5pcHY0IG9yIG5vdCBwcmVzZW50LCBhbmQgbXVzdCBiZSBJUCBJUFY2IGlmIGFk ZHJ0eXBlIGlzIGluaXB2NsKgDQo+DQo+IEV4YW1wbGU6DQo+IGE9Y2FuZGlkYXRlOjIzMTk0Mzcz ODQgMSB1ZHAgMjEyMjI2MDIyMyA4YTJmZDdiNS00MWQ1LTRjMTUtYWQ4My1kMzNhMGQ2NmE3NWEu bG9jYWwgNjA0NTQgdHlwIGhvc3TCoGluaXB2NA0KPiBhPWNhbmRpZGF0ZToyMzE5NDM3Mzg0IDEg dWRwIDIxMjIyNjAyMjMgOGEyZmQ3YjUtNDFkNS00YzE1LWFkODMtZDMzYTBkNjZhNzhiLmxvY2Fs IDYwNDU0IHR5cCBob3N0wqBpbmlwdjbCoMKgDQo+DQo+IFRoaXMga2VlcHMgZWFjaCBjYW5kaWRh dGUgbGluZSB0byBvbmUgYWRkcmVzcyBhbmQgd29ya3MgaW4gY2FzZXMgd2hlbiBGUUROIHJlc29s dmVzIHRvIG9uZSBJUHY0IGFuZCBvbmUgSVB2NiBhZGRyZXNzIA0KPiBkdWUgdG8gc29tZXRoaW5n IGxpa2UgRE5TNjQuIA0KDQpTbywgaWYgSSB1bmRlcnN0YW5kIHlvdSBjb3JyZWN0bHksIHlvdSBh cmUgc3VnZ2VzdGluZyB0aGF0IHRoZSBvbmUgcHJvdmlkaW5nIHRoZSBGUUROIGNhbmRpZGF0ZSBz cGxpdHMgaXQgaW50byB0d28gc2VwYXJhdGUgY2FuZGlkYXRlcyAodHdvIGE9Y2FuZGlkYXRlIGxp bmVzIHdoZW4gU0RQIGlzIHVzZWQpLCBhbmQgdGhlIHJlbW90ZSBwZWVyIHdpbGwgcHJvY2VzcyB0 aGVtIGFzIHR3byBzZXBhcmF0ZSBjYW5kaWRhdGVzLCBidXQgaWYgRE5TIHJldHVybnMgYm90aCBh biBJUHY0IGFuZCBJUHY2IGFkZHJlc3MgdGhlIHBlZXIgd2lsbCBvbmx5IHVzZSB0aGUgSVAgdmVy c2lvbiBpbmRpY2F0ZWQgYnkgdGhlIGFkZHJlc3MgdHlwZSAoImluaXB2NCIgb3IgImluaXB2NiIp Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From nobody Thu Apr 11 01:14:35 2019 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0E512013E; Thu, 11 Apr 2019 01:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6Ai6DS9fBeF; Thu, 11 Apr 2019 01:14:29 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140051.outbound.protection.outlook.com [40.107.14.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13DF712011D; Thu, 11 Apr 2019 01:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qlV5dbMvfPbIqcoIw1gy7Rcv1kYvavtGFzrzzz5Vp9A=; b=VXDVfTUtwX7Ta9JF6kI4oEj9bDllRiOGtT+2oB9qDsbnA2JucPXYbpOxDbkCt6XPYMl9bmpppaV5io7fCdoP3eOeJqbgYKunYUx89gF/R3wJRZrc3IYAYAPGLDM6nlWQaU0McMC3CYc15DjHQYpC8CZwLUn1KZ13J6hacctMjrQ= Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB3004.eurprd07.prod.outlook.com (10.168.93.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.10; Thu, 11 Apr 2019 08:14:26 +0000 Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::107c:5f27:2ef:8505]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::107c:5f27:2ef:8505%5]) with mapi id 15.20.1792.009; Thu, 11 Apr 2019 08:14:26 +0000 From: Magnus Westerlund To: "ietf@ietf.org" CC: Adam Roach , "draft-ietf-mmusic-rfc4566bis@ietf.org" , "mmusic@ietf.org" , "mmusic-chairs@ietf.org" Thread-Topic: [MMUSIC] Last Call: (SDP: Session Description Protocol) to Proposed Standard Thread-Index: AQHU4L35G0bkeH37hEyuzO/M/jMwpA== Date: Thu, 11 Apr 2019 08:14:26 +0000 Message-ID: References: <155326592304.23020.8256337045285295468.idtracker@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.82] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 70140f14-1430-46f6-29e7-08d6be55b684 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB3004; x-ms-traffictypediagnostic: HE1PR0701MB3004: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 00046D390F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(346002)(396003)(366004)(39860400002)(189003)(199004)(8936002)(6116002)(8676002)(54896002)(2351001)(106356001)(105586002)(55016002)(6306002)(9686003)(66066001)(966005)(86362001)(229853002)(478600001)(5640700003)(71200400001)(236005)(99286004)(71190400001)(44832011)(7736002)(54906003)(6916009)(606006)(7696005)(446003)(53936002)(25786009)(3846002)(486006)(33656002)(14444005)(81156014)(81166006)(68736007)(186003)(6506007)(53546011)(2906002)(476003)(52536014)(6436002)(102836004)(316002)(14454004)(2501003)(74316002)(97736004)(76176011)(4326008)(5660300002)(26005)(1730700003)(256004)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB3004; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: CFiro3zgky1vW3xHk0ViZgFADAPwiWkFel3X32ZhjZviDicU/jNONm9lQubQKbjZ/yRiAab8GeaUOIukBjBjOHqD9n/ChQ44b4zaGCql6O7oBi4UY5VveJ/RNkBoPHkPzohynQDLL+oAbAu5xJThf9lHEpxI9oEzpqSoNisLzea7iifBB7A19r5hrHF3oBxrRvcyxeFuwaPdWQx5R5n3x+s0Z11PsCmi5ehS+l3awk9RV3kFNp3d3jUvYPkr/44uSXtr2GorSRCmDjm3QwERTsMlk88rNiaPPv+QIQOCuc7eYpMkTe8tJBmpg72lP2pebosdjoh1tOb7ArXPdwDxUpqTcFXlpJUBi9CDW/PQpDceQIcR3vu6xql/mjNS4dOmwOIcDM1Y0HxfTqCJ8yVt0D15vJL14ZiuT3JAY2PUwDQ= Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB2522795AFC19AB4A73D65ABA952F0HE1PR0701MB2522_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 70140f14-1430-46f6-29e7-08d6be55b684 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2019 08:14:26.1775 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3004 Archived-At: Subject: Re: [MMUSIC] Last Call: (SDP: Session Description Protocol) to Proposed Standard X-BeenThere: mmusic@ietf.org 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: Thu, 11 Apr 2019 08:14:33 -0000 --_000_HE1PR0701MB2522795AFC19AB4A73D65ABA952F0HE1PR0701MB2522_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MMUSIC WG, Document Editors In the processing of draft-ietf-mmusic-data-channel-sdpneg-25 an interestin= g question arose regarding text strings in SDP attribute values. Currently the document says: 4.5. Internationalization The SDP specification recommends the use of the ISO 10646 character set in the UTF-8 encoding [RFC3629] to allow many different languages to be represented. However, to assist in compact representations, SDP also allows other character sets such as ISO 8859-1 to be used when desired. Internationalization only applies to free-text sub- fields (session name and background information), and not to SDP as a whole. If one like to include UTF-8 field for attributes it would be good if the requirement would be clear going forward that there is an expectancy that at least parser can process any UTF-8 strings that may occur in any fields. That would allow future SDP field values to use UTF-8 strings without risks and simplify processing. Like in the case of the data channel SDP mapping where the extra step of encoding lable characters not visually safe as esca= ped characters could be avoided. Does anyone have input if making such a change would have significant impac= t on the interoperability? Cheers Magnus On 2019-03-22 15:46, The IESG wrote: The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'SDP: Session Description Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-04-12. Exceptiona= lly, comments may be sent to iesg@ietf.org instead. In either case, please= retain the beginning of the Subject line to allow automated sorting. Abstract This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/ballot/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic -- Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --_000_HE1PR0701MB2522795AFC19AB4A73D65ABA952F0HE1PR0701MB2522_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
MMUSIC WG, Document Editors

In the processing of draft-ietf-mmusic-data-= channel-sdpneg-25 an interesting question arose regarding text strings in S= DP attribute values.

Currently the document says: 
4.5.  Internationalization=0A=
=0A=
   The SDP specification recommends the use of the ISO 10646 character=0A=
   set in the UTF-8 encoding [RFC3629] to allow many different languages=0A=
   to be represented.  However, to assist in compact representations,=0A=
   SDP also allows other character sets such as ISO 8859-1 to be used=0A=
   when desired.  Internationalization only applies to free-text sub-=0A=
   fields (session name and background information), and not to SDP as a=0A=
   whole.=0A=
=0A=
If one like to include UTF-8 field for attributes it would be good if =0A=
the requirement would be clear going forward that there is an expectancy =
=0A=
that at least parser can process any UTF-8 strings that may occur in any =
=0A=
fields. =0A=
=0A=
That would allow future SDP field values to use UTF-8 strings without risks=
=0A=
and simplify processing. Like in the case of the data channel SDP mapping =
=0A=
where the extra step of encoding lable characters not visually safe as esca=
ped =0A=
characters could be avoided. =0A=
=0A=
Does anyone have input if making such a change would have significant impac=
t on =0A=
the interoperability? =0A=
=0A=
Cheers=0A=
=0A=
Magnus=0A=
=0A=

On 2019-03-22 15:46, The IESG wrote:
=0A=
The IESG has received a request from the Multiparty Multimedia Session=0A=
Control WG (mmusic) to consider the following document: - 'SDP: Session=0A=
Description Protocol'=0A=
  <draft-ietf-mmusic-rfc4566bis-34.txt> as Proposed Standard=0A=
=0A=
The IESG plans to make a decision in the next few weeks, and solicits final=
=0A=
comments on this action. Please send substantive comments to the=0A=
ietf@ie=
tf.org mailing lists by 2019-04-12. Exceptionally, comments may be=0A=
sent to iesg@ietf.org instead. In either case, please retain the beginning of=
=0A=
the Subject line to allow automated sorting.=0A=
=0A=
Abstract=0A=
=0A=
=0A=
   This memo defines the Session Description Protocol (SDP).  SDP is=0A=
   intended for describing multimedia sessions for the purposes of=0A=
   session announcement, session invitation, and other forms of=0A=
   multimedia session initiation.  This document obsoletes RFC 4566.=0A=
=0A=
=0A=
=0A=
=0A=
The file can be obtained via=0A=
https://datatracker.ietf.org/doc/draft-ietf=
-mmusic-rfc4566bis/=0A=
=0A=
IESG discussion can be tracked via=0A=
https://datatracker.ietf.org/doc/dra=
ft-ietf-mmusic-rfc4566bis/ballot/=0A=
=0A=
=0A=
No IPR declarations have been submitted directly on this I-D.=0A=
=0A=
=0A=
=0A=
=0A=
_______________________________________________=0A=
mmusic mailing list=0A=
mmusi=
c@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/mmusic=0A=
=0A=



-- =0A=
=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.=
com=0A=
----------------------------------------------------------------------



--_000_HE1PR0701MB2522795AFC19AB4A73D65ABA952F0HE1PR0701MB2522_--


From nobody Thu Apr 11 02:10:05 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF3F120287 for ; Thu, 11 Apr 2019 02:10:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p45hQTNtyb9W for ; Thu, 11 Apr 2019 02:10:00 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150059.outbound.protection.outlook.com [40.107.15.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3DEB1200FC for ; Thu, 11 Apr 2019 02:09:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HtksghrCXy5OQmy+84fWx/SAWGiADnbpl1nKHd/hURo=; b=bGExcMCdlpexKOqVAm21STujnM6JN73a3XCJr6TvJVPK8l3paBcr6AQ7vLjtFy/47R8TD9F1dcurT7+fhsIUA3iLHB+ppH08IXtLFEA5NGgnQnlVG+aV4nECu8egyXAGgabyUb0Tj7jZwql9PILUDYgF1f/12W5zYVsSvRj4YVQ=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4363.eurprd07.prod.outlook.com (20.176.167.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.9; Thu, 11 Apr 2019 09:09:56 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9%5]) with mapi id 15.20.1792.007; Thu, 11 Apr 2019 09:09:56 +0000
From: Christer Holmberg 
To: Suhas Nandakumar , Roman Shpount 
CC: mmusic WG , Flemming Andreasen 
Thread-Topic: [MMUSIC] FQDN support in ice-sip-sdp
Thread-Index: AQHU6jzz/50YAJx2kEqY4siuQ2NZYqY0606AgADVT4CAAEAVAP//1AeAgADQ14CAAETnAA==
Date: Thu, 11 Apr 2019 09:09:55 +0000
Message-ID: <98CF630B-5CCD-4CE4-84B4-81A4C53979DC@ericsson.com>
References:    <3DD3D8D6-9B13-4F9D-80DD-F89B69240708@ericsson.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.16.1.190220
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-originating-ip: [89.166.49.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 569430dd-b69c-4a76-3ead-08d6be5d7737
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB4363; 
x-ms-traffictypediagnostic: HE1PR07MB4363:
x-microsoft-antispam-prvs: 
x-forefront-prvs: 00046D390F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(136003)(366004)(39860400002)(396003)(189003)(199004)(33656002)(6246003)(186003)(26005)(14454004)(8936002)(236005)(478600001)(68736007)(102836004)(11346002)(110136005)(53936002)(561944003)(8676002)(97736004)(476003)(81166006)(71190400001)(83716004)(71200400001)(2616005)(36756003)(53546011)(54906003)(6506007)(99286004)(81156014)(446003)(6436002)(44832011)(25786009)(4326008)(6486002)(5660300002)(106356001)(2906002)(76176011)(486006)(6116002)(105586002)(316002)(6512007)(6306002)(58126008)(229853002)(54896002)(3846002)(14444005)(86362001)(7736002)(256004)(82746002)(66066001)(93886005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4363; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: /szuGEBe3y5ki+IsWR9UZFZ5MKssWTgRgrmw1Uilb/8B8cuN+poRxEZfwRGR0QOPz3DSkRDO9DJ0lXeAo68zLL6PLerttQycgE4EVqwjOtyda3+5fk5gaDYQEn/Vjy4ZhrbiH1EFQVTU+xQkHIUva+Uo8D7NNgJ6emFqXQsQfLCno1AvqqKMvRGRhD4g+2Dc2Pb3aw2xyi4iTV0Xztypr86iUDzNZdu8Jiro32MSajym9eerB1260ovjAxc6zwx2xjz8bJngJtz65grG3njooJtfnOtDUs7LRBOzA0Cg9iCJe68Vm4BI9AxM7yQAzv/9/XTZKtaL+YWpdjf7WMsIaqckyoogb9pPFN647Q8WztUsOFyyVmYVeHNk0w/F5/51SAeZ25cWGSlqpWF7AWulf64WYxjGN0YLhNV9BRYHWhU=
Content-Type: multipart/alternative; boundary="_000_98CF630B5CCD4CE484B481A4C53979DCericssoncom_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 569430dd-b69c-4a76-3ead-08d6be5d7737
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2019 09:09:55.9047 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4363
Archived-At: 
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp
X-BeenThere: mmusic@ietf.org
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: Thu, 11 Apr 2019 09:10:04 -0000

--_000_98CF630B5CCD4CE484B481A4C53979DCericssoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SEksDQoNCkkgKnRoaW5rKiBJIGFncmVlIHdpdGggU3VoYXMgdGhhdCB0aGUgRlFETiBoYW5kbGlu
ZyBzaG91bGQgYmUgYSBzZXBhcmF0ZSBkcmFmdCDigJMgYSBnZW5lcmljIElDRSBkcmFmdCBwcm9k
dWNlZCBieSB0aGUgSUNFIFdHLiBpY2Utc2lwLXNkcCB3b3VsZCB0aGVuIHNwZWNpZnkgaG93IGl0
IGlzIGltcGxlbWVudGVkIGluIFNEUCAoc2VwYXJhdGUgYT1jYW5kaWRpYXRlIGxpbmVzIGV0Yyku
DQoNClBlcmhhcHMgaXQgY291bGQgYmUgY29tYmluZWQgd2l0aCB0aGUgbUROUyBkcmFmdD8NCg0K
UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpGcm9tOiBTdWhhcyBOYW5kYWt1bWFyIDxzdWhhc2ll
dGZAZ21haWwuY29tPg0KRGF0ZTogVGh1cnNkYXksIDExIEFwcmlsIDIwMTkgYXQgMTEuMDMNClRv
OiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbT4NCkNjOiBDaHJpc3RlciBIb2xtYmVy
ZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiwgU3VoYXMgTmFuZGFrdW1hciA8c3Vo
YXNpZXRmQGdtYWlsLmNvbT4sICJtbXVzaWNAaWV0Zi5vcmciIDxtbXVzaWNAaWV0Zi5vcmc+LCBG
bGVtbWluZyBBbmRyZWFzZW4gPGZhbmRyZWFzQGNpc2NvLmNvbT4NClN1YmplY3Q6IFJlOiBbTU1V
U0lDXSBGUUROIHN1cHBvcnQgaW4gaWNlLXNpcC1zZHANCg0KDQpPbiBXZWQsIEFwciAxMCwgMjAx
OSBhdCAxMjozNiBQTSBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbTxtYWlsdG86cm9t
YW5AdGVsdXJpeC5jb20+PiB3cm90ZToNCk9uIFdlZCwgQXByIDEwLCAyMDE5IGF0IDM6MTMgUE0g
Q2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86
Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQo+TGltaXRpbmcgRlFETiBz
Y29wZSB0byByZXNvbHZpbmcgdG8ganVzdCBvbmUgYWRkcmVzcyBpcyBhbiB1bmltcGxlbWVudGFi
bGUgcmVxdWlyZW1lbnQuIEN1cnJlbnRseSBvbiBsYXJnZSBudW1iZXIgb2YgZGV2aWNlcywgRlFE
Tg0KPndoaWNoIGlzIHN1cHBvc2VkIHRvIHJlc29sdmUgdG8gSVB2NCBhZGRyZXNzIG9ubHksIHdp
bGwgcmVzb2x2ZSB0byBib3RoIElQdjYgYW5kIElQdjQgYWRkcmVzc2VzLiBGb3IgaW5zdGFuY2Ug
b24gdmlydHVhbGx5IGFsbCBJT1MgYW5kIG1vc3QNCj5vZiB0aGUgQW5kcm9pZCBkZXZpY2VzIG9u
IG1vYmlsZSBuZXR3b3JrcyBGUUROIHBvaW50aW5nIHRvIElQdjQgcmV0dXJucyByZXN1bHRzIGZv
ciBJUHY2IGFzIHdlbGwuIEVzc2VudGlhbGx5IHdoYXQgd2UgYXJlIHNwZWNpZnlpbmcgbm93IGlz
DQo+dGhhdCBJQ0UgY2FuZGlkYXRlcyB3aXRoIEZRRE4gYWRkcmVzcyBNVVNUIGJlIGlnbm9yZWQu
DQoNCklzbuKAmXQgdGhlIG1haW4gcmVhc29uIGZvciBhbGxvd2luZyBGUUROIHRvIGVuYWJsZSB1
c2FnZSBvZiBtRE5TPw0KDQogSXQgaXMgbm93LiBOb3RoaW5nIGluIHRoZSBsYXRlc3QgbGFuZ3Vh
Z2UgdGhhdCBJIHByb3Bvc2UgcHJvaGliaXRzIG1ETlMgZHJhZnQgZGVmaW5lIGhvdyBGUUROIGFy
ZSBzdXBwb3NlZCB0byB3b3JrIHdoZW4gbUROUyBpcyB1c2VkLiBBbGwgbXkgbGFuZ3VhZ2Ugc3Rh
dGVzIHRoYXQgZGVmYXVsdCB0cmVhdG1lbnQgZm9yIEZRRE4gaXMgdG8gaWdub3JlIGl0IHdoaWNo
IGtlZXBzIG1ETlMgYmFja3dhcmRzIGNvbXBhdGlibGUuIEkgd291bGQgYWxzbyBzdWdnZXN0IGFk
ZGluZyBhbiBJQ0Ugb3B0aW9uIHRvIHNwZWNpZnkgdGhhdCBtRE5TIGlzIHN1cHBvcnRlZC4gVGhp
cyBiZWluZyBzYWlkLCBJIGFtIG5vdCBzdXJlIG1ETlMgcHJldmVudHMgSVB2NCBhZGRyZXNzIGJl
aW5nIHJlc29sdmVkIGFzIElQdjYgdGhyb3VnaCBETlM2NCwgc28gbUROUyBpcyBsaWtlbHkgZ29p
bmcgdG8gZW5kIHVwIHdpdGggdHdvIGFkZHJlc3NlcyBmb3IgYSBzaW5nbGUgY2FuZGlkYXRlLg0K
DQpJbiBteSBvcGluaW9uLCB0aGUgY3VycmVudCBJQ0UgcHJvY2VkdXJlcyBhc3N1bWVzIG9uZSBJ
UCBhZGRyZXNzOnBvcnQgcGVyIGNhbmRpZGF0ZS4gSWYgd2UgYWxsb3cgYSBjYW5kaWRhdGUgdG8g
YmUgYXNzb2NpYXRlZCB3aXRoIG11bHRpcGxlIElQIGFkZHJlc3Nlczpwb3J0cywgd2Ugd291bGQg
aGF2ZSB0byBtb2RpZnkgdGhlIElDRSBwcm9jZWR1cmVzIGluIG9yZGVyIHRvIGhhbmRsZSB0aGF0
OiBob3cgYSBjYW5kaWRhdGUgY2FuIGJlIHBhcnQgb2YgbXVsdGlwbGUgZm91bmRhdGlvbnMgKG9u
ZSBmb3IgZWFjaCByZXNvbHZlZCBJUCBhZGRyZXNzOnBvcnQpLCBob3cgdGhlIGZyZWV6aW5nL3Vu
ZnJlZXppbmcgcHJvY2VkdXJlIHdvcmssIHdoZXRoZXIgY29ubmVjdGl2aXR5IGNoZWNrcyBhcmUg
c2VudCB0byBhbGwgcmVzb2x2ZWQgYWRkcmVzc2VzLCBob3cgdGhlIHN0YXRlIG9mIHRoZSBjYW5k
aWRhdGUgaXMgc2V0IGlmIG9uZSBJUCBhZGRyZXNzOnBvcnQgc3VjY2VlZHMgYnV0IGFub3RoZXIg
ZG9lc27igJl0LiBPciwgc2hvdWxkIHRoZSBjYW5kaWRhdGUgYmUgc3BsaXQgaW50byBtdWx0aXBs
ZSBjYW5kaWRhdGVzIChvbmUgZm9yIGVhY2ggcmVzb2x2ZWQgSVAgYWRkcmVzczpwb3J0KT8gRXRj
IGV0YyBldGMgZXRjIGV0Yy4gQWxsIG9mIHRoYXQgY291bGQgcHJvYmFibHkgYmUgZG9uZSwgYnV0
IEkgdGhpbmsgaXQgd291bGQgYmUgcXVpdGUgYSBiaXQgb2Ygd29yay0gYW4gdXBkYXRlIChvciBl
dmVuIGEgYmlzKSB0byBSRkMgODQ0NS4gSXQgaXMgKk5PVCogYW4gaWNlLXNpcC1zZHAgc3BlY2lm
aWMgaXNzdWUgaW4gbXkgb3Bpbmlvbi4NCg0KSSBhbSBub3Qgc3VnZ2VzdGluZyBjaGFuZ2luZyB0
aGF0IG9ubHkgb25lIGFkZHJlc3MgaXMgc3VwcG9ydGVkIHBlciBjYW5kaWRhdGUuIFdoYXQgSSBh
bSBzdWdnZXN0aW5nIGlzIHRoYXQgY2FuZGlkYXRlIG5lZWRzIHNvbWUgc29ydCBvZiBoaW50IHdo
ZW4gRlFETiBpcyB1c2VkIHRvIHNwZWNpZnkgaG93IGFkZHJlc3Mgc2hvdWxkIGJlIHJlc29sdmVk
LiBIZXJlIGlzIG15IHByb3Bvc2VkIHNvbHV0aW9uOg0KDQpBZGQgYSBjYW5kaWRhdGUgZXh0ZW5z
aW9uIHdoaWNoIHNwZWNpZmllcyBjYW5kaWRhdGUgYWRkcmVzcyB0eXBlLCBzb21ldGhpbmcgbGlr
ZSBhZGRydHlwZSB3aGljaCBjYW4gYmUgc2V0IHRvICJpbmlwdjQiIG9yICJpbmlwdjYiLiBJZiBJ
UCBhZGRyZXNzIGlzIHVzZWQgYW5kIGl0IGRvZXMgbm90IG1hdGNoIHRoZSBhZGRydHlwZSBjYW5k
aWRhdGUgZXh0ZW5zaW9uLCB0aGlzIGNhbmRpZGF0ZSBpcyBpZ25vcmVkLiBXaGVuIEZRRE4gaXMg
dXNlZCwgaXQgaXMgcmVzb2x2ZWQgdXNpbmcgQSBETlMgcmVxdWVzdCB3aGVuIGFkZHJ0eXBlIGlz
IGluaXB2NCBvciBub3QgcHJlc2VudCBhbmQgdXNpbmcgQUFBQSBETlMgcmVxdWVzdCB3aGVuIGFk
ZHJ0eXBlIGlzIGluaXB2Ni4gQWRkcmVzcyBmYW1pbHkgaW4gYz0gbGluZSwgd2hlbiBGUUROIGlz
IGEgZGVmYXVsdCBjYW5kaWRhdGUgbXVzdCBiZSBJTiBJUFY0IGlmIGFkZHJ0eXBlIGlzIGluaXB2
NCBvciBub3QgcHJlc2VudCwgYW5kIG11c3QgYmUgSVAgSVBWNiBpZiBhZGRydHlwZSBpcyBpbmlw
djYNCg0KRXhhbXBsZToNCmE9Y2FuZGlkYXRlOjIzMTk0MzczODQgMSB1ZHAgMjEyMjI2MDIyMyA4
YTJmZDdiNS00MWQ1LTRjMTUtYWQ4My1kMzNhMGQ2NmE3NWEubG9jYWwgNjA0NTQgdHlwIGhvc3Qg
aW5pcHY0DQphPWNhbmRpZGF0ZToyMzE5NDM3Mzg0IDEgdWRwIDIxMjIyNjAyMjMgOGEyZmQ3YjUt
NDFkNS00YzE1LWFkODMtZDMzYTBkNjZhNzhiLmxvY2FsIDYwNDU0IHR5cCBob3N0IGluaXB2Ng0K
DQpJIGFtIG5vdCBmb3Igb3IgYWdhaW5zdCB0aGUgcHJvcG9zYWwuIEkgYW0gc3VyZSBpdHMgZmlu
ZS4gIEkgYW0gY29uY2VybmVkIGFib3V0IHRoZSBzY29wZSBvZiB0aGlzIGNoYW5nZSBhbmQgY3Vy
cmVudCBpbXBsZW1lbnRhdGlvbnMgd2hvIGFyZSB3aWxsaW5nIHRvIHN1cHBvcnQgdGhpcyBuZXcg
ZXh0ZW5zaW9uLiBXaHkgY2FuJ3QgdGhpcyBiZSBpbiBhIHRvdGFsIG5ldyBkcmFmdCA/DQoNCg0K
DQpUaGlzIGtlZXBzIGVhY2ggY2FuZGlkYXRlIGxpbmUgdG8gb25lIGFkZHJlc3MgYW5kIHdvcmtz
IGluIGNhc2VzIHdoZW4gRlFETiByZXNvbHZlcyB0byBvbmUgSVB2NCBhbmQgb25lIElQdjYgYWRk
cmVzcyBkdWUgdG8gc29tZXRoaW5nIGxpa2UgRE5TNjQuDQoNClJlZ2FyZHMsDQogX19fX19fX19f
X19fXw0KUm9tYW4gU2hwb3VudA0KDQo=

--_000_98CF630B5CCD4CE484B481A4C53979DCericssoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv
bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6
bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207
DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt
c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F
bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm
YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N
CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu
ODVwdCAyLjBjbSA3MC44NXB0IDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk
U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZJIiBsaW5rPSJi
bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5ISSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiPkkgKjxiPnRoaW5rPC9iPiogSSBhZ3JlZSB3aXRoIFN1aGFzIHRoYXQgdGhlIEZRRE4gaGFu
ZGxpbmcgc2hvdWxkIGJlIGEgc2VwYXJhdGUgZHJhZnQg4oCTIGEgZ2VuZXJpYyBJQ0UgZHJhZnQg
cHJvZHVjZWQgYnkgdGhlIElDRSBXRy4gaWNlLXNpcC1zZHAgd291bGQgdGhlbiBzcGVjaWZ5IGhv
dyBpdCBpcyBpbXBsZW1lbnRlZCBpbiBTRFAgKHNlcGFyYXRlIGE9Y2FuZGlkaWF0ZSBsaW5lcw0K
IGV0YykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5QZXJoYXBzIGl0IGNvdWxkIGJlIGNvbWJpbmVkIHdp
dGggdGhlIG1ETlMgZHJhZnQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE
RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3Nw
YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5TdWhhcyBO
YW5kYWt1bWFyICZsdDtzdWhhc2lldGZAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5U
aHVyc2RheSwgMTEgQXByaWwgMjAxOSBhdCAxMS4wMzxicj4NCjxiPlRvOiA8L2I+Um9tYW4gU2hw
b3VudCAmbHQ7cm9tYW5AdGVsdXJpeC5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5DaHJpc3RlciBI
b2xtYmVyZyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0OywgU3VoYXMgTmFu
ZGFrdW1hciAmbHQ7c3VoYXNpZXRmQGdtYWlsLmNvbSZndDssICZxdW90O21tdXNpY0BpZXRmLm9y
ZyZxdW90OyAmbHQ7bW11c2ljQGlldGYub3JnJmd0OywgRmxlbW1pbmcgQW5kcmVhc2VuICZsdDtm
YW5kcmVhc0BjaXNjby5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbTU1VU0lDXSBG
UUROIHN1cHBvcnQgaW4gaWNlLXNpcC1zZHA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEFwciAxMCwgMjAxOSBhdCAx
MjozNiBQTSBSb21hbiBTaHBvdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cm9tYW5AdGVsdXJpeC5j
b20iPnJvbWFuQHRlbHVyaXguY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND
Q0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy
Z2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+T24gV2VkLCBBcHIgMTAsIDIwMTkgYXQgMzoxMyBQTSBDaHJpc3RlciBIb2xtYmVy
ZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFy
Z2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3Rl
OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1
b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh
ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBj
bSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jmd0O0xpbWl0aW5nIEZR
RE4gc2NvcGUgdG8gcmVzb2x2aW5nIHRvIGp1c3Qgb25lIGFkZHJlc3MgaXMgYW4gdW5pbXBsZW1l
bnRhYmxlIHJlcXVpcmVtZW50LiBDdXJyZW50bHkgb24gbGFyZ2UgbnVtYmVyIG9mIGRldmljZXMs
IEZRRE4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0O3doaWNoIGlzIHN1cHBvc2VkIHRvIHJlc29s
dmUgdG8gSVB2NCBhZGRyZXNzIG9ubHksIHdpbGwgcmVzb2x2ZSB0byBib3RoIElQdjYgYW5kIElQ
djQgYWRkcmVzc2VzLiBGb3IgaW5zdGFuY2Ugb24gdmlydHVhbGx5IGFsbCBJT1MgYW5kIG1vc3QN
Cjxicj4NCiZndDtvZiB0aGUgQW5kcm9pZCBkZXZpY2VzIG9uIG1vYmlsZSBuZXR3b3JrcyBGUURO
IHBvaW50aW5nIHRvIElQdjQgcmV0dXJucyByZXN1bHRzIGZvciBJUHY2IGFzIHdlbGwuIEVzc2Vu
dGlhbGx5IHdoYXQgd2UgYXJlIHNwZWNpZnlpbmcgbm93IGlzDQo8YnI+DQomZ3Q7dGhhdCBJQ0Ug
Y2FuZGlkYXRlcyB3aXRoIEZRRE4gYWRkcmVzcyBNVVNUIGJlIGlnbm9yZWQuPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs
YW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SXNu4oCZdCB0aGUgbWFpbiByZWFzb24gZm9yIGFs
bG93aW5nIEZRRE4gdG8gZW5hYmxlIHVzYWdlIG9mIG1ETlM/PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDtJdCBpcyBub3cuIE5vdGhpbmcgaW4gdGhlIGxh
dGVzdCBsYW5ndWFnZSB0aGF0IEkgcHJvcG9zZSBwcm9oaWJpdHMgbUROUyBkcmFmdCBkZWZpbmUg
aG93IEZRRE4gYXJlIHN1cHBvc2VkIHRvIHdvcmsgd2hlbiBtRE5TIGlzIHVzZWQuIEFsbCBteSBs
YW5ndWFnZSBzdGF0ZXMgdGhhdCBkZWZhdWx0IHRyZWF0bWVudCBmb3IgRlFETiBpcyB0byBpZ25v
cmUgaXQgd2hpY2gga2VlcHMgbUROUyBiYWNrd2FyZHMgY29tcGF0aWJsZS4NCiBJIHdvdWxkIGFs
c28gc3VnZ2VzdCBhZGRpbmcgYW4gSUNFIG9wdGlvbiB0byBzcGVjaWZ5IHRoYXQgbUROUyBpcyBz
dXBwb3J0ZWQuIFRoaXMgYmVpbmcgc2FpZCwgSSBhbSBub3Qgc3VyZSBtRE5TIHByZXZlbnRzIElQ
djQgYWRkcmVzcyBiZWluZyByZXNvbHZlZCBhcyBJUHY2IHRocm91Z2ggRE5TNjQsIHNvIG1ETlMg
aXMgbGlrZWx5IGdvaW5nIHRvIGVuZCB1cCB3aXRoIHR3byBhZGRyZXNzZXMgZm9yIGEgc2luZ2xl
IGNhbmRpZGF0ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw
Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkluIG15IG9waW5pb24sIHRoZSBjdXJyZW50
IElDRSBwcm9jZWR1cmVzIGFzc3VtZXMgb25lIElQIGFkZHJlc3M6cG9ydCBwZXIgY2FuZGlkYXRl
LiBJZiB3ZSBhbGxvdyBhIGNhbmRpZGF0ZSB0byBiZSBhc3NvY2lhdGVkIHdpdGggbXVsdGlwbGUg
SVAgYWRkcmVzc2VzOnBvcnRzLCB3ZSB3b3VsZCBoYXZlIHRvDQogbW9kaWZ5IHRoZSBJQ0UgcHJv
Y2VkdXJlcyBpbiBvcmRlciB0byBoYW5kbGUgdGhhdDogaG93IGEgY2FuZGlkYXRlIGNhbiBiZSBw
YXJ0IG9mIG11bHRpcGxlIGZvdW5kYXRpb25zIChvbmUgZm9yIGVhY2ggcmVzb2x2ZWQgSVAgYWRk
cmVzczpwb3J0KSwgaG93IHRoZSBmcmVlemluZy91bmZyZWV6aW5nIHByb2NlZHVyZSB3b3JrLCB3
aGV0aGVyIGNvbm5lY3Rpdml0eSBjaGVja3MgYXJlIHNlbnQgdG8gYWxsIHJlc29sdmVkIGFkZHJl
c3NlcywgaG93DQogdGhlIHN0YXRlIG9mIHRoZSBjYW5kaWRhdGUgaXMgc2V0IGlmIG9uZSBJUCBh
ZGRyZXNzOnBvcnQgc3VjY2VlZHMgYnV0IGFub3RoZXIgZG9lc27igJl0LiBPciwgc2hvdWxkIHRo
ZSBjYW5kaWRhdGUgYmUgc3BsaXQgaW50byBtdWx0aXBsZSBjYW5kaWRhdGVzIChvbmUgZm9yIGVh
Y2ggcmVzb2x2ZWQgSVAgYWRkcmVzczpwb3J0KT8gRXRjIGV0YyBldGMgZXRjIGV0Yy4gQWxsIG9m
IHRoYXQgY291bGQgcHJvYmFibHkgYmUgZG9uZSwgYnV0IEkgdGhpbmsNCiBpdCB3b3VsZCBiZSBx
dWl0ZSBhIGJpdCBvZiB3b3JrLSBhbiB1cGRhdGUgKG9yIGV2ZW4gYSBiaXMpIHRvIFJGQyA4NDQ1
LiBJdCBpcyAqPGI+Tk9UPC9iPiogYW4gaWNlLXNpcC1zZHAgc3BlY2lmaWMgaXNzdWUgaW4gbXkg
b3Bpbmlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIG5vdCBzdWdnZXN0aW5nIGNoYW5naW5n
IHRoYXQgb25seSBvbmUgYWRkcmVzcyBpcyBzdXBwb3J0ZWQgcGVyIGNhbmRpZGF0ZS4gV2hhdCBJ
IGFtIHN1Z2dlc3RpbmcgaXMgdGhhdCBjYW5kaWRhdGUgbmVlZHMgc29tZSBzb3J0IG9mIGhpbnQg
d2hlbiBGUUROIGlzIHVzZWQgdG8gc3BlY2lmeSBob3cgYWRkcmVzcyBzaG91bGQgYmUgcmVzb2x2
ZWQuIEhlcmUgaXMgbXkgcHJvcG9zZWQgc29sdXRpb246PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzAuMHB0O21hcmdpbi1y
aWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZGQgYSBjYW5k
aWRhdGUgZXh0ZW5zaW9uIHdoaWNoIHNwZWNpZmllcyBjYW5kaWRhdGUgYWRkcmVzcyB0eXBlLCBz
b21ldGhpbmcgbGlrZSBhZGRydHlwZSB3aGljaCBjYW4gYmUgc2V0IHRvICZxdW90O2luaXB2NCZx
dW90OyBvciAmcXVvdDtpbmlwdjYmcXVvdDsuIElmIElQIGFkZHJlc3MgaXMgdXNlZCBhbmQgaXQg
ZG9lcyBub3QgbWF0Y2ggdGhlIGFkZHJ0eXBlIGNhbmRpZGF0ZSBleHRlbnNpb24sIHRoaXMgY2Fu
ZGlkYXRlIGlzIGlnbm9yZWQuDQogV2hlbiBGUUROIGlzIHVzZWQsIGl0IGlzIHJlc29sdmVkIHVz
aW5nIEEgRE5TIHJlcXVlc3Qgd2hlbiBhZGRydHlwZSBpcyBpbmlwdjQgb3Igbm90IHByZXNlbnQg
YW5kIHVzaW5nIEFBQUEgRE5TIHJlcXVlc3Qgd2hlbiBhZGRydHlwZSBpcyBpbmlwdjYuIEFkZHJl
c3MgZmFtaWx5IGluIGM9IGxpbmUsIHdoZW4gRlFETiBpcyBhIGRlZmF1bHQgY2FuZGlkYXRlIG11
c3QgYmUgSU4gSVBWNCBpZiBhZGRydHlwZSBpcyBpbmlwdjQgb3Igbm90IHByZXNlbnQsDQogYW5k
IG11c3QgYmUgSVAgSVBWNiBpZiBhZGRydHlwZSBpcyBpbmlwdjYmbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt
YXJnaW4tbGVmdDozMC4wcHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkV4YW1wbGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPmE9Y2FuZGlkYXRl
OjIzMTk0MzczODQgMSB1ZHAgMjEyMjI2MDIyMyA4YTJmZDdiNS00MWQ1LTRjMTUtYWQ4My1kMzNh
MGQ2NmE3NWEubG9jYWwgNjA0NTQgdHlwIGhvc3Q8L3NwYW4+Jm5ic3A7PGI+aW5pcHY0PC9iPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImNvbG9yOmJsYWNrIj5hPWNhbmRpZGF0ZToyMzE5NDM3Mzg0IDEgdWRwIDIxMjIyNjAy
MjMgOGEyZmQ3YjUtNDFkNS00YzE1LWFkODMtZDMzYTBkNjZhNzhiLmxvY2FsIDYwNDU0IHR5cCBo
b3N0PC9zcGFuPiZuYnNwOzxiPmluaXB2NjwvYj4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gbm90IGZvciBvciBhZ2FpbnN0IHRoZSBw
cm9wb3NhbC4gSSBhbSBzdXJlIGl0cyBmaW5lLiZuYnNwOyBJIGFtIGNvbmNlcm5lZCBhYm91dCB0
aGUgc2NvcGUgb2YgdGhpcyBjaGFuZ2UgYW5kIGN1cnJlbnQgaW1wbGVtZW50YXRpb25zIHdobyBh
cmUgd2lsbGluZyB0byBzdXBwb3J0IHRoaXMgbmV3IGV4dGVuc2lvbi4gV2h5IGNhbid0IHRoaXMg
YmUgaW4gYSB0b3RhbCBuZXcgZHJhZnQgPyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND
IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu
LXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0OjMwLjBw
dDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGtlZXBzIGVhY2ggY2FuZGlkYXRlIGxpbmUgdG8gb25l
IGFkZHJlc3MgYW5kIHdvcmtzIGluIGNhc2VzIHdoZW4gRlFETiByZXNvbHZlcyB0byBvbmUgSVB2
NCBhbmQgb25lIElQdjYgYWRkcmVzcyBkdWUgdG8gc29tZXRoaW5nIGxpa2UgRE5TNjQuDQo8bzpw
PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48
L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO19fX19f
X19fX19fX188bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Um9t
YW4gU2hwb3VudDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js
b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_98CF630B5CCD4CE484B481A4C53979DCericssoncom_--


From nobody Thu Apr 11 02:25:49 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49D41206C8; Thu, 11 Apr 2019 02:25:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQXBolG8aee6; Thu, 11 Apr 2019 02:25:36 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B716120397; Thu, 11 Apr 2019 02:25:34 -0700 (PDT)
Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id C16D24EA79755DE21551; Thu, 11 Apr 2019 10:25:30 +0100 (IST)
Received: from lhreml702-chm.china.huawei.com (10.201.108.51) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 11 Apr 2019 10:25:30 +0100
Received: from lhreml702-chm.china.huawei.com (10.201.108.51) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 11 Apr 2019 10:25:30 +0100
Received: from DGGEMM422-HUB.china.huawei.com (10.1.198.39) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Thu, 11 Apr 2019 10:25:30 +0100
Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.138]) by dggemm422-hub.china.huawei.com ([10.1.198.39]) with mapi id 14.03.0415.000; Thu, 11 Apr 2019 17:24:40 +0800
From: "Roni Even (A)" 
To: Roman Danyliw , The IESG 
CC: "draft-ietf-mmusic-data-channel-sdpneg@ietf.org" , Bo Burman , "mmusic-chairs@ietf.org" , "mmusic@ietf.org" 
Thread-Topic: Roman Danyliw's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)
Thread-Index: AQHU7w7V0tv66pNAHEeoztcGvf2AaKY2qXPQ
Date: Thu, 11 Apr 2019 09:24:39 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18CDB59D@dggemm526-mbx.china.huawei.com>
References: <155484000356.19554.8395796686893872238.idtracker@ietfa.amsl.com>
In-Reply-To: <155484000356.19554.8395796686893872238.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.202.102]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [MMUSIC] Roman Danyliw's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)
X-BeenThere: mmusic@ietf.org
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: Thu, 11 Apr 2019 09:25:47 -0000

VGhhbmtzIGZvciB0aGUgcmV2aWV3LCBzZWUgaW5saW5lDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCkZyb206IFJvbWFuIERhbnlsaXcgdmlhIERhdGF0cmFja2VyIFttYWlsdG86bm9y
ZXBseUBpZXRmLm9yZ10gDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAwOSwgMjAxOSAxMTowMCBQTQ0K
VG86IFRoZSBJRVNHDQpDYzogZHJhZnQtaWV0Zi1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZ0Bp
ZXRmLm9yZzsgQm8gQnVybWFuOyBtbXVzaWMtY2hhaXJzQGlldGYub3JnOyBiby5idXJtYW5AZXJp
Y3Nzb24uY29tOyBtbXVzaWNAaWV0Zi5vcmcNClN1YmplY3Q6IFJvbWFuIERhbnlsaXcncyBEaXNj
dXNzIG9uIGRyYWZ0LWlldGYtbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWctMjU6ICh3aXRoIERJ
U0NVU1MgYW5kIENPTU1FTlQpDQoNClJvbWFuIERhbnlsaXcgaGFzIGVudGVyZWQgdGhlIGZvbGxv
d2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQpkcmFmdC1pZXRmLW1tdXNpYy1kYXRhLWNoYW5uZWwt
c2RwbmVnLTI1OiBEaXNjdXNzDQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1
YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVk
ZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1
Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCg0KDQpQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQpmb3IgbW9y
ZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0K
DQoNClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4g
YmUgZm91bmQgaGVyZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll
dGYtbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWcvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpESVND
VVNTOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQooMSkgU2VjdGlvbiA1LjIuMS4gIFRoZSBBQk5GIG9mIHN0
cmVhbS1pZCBvZiDigJxkY3NhLXZhbHVlID0gc3RyZWFtLWlkIOKApuKAnSBkb2VzIG5vdCBhcHBl
YXIgdG8gYmUgZGVmaW5lZCBleHBsaWNpdGx5IG9yIGJ5IHJlZmVyZW5jZSBpbiB0aGUgZHJhZnQu
DQoNClJFOiB3aWxsICBhZGQgInN0cmVhbS1pZCA9IDEqNURJR0lUIiA7IHNhbWUgYXMgZGNtYXAt
c3RyZWFtLWlkDQoNCigyKSBTZWN0aW9uIDYuNiwg4oCc4oCmIHRoZSBvZmZlcmVyIFNIQUxMIGlu
Y2x1ZGUgcHJldmlvdXNseSBuZWdvdGlhdGVkIFNEUCBhdHRyaWJ1dGVzIOKApiBhc3NvY2lhdGVk
IHdpdGggdGhlIGNoYW5uZWzigJ0uICBXaGF0IGlzIHRoZSBiZWhhdmlvciBvZiB0aGUgcmVjZWl2
ZXIgaWYgdGhlIGF0dHJpYnV0ZXMgaW5jbHVkZWQgYnkgdGhlIG9mZmVyZXIgYXJlIE5PVCB0aG9z
ZSB0aGF0IHdlcmUgcHJldmlvdXNseSBuZWdvdGlhdGVkPw0KDQpSRTogVGhlIGJlaGF2aW9yIGlz
IHByb3RvY29sIHNwZWNpZmljLCBvZmZlciBhbnN3ZXIgbWF5IGJlIHVzZWQgYnkgbXVsdGlwbGUg
c2lnbmFsaW5nIHByb3RvY29sIGUuZy4gU0lQDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ09NTUVOVDoN
Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCg0KKDEpIFNlY3Rpb24gMS4gIEVkaXRvcmlhbCBOaXRzLg0Kcy9UaGUg
Y29uY2VwdCBvZiBlc3RhYmxpc2hpbmcgYSBiaS1kaXJlY3Rpb25hbCBkYXRhIGNoYW5uZWwgcnVu
bmluZyBvbiB0b3Agb2YgdGhlIFN0cmVhbSBDb250cm9sIFRyYW5zbWlzc2lvbiBQcm90b2NvbCAo
U0NUUCkgaXMgaW4NCltJLUQuaWV0Zi1ydGN3ZWItZGF0YS1jaGFubmVsXSBhbGxvd2luZyBhcHBs
aWNhdGlvbnMgdG8gdXNlIGRhdGEgICAgY2hhbm5lbHMuLw0KVGhlIGNvbmNlcHQgb2YgZXN0YWJs
aXNoaW5nIGEgYmktZGlyZWN0aW9uYWwgZGF0YSBjaGFubmVsIHJ1bm5pbmcgb24gdG9wIG9mIHRo
ZSBTdHJlYW0gQ29udHJvbCBUcmFuc21pc3Npb24gUHJvdG9jb2wgKFNDVFApIGluIFtJLUQuaWV0
Zi1ydGN3ZWItZGF0YS1jaGFubmVsXSBhbGxvd3MgYXBwbGljYXRpb25zIHRvIHVzZSBkYXRhIGNo
YW5uZWxzLi8NCg0KW1JFXSBOb3Qgc3VyZSAtIHRoZSBhbGxvd2luZyByZWZlcnMgdG8gW3J0Y3dl
Yi1kYXRhLWNoYW5uZWxdDQoNCnMvQW4gaW4tYmFuZCBEYXRhIENoYW5uZWwgRXN0YWJsaXNobWVu
dCBQcm90b2NvbCAoRENFUCkgaXMgaW4gW0ktRC5pZXRmLXJ0Y3dlYi1kYXRhLXByb3RvY29sXSwg
aG93ZXZlciBvdGhlciBpbi1iYW5kIG9yIG91dC1vZi1iYW5kIHByb3RvY29scyBtYXkgYmUgdXNl
ZCBmb3IgZXN0YWJsaXNoaW5nIGRhdGEgY2hhbm5lbHMuLyBJbiBhZGRpdGlvbiB0byB0aGUgaW4t
YmFuZCBEYXRhIENoYW5uZWwgRXN0YWJsaXNobWVudCBQcm90b2NvbCAoRENFUCksIG90aGVyIGlu
LWJhbmQgYW5kIG91dC1vZi1iYW5kIHByb3RvY29scyBtYXkgYmUgdXNlZCBmb3IgZXN0YWJsaXNo
aW5nIGRhdGEgY2hhbm5lbHMvDQoNCltSRV0gcHJlZmVyIHRvIHVzZSBhcyBpcw0KDQooMikgU2Vj
dGlvbiAxLiAgVHlwbyAoZXh0cmEgc3BhY2UgYmV0d2VlbiBjbG9zZSBicmFja2V0IGFuZCBwZXJp
b2QpIHMvRm9yIE1TUlAgdGhleSBhcmUgZG9jdW1lbnRlZCBpbiBbSS1ELmlldGYtbW11c2ljLW1z
cnAtdXNhZ2UtZGF0YS1jaGFubmVsXSAuLyBGb3IgTVNSUCB0aGV5IGFyZSBkb2N1bWVudGVkIGlu
IFtJLUQuaWV0Zi1tbXVzaWMtbXNycC11c2FnZS1kYXRhLWNoYW5uZWxdLi8NCltPS10NCg0KKDMp
IFNlY3Rpb24gMy4gIEVkaXRvcmlhbCBOaXQuDQpvbGQ6ICJkZWxpdmVyeS4uLiApLiI7IG5ldzog
ImRlbGl2ZXJ5LCBldGMuKS4iDQpbUkVdIE9LDQoNCg0KDQooNCkgU2VjdGlvbiA2LjEuICBFZGl0
b3JpYWwgTml0Lg0KVGhlcmUgYXBwZWFycyB0byBiZSB0d28gaW5zdGFuY2VzIG9mIHRoZSBzZW50
ZW5jZSwg4oCcU0NUUCBzdHJlYW0gaWRlbnRpZmllcnMgYXNzb2NpYXRlZCB3aXRoIGRhdGEgY2hh
bm5lbHMgdGhhdCBoYXZlIGJlZW4gbmVnb3RpYXRlZCB1c2luZyBEQ0VQIE1VU1QgTk9UIGJlIGlu
Y2x1ZGVkIGluIFNEUCBvZmZlcnMgYW5kIGFuc3dlcnMu4oCdDQoNCltSRV0gdGhhbmtzLCB3aWxs
IHJlbW92ZSB0aGUgZmlyc3QgaW5zdGFuY2UNCg0KDQooNSkgU2VjdGlvbiA2LjUuICBUaGUgc2Vu
dGVuY2Ug4oCcTm90ZTogRENFUCBpcyBub3QgdXNlZCwgdGhhdCBpcyBuZWl0aGVyIHRoZSBTRFAg
b2ZmZXJlciBub3IgdGhlIFNEUCBhbnN3ZXJlciBzZW5kIGFuIGluLWJhbmQgRENFUCBEQVRBX0NI
QU5ORUxfT1BFTiBtZXNzYWdl4oCdDQp1c2VzIGEgdHJpcGxlIG5lZ2F0aXZlIHNvIHRoZSBndWlk
YW5jZSBpcyBub3QgY2xlYXIuDQpbUkVdICBJIGNhbiByZW1vdmUgdGhlIG5vdGUsIGRvZXMgbm90
IHByb3ZpZGUgYW55IHZhdWUNCg0KDQooNikgU2VjdGlvbiA2LjcsIFBlciDigJxTRFAgb2ZmZXIg
b3IgYW5zd2VyIGhhcyBhbiAiYT1kY3NhIiBhdHRyaWJ1dGUsIHdob3NlIHN1YnByb3RvY29sIGF0
dHJpYnV0ZSBpcyBrbm93biwgYnV0IHdob3NlIHN1YnByb3RvY29sIGF0dHJpYnV0ZSBzZW1hbnRp
YyBpcyBub3Qga25vd24gZm9yIHRoZSBkYXRhIGNoYW5uZWwgdHJhbnNwb3J0IGNhc2XigJ0sIGNv
bnNpZGVyIGEgY2FzZSB3aGVyZSB0aGUgc3ViLXByb3RvY29sIGF0dHJpYnV0ZSBpcyBrbm93biBi
dXQgdGhlIHZhbHVlIGlzIGludmFsaWQuICBJcyB0aGF0IGNhc2UgYSBzdWItc2V0IG9mIHdoYXQg
aXMgbWVhbnQgYnkgdGhlIOKAnGF0dHJpYnV0ZSBzZW1hbnRpYyBpcyBub3Qga25vd27igJ0/DQpb
UkVdIHllcywgdGhpcyBpcyB3aGF0IHNlbWFudGljcyBtZWFucw0KDQoNCg0KDQoNCg==


From nobody Thu Apr 11 02:51:00 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00E41202B3; Thu, 11 Apr 2019 02:50:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QbuRMmPZoRz; Thu, 11 Apr 2019 02:50:57 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC091202B1; Thu, 11 Apr 2019 02:50:57 -0700 (PDT)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 9135FF767181897E29DA; Thu, 11 Apr 2019 10:50:55 +0100 (IST)
Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 11 Apr 2019 10:50:48 +0100
Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 11 Apr 2019 10:50:47 +0100
Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Thu, 11 Apr 2019 10:50:47 +0100
Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.138]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0415.000; Thu, 11 Apr 2019 17:50:19 +0800
From: "Roni Even (A)" 
To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , The IESG 
CC: "draft-ietf-mmusic-data-channel-sdpneg@ietf.org" , Bo Burman , "mmusic-chairs@ietf.org" , "mmusic@ietf.org" 
Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-mmusic-data-channel-sdpneg-25:_(with_COMMENT)?=
Thread-Index: AQHU68sw/YSnkciZbUuyklXvy0atWKY2vu7A
Date: Thu, 11 Apr 2019 09:50:19 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18CDB5D4@dggemm526-mbx.china.huawei.com>
References: <155448109368.10029.4766956503581760917.idtracker@ietfa.amsl.com>
In-Reply-To: <155448109368.10029.4766956503581760917.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.202.102]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [MMUSIC]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-mmusic-data-channel-sdpneg-25=3A_=28with_COMMENT=29?=
X-BeenThere: mmusic@ietf.org
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: Thu, 11 Apr 2019 09:51:00 -0000

SGkgTWlyamEsDQpUaGFua3MNCg0KU2VlIGlubGluZQ0KUm9uaQ0KDQotLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KRnJvbTogTWlyamEgS8O8aGxld2luZCB2aWEgRGF0YXRyYWNrZXIgW21haWx0
bzpub3JlcGx5QGlldGYub3JnXSANClNlbnQ6IEZyaWRheSwgQXByaWwgMDUsIDIwMTkgNzoxOCBQ
TQ0KVG86IFRoZSBJRVNHDQpDYzogZHJhZnQtaWV0Zi1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5l
Z0BpZXRmLm9yZzsgQm8gQnVybWFuOyBtbXVzaWMtY2hhaXJzQGlldGYub3JnOyBiby5idXJtYW5A
ZXJpY3Nzb24uY29tOyBtbXVzaWNAaWV0Zi5vcmcNClN1YmplY3Q6IE1pcmphIEvDvGhsZXdpbmQn
cyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZy0y
NTogKHdpdGggQ09NTUVOVCkNCg0KTWlyamEgS8O8aGxld2luZCBoYXMgZW50ZXJlZCB0aGUgZm9s
bG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCmRyYWZ0LWlldGYtbW11c2ljLWRhdGEtY2hhbm5l
bC1zZHBuZWctMjU6IE5vIE9iamVjdGlvbg0KDQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVw
IHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwgZW1haWwgYWRkcmVzc2Vz
IGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMg
aW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQoNCg0KUGxlYXNlIHJlZmVyIHRvIGh0
dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0K
Zm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0
aW9ucy4NCg0KDQpUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9u
cywgY2FuIGJlIGZvdW5kIGhlcmU6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k
cmFmdC1pZXRmLW1tdXNpYy1kYXRhLWNoYW5uZWwtc2RwbmVnLw0KDQoNCg0KLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQ0KQ09NTUVOVDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhhbmtzIGZvciBxdWlja2x5IGFkZHJlc3Np
bmcgdGhlIGNvbW1lbnRzIGZyb20gdGhlIFRTVi1BUlQgcmV2aWV3IHJlZ2FyZGluZyBpbnRlcmFj
dGlvbnMgd2l0aCBTQ1RQIChhbmQgdGhhbmtzIE1pY2hlYWwgVC4gZm9yIHRoZSByZXZpZXchKSEN
Cg0KT25lIG1pbm9yLCBtb3JlIGVkaXRvcmlhbCBjb21tZW50IG9uIG1heC10aW1lIHBhcmFtZXRl
cjoNCmRyYWZ0LWlldGYtcnRjd2ViLWRhdGEtcHJvdG9jb2wgc2F5cyAiVGhpcyBsaWZlLXRpbWUg
c3RhcnRzIHdoZW4gcHJvdmlkaW5nIHRoZSB1c2VyIG1lc3NhZ2UgdG8gdGhlIHByb3RvY29sIHN0
YWNrLiIuIFdoaWxlIGEgcmVmZXJlbmNlIHRvIGRyYWZ0LWlldGYtcnRjd2ViLWRhdGEtcHJvdG9j
b2wgaXMgZ2l2ZW4gcmVzcGVjdGl2ZWx5LCBJIHdvdWxkIHJlY29tbWVuZCB0byBhbHNvIGNsYXJp
ZnkgaW4gdGhpcyBkcmFmdCB3aGljaCB0aW1lIGZyYW1lIGlzIG1lYW50IGdpdmVuIHRoaXMgdGlt
ZSBmcmFtZSBpbmNsdWRlcyBhbmQgZW5kLXRvLWVuZCBkZWxheXMuDQpbUkVdIGFyZSB5b3Ugc3Vn
Z2VzdGluZyB0byByZXBlYXQgdGhlIHRleHQgZnJvbSB0aGUgUlRDd2ViIGRvY3VtZW50ICIgQSB1
c2VyIG1lc3NhZ2Ugd2lsbCBubyBsb25nZXIgYmUgdHJhbnNtaXR0ZWQgb3IgcmV0cmFuc21pdHRl
ZCBhZnRlciBhICBzcGVjaWZpZWQgbGlmZS10aW1lIGdpdmVuIGluIG1pbGxpc2Vjb25kcyBpbiB0
aGUgJ21heC10aW1lJyBwYXJhbWV0ZXIuIFRoZSBsaWZlLXRpbWUgc3RhcnRzDQogICAgICAgICB3
aGVuIHByb3ZpZGluZyB0aGUgdXNlciBtZXNzYWdlIHRvIHRoZSBwcm90b2NvbCBzdGFjay4iDQog
ICANCg0KQXMgYSBzaWRlIG5vdGU6IG5vdCBzdXJlIGl0IGlzIG5lY2Vzc2FyeSB0byBleHBhbmQg
SUVURiAoSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSkgKHNlZSBzZWMgNS4yKSBpbiBh
biBJRVRGIFJGQyBidXQgdGhlIFJGQyBlZGl0b3IgbWlnaHQgdGVsbCB5b3UuLi4NCltSRV0gd2ls
bCByZW1vdmUNCg0KDQo=


From nobody Thu Apr 11 02:52:28 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2740F1202B7; Thu, 11 Apr 2019 02:52:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMUgFBjMZnt2; Thu, 11 Apr 2019 02:52:25 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC97C1202B1; Thu, 11 Apr 2019 02:52:25 -0700 (PDT)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 0AFA2B24539C4DA9CB13; Thu, 11 Apr 2019 10:52:24 +0100 (IST)
Received: from DGGEMM423-HUB.china.huawei.com (10.1.198.40) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 11 Apr 2019 10:52:23 +0100
Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.138]) by dggemm423-hub.china.huawei.com ([10.1.198.40]) with mapi id 14.03.0415.000; Thu, 11 Apr 2019 17:52:17 +0800
From: "Roni Even (A)" 
To: Barry Leiba , The IESG 
CC: "draft-ietf-mmusic-data-channel-sdpneg@ietf.org" , Bo Burman , "mmusic@ietf.org" 
Thread-Topic: Barry Leiba's No Objection on draft-ietf-mmusic-data-channel-sdpneg-25: (with COMMENT)
Thread-Index: AQHU7cJ8g/80ECYzdkOUtm0vLCUvWqY2vLDQ
Date: Thu, 11 Apr 2019 09:52:17 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18CDB5EC@dggemm526-mbx.china.huawei.com>
References: <155469725925.18284.13353229347477240382.idtracker@ietfa.amsl.com>
In-Reply-To: <155469725925.18284.13353229347477240382.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.202.102]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [MMUSIC] Barry Leiba's No Objection on draft-ietf-mmusic-data-channel-sdpneg-25: (with COMMENT)
X-BeenThere: mmusic@ietf.org
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: Thu, 11 Apr 2019 09:52:27 -0000

QmFycnkgdGhhbmtzLA0KSW5saW5lDQpSb25pDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQpGcm9tOiBCYXJyeSBMZWliYSB2aWEgRGF0YXRyYWNrZXIgW21haWx0bzpub3JlcGx5QGlldGYu
b3JnXSANClNlbnQ6IE1vbmRheSwgQXByaWwgMDgsIDIwMTkgNzoyMSBBTQ0KVG86IFRoZSBJRVNH
DQpDYzogZHJhZnQtaWV0Zi1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZ0BpZXRmLm9yZzsgQm8g
QnVybWFuOyBtbXVzaWNAaWV0Zi5vcmcNClN1YmplY3Q6IEJhcnJ5IExlaWJhJ3MgTm8gT2JqZWN0
aW9uIG9uIGRyYWZ0LWlldGYtbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWctMjU6ICh3aXRoIENP
TU1FTlQpDQoNCkJhcnJ5IExlaWJhIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBv
c2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZy0yNTogTm8g
T2JqZWN0aW9uDQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGlu
ZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhl
IFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFy
YWdyYXBoLCBob3dldmVyLikNCg0KDQpQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQpmb3IgbW9yZSBpbmZvcm1h
dGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KDQoNClRoZSBk
b2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQg
aGVyZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbW11c2lj
LWRhdGEtY2hhbm5lbC1zZHBuZWcvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDT01NRU5UOg0KLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQ0KDQpJIGFncmVlIHdpdGggTWFnbnVz4oCZcyBESVNDVVNTLg0KDQpQbGVhc2Ug
dXNlIHRoZSBmdWxsIEJDUCAxNCBib2lsZXJwbGF0ZSBmcm9tIFJGQyA4MTc0LCByYXRoZXIgdGhh
biBhYnJpZGdpbmcgaXQuDQpbUkVdT0sNCg0K4oCUIFNlY3Rpb24gNS4xLjEg4oCUDQoNCiAgIFdp
dGhpbiBhbiAnYT1kY21hcDonIGF0dHJpYnV0ZSBsaW5lJ3MgJ2RjbWFwLW9wdCcgdmFsdWUgb25s
eSBvbmUNCiAgICdtYXhyZXRyLW9wdCcgcGFyYW1ldGVyIG9yIG9uZSAnbWF4dGltZS1vcHQnIHBh
cmFtZXRlciBNQVkgYmUNCiAgIHByZXNlbnQuICBCb3RoIE1VU1QgTk9UIGJlIHByZXNlbnQuDQoN
Ckxvd2VyIGNhc2Ug4oCcbWF54oCdIGhlcmUsIHBsZWFzZS4gIFRoZSBNVVNUIE5PVCBpcyB0aGUg
bm9ybWF0aXZlIGJpdC4NCltPS10NCg0K4oCUIFNlY3Rpb24gOSBzdWJzZWN0aW9ucyDigJQNCg0K
SW5zdGFuY2VzIG9mIOKAnElFU0cgQ2hhaXJz4oCdIHNob3VsZCBqdXN0IHNheSDigJxJRVNH4oCd
Lg0KW09LXQ0KDQoNCg==


From nobody Thu Apr 11 02:57:29 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A5C1202B6; Thu, 11 Apr 2019 02:57:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8s7D1Mb05gty; Thu, 11 Apr 2019 02:57:18 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C15D1202B3; Thu, 11 Apr 2019 02:57:18 -0700 (PDT)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id DB442D77ACBCA3F11EBE; Thu, 11 Apr 2019 10:57:16 +0100 (IST)
Received: from lhreml703-chm.china.huawei.com (10.201.108.52) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 11 Apr 2019 10:57:16 +0100
Received: from lhreml703-chm.china.huawei.com (10.201.108.52) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 11 Apr 2019 10:57:16 +0100
Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Thu, 11 Apr 2019 10:57:16 +0100
Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.138]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0415.000; Thu, 11 Apr 2019 17:56:32 +0800
From: "Roni Even (A)" 
To: Ignas Bagdonas , The IESG 
CC: "draft-ietf-mmusic-data-channel-sdpneg@ietf.org" , Bo Burman , "mmusic-chairs@ietf.org" , "mmusic@ietf.org" 
Thread-Topic: Ignas Bagdonas' No Objection on draft-ietf-mmusic-data-channel-sdpneg-25: (with COMMENT)
Thread-Index: AQHU7ivgORv5EUVpJk2o4WL39VslZqY2vNZg
Date: Thu, 11 Apr 2019 09:56:32 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18CDB605@dggemm526-mbx.china.huawei.com>
References: <155474252775.3101.13106356106673699503.idtracker@ietfa.amsl.com>
In-Reply-To: <155474252775.3101.13106356106673699503.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.202.102]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [MMUSIC] Ignas Bagdonas' No Objection on draft-ietf-mmusic-data-channel-sdpneg-25: (with COMMENT)
X-BeenThere: mmusic@ietf.org
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: Thu, 11 Apr 2019 09:57:20 -0000

SGkgSWduYXMsDQpUaGFua3MsDQoNClNob3VsZCBiZSBvbmx5IG9uZSBJUDYNCkFsc28gT0sgZm9y
IElFU0cgaW5zdGVhZCBvZiBJRVNHIGNoYWlycw0KUm9uaQ0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLQ0KRnJvbTogSWduYXMgQmFnZG9uYXMgdmlhIERhdGF0cmFja2VyIFttYWlsdG86bm9y
ZXBseUBpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIEFwcmlsIDA4LCAyMDE5IDc6NTUgUE0NClRv
OiBUaGUgSUVTRw0KQ2M6IGRyYWZ0LWlldGYtbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWdAaWV0
Zi5vcmc7IEJvIEJ1cm1hbjsgbW11c2ljLWNoYWlyc0BpZXRmLm9yZzsgYm8uYnVybWFuQGVyaWNz
c29uLmNvbTsgbW11c2ljQGlldGYub3JnDQpTdWJqZWN0OiBJZ25hcyBCYWdkb25hcycgTm8gT2Jq
ZWN0aW9uIG9uIGRyYWZ0LWlldGYtbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWctMjU6ICh3aXRo
IENPTU1FTlQpDQoNCklnbmFzIEJhZ2RvbmFzIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFs
bG90IHBvc2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZy0y
NTogTm8gT2JqZWN0aW9uDQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1Ympl
Y3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQg
aW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3Rv
cnkgcGFyYWdyYXBoLCBob3dldmVyLikNCg0KDQpQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQpmb3IgbW9yZSBp
bmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KDQoN
ClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUg
Zm91bmQgaGVyZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt
bW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWcvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDT01NRU5U
Og0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLQ0KDQpBIGNvdXBsZSBvZiBuaXRzOg0KDQpzNzogYXJlIGV4YW1wbGVz
IGZvciBTRFAgb2ZmZXIgY29ycmVjdD8gYz0gYWRkcnR5cGUgSVA2IGlzIGxpc3RlZCB0d2ljZSB0
aGVyZS4NCg0KczkuMi4xLCBzOS4yLjI6IHMvSUVTRyBDaGFpcnMvSUVTRw0KDQoNCg==


From nobody Thu Apr 11 03:05:14 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039251202B9; Thu, 11 Apr 2019 03:05:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.189
X-Spam-Level: 
X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOrEit117gDo; Thu, 11 Apr 2019 03:05:04 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 625651200F1; Thu, 11 Apr 2019 03:05:04 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 8DC0A5AEF1168462050B; Thu, 11 Apr 2019 11:05:02 +0100 (IST)
Received: from lhreml704-chm.china.huawei.com (10.201.108.53) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 11 Apr 2019 11:05:02 +0100
Received: from lhreml704-chm.china.huawei.com (10.201.108.53) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 11 Apr 2019 11:05:02 +0100
Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Thu, 11 Apr 2019 11:05:01 +0100
Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.138]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0415.000; Thu, 11 Apr 2019 18:04:41 +0800
From: "Roni Even (A)" 
To: Magnus Westerlund , "ietf@ietf.org" 
CC: "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-rfc4566bis@ietf.org" , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] Last Call:  (SDP: Session Description Protocol) to Proposed Standard
Thread-Index: AQHU4L35G0bkeH37hEyuzO/M/jMwpKY22TWQ
Date: Thu, 11 Apr 2019 10:04:41 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18CDB636@dggemm526-mbx.china.huawei.com>
References: <155326592304.23020.8256337045285295468.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.202.102]
Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD18CDB636dggemm526mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [MMUSIC] Last Call:  (SDP: Session Description Protocol) to Proposed Standard
X-BeenThere: mmusic@ietf.org
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: Thu, 11 Apr 2019 10:05:07 -0000

--_000_6E58094ECC8D8344914996DAD28F1CCD18CDB636dggemm526mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Magnus,
I think it will affect the IANA registries where values may be shared with =
non SDP attribute. For example the sub-protocol in the IANA WebSocket Subpr=
otocol name registry

Roni Even



From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Magnus Westerlun=
d
Sent: Thursday, April 11, 2019 11:14 AM
To: ietf@ietf.org
Cc: mmusic-chairs@ietf.org; draft-ietf-mmusic-rfc4566bis@ietf.org; mmusic@i=
etf.org
Subject: Re: [MMUSIC] Last Call:  (SDP=
: Session Description Protocol) to Proposed Standard

MMUSIC WG, Document Editors

In the processing of draft-ietf-mmusic-data-channel-sdpneg-25 an interestin=
g question arose regarding text strings in SDP attribute values.

Currently the document says:

4.5.  Internationalization



   The SDP specification recommends the use of the ISO 10646 character

   set in the UTF-8 encoding [RFC3629] to allow many different languages

   to be represented.  However, to assist in compact representations,

   SDP also allows other character sets such as ISO 8859-1 to be used

   when desired.  Internationalization only applies to free-text sub-

   fields (session name and background information), and not to SDP as a

   whole.



If one like to include UTF-8 field for attributes it would be good if

the requirement would be clear going forward that there is an expectancy

that at least parser can process any UTF-8 strings that may occur in any

fields.



That would allow future SDP field values to use UTF-8 strings without risks

and simplify processing. Like in the case of the data channel SDP mapping

where the extra step of encoding lable characters not visually safe as esca=
ped

characters could be avoided.



Does anyone have input if making such a change would have significant impac=
t on

the interoperability?



Cheers



Magnus



On 2019-03-22 15:46, The IESG wrote:



The IESG has received a request from the Multiparty Multimedia Session

Control WG (mmusic) to consider the following document: - 'SDP: Session

Description Protocol'

   as Proposed Standard



The IESG plans to make a decision in the next few weeks, and solicits final

comments on this action. Please send substantive comments to the

ietf@ietf.org mailing lists by 2019-04-12. Exceptiona=
lly, comments may be

sent to iesg@ietf.org instead. In either case, please=
 retain the beginning of

the Subject line to allow automated sorting.



Abstract





   This memo defines the Session Description Protocol (SDP).  SDP is

   intended for describing multimedia sessions for the purposes of

   session announcement, session invitation, and other forms of

   multimedia session initiation.  This document obsoletes RFC 4566.









The file can be obtained via

https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/



IESG discussion can be tracked via

https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/ballot/





No IPR declarations have been submitted directly on this I-D.









_______________________________________________

mmusic mailing list

mmusic@ietf.org

https://www.ietf.org/mailman/listinfo/mmusic





--



Magnus Westerlund



----------------------------------------------------------------------

Network Architecture & Protocols, Ericsson Research

----------------------------------------------------------------------

Ericsson AB                 | Phone  +46 10 7148287

Torshamnsgatan 23           | Mobile +46 73 0949079

SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com

----------------------------------------------------------------------

--_000_6E58094ECC8D8344914996DAD28F1CCD18CDB636dggemm526mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Magnus,


I think it will affect th=
e IANA registries where values may be shared with non SDP attribute. For ex=
ample the sub-protocol in the IANA WebSocket Subprotocol
 name registry 


 <=
/p>

Roni Even


 <=
/p>

 <=
/p>

 <=
/p>





From: mmusic [mailto:mmusic-bounces@ietf.org]
On Behalf Of Magnus Westerlund

Sent: Thursday, April 11, 2019 11:14 AM

To: ietf@ietf.org

Cc: mmusic-chairs@ietf.org; draft-ietf-mmusic-rfc4566bis@ietf.org; m=
music@ietf.org

Subject: Re: [MMUSIC] Last Call: <draft-ietf-mmusic-rfc4566bis-34=
.txt> (SDP: Session Description Protocol) to Proposed Standard






 




MMUSIC WG, Document Editors






 






In the processing of draft-ietf-mmusic-data-channel-=
sdpneg-25 an interesting question arose regarding text strings in SDP attri=
bute values.







 






Currently the document says: 






4.5.  Internationalization

 


   The SDP specification recommends the use of the ISO 10646=
 character


   set in the UTF-8 encoding [RFC3629] to allow many differe=
nt languages


   to be represented.  However, to assist in compact re=
presentations,


   SDP also allows other character sets such as ISO 8859-1 t=
o be used


   when desired.  Internationalization only applies to =
free-text sub-


   fields (session name and background information), and not=
 to SDP as a


   whole.


 


If one like to include UTF-8 field for attributes it would be good if =



the requirement would be clear going forward that there is an expectan=
cy 


that at least parser can process any UTF-8 strings that may occur in a=
ny 


fields. 


 


That would allow future SDP field values to use UTF-8 strings without =
risks


and simplify processing. Like in the case of the data channel SDP mapp=
ing 


where the extra step of encoding lable characters not visually safe as=
 escaped 


characters could be avoided. 


 


Does anyone have input if making such a change would have significant =
impact on 


the interoperability? 


 


Cheers


 


Magnus


 






 






On 2019-03-22 15:46, The IESG wrote:






 


The IESG has received a request from the Multiparty Multimedia Session=



Control WG (mmusic) to consider the following document: - 'SDP: Sessio=
n


Description Protocol'


  <draft-ietf-mmusic-rfc4566bis-34.txt> as Proposed Standar=
d


 


The IESG plans to make a decision in the next few weeks, and solicits =
final


comments on this action. Please send substantive comments to the<=
/o:p>


ietf@ietf.org mailing lists by 20=
19-04-12. Exceptionally, comments may be


sent to iesg@ietf.org instead. In=
 either case, please retain the beginning of


the Subject line to allow automated sorting.


 


Abstract


 


 


   This memo defines the Session Description Protocol (SDP).=
  SDP is


   intended for describing multimedia sessions for the purpo=
ses of


   session announcement, session invitation, and other forms=
 of


   multimedia session initiation.  This document obsole=
tes RFC 4566.


 


 


 


 


The file can be obtained via


https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/


 


IESG discussion can be tracked via


https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/b=
allot/


 


 


No IPR declarations have been submitted directly on this I-D.


 


 


 


 


_______________________________________________


mmusic mailing list


mmusic@ietf.org

https://www.i=
etf.org/mailman/listinfo/mmusic


 




 


-- 


 


Magnus Westerlund 


 


----------------------------------------------------------------------=



Network Architecture & Protocols, Ericsson Research

----------------------------------------------------------------------=



Ericsson AB          =
;       | Phone  +46 10 7148287=



Torshamnsgatan 23         =
;  | Mobile +46 73 0949079


SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com


----------------------------------------------------------------------=







--_000_6E58094ECC8D8344914996DAD28F1CCD18CDB636dggemm526mbxchi_--


From nobody Thu Apr 11 03:35:05 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C09712004D; Thu, 11 Apr 2019 03:34:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWPKXxLIEuZ5; Thu, 11 Apr 2019 03:34:55 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37A57120044; Thu, 11 Apr 2019 03:34:55 -0700 (PDT)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 43252390BB843AA18E83; Thu, 11 Apr 2019 11:34:53 +0100 (IST)
Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 11 Apr 2019 11:34:52 +0100
Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.138]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0415.000; Thu, 11 Apr 2019 18:34:08 +0800
From: "Roni Even (A)" 
To: "mmusic@ietf.org" 
CC: "iesg@ietf.org" 
Thread-Topic: Addressing comment from IANA on draft-ietf-mmusic-data-channel-sdpneg-25
Thread-Index: AdTwT5OIKFVlXaa2S8ClvVSnITuzDg==
Date: Thu, 11 Apr 2019 10:34:08 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18CDB681@dggemm526-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.202.102]
Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD18CDB681dggemm526mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [MMUSIC] Addressing comment from IANA on draft-ietf-mmusic-data-channel-sdpneg-25
X-BeenThere: mmusic@ietf.org
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: Thu, 11 Apr 2019 10:34:57 -0000

--_000_6E58094ECC8D8344914996DAD28F1CCD18CDB681dggemm526mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
I got the following comment from IANA:


Third, Section 9.3 of the current document appears to request the creation =
of a new registry in the Session Description Protocol (SDP) Parameters regi=
stry located at:



https://www.iana.org/assignments/sdp-parameters/



IANA Question --> The new registry might be modeled upon the existing att-f=
ield (. . . level) registries but instead be a registry for att-field (dcsa=
 level). Is this correct? Would the new registry have the same characterist=
ics as other att-field registries on the registry page? Could the draft be =
revised to explicitly create the registry, if this is correct? Are there an=
y initial registrations in this new registry?



My response was



We are not asking for a new registry,  see https://tools.ietf.org/html/draf=
t-ietf-mmusic-rfc4566bis-33#section-8.5 for  the Reorganization of the att-=
field Registries.  I now think that this third action is not really needed =
since it is now defined in rfc4566bis section 8.5 and 8.4



So I suggest to remove section 9.3 and add to the end of section section 5.=
2.1





A data channel specific usage of a subprotocol attribute is expected to be =
specified

   in the same document that registers the subprotocol's identifier for

   data channel usage.



        SDP attributes that are only defined for use at the

   dcsa usage level, SHALL use the dcsa usage level when registering the

   attribute.  If existing media attributes are used in a datachannel

   subprotocol specific way, then a new dcsa usage level

   MUST be defined for the existing media attribute.  Where the SDP

  attribute is applicable to a particular subprotocol/s this SHALL also

   be registered by indicating the applicable subprotocol identifiers

   (see https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-34#section=
-8.5) along with the dcsa usage level.





Roni Even












--_000_6E58094ECC8D8344914996DAD28F1CCD18CDB681dggemm526mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


I got the following comment from IANA:

 


Third, Section 9.3 of the current document appear=
s to request the creation of a new registry in the Session Description Prot=
ocol (SDP) Parameters registry located at:


 


https://www.iana.org/assignments/sdp-parameters/=



 


IANA Question --> The new registry might be mo=
deled upon the existing att-field (. . . level) registries but instead be a=
 registry for att-field (dcsa level). Is this correct? Would the new regist=
ry have the same characteristics as other
 att-field registries on the registry page? Could the draft be revised to e=
xplicitly create the registry, if this is correct? Are there any initial re=
gistrations in this new registry?


 


My response was


 


We are not asking for a new registry,  see <=
a href=3D"https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-33#secti=
on-8.5">
https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-33#section-8.5=
 for  the Reorganization of the att-field Registries.  I now thin=
k that this third action is not really needed since it is now defined in rf=
c4566bis section 8.5 and 8.4


 


So I suggest to remove section 9.3 and add to the=
 end of section section 5.2.1



 


 


A data channel specific usage of a subprot=
ocol attribute is expected to be specified


   in the same document that reg=
isters the subprotocol's identifier for


   data channel usage. 


 


       =
 SDP attributes that are only defined for use at the

   dcsa usage level, SHALL use t=
he dcsa usage level when registering the


   attribute.  If existing =
media attributes are used in a datachannel


   subprotocol specific way, the=
n a new dcsa usage level


   MUST be defined for the exist=
ing media attribute.  Where the SDP


  attribute is applicable to a partic=
ular subprotocol/s this SHALL also


   be registered by indicating t=
he applicable subprotocol identifiers


   (see https://=
tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-34#section-8.5) along with the dcsa usage level.

 


 


Roni Even


 


 


 


 


 


 






--_000_6E58094ECC8D8344914996DAD28F1CCD18CDB681dggemm526mbxchi_--


From nobody Thu Apr 11 05:15:40 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155F21201B1; Thu, 11 Apr 2019 05:15:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXhpBfu2KMrp; Thu, 11 Apr 2019 05:15:30 -0700 (PDT)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64C32120048; Thu, 11 Apr 2019 05:15:30 -0700 (PDT)
Received: from ewa_guest_internet_sthlm_nat2.ericsson.net ([192.176.1.97] helo=[10.148.125.253]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hEYc2-0003E1-Ug; Thu, 11 Apr 2019 14:15:27 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Mirja Kuehlewind 
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD18CDB5D4@dggemm526-mbx.china.huawei.com>
Date: Thu, 11 Apr 2019 14:15:24 +0200
Cc: The IESG , "mmusic-chairs@ietf.org" , Bo Burman , "draft-ietf-mmusic-data-channel-sdpneg@ietf.org" ,  "mmusic@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <6186A0F4-D36A-48BC-9522-95D81D7814F1@kuehlewind.net>
References: <155448109368.10029.4766956503581760917.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD18CDB5D4@dggemm526-mbx.china.huawei.com>
To: "Roni Even (A)" 
X-Mailer: Apple Mail (2.3445.104.8)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1554984930;7a82340d;
X-HE-SMSGID: 1hEYc2-0003E1-Ug
Archived-At: 
Subject: Re: [MMUSIC]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-mmusic-data-channel-sdpneg-25=3A_=28with_COMMENT=29?=
X-BeenThere: mmusic@ietf.org
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: Thu, 11 Apr 2019 12:15:32 -0000

Hi Roni,

Yes, I think more or less repeating the text from the RTCweb doc could =
be useful here.

Mirja



> On 11. Apr 2019, at 11:50, Roni Even (A)  wrote:
>=20
> Hi Mirja,
> Thanks
>=20
> See inline
> Roni
>=20
> -----Original Message-----
> From: Mirja K=C3=BChlewind via Datatracker [mailto:noreply@ietf.org]=20=

> Sent: Friday, April 05, 2019 7:18 PM
> To: The IESG
> Cc: draft-ietf-mmusic-data-channel-sdpneg@ietf.org; Bo Burman; =
mmusic-chairs@ietf.org; bo.burman@ericsson.com; mmusic@ietf.org
> Subject: Mirja K=C3=BChlewind's No Objection on =
draft-ietf-mmusic-data-channel-sdpneg-25: (with COMMENT)
>=20
> Mirja K=C3=BChlewind has entered the following ballot position for
> draft-ietf-mmusic-data-channel-sdpneg-25: No Objection
>=20
> When responding, please keep the subject line intact and reply to all =
email addresses included in the To and CC lines. (Feel free to cut this =
introductory paragraph, however.)
>=20
>=20
> Please refer to =
https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>=20
>=20
> The document, along with other ballot positions, can be found here:
> =
https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/
>=20
>=20
>=20
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>=20
> Thanks for quickly addressing the comments from the TSV-ART review =
regarding interactions with SCTP (and thanks Micheal T. for the =
review!)!
>=20
> One minor, more editorial comment on max-time parameter:
> draft-ietf-rtcweb-data-protocol says "This life-time starts when =
providing the user message to the protocol stack.". While a reference to =
draft-ietf-rtcweb-data-protocol is given respectively, I would recommend =
to also clarify in this draft which time frame is meant given this time =
frame includes and end-to-end delays.
> [RE] are you suggesting to repeat the text from the RTCweb document " =
A user message will no longer be transmitted or retransmitted after a  =
specified life-time given in milliseconds in the 'max-time' parameter. =
The life-time starts
>         when providing the user message to the protocol stack."
>=20
>=20
> As a side note: not sure it is necessary to expand IETF (Internet =
Engineering Task Force) (see sec 5.2) in an IETF RFC but the RFC editor =
might tell you...
> [RE] will remove
>=20
>=20


From nobody Thu Apr 11 07:56:46 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3FF1202ED; Thu, 11 Apr 2019 07:56:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrI-O97xNBiR; Thu, 11 Apr 2019 07:56:41 -0700 (PDT)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07999120378; Thu, 11 Apr 2019 07:56:40 -0700 (PDT)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x3BEuRuJ015708; Thu, 11 Apr 2019 10:56:28 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x3BEuRuJ015708
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1554994588; bh=DFvctlxXnFTHmo7+HjhC2HDR2zEf5toGzUI8z3knZCo=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=HywfSA8WJqstaSqFBIrXK8I8dbbMW082UOSTrjCQBHckLaDHuPzrK0f0Xl5Idfbp6 x/1v00BEab0c6aEffFKw+PLS1/zwCVrQ/wGMql+lf5GsIsx6fLnfCyU5W/21A4JpB7 69q57gHizkYNXwlGBZOF6WuZTYEwNSIEiDV6uz58=
Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x3BEuNrI023859; Thu, 11 Apr 2019 10:56:23 -0400
Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0435.000; Thu, 11 Apr 2019 10:56:23 -0400
From: Roman Danyliw 
To: "Roni Even (A)" , The IESG 
CC: "draft-ietf-mmusic-data-channel-sdpneg@ietf.org" , Bo Burman , "mmusic-chairs@ietf.org" , "mmusic@ietf.org" 
Thread-Topic: Roman Danyliw's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)
Thread-Index: AQHU7w7aiclXlP59H0y/5xTbuqoJoqY29baAgAAX6kA=
Date: Thu, 11 Apr 2019 14:56:21 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B3327FF5@marchand>
References: <155484000356.19554.8395796686893872238.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD18CDB59D@dggemm526-mbx.china.huawei.com>
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD18CDB59D@dggemm526-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [MMUSIC] Roman Danyliw's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)
X-BeenThere: mmusic@ietf.org
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: Thu, 11 Apr 2019 14:56:44 -0000

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUm9uaSBFdmVuIChBKSBb
bWFpbHRvOnJvbmkuZXZlbkBodWF3ZWkuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMTEs
IDIwMTkgNToyNSBBTQ0KPiBUbzogUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPjsgVGhlIElF
U0cgPGllc2dAaWV0Zi5vcmc+DQo+IENjOiBkcmFmdC1pZXRmLW1tdXNpYy1kYXRhLWNoYW5uZWwt
c2RwbmVnQGlldGYub3JnOyBCbyBCdXJtYW4NCj4gPGJvLmJ1cm1hbkBlcmljc3Nvbi5jb20+OyBt
bXVzaWMtY2hhaXJzQGlldGYub3JnOyBtbXVzaWNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFJv
bWFuIERhbnlsaXcncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtbW11c2ljLWRhdGEtY2hhbm5lbC0N
Cj4gc2RwbmVnLTI1OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiANCj4gVGhhbmtzIGZv
ciB0aGUgcmV2aWV3LCBzZWUgaW5saW5lDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS0NCj4gRnJvbTogUm9tYW4gRGFueWxpdyB2aWEgRGF0YXRyYWNrZXIgW21haWx0bzpub3Jl
cGx5QGlldGYub3JnXQ0KPiBTZW50OiBUdWVzZGF5LCBBcHJpbCAwOSwgMjAxOSAxMTowMCBQTQ0K
PiBUbzogVGhlIElFU0cNCj4gQ2M6IGRyYWZ0LWlldGYtbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBu
ZWdAaWV0Zi5vcmc7IEJvIEJ1cm1hbjsgbW11c2ljLQ0KPiBjaGFpcnNAaWV0Zi5vcmc7IGJvLmJ1
cm1hbkBlcmljc3Nvbi5jb207IG1tdXNpY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSb21hbiBEYW55
bGl3J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLW1tdXNpYy1kYXRhLWNoYW5uZWwtDQo+IHNkcG5l
Zy0yNTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IFJvbWFuIERhbnlsaXcgaGFz
IGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYt
bW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWctMjU6IERpc2N1c3MNCj4gDQo+IFdoZW4gcmVzcG9u
ZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFs
bCBlbWFpbA0KPiBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZl
ZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkNCj4gcGFyYWdyYXBoLCBob3dldmVyLikN
Cj4gDQo+IA0KPiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0
ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0
IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+IA0KPiANCj4gVGhlIGRvY3Vt
ZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJl
Og0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1tdXNpYy1k
YXRhLWNoYW5uZWwtc2RwbmVnLw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IERJU0NV
U1M6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+ICgxKSBTZWN0aW9uIDUuMi4xLiAgVGhlIEFCTkYg
b2Ygc3RyZWFtLWlkIG9mIOKAnGRjc2EtdmFsdWUgPSBzdHJlYW0taWQg4oCm4oCdIGRvZXMNCj4g
bm90IGFwcGVhciB0byBiZSBkZWZpbmVkIGV4cGxpY2l0bHkgb3IgYnkgcmVmZXJlbmNlIGluIHRo
ZSBkcmFmdC4NCj4gDQo+IFJFOiB3aWxsICBhZGQgInN0cmVhbS1pZCA9IDEqNURJR0lUIiA7IHNh
bWUgYXMgZGNtYXAtc3RyZWFtLWlkDQoNCk9LLiAgVGhhbmtzIGZvciB0aGUgZml4Lg0KDQo+ICgy
KSBTZWN0aW9uIDYuNiwg4oCc4oCmIHRoZSBvZmZlcmVyIFNIQUxMIGluY2x1ZGUgcHJldmlvdXNs
eSBuZWdvdGlhdGVkIFNEUA0KPiBhdHRyaWJ1dGVzIOKApiBhc3NvY2lhdGVkIHdpdGggdGhlIGNo
YW5uZWzigJ0uICBXaGF0IGlzIHRoZSBiZWhhdmlvciBvZiB0aGUNCj4gcmVjZWl2ZXIgaWYgdGhl
IGF0dHJpYnV0ZXMgaW5jbHVkZWQgYnkgdGhlIG9mZmVyZXIgYXJlIE5PVCB0aG9zZSB0aGF0IHdl
cmUNCj4gcHJldmlvdXNseSBuZWdvdGlhdGVkPw0KPiANCj4gUkU6IFRoZSBiZWhhdmlvciBpcyBw
cm90b2NvbCBzcGVjaWZpYywgb2ZmZXIgYW5zd2VyIG1heSBiZSB1c2VkIGJ5IG11bHRpcGxlDQo+
IHNpZ25hbGluZyBwcm90b2NvbCBlLmcuIFNJUA0KDQpVbmRlcnN0b29kLiAgQ291bGQgeW91IGFk
ZCB0aGF0IHNpbXBsZSBzZW50ZW5jZSB0aGF0IHRoZSBiZWhhdmlvciBvbiBtaXNtYXRjaCBpcyBw
cm90b2NvbCBzcGVjaWZpYy4NCg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAt
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tDQo+IA0KPiAoMSkgU2VjdGlvbiAxLiAgRWRpdG9yaWFsIE5pdHMuDQo+IHMv
VGhlIGNvbmNlcHQgb2YgZXN0YWJsaXNoaW5nIGEgYmktZGlyZWN0aW9uYWwgZGF0YSBjaGFubmVs
IHJ1bm5pbmcgb24gdG9wIG9mDQo+IHRoZSBTdHJlYW0gQ29udHJvbCBUcmFuc21pc3Npb24gUHJv
dG9jb2wgKFNDVFApIGlzIGluDQo+IFtJLUQuaWV0Zi1ydGN3ZWItZGF0YS1jaGFubmVsXSBhbGxv
d2luZyBhcHBsaWNhdGlvbnMgdG8gdXNlIGRhdGEgICAgY2hhbm5lbHMuLw0KPiBUaGUgY29uY2Vw
dCBvZiBlc3RhYmxpc2hpbmcgYSBiaS1kaXJlY3Rpb25hbCBkYXRhIGNoYW5uZWwgcnVubmluZyBv
biB0b3Agb2YNCj4gdGhlIFN0cmVhbSBDb250cm9sIFRyYW5zbWlzc2lvbiBQcm90b2NvbCAoU0NU
UCkgaW4gW0ktRC5pZXRmLXJ0Y3dlYi1kYXRhLQ0KPiBjaGFubmVsXSBhbGxvd3MgYXBwbGljYXRp
b25zIHRvIHVzZSBkYXRhIGNoYW5uZWxzLi8NCj4gDQo+IFtSRV0gTm90IHN1cmUgLSB0aGUgYWxs
b3dpbmcgcmVmZXJzIHRvIFtydGN3ZWItZGF0YS1jaGFubmVsXQ0KPg0KPiBzL0FuIGluLWJhbmQg
RGF0YSBDaGFubmVsIEVzdGFibGlzaG1lbnQgUHJvdG9jb2wgKERDRVApIGlzIGluIFtJLUQuaWV0
Zi0NCj4gcnRjd2ViLWRhdGEtcHJvdG9jb2xdLCBob3dldmVyIG90aGVyIGluLWJhbmQgb3Igb3V0
LW9mLWJhbmQgcHJvdG9jb2xzIG1heQ0KPiBiZSB1c2VkIGZvciBlc3RhYmxpc2hpbmcgZGF0YSBj
aGFubmVscy4vIEluIGFkZGl0aW9uIHRvIHRoZSBpbi1iYW5kIERhdGENCj4gQ2hhbm5lbCBFc3Rh
Ymxpc2htZW50IFByb3RvY29sIChEQ0VQKSwgb3RoZXIgaW4tYmFuZCBhbmQgb3V0LW9mLWJhbmQN
Cj4gcHJvdG9jb2xzIG1heSBiZSB1c2VkIGZvciBlc3RhYmxpc2hpbmcgZGF0YSBjaGFubmVscy8N
Cj4gDQo+IFtSRV0gcHJlZmVyIHRvIHVzZSBhcyBpcw0KDQpObyBwcm9ibGVtLiAgS2VlcCB0aGUg
b3JpZ2luYWwgdGV4dC4NCiANCj4gKDIpIFNlY3Rpb24gMS4gIFR5cG8gKGV4dHJhIHNwYWNlIGJl
dHdlZW4gY2xvc2UgYnJhY2tldCBhbmQgcGVyaW9kKSBzL0Zvcg0KPiBNU1JQIHRoZXkgYXJlIGRv
Y3VtZW50ZWQgaW4gW0ktRC5pZXRmLW1tdXNpYy1tc3JwLXVzYWdlLWRhdGEtY2hhbm5lbF0gLi8N
Cj4gRm9yIE1TUlAgdGhleSBhcmUgZG9jdW1lbnRlZCBpbiBbSS1ELmlldGYtbW11c2ljLW1zcnAt
dXNhZ2UtZGF0YS0NCj4gY2hhbm5lbF0uLw0KPiBbT0tdDQo+IA0KPiAoMykgU2VjdGlvbiAzLiAg
RWRpdG9yaWFsIE5pdC4NCj4gb2xkOiAiZGVsaXZlcnkuLi4gKS4iOyBuZXc6ICJkZWxpdmVyeSwg
ZXRjLikuIg0KPiBbUkVdIE9LDQo+IA0KPiANCj4gDQo+ICg0KSBTZWN0aW9uIDYuMS4gIEVkaXRv
cmlhbCBOaXQuDQo+IFRoZXJlIGFwcGVhcnMgdG8gYmUgdHdvIGluc3RhbmNlcyBvZiB0aGUgc2Vu
dGVuY2UsIOKAnFNDVFAgc3RyZWFtIGlkZW50aWZpZXJzDQo+IGFzc29jaWF0ZWQgd2l0aCBkYXRh
IGNoYW5uZWxzIHRoYXQgaGF2ZSBiZWVuIG5lZ290aWF0ZWQgdXNpbmcgRENFUCBNVVNUDQo+IE5P
VCBiZSBpbmNsdWRlZCBpbiBTRFAgb2ZmZXJzIGFuZCBhbnN3ZXJzLuKAnQ0KPiANCj4gW1JFXSB0
aGFua3MsIHdpbGwgcmVtb3ZlIHRoZSBmaXJzdCBpbnN0YW5jZQ0KPiANCj4gDQo+ICg1KSBTZWN0
aW9uIDYuNS4gIFRoZSBzZW50ZW5jZSDigJxOb3RlOiBEQ0VQIGlzIG5vdCB1c2VkLCB0aGF0IGlz
IG5laXRoZXIgdGhlIFNEUA0KPiBvZmZlcmVyIG5vciB0aGUgU0RQIGFuc3dlcmVyIHNlbmQgYW4g
aW4tYmFuZCBEQ0VQIERBVEFfQ0hBTk5FTF9PUEVODQo+IG1lc3NhZ2XigJ0NCj4gdXNlcyBhIHRy
aXBsZSBuZWdhdGl2ZSBzbyB0aGUgZ3VpZGFuY2UgaXMgbm90IGNsZWFyLg0KPiBbUkVdICBJIGNh
biByZW1vdmUgdGhlIG5vdGUsIGRvZXMgbm90IHByb3ZpZGUgYW55IHZhdWUNCg0KVGhhbmtzIGZv
ciB0aGVzZSBjaGFuZ2VzLg0KDQo+ICg2KSBTZWN0aW9uIDYuNywgUGVyIOKAnFNEUCBvZmZlciBv
ciBhbnN3ZXIgaGFzIGFuICJhPWRjc2EiIGF0dHJpYnV0ZSwgd2hvc2UNCj4gc3VicHJvdG9jb2wg
YXR0cmlidXRlIGlzIGtub3duLCBidXQgd2hvc2Ugc3VicHJvdG9jb2wgYXR0cmlidXRlIHNlbWFu
dGljIGlzDQo+IG5vdCBrbm93biBmb3IgdGhlIGRhdGEgY2hhbm5lbCB0cmFuc3BvcnQgY2FzZeKA
nSwgY29uc2lkZXIgYSBjYXNlIHdoZXJlIHRoZQ0KPiBzdWItcHJvdG9jb2wgYXR0cmlidXRlIGlz
IGtub3duIGJ1dCB0aGUgdmFsdWUgaXMgaW52YWxpZC4gIElzIHRoYXQgY2FzZSBhIHN1Yi1zZXQN
Cj4gb2Ygd2hhdCBpcyBtZWFudCBieSB0aGUg4oCcYXR0cmlidXRlIHNlbWFudGljIGlzIG5vdCBr
bm93buKAnT8NCj4gW1JFXSB5ZXMsIHRoaXMgaXMgd2hhdCBzZW1hbnRpY3MgbWVhbnMNCg0KVW5k
ZXJzdG9vZC4gIFRoYW5rcyBmb3IgdGhlIGNsYXJpdHkuDQoNClJvbWFuDQoNCj4gDQo+IA0KPiAN
Cg0K


From nobody Thu Apr 11 08:58:54 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589C61202FE; Thu, 11 Apr 2019 08:58:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.68
X-Spam-Level: 
X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9b4CyVo_v-0E; Thu, 11 Apr 2019 08:58:46 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B30E1202FC; Thu, 11 Apr 2019 08:58:46 -0700 (PDT)
Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x3BFwc02047122 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 11 Apr 2019 10:58:40 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1554998323; bh=Vp52alvljIsNuYJWaffjqOzaL6ohS31gLG4bVWM6Ur4=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=UXbyzRq9LsxUaX5hkXMY3Cg5eTcUHMLep9nya/08cIothakwPwauy9QwA+UyGp3/h 3YKRzUJT7nt6KZx0eeDA81TxGy1p+gZfKZ0J8LYgfEin18Wm7tChkBnVpGOk6sKold /wSLnopTrfNNtMN/zDpqBXXq8Db4AKzo1FDWTX7Y=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at
To: Magnus Westerlund , The IESG 
Cc: "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-data-channel-sdpneg@ietf.org" , "mmusic@ietf.org" 
References: <155446588097.13196.6373243259627185094.idtracker@ietfa.amsl.com> <1afcb116-36cb-be51-81ac-e78fc52c9255@nostrum.com>     
From: Adam Roach 
Message-ID: <46d43903-0da2-9d2c-158e-5ec9b0fb11ca@nostrum.com>
Date: Thu, 11 Apr 2019 10:58:33 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)
X-BeenThere: mmusic@ietf.org
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: Thu, 11 Apr 2019 15:58:48 -0000

On 4/11/19 2:57 AM, Magnus Westerlund wrote:
> For 4566bis I hope the WG could discuss this before the IETF last call
> ends. It will run for another 2 week isn't it so there is time for that.


Well, technically, it ends tomorrow, but you are correct that we don't 
have a formal telechat until the 25th. I'm going to hold off creating a 
ballot until the conversation you just started in MMUSIC has time to 
conclude.

/a


From nobody Thu Apr 11 09:09:15 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927EC120308; Thu, 11 Apr 2019 09:08:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsFegBqlg_4M; Thu, 11 Apr 2019 09:08:56 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E62891202E5; Thu, 11 Apr 2019 09:08:53 -0700 (PDT)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x3BG8mTG003643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Apr 2019 12:08:48 -0400
To: Magnus Westerlund , "ietf@ietf.org" 
Cc: Adam Roach , "draft-ietf-mmusic-rfc4566bis@ietf.org" , "mmusic@ietf.org" , "mmusic-chairs@ietf.org" 
References: <155326592304.23020.8256337045285295468.idtracker@ietfa.amsl.com> 
From: Paul Kyzivat 
Message-ID: <7909c1bc-b204-268a-3b81-8e65b9fd2dda@alum.mit.edu>
Date: Thu, 11 Apr 2019 12:08:47 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [MMUSIC] Last Call:  (SDP: Session Description Protocol) to Proposed Standard
X-BeenThere: mmusic@ietf.org
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: Thu, 11 Apr 2019 16:09:00 -0000

On 4/11/19 4:14 AM, Magnus Westerlund wrote:
> MMUSIC WG, Document Editors
> 
> In the processing of draft-ietf-mmusic-data-channel-sdpneg-25 an 
> interesting question arose regarding text strings in SDP attribute values.
> 
> Currently the document says:
> 
> 4.5. Internationalization
> 
>     The SDP specification recommends the use of the ISO 10646 character
>     set in the UTF-8 encoding [RFC3629] to allow many different languages
>     to be represented.  However, to assist in compact representations,
>     SDP also allows other character sets such as ISO 8859-1 to be used
>     when desired.  Internationalization only applies to free-text sub-
>     fields (session name and background information), and not to SDP as a
>     whole.
> 
> If one like to include UTF-8 field for attributes it would be good if
> the requirement would be clear going forward that there is an expectancy
> that at least parser can process any UTF-8 strings that may occur in any
> fields.
> 
> That would allow future SDP field values to use UTF-8 strings without risks
> and simplify processing. Like in the case of the data channel SDP mapping
> where the extra step of encoding lable characters not visually safe as escaped
> characters could be avoided.
> 
> Does anyone have input if making such a change would have significant impact on
> the interoperability?

I'm inclined to just say that attribute values are limited to values 
that are natively representable in the chosen charset. That will impose 
limitations on use with charsets more limited than UTF-8.

	Thanks,
	Paul


From nobody Thu Apr 11 09:31:49 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B0D1202EF for ; Thu, 11 Apr 2019 09:31:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5o3P0QKeMEYJ for ; Thu, 11 Apr 2019 09:31:46 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F41BB1203B6 for ; Thu, 11 Apr 2019 09:31:45 -0700 (PDT)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x3BGVhYa005323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 11 Apr 2019 12:31:44 -0400
To: mmusic@ietf.org
References: <6E58094ECC8D8344914996DAD28F1CCD18CDB681@dggemm526-mbx.china.huawei.com>
From: Paul Kyzivat 
Message-ID: <8f2f339c-8174-b9b1-8204-78d5ee665574@alum.mit.edu>
Date: Thu, 11 Apr 2019 12:31:43 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD18CDB681@dggemm526-mbx.china.huawei.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [MMUSIC] Addressing comment from IANA on draft-ietf-mmusic-data-channel-sdpneg-25
X-BeenThere: mmusic@ietf.org
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: Thu, 11 Apr 2019 16:31:48 -0000

On 4/11/19 6:34 AM, Roni Even (A) wrote:
> Hi,
> 
> I got the following comment from IANA:
> 
> Third, Section 9.3 of the current document appears to request the 
> creation of a new registry in the Session Description Protocol (SDP) 
> Parameters registry located at:
> 
> https://www.iana.org/assignments/sdp-parameters/
> 
> IANA Question --> The new registry might be modeled upon the existing 
> att-field (. . . level) registries but instead be a registry for 
> att-field (dcsa level). Is this correct? Would the new registry have the 
> same characteristics as other att-field registries on the registry page? 
> Could the draft be revised to explicitly create the registry, if this is 
> correct? Are there any initial registrations in this new registry?
> 
> My response was
> 
> We are not asking for a new registry,  see 
> https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-33#section-8.5 
> for  the Reorganization of the att-field Registries.  I now think that 
> this third action is not really needed since it is now defined in 
> rfc4566bis section 8.5 and 8.4
> 
> So I suggest to remove section 9.3 and add to the end of section section 
> 5.2.1

ISTM we actually got a little ahead of ourselves in 4566bis by 
mentioning dcsa and msrp-usage-datachannel.

While 4566bis reorganizes the attribute registries so that we don't need 
a new registry for dcsa, is is draft-ietf-mmusic-data-channel-sdpneg 
that defines the dcsa usage level. The publication of it should result 
in addition of a reference to it in the attribute registry. So I think 
we need an IANA action just to accomplish that.

And maybe the references to dcsa and msrp-usage-data-channel should be 
removed from 4566bis if it isn't too late to do so.

I don't find section 5.2.1 to be an appropriate place for this kind of 
information.

	Thanks,
	Paul

> A data channel specific usage of a subprotocol attribute is expected to 
> be specified
> 
>     in the same document that registers the subprotocol's identifier for
> 
>     data channel usage.
> 
>          SDP attributes that are only defined for use at the
> 
>     dcsa usage level, SHALL use the dcsa usage level when registering the
> 
>     attribute.  If existing media attributes are used in a datachannel
> 
>     subprotocol specific way, then a new dcsa usage level
> 
>     MUST be defined for the existing media attribute.  Where the SDP
> 
>    attribute is applicable to a particular subprotocol/s this SHALL also
> 
>     be registered by indicating the applicable subprotocol identifiers
> 
>     (see 
> https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-34#section-8.5) 
> along with the dcsa usage level.
> 
> Roni Even
> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> 


From nobody Thu Apr 11 12:58:10 2019
Return-Path: 
X-Original-To: mmusic@ietf.org
Delivered-To: mmusic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7AFD1206DA; Thu, 11 Apr 2019 12:58:02 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Dan Romascanu via Datatracker 
To: 
Cc: ietf@ietf.org, draft-ietf-mmusic-rfc4566bis.all@ietf.org, mmusic@ietf.org,  dromasca@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Dan Romascanu 
Message-ID: <155501268276.14212.10440059790785652141@ietfa.amsl.com>
Date: Thu, 11 Apr 2019 12:58:02 -0700
Archived-At: 
Subject: [MMUSIC] Genart last call review of draft-ietf-mmusic-rfc4566bis-34
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Apr 2019 19:58:03 -0000

Reviewer: Dan Romascanu
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-mmusic-rfc4566bis-34
Reviewer: Dan Romascanu
Review Date: 2019-04-11
IETF LC End Date: 2019-04-12
IESG Telechat date: Not scheduled for a telechat

Summary:

This document is a comprehensive and carefully redacted revision of RFC 4566.
Section 10 describes the principal changes brought by this new version, result
of the implementation and deployment experience. The document is Ready.

Major issues:

Minor issues:

Nits/editorial comments:



From nobody Thu Apr 11 14:30:12 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2A0120220 for ; Thu, 11 Apr 2019 14:30:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_GQd4T6VH5d for ; Thu, 11 Apr 2019 14:30:09 -0700 (PDT)
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29089120086 for ; Thu, 11 Apr 2019 14:30:09 -0700 (PDT)
Received: by mail-pl1-x630.google.com with SMTP id b3so4009141plr.7 for ; Thu, 11 Apr 2019 14:30:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iXGmVHzjyqGQh1iBUFrSfTnsDjN1uCMDVUlGaYFsz4s=; b=XLdJcfZZfGkKP7eXGLXEZsFvQaKAAXheWCuVXJqz4PCX/gc95R4ggMp2QfNPrESWgf UQPwjKSDp4Zq2OISTkKnhC1Fv55qSuagCs071nO5Mla8Yuw2i31sM+JwE2bj8JFrcv/X VmT8eXWYjBjQcIaEzWxSiGNF07587GuBa6gp71s9BYsjR9NWjpQZEwYnFBY5CV5UKct6 m5P++Na4gELyIsDWmv8nnvwb0Tzpmmy/5X4zu9xDzjZKJx/dUwvUjhS9AQ7YPeSEnQm/ cf64veetVsSy0bvP6hlKtyCFnx5jhXZJnlqKC1SQ3YQ+lP4Toj3mKCL+DHwsET5H0kKT I+ew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iXGmVHzjyqGQh1iBUFrSfTnsDjN1uCMDVUlGaYFsz4s=; b=iTgCRnlPxbYPGmQui1uiBnqFGkZZxjKo1nvOEqDOblunf3Fpe7k2EW30NTgs2avlSf bzG540v5FqWv68G2W1l9IVIOjd3+6+M36TgkXBqsiI93Z4QoRyBxMWt30goVZMxo/XlI iyf+fJgRqUSFW4pIT4iznDX2rsMpfdCzPm23AK+/MQKJVR1k4+RnptatYruDjFhWhXyx msFgHs+EKDYvl1+yz3LFJxRPJl/i0YRwNuAdbv+7dfP2Nv6RaLZtlWtm9yW+0yfdiN1P lMK2KHPaxSkb+Lw7cTUUweyy9mG1W6Cv78uBjypTJqqvLvxE9wHlkYnvzlQ/bU1ZlYD6 ucRg==
X-Gm-Message-State: APjAAAUpCtYc6GU5ii5kYw5Ng6DFSVBTzn5I/nH3XTyJu9PI2MwKVO2d CCfyGJaiQoXJAkFnBVG2y0tKa3s3/WU=
X-Google-Smtp-Source: APXvYqxiW2bSh5TcmAht/XeEQUNa+HlSa+1/oCC3Hfy6Z9pUUY6WCAF9l1y/NqcBc3QHV4QWlU9n+g==
X-Received: by 2002:a17:902:7885:: with SMTP id q5mr53563616pll.12.1555018208386;  Thu, 11 Apr 2019 14:30:08 -0700 (PDT)
Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com. [209.85.215.176]) by smtp.gmail.com with ESMTPSA id q10sm48476333pgh.93.2019.04.11.14.30.07 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Apr 2019 14:30:07 -0700 (PDT)
Received: by mail-pg1-f176.google.com with SMTP id e6so4117473pgc.4 for ; Thu, 11 Apr 2019 14:30:07 -0700 (PDT)
X-Received: by 2002:a62:4602:: with SMTP id t2mr52083307pfa.26.1555018207256;  Thu, 11 Apr 2019 14:30:07 -0700 (PDT)
MIME-Version: 1.0
References:    <3DD3D8D6-9B13-4F9D-80DD-F89B69240708@ericsson.com>   <98CF630B-5CCD-4CE4-84B4-81A4C53979DC@ericsson.com>
In-Reply-To: <98CF630B-5CCD-4CE4-84B4-81A4C53979DC@ericsson.com>
From: Roman Shpount 
Date: Thu, 11 Apr 2019 17:29:53 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Christer Holmberg 
Cc: Suhas Nandakumar , mmusic WG ,  Flemming Andreasen 
Content-Type: multipart/alternative; boundary="000000000000dcec84058647e3b1"
Archived-At: 
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp
X-BeenThere: mmusic@ietf.org
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: Thu, 11 Apr 2019 21:30:11 -0000

--000000000000dcec84058647e3b1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 11, 2019 at 5:10 AM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> I **think** I agree with Suhas that the FQDN handling should be a
> separate draft =E2=80=93 a generic ICE draft produced by the ICE WG. ice-=
sip-sdp
> would then specify how it is implemented in SDP (separate a=3Dcandidiate
> lines etc).
>
>
>
> Perhaps it could be combined with the mDNS draft?
>
>
>
I am not sure if this belongs to a new draft or mDNS draft. We can decide
this later. What we need to decide now comes down to two choices:

a. Say that FQND is allowed in candidate connection-address but these
candidate lines are skipped. Handling of FQDN lines is defined in the
future specification.

b. Figure out how FQDN is handled. Options written up so far imply either
selecting one resolution result in random or requiring the FQDN resolves to
a single address. I think former is broken and later does not exist in real
life. I would not like this draft to be released with either option. I
think adding address type to candidate brings candidate line connection
address definition in line with SDP c=3D line specification and should work=
,
but someone needs to review this. I do not think this will require more
then 2-3 extra paragraphs in the document which I am willing to write. I
agree this is scope creep but FQDN were included in RFC 5245 so people
expect them to be supported by this draft as well.

At the end, this is up to the group to decide. I just need something I can
implement. If option a makes people unhappy then we will need to find
minimal viable option b.

Regards,
_____________
Roman Shpount

--000000000000dcec84058647e3b1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Thu, Apr 11, 2019 at 5:10 AM C=
hrister Holmberg <chri=
ster.holmberg@ericsson.com> wrote:











I *think* I agree with Suhas that the FQDN ha=
ndling should be a separate draft =E2=80=93 a generic ICE draft produced by=
 the ICE WG. ice-sip-sdp would then specify how it is implemented in SDP (s=
eparate a=3Dcandidiate lines
 etc).


=C2=A0


Perhaps it could be combined wi=
th the mDNS draft?




I am not sure if this belongs to a new draft or mDNS draft. We can decide =
this later. What we need to decide now comes down to two choices:

a. Say that FQND is allowed in candidate connection-address=
 but these candidate lines are skipped. Handling of FQDN lines is defined i=
n the future specification.

b. Figure out how FQDN=
 is handled. Options written up so far imply either selecting one resolutio=
n result in random or requiring the FQDN resolves to a single address. I th=
ink former is broken and later does not exist in real life. I would not lik=
e this draft to be released with either option. I think adding address type=
 to candidate brings candidate line connection address definition in line w=
ith SDP c=3D line specification and should work, but someone needs to revie=
w this. I do not think this will require more then 2-3 extra paragraphs in =
the document which I am willing to write. I agree this is scope creep but F=
QDN were included in RFC 5245 so people expect them to be supported by this=
 draft as well.

At the end, this is up to the grou=
p to decide. I just need something I can implement. If option a makes peopl=
e unhappy then we will need to find minimal viable option b.

=

Regards,
_____________
Roman Shpount
=C2=A0


--000000000000dcec84058647e3b1--


From nobody Thu Apr 11 14:48:42 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581621203D5 for ; Thu, 11 Apr 2019 14:48:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWhLtD4lpB9d for ; Thu, 11 Apr 2019 14:48:39 -0700 (PDT)
Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E13C11203F3 for ; Thu, 11 Apr 2019 14:48:38 -0700 (PDT)
Received: by mail-pg1-x531.google.com with SMTP id q1so4111978pgv.13 for ; Thu, 11 Apr 2019 14:48:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=D+MfPfgKbN/TLDh4udTi099/tobHwvuH/LdAzl+Q1EU=; b=hbxlushT5pD/Mfxz1gzPH83vfG+ubiv0Mr+L3lhylXBL+b1uzC3ww7nomw9S3SKVsM NoN3GXuhGsQfKybhITJLfl2G6peiNBRdaKEKof6DS8g47a08M3RP8PblBtpehjEM4Iil IIJCyNBB4tdcXTqAMs1ccpV210xOUNH+O5y+DewmarBjsTUgWSWW0UB3KnqOK5NLxQOa BErU9oW2lxW9RZfeqr0+YZtdfxh3P5OZvAnSKFvFXW1jJ+cZD0DdZzLN7eYLybMRbEAq dU2Jpp+Hc7JUSwvG9+Xp6wU34VViDn+UgdGNAD1uqphy2P9TL9jQUm7dRglHyE5nWbaY Gf1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=D+MfPfgKbN/TLDh4udTi099/tobHwvuH/LdAzl+Q1EU=; b=LcdyuK99m/upog4Zw9ueP9q7EzdqmaVfko28LT3fbohmcyBubYx3qnd25YKyW235Oe Y19+LWHBjm4ErP/m2VMgZZhSxXRM0Qm7p33Qr2Qh7gpo3QEnfIOjQhv9qCbuXSJFFlH/ fLwJNjLsG+LhSTtd50a5uduqn2+hni7sF5nliop6vHcnMBmwNdketOKJzF37Zpv/Qm1k 3DRkRiKvOy7/NYLlYVrPgPAJFUGYdstMAseiSbNNlzyWs4iVXschF/5ADX474WI/g9np JBNUMslssPad/SOiLP5rwehyD3Uaq9UsLKtH/HQgf894D0ZuyE3p7w6eqloVK3JdSeE5 nuLw==
X-Gm-Message-State: APjAAAUmcuEC3Sub4m0RccxAxtixKbRjLqHxuVcqPtBwNOIgaX3798on zqdUaDD2MLA2duVgWh5Ex+wqLoKud6c=
X-Google-Smtp-Source: APXvYqzB9HERpwgmm/y6+5IHGOfID+TCdh7+5kwNa3EXQXmCMQvcNV1ZinaEgXYU7zr6sLMclp85+A==
X-Received: by 2002:a63:6844:: with SMTP id d65mr50231722pgc.393.1555019318267;  Thu, 11 Apr 2019 14:48:38 -0700 (PDT)
Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com. [209.85.210.176]) by smtp.gmail.com with ESMTPSA id p20sm52469412pgh.83.2019.04.11.14.48.37 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Apr 2019 14:48:37 -0700 (PDT)
Received: by mail-pf1-f176.google.com with SMTP id 10so4079830pfo.5 for ; Thu, 11 Apr 2019 14:48:37 -0700 (PDT)
X-Received: by 2002:a63:4241:: with SMTP id p62mr49568256pga.379.1555019316958;  Thu, 11 Apr 2019 14:48:36 -0700 (PDT)
MIME-Version: 1.0
References:    <3DD3D8D6-9B13-4F9D-80DD-F89B69240708@ericsson.com>  
In-Reply-To: 
From: Roman Shpount 
Date: Thu, 11 Apr 2019 17:48:23 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Christer Holmberg 
Cc: Suhas Nandakumar , mmusic WG ,  Flemming Andreasen 
Content-Type: multipart/alternative; boundary="000000000000019f010586482686"
Archived-At: 
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp
X-BeenThere: mmusic@ietf.org
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: Thu, 11 Apr 2019 21:48:41 -0000

--000000000000019f010586482686
Content-Type: text/plain; charset="UTF-8"

On Thu, Apr 11, 2019 at 4:05 AM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> > Add a candidate extension which specifies candidate address type,
> something like addrtype which can be set to
> > "inipv4" or "inipv6". If IP address is used and it does not match the
> addrtype candidate extension, this candidate is
> > ignored. When FQDN is used, it is resolved using A DNS request when
> addrtype is inipv4 or not present and using
> > AAAA DNS request when addrtype is inipv6. Address family in c= line,
> when FQDN is a default candidate must be
> > IN IPV4 if addrtype is inipv4 or not present, and must be IP IPV6 if
> addrtype is inipv6
> >
> > Example:
> > a=candidate:2319437384 1 udp 2122260223
> 8a2fd7b5-41d5-4c15-ad83-d33a0d66a75a.local 60454 typ host inipv4
> > a=candidate:2319437384 1 udp 2122260223
> 8a2fd7b5-41d5-4c15-ad83-d33a0d66a78b.local 60454 typ host inipv6
> >
> > This keeps each candidate line to one address and works in cases when
> FQDN resolves to one IPv4 and one IPv6 address
> > due to something like DNS64.
>
> So, if I understand you correctly, you are suggesting that the one
> providing the FQDN candidate splits it into two separate candidates (two
> a=candidate lines when SDP is used), and the remote peer will process them
> as two separate candidates, but if DNS returns both an IPv4 and IPv6
> address the peer will only use the IP version indicated by the address type
> ("inipv4" or "inipv6").
>

I am suggesting that:

If agent is dual stack, it can include the same FQDN in two candidate lines
with different address types, effectively creating two candidates. If agent
is single stack or if FQDN is supposed to resolve to an address of specific
address family (different FQDN for IPv4 and IPv6), agent will create a
single candidate line with this FQDN and address family.

On the receiving side, if candidate includes addrtype inipv4, an A DNS
request is sent to resolve FQDN. If more then one result is returned, this
candidate is ignored. If single result is returned, it is an IPv4
candidate. If candidate includes addrtype inipv6, an AAAA DNS request is
sent to resolve FQDN.  If more then one result is returned, this candidate
is ignored. If single result is returned, it is an IPv6 candidate.

Corrected Example for a dual stack agent (note different foundation,
priority and port for two candidates with the same FQDN ):

 a=candidate:2 1 udp 2129033471 alice.comany.biz 60460 typ host addrype
inipv4
 a=candidate:1 1 udp 2129289471 alice.comany. biz 60454 typ host
addrype inipv6

Regards,
_____________
Roman Shpount

--000000000000019f010586482686
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Thu, Apr 11, 2019 at 4:05 AM C=
hrister Holmberg <chri=
ster.holmberg@ericsson.com> wrote:
> Add=
 a candidate extension which specifies candidate address type, something li=
ke addrtype which can be set to 

> "inipv4" or "inipv6". If IP address is used and it=
 does not match the addrtype candidate extension, this candidate is 

> ignored. When FQDN is used, it is resolved using A DNS request when ad=
drtype is inipv4 or not present and using 

> AAAA DNS request when addrtype is inipv6. Address family in c=3D line,=
 when FQDN is a default candidate must be 

> IN IPV4 if addrtype is inipv4 or not present, and must be IP IPV6 if a=
ddrtype is inipv6=C2=A0

>

> Example:

> a=3Dcandidate:2319437384 1 udp 2122260223 8a2fd7b5-41d5-4c15-ad83-d33a=
0d66a75a.local 60454 typ host=C2=A0inipv4

> a=3Dcandidate:2319437384 1 udp 2122260223 8a2fd7b5-41d5-4c15-ad83-d33a=
0d66a78b.local 60454 typ host=C2=A0inipv6=C2=A0=C2=A0

>

> This keeps each candidate line to one address and works in cases when =
FQDN resolves to one IPv4 and one IPv6 address 

> due to something like DNS64. 



So, if I understand you correctly, you are suggesting that the one providin=
g the FQDN candidate splits it into two separate candidates (two a=3Dcandid=
ate lines when SDP is used), and the remote peer will process them as two s=
eparate candidates, but if DNS returns both an IPv4 and IPv6 address the pe=
er will only use the IP version indicated by the address type ("inipv4=
" or "inipv6").

I am sug=
gesting that:
=C2=A0
If agent is dual stack, it can=
 include the same FQDN in two candidate lines with different address types,=
 effectively creating two candidates. If agent is single stack or if FQDN i=
s supposed to resolve to an address of specific address family (different F=
QDN for IPv4 and IPv6), agent will create a single candidate line with this=
 FQDN and address family.=C2=A0

On the receiving s=
ide, if candidate includes addrtype inipv4, an A DNS request is sent to res=
olve FQDN. If more then one result is returned, this candidate is ignored. =
If single result is returned, it is an IPv4 candidate. If candidate include=
s addrtype inipv6, an AAAA DNS request is sent to resolve FQDN.=C2=A0 If mo=
re then one result is returned, this candidate is ignored. If single result=
 is returned, it is an IPv6 candidate.

Corrected E=
xample for a dual stack agent (note different foundation, priority and port=
 for two candidates with the same FQDN ):

=C2=A0a=
=3Dcandidate:2 1 udp=C2=A02129033471=C2=A0alice.comany=
.biz 60460 typ host addrype inipv4
=C2=A0a=3Dcandidate:1 =
1 udp=C2=A02129289471<=
/span>=C2=A0alice.comany.

biz=C2=A060454 typ host addrype=C2=A0inipv6=C2=A0 =C2=A0=C2=A0

Regards,
_____________
Roman Shpount
=C2=A0


--000000000000019f010586482686--


From nobody Fri Apr 12 01:59:57 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 766F7120003; Fri, 12 Apr 2019 01:59:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level: 
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ef2oyF5HQuRD; Fri, 12 Apr 2019 01:59:52 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130084.outbound.protection.outlook.com [40.107.13.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E60121201DD; Fri, 12 Apr 2019 01:59:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fUQ7Fy9b9XUiNUNQdF3qLSwt4ep2eZwTE5PuVRdRIDA=; b=SJVr5InSZoNdQRXOgsK171ZOTG3lA5fcV+/BvkXGqlZkn4Xc23GNHwJpQwRKSb6YXZ1dhtfa9C6GTl3BLm3Lyfe57YGpB4DmSidDs4OA9MOIL+dSN7RxBCV2GSSNC1KXrC3CxIRLchaYVfHWu2ZulNS2+kteHs14f+aL3XfGmec=
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2268.eurprd07.prod.outlook.com (10.168.36.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.11; Fri, 12 Apr 2019 08:59:48 +0000
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::107c:5f27:2ef:8505]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::107c:5f27:2ef:8505%5]) with mapi id 15.20.1792.009; Fri, 12 Apr 2019 08:59:48 +0000
From: Magnus Westerlund 
To: "Roni Even (A)" , "ietf@ietf.org" 
CC: "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-rfc4566bis@ietf.org" , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] Last Call:  (SDP: Session Description Protocol) to Proposed Standard
Thread-Index: AQHU4L35G0bkeH37hEyuzO/M/jMwpA==
Date: Fri, 12 Apr 2019 08:59:48 +0000
Message-ID: 
References: <155326592304.23020.8256337045285295468.idtracker@ietfa.amsl.com>  <6E58094ECC8D8344914996DAD28F1CCD18CDB636@dggemm526-mbx.china.huawei.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; 
x-originating-ip: [192.176.1.87]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3f54c6a6-9e10-4675-c313-08d6bf2537c3
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2268; 
x-ms-traffictypediagnostic: HE1PR0701MB2268:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0005B05917
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(396003)(136003)(346002)(366004)(199004)(189003)(9686003)(7696005)(25786009)(8936002)(256004)(106356001)(229853002)(53546011)(33656002)(606006)(68736007)(186003)(6246003)(7736002)(105586002)(446003)(99286004)(2501003)(476003)(76176011)(478600001)(14444005)(966005)(6506007)(54906003)(44832011)(790700001)(6116002)(8676002)(74316002)(66066001)(14454004)(6306002)(3846002)(52536014)(53936002)(4326008)(71200400001)(2906002)(71190400001)(26005)(110136005)(55016002)(486006)(5660300002)(316002)(86362001)(97736004)(81156014)(81166006)(54896002)(236005)(102836004)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2268; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: OO1stpyMTmNlT1XQp99ZNvPI4X7W5wCXLCKWSRZutySXIYCiYMPGTIn4FpYjZ8KDbbS2VUvPqMoCZi0nz1Lfzaq0+29g2O2zikHIZfJXP6Jb2Vc6F20cR6+ridDcsQ1KoDqoKPRv+AHzZ8pF682/bUSQZrSMWi5/7CrZu1ddod4YewisCgypgJMJgA5VOuM8llJC1J7f7KekZv5JHZ2CtydZ5j9cHIHhqc/UTdGE5QU+i2ybCMm03MYDGg5zdcn/1BJlJ048T7tT6O8MOqskv2n0KAp866gAEe+E0KE2o7m31a4T1hwst863gYgPL2MAxTnzITmh4M4EA1NvlSzNcvgC+rxovcaJq/cDUVO5OeT0uc1D4K/I0nUKSboZN8jx+GF6o+CQjqNxSIV6yzAnZzcpcw+yCYMj510W7R3vz+g=
Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB2522339DBB98ACE3399DB7B295280HE1PR0701MB2522_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3f54c6a6-9e10-4675-c313-08d6bf2537c3
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 08:59:48.8684 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2268
Archived-At: 
Subject: Re: [MMUSIC] Last Call:  (SDP: Session Description Protocol) to Proposed Standard
X-BeenThere: mmusic@ietf.org
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: Fri, 12 Apr 2019 08:59:56 -0000

--_000_HE1PR0701MB2522339DBB98ACE3399DB7B295280HE1PR0701MB2522_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

To be clear, I am not proposing that any existing attribute would be forced=
 to suddenly accept UTF-8 strings with no charset restriction. Simply that =
new attribute's values can be defined to be UTF-8 in general. I think the i=
mportant distinction here is that a parser must be ready to accept any UTF-=
8 character as the sender can't know if a particular charset limitation app=
lies to a specific consumer. However, in form I don't see a problem of the =
SDP itself informing the consumer that there is a charset limitation applie=
d in this document.

My interpretation of the current situation is that it we hesitate to use UT=
F-8 fields due to the uncertainty in the requirements on consumers of SDP.

Cheers

Magnus Westerlund
(As Individual)


On 2019-04-11 12:05, Roni Even (A) wrote:
Hi Magnus,
I think it will affect the IANA registries where values may be shared with =
non SDP attribute. For example the sub-protocol in the IANA WebSocket Subpr=
otocol name registry

Roni Even



From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Magnus Westerlun=
d
Sent: Thursday, April 11, 2019 11:14 AM
To: ietf@ietf.org
Cc: mmusic-chairs@ietf.org; draft-ietf-mmusi=
c-rfc4566bis@ietf.org; mmusic=
@ietf.org
Subject: Re: [MMUSIC] Last Call:  (SDP=
: Session Description Protocol) to Proposed Standard

MMUSIC WG, Document Editors

In the processing of draft-ietf-mmusic-data-channel-sdpneg-25 an interestin=
g question arose regarding text strings in SDP attribute values.

Currently the document says:

4.5.  Internationalization



   The SDP specification recommends the use of the ISO 10646 character

   set in the UTF-8 encoding [RFC3629] to allow many different languages

   to be represented.  However, to assist in compact representations,

   SDP also allows other character sets such as ISO 8859-1 to be used

   when desired.  Internationalization only applies to free-text sub-

   fields (session name and background information), and not to SDP as a

   whole.



If one like to include UTF-8 field for attributes it would be good if

the requirement would be clear going forward that there is an expectancy

that at least parser can process any UTF-8 strings that may occur in any

fields.



That would allow future SDP field values to use UTF-8 strings without risks

and simplify processing. Like in the case of the data channel SDP mapping

where the extra step of encoding lable characters not visually safe as esca=
ped

characters could be avoided.



Does anyone have input if making such a change would have significant impac=
t on

the interoperability?



Cheers



Magnus



On 2019-03-22 15:46, The IESG wrote:



The IESG has received a request from the Multiparty Multimedia Session

Control WG (mmusic) to consider the following document: - 'SDP: Session

Description Protocol'

   as Proposed Standard



The IESG plans to make a decision in the next few weeks, and solicits final

comments on this action. Please send substantive comments to the

ietf@ietf.org mailing lists by 2019-04-12. Exceptiona=
lly, comments may be

sent to iesg@ietf.org instead. In either case, please=
 retain the beginning of

the Subject line to allow automated sorting.



Abstract





   This memo defines the Session Description Protocol (SDP).  SDP is

   intended for describing multimedia sessions for the purposes of

   session announcement, session invitation, and other forms of

   multimedia session initiation.  This document obsoletes RFC 4566.









The file can be obtained via

https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/



IESG discussion can be tracked via

https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/ballot/





No IPR declarations have been submitted directly on this I-D.









_______________________________________________

mmusic mailing list

mmusic@ietf.org

https://www.ietf.org/mailman/listinfo/mmusic





--



Magnus Westerlund



----------------------------------------------------------------------

Network Architecture & Protocols, Ericsson Research

----------------------------------------------------------------------

Ericsson AB                 | Phone  +46 10 7148287

Torshamnsgatan 23           | Mobile +46 73 0949079

SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com

----------------------------------------------------------------------


--

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

--_000_HE1PR0701MB2522339DBB98ACE3399DB7B295280HE1PR0701MB2522_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Hi, 









To be clear, I am not proposing that any exi=
sting attribute would be forced to suddenly accept UTF-8 strings with no ch=
arset restriction. Simply that new attribute's values can be defined to be =
UTF-8 in general. I think the important
 distinction here is that a parser must be ready to accept any UTF-8 charac=
ter as the sender can't know if a particular charset limitation applies to =
a specific consumer. However, in form I don't see a problem of the SDP itse=
lf informing the consumer that there
 is a charset limitation applied in this document. 









My interpretation of the current situation i=
s that it we hesitate to use UTF-8 fields due to the uncertainty in the req=
uirements on consumers of SDP.










Cheers







Magnus Westerlund


(As Individual)












On 2019-04-11 12:05, Roni Even (A) wrote:









Hi Magnus,


I think it will affect th=
e IANA registries where values may be shared with non SDP attribute. For ex=
ample the sub-protocol in the IANA WebSocket Subprotocol
 name registry 


 <=
/p>

Roni Even


 <=
/p>

 <=
/p>

 <=
/p>





From: mmusic [mailto:mmusic-bounces@ietf.org]
On Behalf Of Magnus Westerlund

Sent: Thursday, April 11, 2019 11:14 AM

To: ietf@ietf.org

Cc: 
mmusic-chairs@ietf.org; 
draft-ietf-mmusic-rfc4566bis@ietf.org; 
mmusic@ietf.org

Subject: Re: [MMUSIC] Last Call: <draft-ietf-mmusic-rfc4566bis-34=
.txt> (SDP: Session Description Protocol) to Proposed Standard






 




MMUSIC WG, Document Editors






 






In the processing of draft-ietf-mmusic-data-channel-=
sdpneg-25 an interesting question arose regarding text strings in SDP attri=
bute values.







 






Currently the document says: 






4.5.  Internationalization

 


   The SDP specification recommends the use of the ISO 10646=
 character


   set in the UTF-8 encoding [RFC3629] to allow many differe=
nt languages


   to be represented.  However, to assist in compact re=
presentations,


   SDP also allows other character sets such as ISO 8859-1 t=
o be used


   when desired.  Internationalization only applies to =
free-text sub-


   fields (session name and background information), and not=
 to SDP as a


   whole.


 


If one like to include UTF-8 field for attributes it would be good if =



the requirement would be clear going forward that there is an expectan=
cy 


that at least parser can process any UTF-8 strings that may occur in a=
ny 


fields. 


 


That would allow future SDP field values to use UTF-8 strings without =
risks


and simplify processing. Like in the case of the data channel SDP mapp=
ing 


where the extra step of encoding lable characters not visually safe as=
 escaped 


characters could be avoided. 


 


Does anyone have input if making such a change would have significant =
impact on 


the interoperability? 


 


Cheers


 


Magnus


 






 






On 2019-03-22 15:46, The IESG wrote:






 


The IESG has received a request from the Multiparty Multimedia Session=



Control WG (mmusic) to consider the following document: - 'SDP: Sessio=
n


Description Protocol'


  <draft-ietf-mmusic-rfc4566bis-34.txt> as Proposed Standar=
d


 


The IESG plans to make a decision in the next few weeks, and solicits =
final


comments on this action. Please send substantive comments to the<=
/o:p>


ietf@ietf.or=
g mailing lists by 2019-04-12. Exceptionally, comments may be


sent to iesg=
@ietf.org instead. In either case, please retain the beginning of<=
/o:p>


the Subject line to allow automated sorting.


 


Abstract


 


 


   This memo defines the Session Description Protocol (SDP).=
  SDP is


   intended for describing multimedia sessions for the purpo=
ses of


   session announcement, session invitation, and other forms=
 of


   multimedia session initiation.  This document obsole=
tes RFC 4566.


 


 


 


 


The file can be obtained via


https://datatracker.ietf.org/doc/draft-ietf-m=
music-rfc4566bis/


 


IESG discussion can be tracked via


https://datatracker.ietf.org/doc/draft=
-ietf-mmusic-rfc4566bis/ballot/


 


 


No IPR declarations have been submitted directly on this I-D.


 


 


 


 


_______________________________________________


mmusic mailing list


mmusic@iet=
f.org


https://www.ietf.org/mailman/listinfo/mmusic

 




 


-- 


 


Magnus Westerlund 


 


----------------------------------------------------------------------=



Network Architecture & Protocols, Ericsson Research

----------------------------------------------------------------------=



Ericsson AB          =
;       | Phone  +46 10 7148287=



Torshamnsgatan 23         =
;  | Mobile +46 73 0949079


SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com


----------------------------------------------------------------------=












-- =0A=
=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.=
com=0A=
----------------------------------------------------------------------



--_000_HE1PR0701MB2522339DBB98ACE3399DB7B295280HE1PR0701MB2522_--


From nobody Fri Apr 12 02:07:01 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC00120203; Fri, 12 Apr 2019 02:06:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yH5AhxDoVRmi; Fri, 12 Apr 2019 02:06:47 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130089.outbound.protection.outlook.com [40.107.13.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6593A120221; Fri, 12 Apr 2019 02:06:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ah3hr289/ZwwwoUbcHYgeYRvsiajpDn0PoDDA774njo=; b=b5qZiHe9Ktv5jWdGPSgnYvUrCMJvOVuJ9T5j6V8UqibCLLhGibw9tHzZfUKa4Y2W3cANsm7y/vmEUvjRY80Y2y3K7YjC/ELa+WJqhJymeacJqQ6OOcU5r91SX5kUTwBLJ3FlxxpBCpg1YxYyqXPi2NU4IWbuwNvv7xybKnkToPs=
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2123.eurprd07.prod.outlook.com (10.168.36.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.8; Fri, 12 Apr 2019 09:06:44 +0000
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::107c:5f27:2ef:8505]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::107c:5f27:2ef:8505%5]) with mapi id 15.20.1792.009; Fri, 12 Apr 2019 09:06:44 +0000
From: Magnus Westerlund 
To: Adam Roach , The IESG 
CC: "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-data-channel-sdpneg@ietf.org" , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)
Thread-Index: AQHU66fNA40h4UsP7kq3a/Vv5QT6wQ==
Date: Fri, 12 Apr 2019 09:06:43 +0000
Message-ID: 
References: <155446588097.13196.6373243259627185094.idtracker@ietfa.amsl.com> <1afcb116-36cb-be51-81ac-e78fc52c9255@nostrum.com>      <46d43903-0da2-9d2c-158e-5ec9b0fb11ca@nostrum.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; 
x-originating-ip: [192.176.1.87]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 543ad11a-392d-4917-897c-08d6bf262f2b
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2123; 
x-ms-traffictypediagnostic: HE1PR0701MB2123:
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0005B05917
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(39860400002)(376002)(396003)(346002)(199004)(189003)(26005)(478600001)(86362001)(305945005)(105586002)(55016002)(6436002)(74316002)(6246003)(53936002)(9686003)(71200400001)(71190400001)(256004)(229853002)(2906002)(25786009)(44832011)(6116002)(106356001)(99286004)(68736007)(5660300002)(97736004)(3846002)(6506007)(14454004)(7696005)(66066001)(81166006)(8676002)(81156014)(7736002)(8936002)(476003)(33656002)(486006)(52536014)(76176011)(186003)(54906003)(110136005)(102836004)(4326008)(446003)(316002)(53546011)(93886005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2123; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: nGuliIQKVbG3Nu99rfwcFHppN0W1khxFitw3g2sIw/yCahU6KY2XiE2VtlNJLGK+j4/BGXOa5ilSMOB96NOqlMbWQh+SddHuSeLjeFCMzkUq7tT4vaJ3jdWA16bucZPJYQJWg++QPkwPGMJXnt4HuR7vroF2a6hPdwGVdqfsIZYe2YMSR8TPlv7hdwhU20OxezPJO046HjFXStx/hFRTxralyqZk23aW8HBtNVa9yfhH+EGMrWvhGrZKT/+FYue9lJz5gjO+rNDj55OjhmH+z0dKanMJ4KQg3pYaCCNv1jbU3Y9rbuBqpq58Xvm1+fxrFwjmKcXXr+JbBb2mr1yd4hbcYH65F7UahaeLezFut0pzrGhwCCxPD4g0/yVHPTDSMjW0MmGQWJVevY5YQj/zdNw9PZFbAoZN67uaPTI01ng=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 543ad11a-392d-4917-897c-08d6bf262f2b
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 09:06:43.9197 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2123
Archived-At: 
Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)
X-BeenThere: mmusic@ietf.org
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: Fri, 12 Apr 2019 09:06:55 -0000

On 2019-04-11 17:58, Adam Roach wrote:=0A=
> On 4/11/19 2:57 AM, Magnus Westerlund wrote:=0A=
>> For 4566bis I hope the WG could discuss this before the IETF last call=
=0A=
>> ends. It will run for another 2 week isn't it so there is time for that.=
=0A=
>=0A=
> Well, technically, it ends tomorrow, but you are correct that we don't =
=0A=
> have a formal telechat until the 25th. I'm going to hold off creating a =
=0A=
> ballot until the conversation you just started in MMUSIC has time to =0A=
> conclude.=0A=
>=0A=
I have submitted an IETF last call comment as individual on the issue. I=0A=
managed to missinterpret the number of days in IETF LC as the days letf,=0A=
sorry about that if it caused any confusion.=0A=
=0A=
I would also note that the next IESG telechat is actually the 2nd of May=0A=
due to the IESG retreat.=0A=
=0A=
Cheers=0A=
=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A=
----------------------------------------------------------------------=0A=
=0A=


From nobody Fri Apr 12 02:25:53 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62BEC12018D for ; Fri, 12 Apr 2019 02:25:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uuNrcYPHevq for ; Fri, 12 Apr 2019 02:25:50 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80081.outbound.protection.outlook.com [40.107.8.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2031F12013C for ; Fri, 12 Apr 2019 02:25:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=V+YLoznZHIZ1N7et0ygQg5QiI75ZzdbJwkBw4twy130=; b=AYJmz3dalIoc6UsinpdxINYHR5BmbKT0csytGcXHOg4W3kEhLAgjMajk0H0feeWUnIS8QJ0OiWvZKCiIceUX84+4qOqdyToZEZ2bPcenDKGq6rDHE0OXu0tXqLWxHy6mSe9YKCYeB14OXZmcnq5tdNOUM0L7pBJ72pk2MmytYkY=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4249.eurprd07.prod.outlook.com (20.176.166.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.9; Fri, 12 Apr 2019 09:25:45 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9%5]) with mapi id 15.20.1792.007; Fri, 12 Apr 2019 09:25:45 +0000
From: Christer Holmberg 
To: Roman Shpount 
CC: Suhas Nandakumar , mmusic WG , Flemming Andreasen 
Thread-Topic: [MMUSIC] FQDN support in ice-sip-sdp
Thread-Index: AQHU6jzz/50YAJx2kEqY4siuQ2NZYqY0606AgADVT4CAAEAVAP//1AeAgAED24CAALOEgIAA9SEA
Date: Fri, 12 Apr 2019 09:25:45 +0000
Message-ID: <225C8798-1FE6-4D80-BBA0-5D1A6BB4EA94@ericsson.com>
References:    <3DD3D8D6-9B13-4F9D-80DD-F89B69240708@ericsson.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.16.1.190220
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-originating-ip: [89.166.49.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e1d77a38-8557-406c-4142-08d6bf28d7a6
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB4249; 
x-ms-traffictypediagnostic: HE1PR07MB4249:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0005B05917
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(366004)(136003)(346002)(376002)(209900001)(199004)(189003)(71200400001)(316002)(106356001)(71190400001)(25786009)(58126008)(54906003)(6486002)(2906002)(86362001)(105586002)(3846002)(229853002)(966005)(6916009)(99286004)(6116002)(83716004)(7736002)(305945005)(81166006)(66066001)(4326008)(478600001)(486006)(2616005)(476003)(33656002)(53386004)(587094005)(76176011)(8676002)(14454004)(5660300002)(93886005)(44832011)(36756003)(8936002)(81156014)(82746002)(14444005)(256004)(68736007)(186003)(6506007)(6306002)(102836004)(26005)(6512007)(97736004)(53936002)(446003)(11346002)(6246003)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4249; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: MUp07/nlAA76vMpGOH8MMZRhaxMwkFXowljiVvREOYoJZszUKLWA7TFCbKSdEX9jd+Cq1bgpNae5HmlvLBsrYWMT9J1x/cIqnZVVveIW4BdWsbrc45Q3+KClV49uqQLmXD3+a/nAv0t4wxuoMCu2N8fnHfTMisGw3bVVOjSWS+LsLyRFYwfjdqfa7DdWNjh9XKnQiX5yU59cQkq7D9HnQ3cQuAYa2RTxlwljHA1GimROHmy6KTBcBSdY7FC/rlIew43qiZnIyOAjJQB/m1Nv+vTeSHcC/QDYPvsiIVZDchREPmDrHu/3VR3dmRSAQAY2DmCeYmQDbSieSVA940uYxvHUdw+JIet/DCvDi6CwYD0PSHdICgk1UHL55CDebIi1EwoAn0guImZpXRtikZ+ytWjFSU8Zgb2CbYCASF6xukI=
Content-Type: text/plain; charset="utf-8"
Content-ID: <8A97FCC89BA71743B5C32EFD86ECCAE5@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e1d77a38-8557-406c-4142-08d6bf28d7a6
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 09:25:45.5296 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4249
Archived-At: 
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp
X-BeenThere: mmusic@ietf.org
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: Fri, 12 Apr 2019 09:25:52 -0000

SGksDQoNCj4+PiBBZGQgYSBjYW5kaWRhdGUgZXh0ZW5zaW9uIHdoaWNoIHNwZWNpZmllcyBjYW5k
aWRhdGUgYWRkcmVzcyB0eXBlLCBzb21ldGhpbmcgbGlrZSBhZGRydHlwZSB3aGljaCBjYW4gYmUg
c2V0IHRvIA0KPj4+ICJpbmlwdjQiIG9yICJpbmlwdjYiLiBJZiBJUCBhZGRyZXNzIGlzIHVzZWQg
YW5kIGl0IGRvZXMgbm90IG1hdGNoIHRoZSBhZGRydHlwZSBjYW5kaWRhdGUgZXh0ZW5zaW9uLCB0
aGlzIGNhbmRpZGF0ZSBpcyANCj4+PiBpZ25vcmVkLiBXaGVuIEZRRE4gaXMgdXNlZCwgaXQgaXMg
cmVzb2x2ZWQgdXNpbmcgQSBETlMgcmVxdWVzdCB3aGVuIGFkZHJ0eXBlIGlzIGluaXB2NCBvciBu
b3QgcHJlc2VudCBhbmQgdXNpbmcgDQo+Pj4gQUFBQSBETlMgcmVxdWVzdCB3aGVuIGFkZHJ0eXBl
IGlzIGluaXB2Ni4gQWRkcmVzcyBmYW1pbHkgaW4gYz0gbGluZSwgd2hlbiBGUUROIGlzIGEgZGVm
YXVsdCBjYW5kaWRhdGUgbXVzdCBiZSANCj4+PiBJTiBJUFY0IGlmIGFkZHJ0eXBlIGlzIGluaXB2
NCBvciBub3QgcHJlc2VudCwgYW5kIG11c3QgYmUgSVAgSVBWNiBpZiBhZGRydHlwZSBpcyBpbmlw
djbCoA0KPj4+DQo+Pj4gRXhhbXBsZToNCj4+PiBhPWNhbmRpZGF0ZToyMzE5NDM3Mzg0IDEgdWRw
IDIxMjIyNjAyMjMgOGEyZmQ3YjUtNDFkNS00YzE1LWFkODMtZDMzYTBkNjZhNzVhLmxvY2FsIDYw
NDU0IHR5cCBob3N0wqBpbmlwdjQNCj4+PiBhPWNhbmRpZGF0ZToyMzE5NDM3Mzg0IDEgdWRwIDIx
MjIyNjAyMjMgOGEyZmQ3YjUtNDFkNS00YzE1LWFkODMtZDMzYTBkNjZhNzhiLmxvY2FsIDYwNDU0
IHR5cCBob3N0wqBpbmlwdjbCoMKgDQo+Pj4NCj4+PiBUaGlzIGtlZXBzIGVhY2ggY2FuZGlkYXRl
IGxpbmUgdG8gb25lIGFkZHJlc3MgYW5kIHdvcmtzIGluIGNhc2VzIHdoZW4gRlFETiByZXNvbHZl
cyB0byBvbmUgSVB2NCBhbmQgb25lIElQdjYgYWRkcmVzcyANCj4+PiBkdWUgdG8gc29tZXRoaW5n
IGxpa2UgRE5TNjQuIA0KPj4NCj4+IFNvLCBpZiBJIHVuZGVyc3RhbmQgeW91IGNvcnJlY3RseSwg
eW91IGFyZSBzdWdnZXN0aW5nIHRoYXQgdGhlIG9uZSBwcm92aWRpbmcgdGhlIEZRRE4gY2FuZGlk
YXRlIHNwbGl0cyBpdCBpbnRvIHR3byBzZXBhcmF0ZSBjYW5kaWRhdGVzICh0d28gYT1jYW5kaWRh
dGUgbGluZXMgd2hlbiBTRFAgaXMgdXNlZCksIGFuZCANCj4+IHRoZSByZW1vdGUgcGVlciB3aWxs
IHByb2Nlc3MgdGhlbSBhcyB0d28gc2VwYXJhdGUgY2FuZGlkYXRlcywgYnV0IGlmIEROUyByZXR1
cm5zIGJvdGggYW4gSVB2NCBhbmQgSVB2NiBhZGRyZXNzIHRoZSBwZWVyIHdpbGwgb25seSB1c2Ug
dGhlIElQIHZlcnNpb24gaW5kaWNhdGVkIGJ5IHRoZSANCj4+IGFkZHJlc3MgdHlwZSAoImluaXB2
NCIgb3IgImluaXB2NiIpLg0KPg0KPiBJIGFtIHN1Z2dlc3RpbmcgdGhhdDoNCj7CoA0KPiBJZiBh
Z2VudCBpcyBkdWFsIHN0YWNrLCBpdCBjYW4gaW5jbHVkZSB0aGUgc2FtZSBGUUROIGluIHR3byBj
YW5kaWRhdGUgbGluZXMgd2l0aCBkaWZmZXJlbnQgYWRkcmVzcyB0eXBlcywgZWZmZWN0aXZlbHkg
Y3JlYXRpbmcgdHdvIGNhbmRpZGF0ZXMuDQoNCkNvcnJlY3QsIHRoYXQncyB3aGF0IEkgbWVhbnQg
YnkgInNwbGl0dGluZyB0aGUgY2FuZGlkYXRlIi4NCg0KPiBJZiBhZ2VudCBpcyBzaW5nbGUgc3Rh
Y2sgb3IgaWYgRlFETiBpcyBzdXBwb3NlZCB0byByZXNvbHZlIHRvIGFuIGFkZHJlc3Mgb2Ygc3Bl
Y2lmaWMgYWRkcmVzcyBmYW1pbHkgKGRpZmZlcmVudCBGUUROIGZvciBJUHY0IGFuZCBJUHY2KSwg
YWdlbnQgd2lsbCBjcmVhdGUgYSBzaW5nbGUgY2FuZGlkYXRlIGxpbmUgd2l0aCB0aGlzIEZRRE4g
YW5kIGFkZHJlc3MgZmFtaWx5LsKgDQoNClllcy4NCg0KPk9uIHRoZSByZWNlaXZpbmcgc2lkZSwg
aWYgY2FuZGlkYXRlIGluY2x1ZGVzIGFkZHJ0eXBlIGluaXB2NCwgYW4gQSBETlMgcmVxdWVzdCBp
cyBzZW50IHRvIHJlc29sdmUgRlFETi4gSWYgbW9yZSB0aGVuIG9uZSByZXN1bHQgaXMgcmV0dXJu
ZWQsIHRoaXMgPmNhbmRpZGF0ZSBpcyBpZ25vcmVkLiBJZiBzaW5nbGUgcmVzdWx0IGlzIHJldHVy
bmVkLCBpdCBpcyBhbiBJUHY0IGNhbmRpZGF0ZS4gSWYgY2FuZGlkYXRlIGluY2x1ZGVzIGFkZHJ0
eXBlIGluaXB2NiwgYW4gQUFBQSBETlMgcmVxdWVzdCBpcyBzZW50IHRvID5yZXNvbHZlIEZRRE4u
wqAgSWYgbW9yZSB0aGVuIG9uZSByZXN1bHQgaXMgcmV0dXJuZWQsIHRoaXMgY2FuZGlkYXRlIGlz
IGlnbm9yZWQuIElmIHNpbmdsZSByZXN1bHQgaXMgcmV0dXJuZWQsIGl0IGlzIGFuIElQdjYgY2Fu
ZGlkYXRlLg0KPg0KPkNvcnJlY3RlZCBFeGFtcGxlIGZvciBhIGR1YWwgc3RhY2sgYWdlbnQgKG5v
dGUgZGlmZmVyZW50IGZvdW5kYXRpb24sIHByaW9yaXR5IGFuZCBwb3J0IGZvciB0d28gY2FuZGlk
YXRlcyB3aXRoIHRoZSBzYW1lIEZRRE4gKToNCj4NCj7CoGE9Y2FuZGlkYXRlOjIgMSB1ZHDCoDIx
MjkwMzM0NzHCoGh0dHA6Ly9hbGljZS5jb21hbnkuYml6IDYwNDYwIHR5cCBob3N0IGFkZHJ5cGUg
aW5pcHY0DQo+wqBhPWNhbmRpZGF0ZToxIDEgdWRwwqAyMTI5Mjg5NDcxwqBhbGljZS5jb21hbnku
IGJpesKgNjA0NTQgdHlwIGhvc3QgYWRkcnlwZcKgaW5pcHY2wqAgwqDCoA0KDQpMb29rcyBmaW5l
Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg==


From nobody Fri Apr 12 02:32:55 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15C041201DD for ; Fri, 12 Apr 2019 02:32:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jj_WBzbcDm68 for ; Fri, 12 Apr 2019 02:32:50 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80059.outbound.protection.outlook.com [40.107.8.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60C4712018D for ; Fri, 12 Apr 2019 02:32:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iD8y/DlriOpBgmqDAjUu0k7DJhIV1dlhdtdCNMn/7QQ=; b=dwT2AvQGeIvPks/3w3Wt9G7UaGmBty6snGlVoM8sr1U2KUTdSynC8lewvCC0VJIGLXcIxCfPiLCcFVB772AcIkgCqeyz2HHi2dDnVVEk04u66dwXeRLLCDhJMz5Snqb+czMRzDp+rm04BWKYpkHKCqN+eThLqRntfNwc+7k5eNA=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4249.eurprd07.prod.outlook.com (20.176.166.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.9; Fri, 12 Apr 2019 09:32:46 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::a832:85f:a8bb:73b9%5]) with mapi id 15.20.1792.007; Fri, 12 Apr 2019 09:32:46 +0000
From: Christer Holmberg 
To: Roman Shpount 
CC: Suhas Nandakumar , mmusic WG , Flemming Andreasen 
Thread-Topic: [MMUSIC] FQDN support in ice-sip-sdp
Thread-Index: AQHU6jzz/50YAJx2kEqY4siuQ2NZYqY0606AgADVT4CAAEAVAP//1AeAgADQ14CAAETnAIAAnHWAgAD8QQA=
Date: Fri, 12 Apr 2019 09:32:46 +0000
Message-ID: 
References:    <3DD3D8D6-9B13-4F9D-80DD-F89B69240708@ericsson.com>   <98CF630B-5CCD-4CE4-84B4-81A4C53979DC@ericsson.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.16.1.190220
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-originating-ip: [89.166.49.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cb4af067-1377-470d-869d-08d6bf29d28b
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB4249; 
x-ms-traffictypediagnostic: HE1PR07MB4249:
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0005B05917
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(136003)(366004)(39860400002)(396003)(189003)(199004)(44832011)(36756003)(8936002)(81156014)(476003)(2616005)(486006)(478600001)(66066001)(82746002)(81166006)(4326008)(5660300002)(14454004)(93886005)(33656002)(76176011)(8676002)(446003)(53936002)(11346002)(97736004)(6246003)(6436002)(68736007)(186003)(256004)(26005)(6512007)(102836004)(6506007)(105586002)(86362001)(71200400001)(316002)(25786009)(71190400001)(106356001)(2906002)(58126008)(54906003)(6486002)(6116002)(7736002)(305945005)(83716004)(229853002)(3846002)(99286004)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4249; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: aifgBH4AR51Qu5oNbT1Qrmb1i9P7fZGTQmMWM71Si9YNx3WVllkL5e50m66Wk8PZz/+1AAcLYCsJEPchzWeZUR3dXbdxoMfEXJoWnu6djIYJv5Gr4YajjpEg377/aXxNBb7ImyLs/13lGpB3SwK6C+CTLhvpVDEzEYag9Ptp+r+P29wqelRVfwICT6ujKaWy/FyaxbWwvbVHg01utRWyVSbu5C9yBCnssDUPH+CVBHqXgVqbe2BzzmTg/P1xJCmzQMvSZJTqmC2FhyZymo8pt6+CdMMPSfey5ge9yWvQEMuQ618qyVJgVcdA3lRrLQ+8UHMMRjx6ausquY1zUeqWorZVxJ6VsA0aWIhs9TcxQy3EIajQ3QLoKlHDiL5kPUc0+30puHKIa/an+ufTCKDkkyikKAcrHboliE6YFhqnKMQ=
Content-Type: text/plain; charset="utf-8"
Content-ID: <3EEBAD0B140A744CB10AB31014C12DF1@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cb4af067-1377-470d-869d-08d6bf29d28b
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 09:32:46.5436 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4249
Archived-At: 
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp
X-BeenThere: mmusic@ietf.org
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: Fri, 12 Apr 2019 09:32:53 -0000

SGksDQoNCj4+IEkgKnRoaW5rKiBJIGFncmVlIHdpdGggU3VoYXMgdGhhdCB0aGUgRlFETiBoYW5k
bGluZyBzaG91bGQgYmUgYSBzZXBhcmF0ZSBkcmFmdCDigJMgYSBnZW5lcmljIElDRSBkcmFmdCBw
cm9kdWNlZCBieSB0aGUgSUNFIFdHLiBpY2Utc2lwLXNkcCB3b3VsZCB0aGVuIHNwZWNpZnkgaG93
IGl0IGlzIGltcGxlbWVudGVkIGluIFNEUCAoc2VwYXJhdGUgYT1jYW5kaWRpYXRlIGxpbmVzIGV0
YykuDQo+PsKgDQo+PiBQZXJoYXBzIGl0IGNvdWxkIGJlIGNvbWJpbmVkIHdpdGggdGhlIG1ETlMg
ZHJhZnQ/DQo+DQo+IEkgYW0gbm90IHN1cmUgaWYgdGhpcyBiZWxvbmdzIHRvIGEgbmV3IGRyYWZ0
IG9yIG1ETlMgZHJhZnQuIFdlIGNhbiBkZWNpZGUgdGhpcyBsYXRlci4gV2hhdCB3ZSBuZWVkIHRv
IGRlY2lkZSBub3cgY29tZXMgZG93biB0byB0d28gY2hvaWNlczoNCj4NCj4gYS4gU2F5IHRoYXQg
RlFORCBpcyBhbGxvd2VkIGluIGNhbmRpZGF0ZSBjb25uZWN0aW9uLWFkZHJlc3MgYnV0IHRoZXNl
IGNhbmRpZGF0ZSBsaW5lcyBhcmUgc2tpcHBlZC4gSGFuZGxpbmcgb2YgRlFETiBsaW5lcyBpcyBk
ZWZpbmVkIGluIHRoZSBmdXR1cmUgc3BlY2lmaWNhdGlvbi4NCj4NCj4gYi4gRmlndXJlIG91dCBo
b3cgRlFETiBpcyBoYW5kbGVkLiBPcHRpb25zIHdyaXR0ZW4gdXAgc28gZmFyIGltcGx5IGVpdGhl
ciBzZWxlY3Rpbmcgb25lIHJlc29sdXRpb24gcmVzdWx0IGluIHJhbmRvbSBvciByZXF1aXJpbmcg
dGhlIEZRRE4gcmVzb2x2ZXMgdG8gYSBzaW5nbGUgYWRkcmVzcy4gSSB0aGluayBmb3JtZXIgaXMg
YnJva2VuIGFuZCBsYXRlciBkb2VzIG5vdCBleGlzdCBpbiByZWFsIGxpZmUuDQo+IEkgd291bGQg
bm90IGxpa2UgdGhpcyBkcmFmdCB0byBiZSByZWxlYXNlZCB3aXRoIGVpdGhlciBvcHRpb24uIEkg
dGhpbmsgYWRkaW5nIGFkZHJlc3MgdHlwZSB0byBjYW5kaWRhdGUgYnJpbmdzIGNhbmRpZGF0ZSBs
aW5lIGNvbm5lY3Rpb24gYWRkcmVzcyBkZWZpbml0aW9uIGluIGxpbmUgd2l0aCBTRFAgYz0gbGlu
ZSBzcGVjaWZpY2F0aW9uIGFuZCBzaG91bGQgd29yaywgYnV0IHNvbWVvbmUgbmVlZHMgDQo+IHRv
IHJldmlldyB0aGlzLiBJIGRvIG5vdCB0aGluayB0aGlzIHdpbGwgcmVxdWlyZSBtb3JlIHRoZW4g
Mi0zIGV4dHJhIHBhcmFncmFwaHMgaW4gdGhlIGRvY3VtZW50IHdoaWNoIEkgYW0gd2lsbGluZyB0
byB3cml0ZS4gSSBhZ3JlZSB0aGlzIGlzIHNjb3BlIGNyZWVwIGJ1dCBGUUROIHdlcmUgaW5jbHVk
ZWQgaW4gUkZDIDUyNDUgc28gcGVvcGxlIGV4cGVjdCB0aGVtIHRvIGJlIHN1cHBvcnRlZCANCj4g
YnkgdGhpcyBkcmFmdCBhcyB3ZWxsLg0KPg0KPiBBdCB0aGUgZW5kLCB0aGlzIGlzIHVwIHRvIHRo
ZSBncm91cCB0byBkZWNpZGUuIEkganVzdCBuZWVkIHNvbWV0aGluZyBJIGNhbiBpbXBsZW1lbnQu
IElmIG9wdGlvbiBhIG1ha2VzIHBlb3BsZSB1bmhhcHB5IHRoZW4gd2Ugd2lsbCBuZWVkIHRvIGZp
bmQgbWluaW1hbCB2aWFibGUgb3B0aW9uIGIuDQoNCkFzIGZhciBhcyB0aGUgdGVjaG5pY2FsIHNv
bHV0aW9uIGlzIGNvbmNlcm5lZCAodXNpbmcgc2VwYXJhdGUgYT1jYW5kaWRpYXRlIGxpbmVzIGZv
ciBlYWNoIElQIHZlcnNpb24gZmFtaWx5IGV0YyksIEkgdGhpbmsgaXQgbG9va3MgZ29vZC4NCg0K
QXMgZmFyIGFzIGRvY3VtZW50aW5nIGlzIGNvbmNlcm5lZCwgSSB0aGluayB0aGUgU0RQIHNwZWNp
ZmljcyAoc2VwYXJhdGUgYT0gbGluZXMgZXRjKSBjb3VsZCBiZSBkZWZpbmVkIGluIGljZS1zaXAt
c2RwIC0gYnV0IEkgd291bGQgbm90IG9iamVjdCB0byBoYXZpbmcgYSBzZXBhcmF0ZSBkcmFmdC4N
Cg0KTXkgcG9pbnQgaXMgdGhhdCBJIGRvbid0IHNlZSBGUUROIHN1cHBvcnQgYXMgU0RQLXNwZWNp
ZmljLCBzbyBJIHdvdWxkIGxpa2UgdG8gaGF2ZSBnZW5lcmljIElDRSBGUUROIHRleHQgZG9jdW1l
bnRlZCBzb21laHdoZXJlLCB3aGljaCB0aGUgU0RQLXNwZWNpZmljIHByb2NlZHVyZXMgdGhlbiBy
ZWZlcmVuY2UuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQo=


From nobody Fri Apr 12 08:45:30 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9CE1202DE for ; Fri, 12 Apr 2019 08:45:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PGLsnVWZ4mE for ; Fri, 12 Apr 2019 08:45:27 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE9F812037B for ; Fri, 12 Apr 2019 08:45:26 -0700 (PDT)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x3CFjO9I001569 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 12 Apr 2019 11:45:25 -0400
To: mmusic@ietf.org
References: <155326592304.23020.8256337045285295468.idtracker@ietfa.amsl.com>  <6E58094ECC8D8344914996DAD28F1CCD18CDB636@dggemm526-mbx.china.huawei.com> 
From: Paul Kyzivat 
Message-ID: 
Date: Fri, 12 Apr 2019 11:45:24 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [MMUSIC] Last Call:  (SDP: Session Description Protocol) to Proposed Standard
X-BeenThere: mmusic@ietf.org
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: Fri, 12 Apr 2019 15:45:29 -0000

On 4/12/19 4:59 AM, Magnus Westerlund wrote:
> Hi,
> 
> To be clear, I am not proposing that any existing attribute would be 
> forced to suddenly accept UTF-8 strings with no charset restriction. 
> Simply that new attribute's values can be defined to be UTF-8 in 
> general. I think the important distinction here is that a parser must be 
> ready to accept any UTF-8 character as the sender can't know if a 
> particular charset limitation applies to a specific consumer. However, 
> in form I don't see a problem of the SDP itself informing the consumer 
> that there is a charset limitation applied in this document.
> 
> My interpretation of the current situation is that it we hesitate to use 
> UTF-8 fields due to the uncertainty in the requirements on consumers of 
> SDP.

After re-reviewing the text, I think we may have a can of worms here 
that has existed a long time, perhaps from the beginning. Let me explain:

Section 5 says:

    An SDP description is entirely textual.  SDP field names and
    attribute names use only the US-ASCII subset of UTF-8, but textual
    fields and attribute values MAY use the full ISO 10646 character set
    in UTF-8 encoding, or some other character set defined by the
    "a=charset:" attribute.

Section 6.10 (charset attribute) says:

    The charset specified MUST be one of those registered in the IANA
    Character Sets registry (http://www.iana.org/assignments/character-
    sets), such as ISO-8859-1.
    ...
    Note that a character set specified MUST still prohibit the use of
    bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR).  Character sets requiring
    the use of these characters MUST define a quoting mechanism that
    prevents these bytes from appearing within text fields.

The charsets registry has a *lot* of entries, including a lot of ancient 
obsolete ones not vaguely related to ascii. (E.g., EBCDIC-related ones.) 
Many of these refer to RFC1345, which seems to be a pre-unicode attempt 
to rationalize character sets. The charsets registry also includes 
UTF-16 and UTF-32. It is really hard to understand how certain parts of 
an SDP body might be in UTF-8 while other parts are in UTF-32.

I can't make any sense of:

    Character sets requiring
    the use of these characters MUST define a quoting mechanism that
    prevents these bytes from appearing within text fields.

AFAIK character sets don't define quoting mechanisms. Also, I don't know 
what it means for a charset to require use of particular characters. And 
this text is very sloppy in muddling the use of "character" and "byte".

The bottom line is that this is a mess. I'm not sure if it ever could 
have worked. Nor do I understand what usage it was trying to 
accommodate. (Note that most of this stuff is largely unchanged since 
RFC2327.)

Perhaps all the charset-dependent stuff should be obsoleted.

	Thanks,
	Paul

	


From nobody Fri Apr 12 11:23:20 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B31D1203DB for ; Fri, 12 Apr 2019 11:23:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J69k7tL5g4zj for ; Fri, 12 Apr 2019 11:23:17 -0700 (PDT)
Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E22DD1203B6 for ; Fri, 12 Apr 2019 11:23:16 -0700 (PDT)
Received: by mail-pf1-x42e.google.com with SMTP id y13so5517802pfm.11 for ; Fri, 12 Apr 2019 11:23:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KxdLm7wA1Yz2C8Rtyd/3mZE1r2gVvy9PrMk1nKSf6cY=; b=CTIZRdgvHjCQjjDpwDTE2YqFtbWjlJN9jumMpt0ZtQHABOXuMGakD8ARzgEJgAiui8 Soezcuo5vwlwqI/RwguUk7MBTXfa7f5FLJ49l9x19dyyq5YepZHyJ198T5p4RmJtTB0T 7e8OqQ8bF48eQt0fPo9j9FHeG8eCs2dSQEv6PYME3onroxfAsdxuqlwnC2qFCt1BFJtb Vxsb8ZSA65UWEwq2/hrD9lwwUaAjY3f0NMMTcUWICHnLIHVg0qHuWW03Ok9vyrFg09Wz UOKwZGtdRLilqMwyoJDfY/Ds7L525/DuscWtkd6kN1ehgOF5bdQCyAVknHJCS/Up0XCi JjwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KxdLm7wA1Yz2C8Rtyd/3mZE1r2gVvy9PrMk1nKSf6cY=; b=alNMOAlohtaeRReiwCIfr57hJmHl8O/0zJNkPAKqXG9FdGfvzm1KeQqWAaVAvjfXzZ xC29by6m33J/EUTlnIzbcRZ0SoEIohfKEmP1lFDEMNghphDOkDJqz9IyXQUDC1Ekd0mv URj8FTl5tkJaRTM7vX85BMGDlrivcwnWzXob8zdQaXt5ZQPToItDRn9s3UZTKOJxjUoI yVqOmzrz45n4eroOvmb5EerWIno/GFDe/XoMnPIyUhVDIaM6vATu/dPGLiJb7FJ9h5PM 9BDkX+SlbrdfWvEbnYZMftR8FFl73JOLDCb/n4kaJ4hL9uej+fojIs1nEFjtm/RsINWF rPsA==
X-Gm-Message-State: APjAAAXGuvhCqJUE9pTw65y2F3n9wEkWapZBZ031hQJg59w8kWc2Z9rd ccluF1uym6oNJLqwt+Y/FacUSsKFHNE=
X-Google-Smtp-Source: APXvYqyFpU8DhBbzPhNutPgOGdIBdA7hv+PTc5sSiKApg/qTZ0JsbjLljx2Bo/ONPXo8LtNAeXCCCw==
X-Received: by 2002:aa7:9116:: with SMTP id 22mr58761697pfh.165.1555093396073;  Fri, 12 Apr 2019 11:23:16 -0700 (PDT)
Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com. [209.85.215.171]) by smtp.gmail.com with ESMTPSA id c81sm30482799pfb.158.2019.04.12.11.23.14 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Apr 2019 11:23:14 -0700 (PDT)
Received: by mail-pg1-f171.google.com with SMTP id f6so5577104pgs.8 for ; Fri, 12 Apr 2019 11:23:14 -0700 (PDT)
X-Received: by 2002:a63:ce50:: with SMTP id r16mr52818703pgi.89.1555093394486;  Fri, 12 Apr 2019 11:23:14 -0700 (PDT)
MIME-Version: 1.0
References:    <3DD3D8D6-9B13-4F9D-80DD-F89B69240708@ericsson.com>   <98CF630B-5CCD-4CE4-84B4-81A4C53979DC@ericsson.com>  
In-Reply-To: 
From: Roman Shpount 
Date: Fri, 12 Apr 2019 14:23:00 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Christer Holmberg 
Cc: Suhas Nandakumar , mmusic WG ,  Flemming Andreasen 
Content-Type: multipart/alternative; boundary="0000000000005efcc4058659654a"
Archived-At: 
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp
X-BeenThere: mmusic@ietf.org
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: Fri, 12 Apr 2019 18:23:19 -0000

--0000000000005efcc4058659654a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 12, 2019 at 5:32 AM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> >> I *think* I agree with Suhas that the FQDN handling should be a
> separate draft =E2=80=93 a generic ICE draft produced by the ICE WG. ice-=
sip-sdp
> would then specify how it is implemented in SDP (separate a=3Dcandidiate
> lines etc).
> >>
> >> Perhaps it could be combined with the mDNS draft?
> >
> > I am not sure if this belongs to a new draft or mDNS draft. We can
> decide this later. What we need to decide now comes down to two choices:
> >
> > a. Say that FQND is allowed in candidate connection-address but these
> candidate lines are skipped. Handling of FQDN lines is defined in the
> future specification.
> >
> > b. Figure out how FQDN is handled. Options written up so far imply
> either selecting one resolution result in random or requiring the FQDN
> resolves to a single address. I think former is broken and later does not
> exist in real life.
> > I would not like this draft to be released with either option. I think
> adding address type to candidate brings candidate line connection address
> definition in line with SDP c=3D line specification and should work, but
> someone needs
> > to review this. I do not think this will require more then 2-3 extra
> paragraphs in the document which I am willing to write. I agree this is
> scope creep but FQDN were included in RFC 5245 so people expect them to b=
e
> supported
> > by this draft as well.
> >
> > At the end, this is up to the group to decide. I just need something I
> can implement. If option a makes people unhappy then we will need to find
> minimal viable option b.
>
> As far as the technical solution is concerned (using separate a=3Dcandidi=
ate
> lines for each IP version family etc), I think it looks good.
>
> As far as documenting is concerned, I think the SDP specifics (separate a=
=3D
> lines etc) could be defined in ice-sip-sdp - but I would not object to
> having a separate draft.
>
> My point is that I don't see FQDN support as SDP-specific, so I would lik=
e
> to have generic ICE FQDN text documented somehwhere, which the SDP-specif=
ic
> procedures then reference.
>

I see your point, but I would prefer to avoid creating another dependency
which will prevent ice-sip-sdp from being published.

Please note, that if we specify that candidate line using FQDN
contact-address MUST specify address type and FQDN MUST resolve to a single
address per address type, then FQDN handling is trivial: Agent should do a
DNS resolution and use the result. Figuring out how to handle multiple
results per DNS query certainly warrants a separate draft and should be out
of scope.

What makes sense for me is:

a. Define how to specify address type in candidate line. This is certainly
an SDP problem and I think is a pre-requisite to using any addresses, such
as FQDN, where address type is non-obvious

b. Specify that if agent compliant with ice-sip-sdp uses FQDN
contact-address, it MUST specify addrtype for the candidate.

c. Specify that if FQDN resolves to a single address for the specified
family then that this address is used for this candidate. Candidate lines
with FQDN returning multiple results per query MUST be ignored until their
handling is defined in a future draft

d. Specify what to do with FQDN without address type specified such as SDP
from legacy RFC 5245 implementations. We can go with try AAAA resolution
first and use if single address is returned. If nothing is returned from
AAAA query, try A query. If single address is returned, used that address,
ignore the candidate line otherwise. This matches RFC 5245 language and
should work in all the same situations where RFC 5245 implementations were
working.

What do you think?
_____________
Roman Shpount

--0000000000005efcc4058659654a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Fri, Apr 12, 2019 at 5:32 AM C=
hrister Holmberg <chri=
ster.holmberg@ericsson.com> wrote:
>>=
 I *think* I agree with Suhas that the FQDN handling should be a separate d=
raft =E2=80=93 a generic ICE draft produced by the ICE WG. ice-sip-sdp woul=
d then specify how it is implemented in SDP (separate a=3Dcandidiate lines =
etc).

>>=C2=A0

>> Perhaps it could be combined with the mDNS draft?

>

> I am not sure if this belongs to a new draft or mDNS draft. We can dec=
ide this later. What we need to decide now comes down to two choices:

>

> a. Say that FQND is allowed in candidate connection-address but these =
candidate lines are skipped. Handling of FQDN lines is defined in the futur=
e specification.

>

> b. Figure out how FQDN is handled. Options written up so far imply eit=
her selecting one resolution result in random or requiring the FQDN resolve=
s to a single address. I think former is broken and later does not exist in=
 real life.

> I would not like this draft to be released with either option. I think=
 adding address type to candidate brings candidate line connection address =
definition in line with SDP c=3D line specification and should work, but so=
meone needs 

> to review this. I do not think this will require more then 2-3 extra p=
aragraphs in the document which I am willing to write. I agree this is scop=
e creep but FQDN were included in RFC 5245 so people expect them to be supp=
orted 

> by this draft as well.

>

> At the end, this is up to the group to decide. I just need something I=
 can implement. If option a makes people unhappy then we will need to find =
minimal viable option b.



As far as the technical solution is concerned (using separate a=3Dcandidiat=
e lines for each IP version family etc), I think it looks good.



As far as documenting is concerned, I think the SDP specifics (separate a=
=3D lines etc) could be defined in ice-sip-sdp - but I would not object to =
having a separate draft.



My point is that I don't see FQDN support as SDP-specific, so I would l=
ike to have generic ICE FQDN text documented somehwhere, which the SDP-spec=
ific procedures then reference.

I see y=
our point, but I would prefer to avoid creating another dependency which wi=
ll prevent ice-sip-sdp from being published.

Pleas=
e note, that if we specify that candidate line using FQDN contact-address M=
UST specify address type and FQDN MUST resolve to a single address per addr=
ess type, then FQDN handling is trivial: Agent should do a DNS resolution a=
nd use the result. Figuring out how to handle multiple results per DNS quer=
y certainly warrants a separate draft and should be out of scope.=C2=A0

What makes sense for me is:

=
a. Define how to specify address type in candidate line. This is certainly =
an SDP problem and I think is a pre-requisite to using any addresses, such =
as FQDN, where address type is non-obvious

b.=
 Specify that if agent compliant with ice-sip-sdp uses FQDN contact-address=
, it MUST specify addrtype for the candidate.

c. Specify that if FQDN resolves to a sing=
le address for the specified family then that this address is used for this=
 candidate. Candidate lines with FQDN returning multiple results per query =
MUST be ignored until their handling is defined in a future draft

d. Specify what to do with FQDN without address type specif=
ied such as SDP from legacy RFC 5245 implementations. We can go with try AA=
AA resolution first and use if single address is returned. If nothing is re=
turned from AAAA query, try A query. If single address is returned, used th=
at address, ignore the candidate line otherwise. This matches RFC 5245 lang=
uage and should work in all the same situations where RFC 5245 implementati=
ons were working.

What do you think?
_____________
Roman Shpount


=C2=A0
<=
/div>


--0000000000005efcc4058659654a--


From nobody Sat Apr 13 22:37:25 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE98F12014C for ; Sat, 13 Apr 2019 22:37:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Cei2pWslr3S for ; Sat, 13 Apr 2019 22:37:22 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CA8712014A for ; Sat, 13 Apr 2019 22:37:22 -0700 (PDT)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id B3DFCC2F1FFA600FB50B for ; Sun, 14 Apr 2019 06:37:19 +0100 (IST)
Received: from DGGEMM422-HUB.china.huawei.com (10.1.198.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 14 Apr 2019 06:37:19 +0100
Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.138]) by dggemm422-hub.china.huawei.com ([10.1.198.39]) with mapi id 14.03.0415.000; Sun, 14 Apr 2019 13:37:13 +0800
From: "Roni Even (A)" 
To: Paul Kyzivat , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] Addressing comment from IANA on draft-ietf-mmusic-data-channel-sdpneg-25
Thread-Index: AdTwT5OIKFVlXaa2S8ClvVSnITuzDv//4tSA//t+d7A=
Date: Sun, 14 Apr 2019 05:37:13 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18CDBE66@dggemm526-mbx.china.huawei.com>
References: <6E58094ECC8D8344914996DAD28F1CCD18CDB681@dggemm526-mbx.china.huawei.com> <8f2f339c-8174-b9b1-8204-78d5ee665574@alum.mit.edu>
In-Reply-To: <8f2f339c-8174-b9b1-8204-78d5ee665574@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.202.102]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [MMUSIC] Addressing comment from IANA on draft-ietf-mmusic-data-channel-sdpneg-25
X-BeenThere: mmusic@ietf.org
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: Sun, 14 Apr 2019 05:37:25 -0000

Hi Paul,
Section 8.2.4.1 of https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis=
-33#section-8.2.4 (normative reference in SDPNEG) registers usage level dcs=
a and dcsa (subprotocol) for the IANA att-field and point at the data-chann=
el-sdpneg document for the definition. I think it will be simple to keep as=
 is and just have the definition  in sdpneg but I have no strong feeling. S=
o just decide, if you change RFC4566bis , we will need to keep section 9.3 =
in data-channel-sdpneg and just clarify what we register.

Roni
=20

-----Original Message-----
From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: Thursday, April 11, 2019 7:32 PM
To: mmusic@ietf.org
Subject: Re: [MMUSIC] Addressing comment from IANA on draft-ietf-mmusic-dat=
a-channel-sdpneg-25

On 4/11/19 6:34 AM, Roni Even (A) wrote:
> Hi,
>=20
> I got the following comment from IANA:
>=20
> Third, Section 9.3 of the current document appears to request the=20
> creation of a new registry in the Session Description Protocol (SDP)=20
> Parameters registry located at:
>=20
> https://www.iana.org/assignments/sdp-parameters/
>=20
> IANA Question --> The new registry might be modeled upon the existing=20
> att-field (. . . level) registries but instead be a registry for=20
> att-field (dcsa level). Is this correct? Would the new registry have=20
> the same characteristics as other att-field registries on the registry pa=
ge?
> Could the draft be revised to explicitly create the registry, if this=20
> is correct? Are there any initial registrations in this new registry?
>=20
> My response was
>=20
> We are not asking for a new registry,=A0 see
> https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-33#section-8.
> 5 for=A0 the Reorganization of the att-field Registries.=A0 I now think=20
> that this third action is not really needed since it is now defined in=20
> rfc4566bis section 8.5 and 8.4
>=20
> So I suggest to remove section 9.3 and add to the end of section=20
> section
> 5.2.1

ISTM we actually got a little ahead of ourselves in 4566bis by mentioning d=
csa and msrp-usage-datachannel.

While 4566bis reorganizes the attribute registries so that we don't need a =
new registry for dcsa, is is draft-ietf-mmusic-data-channel-sdpneg
that defines the dcsa usage level. The publication of it should result in a=
ddition of a reference to it in the attribute registry. So I think we need =
an IANA action just to accomplish that.

And maybe the references to dcsa and msrp-usage-data-channel should be remo=
ved from 4566bis if it isn't too late to do so.

I don't find section 5.2.1 to be an appropriate place for this kind of info=
rmation.

	Thanks,
	Paul

> A data channel specific usage of a subprotocol attribute is expected=20
> to be specified
>=20
>  =A0=A0 in the same document that registers the subprotocol's identifier=
=20
> for
>=20
>  =A0=A0 data channel usage.
>=20
>  =A0=A0=A0=A0=A0=A0=A0 SDP attributes that are only defined for use at th=
e
>=20
>  =A0=A0 dcsa usage level, SHALL use the dcsa usage level when registering=
=20
> the
>=20
>  =A0=A0 attribute.=A0 If existing media attributes are used in a datachan=
nel
>=20
>  =A0=A0 subprotocol specific way, then a new dcsa usage level
>=20
>  =A0=A0 MUST be defined for the existing media attribute.=A0 Where the SD=
P
>=20
>  =A0 attribute is applicable to a particular subprotocol/s this SHALL=20
> also
>=20
>  =A0=A0 be registered by indicating the applicable subprotocol identifier=
s
>=20
>  =A0=A0 (see
> https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-34#section-8.
> 5)
> along with the dcsa usage level.
>=20
> Roni Even
>=20
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>=20

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


From nobody Sun Apr 14 01:43:29 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52EF1201A1 for ; Sun, 14 Apr 2019 01:43:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWKp7WBES176 for ; Sun, 14 Apr 2019 01:43:24 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150051.outbound.protection.outlook.com [40.107.15.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F4B4120020 for ; Sun, 14 Apr 2019 01:43:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nS/fWeRhZFl6EizyEHIX/Tof/7Re9SKFf/e/a5I6oXI=; b=XK6kjeG2i4mAlYLkQcN5ix/1v1BrvgTKCmp/6C1l71K7d2YqekTaPKRqynVfV8Kk8CqMk6jngfEIHAN49lNl2rnXllTnmYEF57s7rcyFAvTNusCtmH3PMv2jVsGZn0ZDNBi4gPEkp9uv2LssabBpNcYtNRRYudtdcZ5r7DzUt/k=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4220.eurprd07.prod.outlook.com (20.176.166.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Sun, 14 Apr 2019 08:43:20 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184%2]) with mapi id 15.20.1813.009; Sun, 14 Apr 2019 08:43:20 +0000
From: Christer Holmberg 
To: Roman Shpount 
CC: Suhas Nandakumar , mmusic WG , Flemming Andreasen 
Thread-Topic: [MMUSIC] FQDN support in ice-sip-sdp
Thread-Index: AQHU6jzz/50YAJx2kEqY4siuQ2NZYqY0606AgADVT4CAAEAVAP//1AeAgADQ14CAAETnAIAAnHWAgAD8QQCAAGHdAIACtQAA
Date: Sun, 14 Apr 2019 08:43:20 +0000
Message-ID: <1552A692-1020-43CA-B15E-92595729EE8B@ericsson.com>
References:    <3DD3D8D6-9B13-4F9D-80DD-F89B69240708@ericsson.com>   <98CF630B-5CCD-4CE4-84B4-81A4C53979DC@ericsson.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.16.1.190220
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-originating-ip: [87.93.15.155]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6e603462-311a-47cf-7c16-08d6c0b53fa2
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB4220; 
x-ms-traffictypediagnostic: HE1PR07MB4220:
x-microsoft-antispam-prvs: 
x-forefront-prvs: 00073DB75F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(376002)(346002)(136003)(39860400002)(189003)(199004)(7736002)(36756003)(105586002)(8676002)(11346002)(486006)(305945005)(25786009)(86362001)(4326008)(44832011)(6246003)(106356001)(446003)(58126008)(81166006)(81156014)(8936002)(68736007)(6506007)(316002)(76176011)(102836004)(186003)(2616005)(476003)(26005)(2906002)(54906003)(6436002)(6116002)(83716004)(256004)(71190400001)(71200400001)(3846002)(33656002)(6916009)(82746002)(99286004)(229853002)(97736004)(14444005)(478600001)(6512007)(66066001)(14454004)(53936002)(6486002)(93886005)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4220; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: t9dPbuCVfoY7xrwCj56v7eNscn/XFRQNrvtjIODyoVdibKQJBO47xRr/3h+IOk2i0UsTJhUL9beC5uCnT8lLNQarjZdaNe15WGnoHRgTF408WrAuLvRQ66nxQldrFpHgBqQ7r6qtNFiQFyw7JoPZETtSdxY05rNai4dyyDjZTM+d573Mb1A7yDnSp/ZfZ0tRKv75vQdhcLV9pS3r8g7AIDVWhJ1b1Xhssp5gOSiizRJnYJgxsNNwdAItNN2GhbZf7mIBOrXrVLSncvUWsJ/cSwRe9TEJ9MKD4NlU4lo+G4t4VxSRlEuLMBoA9oZuV63wR4wp5ZugfK/ogKfA/HEZWox8m1CN8JW5UoplA51VyTq7DTJOPp3iymQYRADF3jzvEZu0eaBdqFqd/c4mD5t3BQWDVnNstQZ5qdDJ6PlHXF8=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6e603462-311a-47cf-7c16-08d6c0b53fa2
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2019 08:43:20.7629 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4220
Archived-At: 
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp
X-BeenThere: mmusic@ietf.org
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: Sun, 14 Apr 2019 08:43:28 -0000

SGksDQoNCj4+Pj4+IEkgKnRoaW5rKiBJIGFncmVlIHdpdGggU3VoYXMgdGhhdCB0aGUgRlFETiBo
YW5kbGluZyBzaG91bGQgYmUgYSBzZXBhcmF0ZSBkcmFmdCDigJMgYSBnZW5lcmljIElDRSBkcmFm
dCBwcm9kdWNlZCBieSB0aGUgSUNFIFdHLiANCj4+Pj4+IGljZS1zaXAtc2RwIHdvdWxkIHRoZW4g
c3BlY2lmeSBob3cgaXQgaXMgaW1wbGVtZW50ZWQgaW4gU0RQIChzZXBhcmF0ZSBhPWNhbmRpZGlh
dGUgbGluZXMgZXRjKS4NCj4+Pj7CoA0KPj4+PiBQZXJoYXBzIGl0IGNvdWxkIGJlIGNvbWJpbmVk
IHdpdGggdGhlIG1ETlMgZHJhZnQ/DQo+Pj4NCj4+PiBJIGFtIG5vdCBzdXJlIGlmIHRoaXMgYmVs
b25ncyB0byBhIG5ldyBkcmFmdCBvciBtRE5TIGRyYWZ0LiBXZSBjYW4gZGVjaWRlIHRoaXMgbGF0
ZXIuIA0KPj4+IFdoYXQgd2UgbmVlZCB0byBkZWNpZGUgbm93IGNvbWVzIGRvd24gdG8gdHdvIGNo
b2ljZXM6DQo+Pj4NCj4+PiBhLiBTYXkgdGhhdCBGUU5EIGlzIGFsbG93ZWQgaW4gY2FuZGlkYXRl
IGNvbm5lY3Rpb24tYWRkcmVzcyBidXQgdGhlc2UgY2FuZGlkYXRlIGxpbmVzIGFyZSBza2lwcGVk
LiANCj4+PiBIYW5kbGluZyBvZiBGUUROIGxpbmVzIGlzIGRlZmluZWQgaW4gdGhlIGZ1dHVyZSBz
cGVjaWZpY2F0aW9uLg0KPj4+DQo+Pj4gYi4gRmlndXJlIG91dCBob3cgRlFETiBpcyBoYW5kbGVk
LiBPcHRpb25zIHdyaXR0ZW4gdXAgc28gZmFyIGltcGx5IGVpdGhlciBzZWxlY3Rpbmcgb25lIHJl
c29sdXRpb24gcmVzdWx0DQo+Pj4gaW4gcmFuZG9tIG9yIHJlcXVpcmluZyB0aGUgRlFETiByZXNv
bHZlcyB0byBhIHNpbmdsZSBhZGRyZXNzLiBJIHRoaW5rIGZvcm1lciBpcyBicm9rZW4gYW5kIGxh
dGVyIGRvZXMgbm90IA0KPj4+IGV4aXN0IGluIHJlYWwgbGlmZS4NCj4+PiBJIHdvdWxkIG5vdCBs
aWtlIHRoaXMgZHJhZnQgdG8gYmUgcmVsZWFzZWQgd2l0aCBlaXRoZXIgb3B0aW9uLiBJIHRoaW5r
IGFkZGluZyBhZGRyZXNzIHR5cGUgdG8gY2FuZGlkYXRlIGJyaW5ncyANCj4+PiBjYW5kaWRhdGUg
bGluZSBjb25uZWN0aW9uIGFkZHJlc3MgZGVmaW5pdGlvbiBpbiBsaW5lIHdpdGggU0RQIGM9IGxp
bmUgc3BlY2lmaWNhdGlvbiBhbmQgc2hvdWxkIHdvcmssIGJ1dCBzb21lb25lIA0KPj4+IG5lZWRz
IHRvIHJldmlldyB0aGlzLiBJIGRvIG5vdCB0aGluayB0aGlzIHdpbGwgcmVxdWlyZSBtb3JlIHRo
ZW4gMi0zIGV4dHJhIHBhcmFncmFwaHMgaW4gdGhlIGRvY3VtZW50IHdoaWNoIEkgYW0gDQo+Pj4g
d2lsbGluZyB0byB3cml0ZS4gSSBhZ3JlZSB0aGlzIGlzIHNjb3BlIGNyZWVwIGJ1dCBGUUROIHdl
cmUgaW5jbHVkZWQgaW4gUkZDIDUyNDUgc28gcGVvcGxlIGV4cGVjdCB0aGVtIHRvIGJlIHN1cHBv
cnRlZCANCj4+PiBieSB0aGlzIGRyYWZ0IGFzIHdlbGwuDQo+Pj4NCj4+PiBBdCB0aGUgZW5kLCB0
aGlzIGlzIHVwIHRvIHRoZSBncm91cCB0byBkZWNpZGUuIEkganVzdCBuZWVkIHNvbWV0aGluZyBJ
IGNhbiBpbXBsZW1lbnQuIElmIG9wdGlvbiBhIG1ha2VzIHBlb3BsZSB1bmhhcHB5IA0KPj4+IHRo
ZW4gd2Ugd2lsbCBuZWVkIHRvIGZpbmQgbWluaW1hbCB2aWFibGUgb3B0aW9uIGIuDQo+Pg0KPj4g
QXMgZmFyIGFzIHRoZSB0ZWNobmljYWwgc29sdXRpb24gaXMgY29uY2VybmVkICh1c2luZyBzZXBh
cmF0ZSBhPWNhbmRpZGF0ZSBsaW5lcyBmb3IgZWFjaCBJUCB2ZXJzaW9uIGZhbWlseSBldGMpLA0K
Pj4gSSB0aGluayBpdCBsb29rcyBnb29kLg0KPj4NCj4+IEFzIGZhciBhcyBkb2N1bWVudGluZyBp
cyBjb25jZXJuZWQsIEkgdGhpbmsgdGhlIFNEUCBzcGVjaWZpY3MgKHNlcGFyYXRlIGE9IGxpbmVz
IGV0YykgY291bGQgYmUgZGVmaW5lZCBpbiBpY2Utc2lwLXNkcCAtIGJ1dCBJDQo+PiB3b3VsZCBu
b3Qgb2JqZWN0IHRvIGhhdmluZyBhIHNlcGFyYXRlIGRyYWZ0Lg0KPj4NCj4+IE15IHBvaW50IGlz
IHRoYXQgSSBkb24ndCBzZWUgRlFETiBzdXBwb3J0IGFzIFNEUC1zcGVjaWZpYywgc28gSSB3b3Vs
ZCBsaWtlIHRvIGhhdmUgZ2VuZXJpYyBJQ0UgRlFETiB0ZXh0IGRvY3VtZW50ZWQgDQo+PiBzb21l
d2hlcmUsIHdoaWNoIHRoZSBTRFAtc3BlY2lmaWMgcHJvY2VkdXJlcyB0aGVuIHJlZmVyZW5jZS4N
Cj4NCj4gSSBzZWUgeW91ciBwb2ludCwgYnV0IEkgd291bGQgcHJlZmVyIHRvIGF2b2lkIGNyZWF0
aW5nIGFub3RoZXIgZGVwZW5kZW5jeSB3aGljaCB3aWxsIHByZXZlbnQgaWNlLXNpcC1zZHAgZnJv
bSANCj4gYmVpbmcgcHVibGlzaGVkLg0KDQpXZSBuZWVkIHRvIGtlZXAgaW4gbWluZCB3aHkgd2Ug
YXJlIGRvaW5nIFJGQyA4NDQ1IGljZS1zaXAtc2RwIGluIHRoZSBmaXJzdCBwbGFjZS4NCg0KU3Vy
ZSwgb25lIHJlYXNvbiB3YXMgdG8gc2VwYXJhdGUgZnVuY3Rpb25hbGl0eSBmcm9tIHByb3RvY29s
Lg0KDQpCdXQsIHRoZSBvdGhlciByZWFzb24gd2FzIHRvIGNvcnJlY3QgaXNzdWVzIGFuZCB1bnNw
ZWNpZmllZCBjYXNlcyBmb3VuZCBpbiBSRkMgNTI0NSwgYW5kIEZRRE4gc2VlbXMgdG8gYmUgb25l
IHN1Y2ggaXNzdWUuIFVuZm9ydHVuYXRlbHkgd2UgZGlkbid0IGRldGVjdCBpdCBiZWZvcmUgcHVi
bGlzaGluZyBSRkMgODQ0NSwgc28gYW55IGdlbmVyaWMgSUNFIEZRRE4gcHJvY2VkdXJlcyB3b3Vs
ZCBoYXZlIHRvIGJlIGluIGEgc2VwYXJhdGUgZHJhZnQuDQoNCkFnYWluLCBJIGRvbid0IGhhdmUg
YSBzdHJvbmcgb3BpbmlvbiBvbiB3aGV0aGVyIHRoZSBTRFAgc3BlY2lmaWMgcGFydHMgb2YgRlFE
TiBhcmUgaW4gaWNlLXNpcC1zZHAgb3IgaW4gYSBzZXBhcmF0ZSBkcmFmdC4NCg0KS2VlcCBpbiBt
aW5kIHRoYXQgd2UgYWxzbyBuZWVkIHRvIGRlY2lkZSBvbiB3aGV0aGVyIGljZS1wYWMgc2hvdWxk
IGJlIGFuIGljZS1zaXAtc2RwIGRlcGVuZGVuY3ksIGluIHdoaWNoIGNhc2UgdGhlIHB1YmxpY2F0
aW9uIG1heSBnZXQgZGVsYXllZCBhbnl3YXkgKGV2ZW50aG91Z2ggd2UgaG9wZSB0byBmaW5hbGl6
ZSBpY2UtcGFjIHByZXR0eSBmYXN0KS4NCg0KPiBQbGVhc2Ugbm90ZSwgdGhhdCBpZiB3ZSBzcGVj
aWZ5IHRoYXQgY2FuZGlkYXRlIGxpbmUgdXNpbmcgRlFETiBjb250YWN0LWFkZHJlc3MgTVVTVCBz
cGVjaWZ5IGFkZHJlc3MgdHlwZSBhbmQgRlFETiBNVVNUIHJlc29sdmUgDQo+IHRvIGEgc2luZ2xl
IGFkZHJlc3MgcGVyIGFkZHJlc3MgdHlwZSwgdGhlbiBGUUROIGhhbmRsaW5nIGlzIHRyaXZpYWw6
IEFnZW50IHNob3VsZCBkbyBhIEROUyByZXNvbHV0aW9uIGFuZCB1c2UgdGhlIHJlc3VsdC4gDQoN
Clllcy4NCg0KPiBGaWd1cmluZyBvdXQgaG93IHRvIGhhbmRsZSBtdWx0aXBsZSByZXN1bHRzIHBl
ciBETlMgcXVlcnkgY2VydGFpbmx5IHdhcnJhbnRzIGEgc2VwYXJhdGUgZHJhZnQgYW5kIHNob3Vs
ZCBiZSBvdXQgb2Ygc2NvcGUuwqANCg0KV2UgYWxzbyBuZWVkIHRvIGtlZXAgaW4gbWluZCB0aGF0
LCBldmVudGhvdWdoIGEgc2luZ2xlIEROUyByZXF1ZXN0IG9ubHkgcmV0dXJucyBhIHNpbmdsZSBh
ZGRyZXNzLCBpZiBzb21lIGtpbmQgb2YgbG9hZCBiYWxhbmNpbmcgaXMgdXNlZCBkaWZmZXJlbnQg
RE5TIHJlcXVlc3RzIG1heSByZXR1cm4gYSBkaWZmZXJlbnQgYWRkcmVzcy4gUGVyaGFwcyB3ZSBu
ZWVkIHRvIGNvdmVyIHRoYXQgYnkgc2F5aW5nIHRoYXQgYW4gSUNFIGFnZW50IG11c3Qgbm90IGNo
YW5nZSB0aGUgSVAgYWRkcmVzczpwb3J0IGFzc29jaWF0ZWQgd2l0aCBhIGNhbmRpZGF0ZS4NCg0K
PiBXaGF0IG1ha2VzIHNlbnNlIGZvciBtZSBpczoNCj4NCj4gYS4gRGVmaW5lIGhvdyB0byBzcGVj
aWZ5IGFkZHJlc3MgdHlwZSBpbiBjYW5kaWRhdGUgbGluZS4gVGhpcyBpcyBjZXJ0YWlubHkgYW4g
U0RQIHByb2JsZW0gYW5kIEkgdGhpbmsgaXMgYSBwcmUtcmVxdWlzaXRlIHRvIHVzaW5nIGFueSBh
ZGRyZXNzZXMsIHN1Y2ggYXMgDQo+IEZRRE4sIHdoZXJlIGFkZHJlc3MgdHlwZSBpcyBub24tb2J2
aW91cw0KDQpIT1cgdG8gZGVmaW5lIHRoZSBhZGRyZXNzIHR5cGUgaW4gYSBjYW5kaWRhdGUgbGl0
ZSBpcyBmb3Igc3VyZSBhbiBTRFAgcHJvYmxlbS4gQnV0LCB0aGUgZmFjdCB0aGF0IHRoZSBhZGRy
ZXNzIHR5cGUgbmVlZHMgdG8gYmUgcHJvdmlkZWQgZm9yIGEgY2FuZGlkYXRlIGlzIGFuIElDRSBw
cm9ibGVtLiANCg0KSXQgaXMgdmVyeSBzaW1pbGFyIHRvIHRoZSBJQ0Ugb3B0aW9uLiBSRkMgODQ0
NSBkZWZpbmVzIGl0IGluIGFuIGFic3RyYWN0IHdheSwgYW5kIGljZS1pY2Utc2RwIGRlZmluZXMg
aG93IHRvIGVuY29kZSBpdCBpbiBTSVAvU0RQLg0KDQo+IGIuIFNwZWNpZnkgdGhhdCBpZiBhZ2Vu
dCBjb21wbGlhbnQgd2l0aCBpY2Utc2lwLXNkcCB1c2VzIEZRRE4gY29udGFjdC1hZGRyZXNzLCBp
dCBNVVNUIHNwZWNpZnkgYWRkcnR5cGUgZm9yIHRoZSBjYW5kaWRhdGUuDQoNCkRvIHdlIGtub3cg
aG93IGFuIGV4aXN0aW5nIGltcGxlbWVudGF0aW9uIHdvdWxkIHByb2Nlc3MgdGhlIGFkZHJ0eXBl
PyBBcmUgdGhlcmUgYW55IHByb2NlZHVyZXMgcmVnYXJkaW5nIHVuc3VwcG9ydGVkIGNhbmRpZGF0
ZSBwcm9wZXJ0aWVzPw0KDQo+IGMuIFNwZWNpZnkgdGhhdCBpZiBGUUROIHJlc29sdmVzIHRvIGEg
c2luZ2xlIGFkZHJlc3MgZm9yIHRoZSBzcGVjaWZpZWQgZmFtaWx5IHRoZW4gdGhhdCB0aGlzIGFk
ZHJlc3MgaXMgdXNlZCBmb3IgdGhpcyBjYW5kaWRhdGUuIENhbmRpZGF0ZSBsaW5lcyB3aXRoIA0K
PiBGUUROIHJldHVybmluZyBtdWx0aXBsZSByZXN1bHRzIHBlciBxdWVyeSBNVVNUIGJlIGlnbm9y
ZWQgdW50aWwgdGhlaXIgaGFuZGxpbmcgaXMgZGVmaW5lZCBpbiBhIGZ1dHVyZSBkcmFmdA0KPg0K
PiBkLiBTcGVjaWZ5IHdoYXQgdG8gZG8gd2l0aCBGUUROIHdpdGhvdXQgYWRkcmVzcyB0eXBlIHNw
ZWNpZmllZCBzdWNoIGFzIFNEUCBmcm9tIGxlZ2FjeSBSRkMgNTI0NSBpbXBsZW1lbnRhdGlvbnMu
IFdlIGNhbiBnbyB3aXRoIHRyeSBBQUFBIHJlc29sdXRpb24gDQo+IGZpcnN0IGFuZCB1c2UgaWYg
c2luZ2xlIGFkZHJlc3MgaXMgcmV0dXJuZWQuIElmIG5vdGhpbmcgaXMgcmV0dXJuZWQgZnJvbSBB
QUFBIHF1ZXJ5LCB0cnkgQSBxdWVyeS4gSWYgc2luZ2xlIGFkZHJlc3MgaXMgcmV0dXJuZWQsIHVz
ZWQgdGhhdCBhZGRyZXNzLCBpZ25vcmUgDQo+IHRoZSBjYW5kaWRhdGUgbGluZSBvdGhlcndpc2Uu
IFRoaXMgbWF0Y2hlcyBSRkMgNTI0NSBsYW5ndWFnZSBhbmQgc2hvdWxkIHdvcmsgaW4gYWxsIHRo
ZSBzYW1lIHNpdHVhdGlvbnMgd2hlcmUgUkZDIDUyNDUgaW1wbGVtZW50YXRpb25zIHdlcmUgd29y
a2luZy4NCg0KZCkgd29ya3MgYXNzdW1pbmcgYm90aCBJQ0UgYWdlbnRzIGdldCB0aGUgc2FtZSBJ
UCBhZGRyZXNzOnBvcnQgZnJvbSBETlMuDQoNCj4gV2hhdCBkbyB5b3UgdGhpbms/DQoNCkkgdGhp
bmsgeW91IHN1Z2dlc3Rpb24gaXMgZ29vZC4gQnV0LCBhcyBJIGhhdmUgaW5kaWNhdGVkLCBJIHdv
dWxkIGxpa2UgdG8gaGF2ZSBhIGdlbmVyaWMgSUNFIEZRRE4gZHJhZnQgdGhhdCBpY2Utc2lwLXNk
cCAob3IgYSBzZXBhcmF0ZSBNTVVTSUMgZHJhZnQpIHJlZmVyZW5jZXMuDQoNClNpbWlsYXJseSB0
byBpY2UtcGFjLCBJIHRoaW5rIHN1Y2ggZHJhZnQgY291bGQgYmUgcHJvZHVjZWQgcmVsYXRpdmVs
eSBmYXN0LiBJdCBtb3JlIG9yIGxlc3Mgb25seSBuZWVkcyB0byBzYXkgdGhhdDoNCg0KMSkgQW4g
SUNFIGFnZW50IHRoYXQgdXNlcyBGUUROIG5lZWRzIHRvIHByb3ZpZGUgb25lIGNhbmRpZGF0ZSBw
ZXIgYWRkcmVzcyBmYW1pbHksIGFuZCBpbmRpY2F0ZSB0aGUgYWRkcnR5cGUgZm9yIGVhY2ggb2Yg
dGhvc2UgY2FuZGlkYXRlcy4NCjIpIFNvbWUgdGV4dCByZWdhcmRpbmcgYmFja3dhcmQgY29tcGF0
aWJpbGl0eS4gRG8gd2UgYXNzdW1lIHNvbWUgZGVmYXVsdCBiZWhhdmlvciBieSBleGlzdGluZyBp
bXBsZW1lbnRhdGlvbnMsIG9yIGRvIHdlIHJlcXVpcmUgYW4gSUNFIG9wdGlvbj8NCiANClJlZ2Fy
ZHMsDQoNCkNocmlzdGVyDQoNCg0K


From nobody Sun Apr 14 12:26:14 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AAC1200FB for ; Sun, 14 Apr 2019 12:26:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoffeYrXtCMT for ; Sun, 14 Apr 2019 12:26:11 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4F351200B1 for ; Sun, 14 Apr 2019 12:26:10 -0700 (PDT)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x3EJQ3v3015247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 14 Apr 2019 15:26:04 -0400
To: "Roni Even (A)" , "mmusic@ietf.org" 
References: <6E58094ECC8D8344914996DAD28F1CCD18CDB681@dggemm526-mbx.china.huawei.com> <8f2f339c-8174-b9b1-8204-78d5ee665574@alum.mit.edu> <6E58094ECC8D8344914996DAD28F1CCD18CDBE66@dggemm526-mbx.china.huawei.com>
From: Paul Kyzivat 
Message-ID: 
Date: Sun, 14 Apr 2019 15:26:03 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD18CDBE66@dggemm526-mbx.china.huawei.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [MMUSIC] Addressing comment from IANA on draft-ietf-mmusic-data-channel-sdpneg-25
X-BeenThere: mmusic@ietf.org
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: Sun, 14 Apr 2019 19:26:13 -0000

On 4/14/19 1:37 AM, Roni Even (A) wrote:
> Hi Paul,
> Section 8.2.4.1 of https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-33#section-8.2.4 (normative reference in SDPNEG) registers usage level dcsa and dcsa (subprotocol) for the IANA att-field and point at the data-channel-sdpneg document for the definition. I think it will be simple to keep as is and just have the definition  in sdpneg but I have no strong feeling. So just decide, if you change RFC4566bis , we will need to keep section 9.3 in data-channel-sdpneg and just clarify what we register.

Duh, you are right. I forgot we put the dependency in there.

	Sorry,
	Paul

> Roni
>   
> 
> -----Original Message-----
> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat
> Sent: Thursday, April 11, 2019 7:32 PM
> To: mmusic@ietf.org
> Subject: Re: [MMUSIC] Addressing comment from IANA on draft-ietf-mmusic-data-channel-sdpneg-25
> 
> On 4/11/19 6:34 AM, Roni Even (A) wrote:
>> Hi,
>>
>> I got the following comment from IANA:
>>
>> Third, Section 9.3 of the current document appears to request the
>> creation of a new registry in the Session Description Protocol (SDP)
>> Parameters registry located at:
>>
>> https://www.iana.org/assignments/sdp-parameters/
>>
>> IANA Question --> The new registry might be modeled upon the existing
>> att-field (. . . level) registries but instead be a registry for
>> att-field (dcsa level). Is this correct? Would the new registry have
>> the same characteristics as other att-field registries on the registry page?
>> Could the draft be revised to explicitly create the registry, if this
>> is correct? Are there any initial registrations in this new registry?
>>
>> My response was
>>
>> We are not asking for a new registry,  see
>> https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-33#section-8.
>> 5 for  the Reorganization of the att-field Registries.  I now think
>> that this third action is not really needed since it is now defined in
>> rfc4566bis section 8.5 and 8.4
>>
>> So I suggest to remove section 9.3 and add to the end of section
>> section
>> 5.2.1
> 
> ISTM we actually got a little ahead of ourselves in 4566bis by mentioning dcsa and msrp-usage-datachannel.
> 
> While 4566bis reorganizes the attribute registries so that we don't need a new registry for dcsa, is is draft-ietf-mmusic-data-channel-sdpneg
> that defines the dcsa usage level. The publication of it should result in addition of a reference to it in the attribute registry. So I think we need an IANA action just to accomplish that.
> 
> And maybe the references to dcsa and msrp-usage-data-channel should be removed from 4566bis if it isn't too late to do so.
> 
> I don't find section 5.2.1 to be an appropriate place for this kind of information.
> 
> 	Thanks,
> 	Paul
> 
>> A data channel specific usage of a subprotocol attribute is expected
>> to be specified
>>
>>      in the same document that registers the subprotocol's identifier
>> for
>>
>>      data channel usage.
>>
>>           SDP attributes that are only defined for use at the
>>
>>      dcsa usage level, SHALL use the dcsa usage level when registering
>> the
>>
>>      attribute.  If existing media attributes are used in a datachannel
>>
>>      subprotocol specific way, then a new dcsa usage level
>>
>>      MUST be defined for the existing media attribute.  Where the SDP
>>
>>     attribute is applicable to a particular subprotocol/s this SHALL
>> also
>>
>>      be registered by indicating the applicable subprotocol identifiers
>>
>>      (see
>> https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-34#section-8.
>> 5)
>> along with the dcsa usage level.
>>
>> Roni Even
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> 


From nobody Sun Apr 14 15:13:00 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FED1202CD for ; Sun, 14 Apr 2019 15:12:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4Ju9XSBvPcn for ; Sun, 14 Apr 2019 15:12:55 -0700 (PDT)
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 897151202CC for ; Sun, 14 Apr 2019 15:12:55 -0700 (PDT)
Received: by mail-pl1-x632.google.com with SMTP id bf11so7568175plb.12 for ; Sun, 14 Apr 2019 15:12:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1T5tmiG4wzonm+8OIMjT9ayi0gnLM6ZbYhH+QVkUQsM=; b=tw5DZWGmyBLi+RJgpVAXkEbLFfynh2z8ytGy5f5CIUa43Ey18JjSHMPou4wkv7Yua8 SHF24XW4gz6djRYJxDM+24TmhzUQ3y2O+LZunls8dMQDyZOm2/r6itXGcVQLDx9aeLNP Uww7GkbM3SEf4BMgfMXTpcx2tUaEd62+x3n/L0BiAncvyQE+2M3SjPqKE1jAXtPxNVct io3bB3xRzC1SfQNMHG6clDhWaySWhHekaRHXIAhASw+kh9C9CrfxECywjQgomgvoulM3 dJC/GIEJvDSW7uJMKVr9tF1wgBpUSZFKyhzV+v3NcbspFWxRVCBlS+COOqV+jkaPBasx Ej4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1T5tmiG4wzonm+8OIMjT9ayi0gnLM6ZbYhH+QVkUQsM=; b=eymHP5JLDHvb0wqzo8tNQi3qEaVFjuObA6MEfTcp0OmpL91NDpSSsdINO3VEfltBsd A0iTtU/GbFDZ/DsKQXUd250lkv5slHrtChwTz0LofOKC+Ygpl6fZ/mSVlJQ5e+V7CAxZ G9MZaVyHnkrDknjOJvO2u+DwJSUdl0Yjk7fBrYDEy7M1dXTQLr4KnVwJlEgLVASvMUY9 W7/qfS9KyouPDWBHQyp8ms0mIPIreAlq5k7Hw7IvGOD97VhikohSkopYbHewNnFpA38+ YNZ20btXeDPi5LnXwji563APA7MpjPcTvpYmk4ZpXfXVrwLizrxhZ1zeQHvOmN0XrTiv tuRg==
X-Gm-Message-State: APjAAAV42xuP8+xQBugOnr51iZJCfnWCNFHkcfp2UTXx97qUZKITBOLy ZYICu7I4SHkcw2aukZGFbAAJmTAPiHM=
X-Google-Smtp-Source: APXvYqxwQysKD1CGb6m6rmxIsaxwf404xjM2JTTP4PvM/r31LXxlrJ8It4+Rb9paSFLJM54aR1vW1Q==
X-Received: by 2002:a17:902:525:: with SMTP id 34mr59838543plf.138.1555279974673;  Sun, 14 Apr 2019 15:12:54 -0700 (PDT)
Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com. [209.85.210.179]) by smtp.gmail.com with ESMTPSA id a10sm16868545pfc.21.2019.04.14.15.12.53 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Apr 2019 15:12:53 -0700 (PDT)
Received: by mail-pf1-f179.google.com with SMTP id 8so7608964pfr.4 for ; Sun, 14 Apr 2019 15:12:53 -0700 (PDT)
X-Received: by 2002:a63:6a44:: with SMTP id f65mr32928342pgc.354.1555279972962;  Sun, 14 Apr 2019 15:12:52 -0700 (PDT)
MIME-Version: 1.0
References:    <3DD3D8D6-9B13-4F9D-80DD-F89B69240708@ericsson.com>   <98CF630B-5CCD-4CE4-84B4-81A4C53979DC@ericsson.com>    <1552A692-1020-43CA-B15E-92595729EE8B@ericsson.com>
In-Reply-To: <1552A692-1020-43CA-B15E-92595729EE8B@ericsson.com>
From: Roman Shpount 
Date: Sun, 14 Apr 2019 18:12:54 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Christer Holmberg 
Cc: Suhas Nandakumar , mmusic WG ,  Flemming Andreasen 
Content-Type: multipart/alternative; boundary="0000000000005099f1058684d65c"
Archived-At: 
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp
X-BeenThere: mmusic@ietf.org
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: Sun, 14 Apr 2019 22:12:59 -0000

--0000000000005099f1058684d65c
Content-Type: text/plain; charset="UTF-8"

Hi  Christer,

On Sun, Apr 14, 2019 at 4:43 AM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> But, the other reason was to correct issues and unspecified cases found in
> RFC 5245, and FQDN seems to be one such issue. Unfortunately we didn't
> detect it before publishing RFC 8445, so any generic ICE FQDN procedures
> would have to be in a separate draft.
>
> Again, I don't have a strong opinion on whether the SDP specific parts of
> FQDN are in ice-sip-sdp or in a separate draft.
>

I think the question is if FQDN is just another way to encode a single IP
address or if FQDN resolution affects ICE nomination process. If we decide
that demarcation point between ICE candidate signaling (ice-sip-sdp) and
ICE nomination i(RFC 8445) s the list of candidates with IP addresses, then
handling FQDN falls under signaling (ice-sip-sdp). If you think DNS
resolution affects ICE nomination process, then we will need a separate
draft for handling candidates with FQDN. I think former is the case and we
can put FQDN handling in ice-sip-sdp.

Keep in mind that we also need to decide on whether ice-pac should be an
> ice-sip-sdp dependency, in which case the publication may get delayed
> anyway (eventhough we hope to finalize ice-pac pretty fast).
>

I do not think ice-sip-sdp needs to have ice-pac as dependency, but I am
going to bring this up in another thread. I wanted to concentrate on FQDN
first and then address other ice-sip-sdp issues, such as the fact that SDP
offer can contain an empty candidate list.

> Please note, that if we specify that candidate line using FQDN
> contact-address MUST specify address type and FQDN MUST resolve
> > to a single address per address type, then FQDN handling is trivial:
> Agent should do a DNS resolution and use the result.
>
> Yes.
>
> > Figuring out how to handle multiple results per DNS query certainly
> warrants a separate draft and should be out of scope.
>
> We also need to keep in mind that, even though a single DNS request only
> returns a single address, if some kind of load balancing is used different
> DNS requests may return a different address. Perhaps we need to cover that
> by saying that an ICE agent must not change the IP address:port associated
> with a candidate.
>

This is part of the problem with DNS. One agent can publish FQDN that
points to a single IP, but when another agent runs the DNS query, it can
return more then one result (such as DNS64), different result (some sort of
NAT or proxy) or no results. DNS network can be adversarial and
deliberately send traffic through a proxy for man-on-the-middle attack. I
would prefer to limit what we require to each of the agents and then allow
connectivity checks to sort this out. So far the requirements are that
agent that creates the candidate list should only use FQDN that points to
single address of given type and agent receiving the candidate list should
only use candidate lines that produce a single address.

> a. Define how to specify address type in candidate line. This is
> certainly an SDP problem and I think is a pre-requisite to using any
> addresses, such as
> > FQDN, where address type is non-obvious
>
> HOW to define the address type in a candidate lite is for sure an SDP
> problem. But, the fact that the address type needs to be provided for a
> candidate is an ICE problem.
>

As I have mentioned earlier, this is the question of defining
responsibilities of signaling vs actual ICE processing. DNS resolution does
not have to be part of ICE processing and can be part of signaling. ICE
processing can always start with the list of candidates with addresses
already resolved.

> b. Specify that if agent compliant with ice-sip-sdp uses FQDN
> contact-address, it MUST specify addrtype for the candidate.
>
> Do we know how an existing implementation would process the addrtype? Are
> there any procedures regarding unsupported candidate properties?
>

 Since I just invented addrtype, I do not think anything would process it.
Unsupported candidate properties are supposed to be ignored. We see a lot
of unsupported properties in the wild, such as "generation" and
"network-id". These extra candidate attributes do not seem to cause any
interop issues, so I do not think adding a new candidate type attribute
would be a problem

> c. Specify that if FQDN resolves to a single address for the specified
> family then that this address is used for this candidate. Candidate lines
> with
> > FQDN returning multiple results per query MUST be ignored until their
> handling is defined in a future draft
> >
> > d. Specify what to do with FQDN without address type specified such as
> SDP from legacy RFC 5245 implementations. We can go with try AAAA
> resolution
> > first and use if single address is returned. If nothing is returned from
> AAAA query, try A query. If single address is returned, used that address,
> ignore
> > the candidate line otherwise. This matches RFC 5245 language and should
> work in all the same situations where RFC 5245 implementations were working.
>
> d) works assuming both ICE agents get the same IP address:port from DNS.
>

Option d  is best effort for interop with current RFC 5245 implementations.
It would work in the same cases when RFC 5245 implementation would. I am
not sure any current RFC 5245 implementations actually use FQDN, but if
such implementations do exist, this is what RFC 5245 specified.

> What do you think?
>
> I think you suggestion is good. But, as I have indicated, I would like to
> have a generic ICE FQDN draft that ice-sip-sdp (or a separate MMUSIC draft)
> references.
>
> Similarly to ice-pac, I think such draft could be produced relatively
> fast. It more or less only needs to say that:
>
> 1) An ICE agent that uses FQDN needs to provide one candidate per address
> family, and indicate the addrtype for each of those candidates.
> 2) Some text regarding backward compatibility. Do we assume some default
> behavior by existing implementations, or do we require an ICE option?
>

I do not think we need an ICE option. I think presence of addrtype can be
sufficient.

This being said we need to decide two things:

1. Does FQDN resolution belongs to ICE processing? In this case candidate
list includes FQDN with address type and ICE processing describes how FQDN
are resolved and converted to addresses. Or, alternatively, does FQDN
resolution belongs to ICE signaling? In this case candidate list includes
resolved address and ICE agent deals with addresses only.

2. Do we specify how to deal with FQDN in ice-sip-sdp or do we specify in
ice-sip-sdp that FQDN must be ignored and their handling is defined in some
other draft?

Based on answers to these questions we can deiced how many additional
drafts we will need.

Regards,
______________
Roman Shpount

--0000000000005099f1058684d65c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi=C2=A0

Christer,

On Sun, Apr 14, 2019 at 4:43 AM Christer Holmberg <=
christer.holmberg@ericsso=
n.com> wrote:
But, the other reason was to co=
rrect issues and unspecified cases found in RFC 5245, and FQDN seems to be =
one such issue. Unfortunately we didn't detect it before publishing RFC=
 8445, so any generic ICE FQDN procedures would have to be in a separate dr=
aft.



Again, I don't have a strong opinion on whether the SDP specific parts =
of FQDN are in ice-sip-sdp or in a separate draft.
=C2=
=A0
I think the question is if FQDN is just another way to encode=
 a single IP address or if FQDN resolution affects ICE nomination process. =
If we decide that demarcation point between ICE candidate signaling (ice-si=
p-sdp) and ICE nomination i(RFC 8445) s the list of candidates with IP addr=
esses, then handling FQDN falls under signaling (ice-sip-sdp). If you think=
 DNS resolution affects ICE nomination process, then we will need a separat=
e draft for handling candidates with FQDN. I think former is the case and w=
e can put FQDN handling in ice-sip-sdp.

Keep in mind that we also need to decide=
 on whether ice-pac should be an ice-sip-sdp dependency, in which case the =
publication may get delayed anyway (eventhough we hope to finalize ice-pac =
pretty fast).
=C2=A0
I do not think ice-sip-=
sdp needs to have ice-pac as dependency, but I am going to bring this up in=
 another thread. I wanted to concentrate on FQDN first and then address oth=
er ice-sip-sdp issues, such as the fact that SDP offer can contain an empty=
 candidate list.

> Please note, that if we specify that candidate line using =
FQDN contact-address MUST specify address type and FQDN MUST resolve 

> to a single address per address type, then FQDN handling is trivial: A=
gent should do a DNS resolution and use the result. 



Yes.



> Figuring out how to handle multiple results per DNS query certainly wa=
rrants a separate draft and should be out of scope.=C2=A0



We also need to keep in mind that, even though a single DNS request only re=
turns a single address, if some kind of load balancing is used different DN=
S requests may return a different address. Perhaps we need to cover that by=
 saying that an ICE agent must not change the IP address:port associated wi=
th a candidate.
=C2=A0
This is part of the p=
roblem with DNS. One agent can publish FQDN that points to a single IP, but=
 when another agent runs the DNS query, it can return more then one result =
(such as DNS64), different result (some sort of NAT or proxy) or no results=
. DNS network can be adversarial and deliberately send traffic through a pr=
oxy for man-on-the-middle attack. I would prefer to limit what we require t=
o each of the agents and then allow connectivity checks to sort this out. S=
o far the requirements are that agent that creates the candidate list shoul=
d only use FQDN that points to single address of given type and agent recei=
ving the candidate list should only use candidate lines that produce a sing=
le address.

> a. Define how to specify address type in candidate line. This i=
s certainly an SDP problem and I think is a pre-requisite to using any addr=
esses, such as 

> FQDN, where address type is non-obvious



HOW to define the address type in a candidate lite is for sure an SDP probl=
em. But, the fact that the address type needs to be provided for a candidat=
e is an ICE problem. 
=C2=A0
As I have menti=
oned earlier, this is the question of defining responsibilities of signalin=
g vs actual ICE processing. DNS resolution does not have to be part of ICE =
processing and can be part of signaling. ICE processing can always start wi=
th the list of candidates with addresses already resolved.

> b. Specify that =
if agent compliant with ice-sip-sdp uses FQDN contact-address, it MUST spec=
ify addrtype for the candidate.



Do we know how an existing implementation would process the addrtype? Are t=
here any procedures regarding unsupported candidate properties?

=C2=A0Since I just invented addrtype, I do not thi=
nk anything would process it. Unsupported candidate properties are supposed=
 to be ignored. We see a lot of unsupported properties in the wild, such as=
 "generation" and "network-id". These extra candidate a=
ttributes do not seem to cause any interop issues, so I do not think adding=
 a new candidate type attribute would be a problem

> c. Specify that if FQDN =
resolves to a single address for the specified family then that this addres=
s is used for this candidate. Candidate lines with 

> FQDN returning multiple results per query MUST be ignored until their =
handling is defined in a future draft

>

> d. Specify what to do with FQDN without address type specified such as=
 SDP from legacy RFC 5245 implementations. We can go with try AAAA resoluti=
on 

> first and use if single address is returned. If nothing is returned fr=
om AAAA query, try A query. If single address is returned, used that addres=
s, ignore 

> the candidate line otherwise. This matches RFC 5245 language and shoul=
d work in all the same situations where RFC 5245 implementations were worki=
ng.



d) works assuming both ICE agents get the same IP address:port from DNS.
=C2=A0
Option d=C2=A0 is best effort for inter=
op with current RFC 5245 implementations. It would work in the same cases w=
hen RFC 5245 implementation would. I am not sure any current RFC 5245 imple=
mentations actually use FQDN, but if such implementations do exist, this is=
 what RFC 5245 specified.

> What do you think?



I think you suggestion is good. But, as I have indicated, I would like to h=
ave a generic ICE FQDN draft that ice-sip-sdp (or a separate MMUSIC draft) =
references.



Similarly to ice-pac, I think such draft could be produced relatively fast.=
 It more or less only needs to say that:



1) An ICE agent that uses FQDN needs to provide one candidate per address f=
amily, and indicate the addrtype for each of those candidates.

2) Some text regarding backward compatibility. Do we assume some default be=
havior by existing implementations, or do we require an ICE option?

I do not think we need an ICE option. I think =
presence of addrtype can be sufficient.

This being=
 said we need to decide two things:

1. Does FQDN r=
esolution belongs to ICE processing? In this case candidate list includes F=
QDN with address type and ICE processing describes how FQDN are resolved an=
d converted to addresses. Or, alternatively, does FQDN resolution belongs t=
o ICE signaling? In this case candidate list includes resolved address and =
ICE agent deals with addresses only.

2. Do we spec=
ify how to deal with FQDN in ice-sip-sdp or do we specify in ice-sip-sdp th=
at FQDN must be ignored and their handling is defined in some other draft?<=
/div>

Based on answers to these questions we can deiced =
how many additional drafts we will need.

Regards,<=
/div>
______________
Roman Shpount


--0000000000005099f1058684d65c--


From nobody Sun Apr 14 22:05:04 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F9D120075; Sun, 14 Apr 2019 22:04:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.19
X-Spam-Level: 
X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWQYmyxoMm4i; Sun, 14 Apr 2019 22:04:50 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25A1E120052; Sun, 14 Apr 2019 22:04:50 -0700 (PDT)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 59FF0C0C4F653A647DF5; Mon, 15 Apr 2019 06:04:48 +0100 (IST)
Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 15 Apr 2019 06:04:47 +0100
Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.138]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0415.000; Mon, 15 Apr 2019 13:04:43 +0800
From: "Roni Even (A)" 
To: Magnus Westerlund 
CC: "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-data-channel-sdpneg@ietf.org" , "mmusic@ietf.org" , Adam Roach , The IESG 
Thread-Topic: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)
Thread-Index: AQHU66fNA40h4UsP7kq3a/Vv5QT6waYzi0CAgAkt3MA=
Date: Mon, 15 Apr 2019 05:04:42 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18CDC02D@dggemm526-mbx.china.huawei.com>
References: <155446588097.13196.6373243259627185094.idtracker@ietfa.amsl.com> <1afcb116-36cb-be51-81ac-e78fc52c9255@nostrum.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.202.102]
Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD18CDC02Ddggemm526mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)
X-BeenThere: mmusic@ietf.org
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: Mon, 15 Apr 2019 05:04:54 -0000

--_000_6E58094ECC8D8344914996DAD28F1CCD18CDC02Ddggemm526mbxchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgTWFnbnVzLA0KSSByZXNwb25kZWQgdG8geW91ciBjb21tZW50cyBhbmQgdGhpcyBpcyBjdXJy
ZW50bHkgdGhlIG9ubHkgb3BlbiBjb21tZW50IGZyb20gYWxsIHRoZSBjb21tZW50cyB0aGF0IHdl
IGdvdCAgdGhhdCBJIG5lZWQgdG8gYWRkcmVzcw0KDQpJIHRoaW5rIHRoYXQgdGhlIHRleHQgcHJv
cG9zZWQgYnkgQWRhbSBtYWtlIHNlbnNlIHNvIEkgc3VnZ2VzdCBhZGRpbmcgdG8gc2VjdGlvbiA1
LjEuMyB0aGUgZm9sbG93aW5nIHRleHQNCg0KDQoNCg0K4oCcSW4gb3JkZXIgdG8gY29tbXVuaWNh
dGUgd2l0aCBXRWJSVEMgQVBJIHRoZSBsYWJlbCBhdHRyaWJ1dGUgc2hvdWxkDQoNCiAgKiAgIFNl
cmlhbGl6ZSB0aGUgV2ViUlRDIGxhYmVsIGFzIGEgVVRGLTggc3RyaW5nDQogICogICBUcmVhdCB0
aGUgVVRGLTggc2VyaWFsaXphdGlvbiBhcyBhIHNlcmllcyBvZiBieXRlcw0KICAqICAgRm9yIGVh
Y2ggYnl0ZSBpbiB0aGUgc2VyaWFsaXphdGlvbjoNCiAgICAgKiAgIElmIHRoZSBieXRlIGNhbiBi
ZSBleHByZXNzZWQgYXMgYSBgcXVvdGVkLWNoYXJgLCBkbyBzbw0KICAgICAqICAgT3RoZXJ3aXNl
LCBleHByZXNzIHRoZSBieXRlIGFzIGFuIGBlc2NhcGVkLWNoYXJgLg0K4oCcDQoNCkRvZXMgdGhp
cyBzb3VuZCByZWFzb25hYmxlIHRvIHlvdQ0KDQpSZWdhcmRzDQpSb25pDQoNCg0KRnJvbTogQWRh
bSBSb2FjaCBbbWFpbHRvOmFkYW1Abm9zdHJ1bS5jb21dDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAw
OSwgMjAxOSA3OjUwIFBNDQpUbzogTWFnbnVzIFdlc3Rlcmx1bmQ7IFRoZSBJRVNHDQpDYzogbW11
c2ljLWNoYWlyc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5l
Z0BpZXRmLm9yZzsgbW11c2ljQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW01NVVNJQ10gTWFnbnVz
IFdlc3Rlcmx1bmQncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtbW11c2ljLWRhdGEtY2hhbm5lbC1z
ZHBuZWctMjU6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQoNCk9uIDQvOS8xOSA0OjAwIEFN
LCBNYWdudXMgV2VzdGVybHVuZCB3cm90ZToNCk9uIDIwMTktMDQtMDggMTc6NTUsIEFkYW0gUm9h
Y2ggd3JvdGU6DQpPbiA0LzUvMTkgNzowNCBBTSwgTWFnbnVzIFdlc3Rlcmx1bmQgdmlhIERhdGF0
cmFja2VyIHdyb3RlOg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkRJU0NVU1M6DQoNCi0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0NCg0KDQoNClRoZXJlIG1pZ2h0IGJlIGEgc2VyaW91cyBpc3N1ZSBpbiBsYWJlbCBkZWZpbml0
aW9uLg0KDQoNCg0KNS4xLjMuICBMYWJlbCBQYXJhbWV0ZXINCg0KDQoNCiAgIFRoZSAnbGFiZWwn
IHBhcmFtZXRlciBpbmRpY2F0ZXMgdGhlIG5hbWUgb2YgdGhlIGNoYW5uZWwuICBJdA0KDQogICBy
ZXByZXNlbnRzIGEgbGFiZWwgdGhhdCBjYW4gYmUgdXNlZCB0byBkaXN0aW5ndWlzaCwgaW4gdGhl
IGNvbnRleHQgb2YNCg0KICAgdGhlIFdlYlJUQyBBUEkgW1dlYlJ0Y0FQSV0sIGFuIFJUQ0RhdGFD
aGFubmVsIG9iamVjdCBmcm9tIG90aGVyDQoNCiAgIFJUQ0RhdGFDaGFubmVsIG9iamVjdHMuICBU
aGlzIHBhcmFtZXRlciBtYXBzIHRvIHRoZSAnTGFiZWwnIHBhcmFtZXRlcg0KDQogICBkZWZpbmVk
IGluIFtJLUQuaWV0Zi1ydGN3ZWItZGF0YS1wcm90b2NvbF0uICBUaGUgJ2xhYmVsJyBwYXJhbWV0
ZXIgaXMNCg0KICAgb3B0aW9uYWwuICBJZiBpdCBpcyBub3QgcHJlc2VudCwgdGhlbiBpdHMgdmFs
dWUgZGVmYXVsdHMgdG8gdGhlIGVtcHR5DQoNCiAgIHN0cmluZy4NCg0KDQoNCiAgbGFiZWwtb3B0
ICAgICAgID0gImxhYmVsPSIgcXVvdGVkLXN0cmluZw0KDQogIHF1b3RlZC1zdHJpbmcgICA9IERR
VU9URSAqKHF1b3RlZC1jaGFyIC8gZXNjYXBlZC1jaGFyKSBEUVVPVEUNCg0KICBxdW90ZWQtY2hh
ciAgICAgPSBTUCAvIHF1b3RlZC12aXNpYmxlDQoNCiAgcXVvdGVkLXZpc2libGUgID0gJXgyMSAv
ICV4MjMtMjQgLyAleDI2LTdFIDsgVkNIQVIgd2l0aG91dCAiIG9yICUNCg0KICBlc2NhcGVkLWNo
YXIgICAgPSAiJSIgSEVYRElHIEhFWERJRw0KDQoNCg0KSSBpbnRlcnByZXQgdGhhdCBhcyB0aGUg
aW50ZW50aW9uIGlzIHRvIGVuYWJsZSB0aGUgU0RQIEF0dHJpYnV0ZSB0byBjYXJyeSB0aGUNCg0K
bGFiZWwgYXMgZGVmaW5lZCBpbiBXM0MgQVBJLiBUaGF0IHZhbHVlIGlzIGluIHRoZSBjdXJyZW50
IGNhbmRpZGF0YXRlDQoNCnNwZWNpZmljYXRpb24gYW4gaHR0cHM6Ly93d3cudzMub3JnL1RSL3dl
YnJ0Yy8gYXMgYW4gVVNWU3N0aW5nDQoNCihodHRwczovL2hleWNhbS5naXRodWIuaW8vd2ViaWRs
LyNpZGwtVVNWU3RyaW5nKS4gQW5kIGluIHRoZSByZWZlcmVuY2UgdmVyc2lvbg0KDQpvZiB0aGUg
V2ViUlRDIEFQSSBhcyBhbiBET01zdHJpbmcuIEJvdGggYXJlIG5vdCBsaW1pdGVkIHRvIEFTQ0lJ
IGFuZCBtYXkNCg0KY29udGFpbiBhbnkgVW5pY29kZSBjaGFyYWN0ZXJzLiBUaHVzIHRoZSBlc2Nh
cGluZyBtZWNoYW5pc20gZGVmaW5lZCBhcHBlYXIgdG8NCg0KYmUgaW5zdWZmaWNpZW50Lg0KDQoN
Cg0KSSB0aGluayB0aGUgInF1b3RlZC1zdHJpbmciIG5lZWQgYSBkZWZpbml0aW9uIG9mIHdoYXQg
dHlwZSBvZiBzdHJpbmcgdGhpcyB0cnVseQ0KDQphcmUgc28gdGhhdCBpdCBpcyBjbGVhciB3aGF0
IGEgY2hhcmFjdGVyIGluIHRoZSBzdHJpbmcgaXMuDQoNCg0KDQpJbiBhZGRpdGlvbiB0aGUgc3Bl
Y2lmaWNhdGlvbiBvZiBlc2NhcGluZyBpcyB1bmRlcnNzcGVjaWZpZWQuIEkgd291bGQgcmVjb21t
ZW5kDQoNCmF0IGxlYXN0IGFkZGluZyBkaXNjdXNzaW9uIG9mIHRoZSBuZWVkIGFuZCBob3cgdG8g
ZXNjYXBlIERRVU9URSBhbmQgJSB0aGF0IGNhbg0KDQpiZSByZWxhdGl2ZWx5IGNvbW1vbiBvcGVy
YXRpb25zLg0KDQoNCg0KSSBjYW4gc2VlIHRoYXQgdGhpcyBjb3VsZCBiZW5lZml0IGZyb20gc29t
ZSBleHBsaWNpdCBkZXRhaWwgYWJvdXQgaG93IHRvIGNvbnZlcnQgdGhlIGNpdGVkIFVTVlN0cmlu
ZyBzdHJpbmcgaW50byB0aGUgInF1b3RlZC1zdHJpbmciIGNvbnN0cnVjdCBkZWZpbmVkIGhlcmUu
IEkgdGhpbmsgdGhpcyByb3VnaGx5IGNvbnNpc3RzIG9mOg0KDQogICogICBTZXJpYWxpemUgdGhl
IFdlYlJUQyBsYWJlbCBhcyBhIFVURi04IHN0cmluZw0KICAqICAgVHJlYXQgdGhlIFVURi04IHNl
cmlhbGl6YXRpb24gYXMgYSBzZXJpZXMgb2YgYnl0ZXMNCiAgKiAgIEZvciBlYWNoIGJ5dGUgaW4g
dGhlIHNlcmlhbGl6YXRpb246DQoNCiAgICAgKiAgIElmIHRoZSBieXRlIGNhbiBiZSBleHByZXNz
ZWQgYXMgYSBgcXVvdGVkLWNoYXJgLCBkbyBzbw0KICAgICAqICAgT3RoZXJ3aXNlLCBleHByZXNz
IHRoZSBieXRlIGFzIGFuIGBlc2NhcGVkLWNoYXJgLg0KDQpXb3VsZCBpbmNsdWRpbmcgdGV4dCB0
byB0aGF0IGVmZmVjdCBzYXRpc2Z5IHlvdXIgY29uY2Vybj8NCg0KWWVzIGl0IHdvdWxkIGJlIGNs
ZWFyIHdoYXQgaXMgZXhwZWN0ZWQuIEhvd2V2ZXIsIEkgZmFpbCB0byB1bmRlcnN0YW5kIHdoeSBv
bmUgbmVlZCB0byBBU0NJSWlmeSBhbmQgZXNjYXBlIHRoZSBVVEYtOCBlbmNvZGVkIGNoYXJhY3Rl
cnMgd2hlcmUgb25lIGNvdWxkIHNpbXBseSBkZWZpbmUgdGhlIGxhYmVsIHZhbHVlIGFzIGFuIFVU
Ri04IHN0cmluZyBzb21ldGhpbmcgdGhhdCBpcyBjb21wYXRpYmxlIHdpdGggU0RQIHNwZWNpZmlj
YXRpb24uIFdvdWxkbid0IHRoYXQgcmVkdWNlIHRoZSBzZXQgb2YgY2hhcmFjdGVycyBuZWVkaW5n
IGVzY2FwaW5nIHRvIGEgbXVjaCBzbWFsbGVyIHNldC4NCg0KDQoNClRoYXQncyBhIGxpdHRsZSB0
cmlja3kuIFJGQyA0NTY2OiAiU0RQIGFsc28gYWxsb3dzIG90aGVyIGNoYXJhY3RlciBzZXRzIHN1
Y2ggYXMgSVNPIDg4NTktMSB0byBiZSB1c2VkIHdoZW4gZGVzaXJlZC4iDQoNCkV2ZW4gaWYgd2Ug
anVzdCBjb25zdHJhaW4gdGhpcyB0byBTSVAsIFJGQyAzMjYxOiAiV2hlbiBubyBleHBsaWNpdCBj
aGFyc2V0IHBhcmFtZXRlciBpcyBwcm92aWRlZCBieSB0aGUgc2VuZGVyLCBtZWRpYSBzdWJ0eXBl
cyBvZiB0aGUgJ3RleHQnIHR5cGUgYXJlIGRlZmluZWQgdG8gaGF2ZSBhIGRlZmF1bHQgY2hhcnNl
dCB2YWx1ZSBvZiAnVVRGLTgnLiINCg0KU28gdGhlcmUncyBhIGJpYXMgdG93YXJkcyBVVEYtOCwg
YnV0IG5vIHN0cmljdCByZXF1aXJlbWVudC4NCg0KSSdkIHN1cHBvcnQgYSBzaG9ydCBkb2N1bWVu
dCB0aGF0IGRlcHJlY2F0ZWQgbm9uLVVURi04IGVuY29kaW5ncyBvZiBTRFAgc28gdGhhdCBzcGVj
aWZpY2F0aW9ucyBsaWtlIHRoaXMgb25lIGNvdWxkIHNpbXBseSBhc3N1bWUgdGhhdCB0aGUgZnVs
bCBjaGFyYWN0ZXIgc2V0IGNhbiBiZSB1c2VkIGRpcmVjdGx5LCBidXQgdGhhdCdzIG5vdCB0aGUg
Y3VycmVudCBzdGF0ZSBvZiBhZmZhaXJzLg0KDQovYQ0K

--_000_6E58094ECC8D8344914996DAD28F1CCD18CDC02Ddggemm526mbxchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9
DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg
MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl
LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z
b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0
aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn
aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy
LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJs
YWNrO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU
TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw
MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglj
b2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1l
OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv
LXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsN
Cgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJz
b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y
OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7
DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx
MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv
bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3Qg
bDANCgl7bXNvLWxpc3QtaWQ6NDYxNzczMDYyOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNjg0
MzIwNTE2O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs
ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv
LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6
bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4
dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0
aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w
cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToi
VGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m
b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6
MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u
MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n
czt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K
CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z
aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps
ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0
Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu
MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxl
dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2
ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt
aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt
YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41
aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp
bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9
DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m
b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl
bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C
pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0
Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo2MTM3
MDkyMzc7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEzNzM5NzQzNDt9DQpAbGlzdCBsMTpsZXZl
bDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C
tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u
OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7
DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50
Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy
aWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxp
c3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2
ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z
aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJ
e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm
dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm
b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i
ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z
dG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu
dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n
ZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl
dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv
LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg
bDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl
OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21z
by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv
LWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN
Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250
LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt
Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w
OjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot
LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu
Z3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47
fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg
djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm
IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw
IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm
XS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJi
bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
SGkgTWFnbnVzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHJlc3BvbmRlZCB0byB5
b3VyIGNvbW1lbnRzIGFuZCB0aGlzIGlzIGN1cnJlbnRseSB0aGUgb25seSBvcGVuIGNvbW1lbnQg
ZnJvbSBhbGwgdGhlIGNvbW1lbnRzIHRoYXQgd2UgZ290ICZuYnNwO3RoYXQgSSBuZWVkIHRvIGFk
ZHJlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgdGhhdCB0aGUgdGV4dCBwcm9wb3NlZCBieSBBZGFtIG1h
a2Ugc2Vuc2Ugc28gSSBzdWdnZXN0IGFkZGluZyB0byBzZWN0aW9uIDUuMS4zIHRoZSBmb2xsb3dp
bmcgdGV4dA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnEluIG9yZGVyIHRvIGNvbW11bmljYXRl
IHdpdGggV0ViUlRDIEFQSSB0aGUgbGFiZWwgYXR0cmlidXRlIHNob3VsZDxvOnA+PC9vOnA+PC9w
Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBs
ZXZlbDEgbGZvMiI+DQpTZXJpYWxpemUgdGhlIFdlYlJUQyBsYWJlbCBhcyBhIFVURi04IHN0cmlu
ZzxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVs
MSBsZm8yIj4NClRyZWF0IHRoZSBVVEYtOCBzZXJpYWxpemF0aW9uIGFzIGEgc2VyaWVzIG9mIGJ5
dGVzPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2
ZWwxIGxmbzIiPg0KRm9yIGVhY2ggYnl0ZSBpbiB0aGUgc2VyaWFsaXphdGlvbjo8bzpwPjwvbzpw
Pg0KPHVsIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omww
IGxldmVsMiBsZm8yIj4NCklmIHRoZSBieXRlIGNhbiBiZSBleHByZXNzZWQgYXMgYSBgcXVvdGVk
LWNoYXJgLCBkbyBzbzxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s
aXN0OmwwIGxldmVsMiBsZm8yIj4NCk90aGVyd2lzZSwgZXhwcmVzcyB0aGUgYnl0ZSBhcyBhbiBg
ZXNjYXBlZC1jaGFyYC48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvbGk+PC91bD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPuKAnDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb2VzIHRoaXMgc291bmQg
cmVhc29uYWJsZSB0byB5b3U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkczxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Um9uaTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp
ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+
RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3Rl
eHQiPiBBZGFtIFJvYWNoIFttYWlsdG86YWRhbUBub3N0cnVtLmNvbV0NCjxicj4NCjxiPlNlbnQ6
PC9iPiBUdWVzZGF5LCBBcHJpbCAwOSwgMjAxOSA3OjUwIFBNPGJyPg0KPGI+VG86PC9iPiBNYWdu
dXMgV2VzdGVybHVuZDsgVGhlIElFU0c8YnI+DQo8Yj5DYzo8L2I+IG1tdXNpYy1jaGFpcnNAaWV0
Zi5vcmc7IGRyYWZ0LWlldGYtbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWdAaWV0Zi5vcmc7IG1t
dXNpY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW01NVVNJQ10gTWFnbnVzIFdl
c3Rlcmx1bmQncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBu
ZWctMjU6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpPG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDQvOS8xOSA0OjAwIEFNLCBNYWdudXMg
V2VzdGVybHVuZCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5
bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+T24gMjAxOS0wNC0wOCAxNzo1NSwgQWRhbSBSb2FjaCB3cm90ZTo8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7
bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gNC81
LzE5IDc6MDQgQU0sIE1hZ251cyBXZXN0ZXJsdW5kIHZpYSBEYXRhdHJhY2tlciB3cm90ZTo8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7
bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT5ESVNDVVNTOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPi0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGVyZSBt
aWdodCBiZSBhIHNlcmlvdXMgaXNzdWUgaW4gbGFiZWwgZGVmaW5pdGlvbi48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT41LjEuMy4mbmJzcDsgTGFi
ZWwgUGFyYW1ldGVyPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By
ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoZSAnbGFiZWwnIHBhcmFtZXRlciBpbmRpY2F0ZXMgdGhl
IG5hbWUgb2YgdGhlIGNoYW5uZWwuJm5ic3A7IEl0PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7Jm5ic3A7IHJlcHJlc2VudHMgYSBsYWJlbCB0aGF0IGNhbiBiZSB1c2VkIHRvIGRpc3Rpbmd1
aXNoLCBpbiB0aGUgY29udGV4dCBvZjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw
OyB0aGUgV2ViUlRDIEFQSSBbV2ViUnRjQVBJXSwgYW4gUlRDRGF0YUNoYW5uZWwgb2JqZWN0IGZy
b20gb3RoZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgUlRDRGF0YUNoYW5u
ZWwgb2JqZWN0cy4mbmJzcDsgVGhpcyBwYXJhbWV0ZXIgbWFwcyB0byB0aGUgJ0xhYmVsJyBwYXJh
bWV0ZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgZGVmaW5lZCBpbiBbSS1E
LmlldGYtcnRjd2ViLWRhdGEtcHJvdG9jb2xdLiZuYnNwOyBUaGUgJ2xhYmVsJyBwYXJhbWV0ZXIg
aXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgb3B0aW9uYWwuJm5ic3A7IElm
IGl0IGlzIG5vdCBwcmVzZW50LCB0aGVuIGl0cyB2YWx1ZSBkZWZhdWx0cyB0byB0aGUgZW1wdHk8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgc3RyaW5nLjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyBsYWJlbC1vcHQm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPSAmcXVvdDtsYWJlbD0mcXVvdDsg
cXVvdGVkLXN0cmluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyBxdW90ZWQtc3RyaW5n
Jm5ic3A7Jm5ic3A7ID0gRFFVT1RFICoocXVvdGVkLWNoYXIgLyBlc2NhcGVkLWNoYXIpIERRVU9U
RTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyBxdW90ZWQtY2hhciZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyA9IFNQIC8gcXVvdGVkLXZpc2libGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m
bmJzcDsgcXVvdGVkLXZpc2libGUmbmJzcDsgPSAleDIxIC8gJXgyMy0yNCAvICV4MjYtN0UgOyBW
Q0hBUiB3aXRob3V0ICZxdW90OyBvciAlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7IGVz
Y2FwZWQtY2hhciZuYnNwOyZuYnNwOyZuYnNwOyA9ICZxdW90OyUmcXVvdDsgSEVYRElHIEhFWERJ
RzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkkg
aW50ZXJwcmV0IHRoYXQgYXMgdGhlIGludGVudGlvbiBpcyB0byBlbmFibGUgdGhlIFNEUCBBdHRy
aWJ1dGUgdG8gY2FycnkgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+bGFiZWwgYXMgZGVmaW5l
ZCBpbiBXM0MgQVBJLiBUaGF0IHZhbHVlIGlzIGluIHRoZSBjdXJyZW50IGNhbmRpZGF0YXRlPG86
cD48L286cD48L3ByZT4NCjxwcmU+c3BlY2lmaWNhdGlvbiBhbiA8YSBocmVmPSJodHRwczovL3d3
dy53My5vcmcvVFIvd2VicnRjLyI+aHR0cHM6Ly93d3cudzMub3JnL1RSL3dlYnJ0Yy88L2E+IGFz
IGFuIFVTVlNzdGluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPig8YSBocmVmPSJodHRwczovL2hl
eWNhbS5naXRodWIuaW8vd2ViaWRsLyNpZGwtVVNWU3RyaW5nIj5odHRwczovL2hleWNhbS5naXRo
dWIuaW8vd2ViaWRsLyNpZGwtVVNWU3RyaW5nPC9hPikuIEFuZCBpbiB0aGUgcmVmZXJlbmNlIHZl
cnNpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5vZiB0aGUgV2ViUlRDIEFQSSBhcyBhbiBET01z
dHJpbmcuIEJvdGggYXJlIG5vdCBsaW1pdGVkIHRvIEFTQ0lJIGFuZCBtYXk8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT5jb250YWluIGFueSBVbmljb2RlIGNoYXJhY3RlcnMuIFRodXMgdGhlIGVzY2Fw
aW5nIG1lY2hhbmlzbSBkZWZpbmVkIGFwcGVhciB0bzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmJl
IGluc3VmZmljaWVudC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPHByZT5JIHRoaW5rIHRoZSAmcXVvdDtxdW90ZWQtc3RyaW5nJnF1b3Q7IG5lZWQgYSBk
ZWZpbml0aW9uIG9mIHdoYXQgdHlwZSBvZiBzdHJpbmcgdGhpcyB0cnVseTxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPmFyZSBzbyB0aGF0IGl0IGlzIGNsZWFyIHdoYXQgYSBjaGFyYWN0ZXIgaW4gdGhl
IHN0cmluZyBpcy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl
Pg0KPHByZT5JbiBhZGRpdGlvbiB0aGUgc3BlY2lmaWNhdGlvbiBvZiBlc2NhcGluZyBpcyB1bmRl
cnNzcGVjaWZpZWQuIEkgd291bGQgcmVjb21tZW5kPG86cD48L286cD48L3ByZT4NCjxwcmU+YXQg
bGVhc3QgYWRkaW5nIGRpc2N1c3Npb24gb2YgdGhlIG5lZWQgYW5kIGhvdyB0byBlc2NhcGUgRFFV
T1RFIGFuZCAlIHRoYXQgY2FuPG86cD48L286cD48L3ByZT4NCjxwcmU+YmUgcmVsYXRpdmVseSBj
b21tb24gb3BlcmF0aW9ucy48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHA+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8cD5JIGNhbiBzZWUgdGhhdCB0aGlzIGNvdWxkIGJlbmVmaXQg
ZnJvbSBzb21lIGV4cGxpY2l0IGRldGFpbCBhYm91dCBob3cgdG8gY29udmVydCB0aGUgY2l0ZWQg
VVNWU3RyaW5nIHN0cmluZyBpbnRvIHRoZSAmcXVvdDtxdW90ZWQtc3RyaW5nJnF1b3Q7IGNvbnN0
cnVjdCBkZWZpbmVkIGhlcmUuIEkgdGhpbmsgdGhpcyByb3VnaGx5IGNvbnNpc3RzIG9mOjxvOnA+
PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28t
bGlzdDpsMSBsZXZlbDEgbGZvMSI+DQpTZXJpYWxpemUgdGhlIFdlYlJUQyBsYWJlbCBhcyBhIFVU
Ri04IHN0cmluZzxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0
OmwxIGxldmVsMSBsZm8xIj4NClRyZWF0IHRoZSBVVEYtOCBzZXJpYWxpemF0aW9uIGFzIGEgc2Vy
aWVzIG9mIGJ5dGVzPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxp
c3Q6bDEgbGV2ZWwxIGxmbzEiPg0KRm9yIGVhY2ggYnl0ZSBpbiB0aGUgc2VyaWFsaXphdGlvbjo8
bzpwPjwvbzpwPjwvbGk+PC91bD4NCjx1bCB0eXBlPSJkaXNjIj4NCjx1bCB0eXBlPSJjaXJjbGUi
Pg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDIgbGZvMSI+DQpJZiB0
aGUgYnl0ZSBjYW4gYmUgZXhwcmVzc2VkIGFzIGEgYHF1b3RlZC1jaGFyYCwgZG8gc288bzpwPjwv
bzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDIgbGZvMSI+
DQpPdGhlcndpc2UsIGV4cHJlc3MgdGhlIGJ5dGUgYXMgYW4gYGVzY2FwZWQtY2hhcmAuPG86cD48
L286cD48L2xpPjwvdWw+DQo8L3VsPg0KPHA+V291bGQgaW5jbHVkaW5nIHRleHQgdG8gdGhhdCBl
ZmZlY3Qgc2F0aXNmeSB5b3VyIGNvbmNlcm4/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+
DQo8cD5ZZXMgaXQgd291bGQgYmUgY2xlYXIgd2hhdCBpcyBleHBlY3RlZC4gSG93ZXZlciwgSSBm
YWlsIHRvIHVuZGVyc3RhbmQgd2h5IG9uZSBuZWVkIHRvIEFTQ0lJaWZ5IGFuZCBlc2NhcGUgdGhl
IFVURi04IGVuY29kZWQgY2hhcmFjdGVycyB3aGVyZSBvbmUgY291bGQgc2ltcGx5IGRlZmluZSB0
aGUgbGFiZWwgdmFsdWUgYXMgYW4gVVRGLTggc3RyaW5nIHNvbWV0aGluZyB0aGF0IGlzIGNvbXBh
dGlibGUgd2l0aCBTRFAgc3BlY2lmaWNhdGlvbi4gV291bGRuJ3QNCiB0aGF0IHJlZHVjZSB0aGUg
c2V0IG9mIGNoYXJhY3RlcnMgbmVlZGluZyBlc2NhcGluZyB0byBhIG11Y2ggc21hbGxlciBzZXQu
IDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8cD5UaGF0J3MgYSBsaXR0bGUgdHJpY2t5LiBSRkMgNDU2NjogJnF1b3Q7U0RQIGFsc28gYWxs
b3dzIG90aGVyIGNoYXJhY3RlciBzZXRzIHN1Y2ggYXMgSVNPIDg4NTktMSB0byBiZSB1c2VkIHdo
ZW4gZGVzaXJlZC4mcXVvdDsNCjxvOnA+PC9vOnA+PC9wPg0KPHA+RXZlbiBpZiB3ZSBqdXN0IGNv
bnN0cmFpbiB0aGlzIHRvIFNJUCwgUkZDIDMyNjE6ICZxdW90O1doZW4gbm8gZXhwbGljaXQgY2hh
cnNldCBwYXJhbWV0ZXIgaXMgcHJvdmlkZWQgYnkgdGhlIHNlbmRlciwgbWVkaWEgc3VidHlwZXMg
b2YgdGhlICd0ZXh0JyB0eXBlIGFyZSBkZWZpbmVkIHRvIGhhdmUgYSBkZWZhdWx0IGNoYXJzZXQg
dmFsdWUgb2YgJ1VURi04Jy4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwPlNvIHRoZXJlJ3MgYSBi
aWFzIHRvd2FyZHMgVVRGLTgsIGJ1dCBubyBzdHJpY3QgcmVxdWlyZW1lbnQuPG86cD48L286cD48
L3A+DQo8cD5JJ2Qgc3VwcG9ydCBhIHNob3J0IGRvY3VtZW50IHRoYXQgZGVwcmVjYXRlZCBub24t
VVRGLTggZW5jb2RpbmdzIG9mIFNEUCBzbyB0aGF0IHNwZWNpZmljYXRpb25zIGxpa2UgdGhpcyBv
bmUgY291bGQgc2ltcGx5IGFzc3VtZSB0aGF0IHRoZSBmdWxsIGNoYXJhY3RlciBzZXQgY2FuIGJl
IHVzZWQgZGlyZWN0bHksIGJ1dCB0aGF0J3Mgbm90IHRoZSBjdXJyZW50IHN0YXRlIG9mIGFmZmFp
cnMuPG86cD48L286cD48L3A+DQo8cD4vYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+
DQo8L2h0bWw+DQo=

--_000_6E58094ECC8D8344914996DAD28F1CCD18CDC02Ddggemm526mbxchi_--


From nobody Mon Apr 15 00:43:52 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172B31203CE; Mon, 15 Apr 2019 00:43:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9QHtjPXkFCW; Mon, 15 Apr 2019 00:43:41 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30076.outbound.protection.outlook.com [40.107.3.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36DD21203BA; Mon, 15 Apr 2019 00:43:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PgVJbG1CrDRo7p837ahZforrfMVygiYA8XmBmBUPfAE=; b=U8eg4YwVzCLCj3W1bhVx2tLPi16pWYnT3cQjgCxLGfHUrCDMDDSj/uzlzVUhER520pMWC/xEN6K0khknfXWnyAejGVjmW3+V7vUWiujsGDt6L/a8t9ojErjsokkLTNJTseQP+D8Whzkt9QS2kVunh0No4idRr4oNmV7trEnC7/4=
Received: from HE1PR07MB3259.eurprd07.prod.outlook.com (10.170.246.26) by HE1PR07MB4410.eurprd07.prod.outlook.com (20.176.167.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Mon, 15 Apr 2019 07:43:38 +0000
Received: from HE1PR07MB3259.eurprd07.prod.outlook.com ([fe80::5ce7:e79c:91a5:5629]) by HE1PR07MB3259.eurprd07.prod.outlook.com ([fe80::5ce7:e79c:91a5:5629%6]) with mapi id 15.20.1813.009; Mon, 15 Apr 2019 07:43:38 +0000
From: Bo Burman 
To: "mmusic (mmusic@ietf.org)" , "Adam Roach (adam@nostrum.com)" , "'draft-ietf-mmusic-msrp-usage-data-channel@ietf.org'" 
CC: "mmusic-chairs@ietf.org" 
Thread-Topic: Re-adoption call for draft-ietf-mmusic-msrp-usage-data-channel
Thread-Index: AdTzW+sgbwwu69taT3isydhvU8Szaw==
Date: Mon, 15 Apr 2019 07:43:38 +0000
Message-ID: 
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=bo.burman@ericsson.com; 
x-originating-ip: [192.176.1.84]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8d3a2ff3-2473-4aa5-0d42-08d6c176129c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(49563074)(7193020); SRVR:HE1PR07MB4410; 
x-ms-traffictypediagnostic: HE1PR07MB4410:
x-microsoft-antispam-prvs: 
x-forefront-prvs: 000800954F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(136003)(396003)(376002)(39860400002)(199004)(189003)(105586002)(110136005)(4744005)(316002)(71190400001)(97736004)(2906002)(14444005)(256004)(71200400001)(81156014)(81166006)(8936002)(66066001)(8676002)(86362001)(106356001)(3846002)(790700001)(6116002)(68736007)(476003)(186003)(25786009)(486006)(44832011)(99286004)(14454004)(26005)(53936002)(606006)(4326008)(9686003)(74316002)(55016002)(236005)(7696005)(478600001)(5660300002)(6436002)(102836004)(99936001)(33656002)(6506007)(7736002)(52536014)(54896002)(6306002)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4410; H:HE1PR07MB3259.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Kn42ESjKb8fyqJ1vrFQDweIA6y/6HhDVaJ9Kal159wwECiO8/HPX3RuTWUDp7TjWc4Q26S2ZcMmk/eRtukN/G1RNuSQ7j8YjZaLr0A3NC9ojDFd6t8ZOTIqThO1+qTdGoEOT5qCjIvlTs2eQ84gcV7Ie3M3dTnNtY/3uUyQLLEaheRk5RmVNxUaPuiWB7U1ttC6vClIqZI/t3hPXIOrHdcKp0lq5d3l6fUuQUVQ5pXWFCWudvSu8hsmdO9S3oBu9KWZznZ/JGctEH1nZ/ny8UJ5VFRCbudQR+d7A5O2+2yo0MQla5bHhr7HzkXGnBx+u1sOTgcaEKhb8OXuP8/FDjXJ2cFP1+TgXjHAVkVByZxHQUSJlNdJ3hn+a9kFjt/zvu2slB0u4aksCh3orWovD+EPlFYumo4Nz9E6YdmcORoQ=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0006_01D4F36F.AF8E6050"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8d3a2ff3-2473-4aa5-0d42-08d6c176129c
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2019 07:43:38.0681 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4410
Archived-At: 
Subject: [MMUSIC] Re-adoption call for draft-ietf-mmusic-msrp-usage-data-channel
X-BeenThere: mmusic@ietf.org
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: Mon, 15 Apr 2019 07:43:50 -0000

------=_NextPart_000_0006_01D4F36F.AF8E6050
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0007_01D4F36F.AF8E6050"


------=_NextPart_001_0007_01D4F36F.AF8E6050
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

MMUSIC, authors,

 

This concludes the call to re-adopt "Submit SDP Negotiation of MSRP over
Data Channels as Proposed Standard" as an MMUSIC WG milestone, reviving the
expired
 draft-ietf-mmusic-msrp-usage-data-channel as document.

 

I find that we have received sufficient interest to continue progressing
this draft and commitment from a number of people to work on it. No one has
objected this re-adoption.

 

I have asked our ART AD (Adam) to accept "Submit SDP Negotiation of MSRP
over Data Channels as Proposed Standard" as an MMUSIC WG milestone with
target date December 2019.

 

Authors, please submit a new version of the document at your earliest
convenience.

 

Thanks,

/Bo

MMUSIC co-chair

 


------=_NextPart_001_0007_01D4F36F.AF8E6050
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


MMUSIC, =
authors,
 
This concludes the call to =
re-adopt “Submit SDP Negotiation of MSRP over Data Channels as =
Proposed Standard” as an MMUSIC WG milestone, reviving the expired =
draft-ietf-mmusic-msrp-usage-data-channel<=
/a> as document.
 
I find that we have =
received sufficient interest to continue progressing this draft and =
commitment from a number of people to work on it. No one has objected =
this re-adoption.
 
I have asked our ART AD =
(Adam) to accept “Submit SDP Negotiation of MSRP over Data =
Channels as Proposed Standard” as an MMUSIC WG milestone with =
target date December 2019.
 
Authors, please submit a =
new version of the document at your earliest =
convenience.
 
Thanks,
/Bo
MMUSIC =
co-chair
 

------=_NextPart_001_0007_01D4F36F.AF8E6050--

------=_NextPart_000_0006_01D4F36F.AF8E6050
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVXjCCAyAw
ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy
YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5
NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz
czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/
gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE
41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI
xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI
9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ
Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4
pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W
NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch
dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo
Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf
TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV
BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx
MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE
AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB
AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I
tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L
jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ
jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c
3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J
Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h
ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4
pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw
EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN
AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz
dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD
VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1
j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs
aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm
aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp
YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG
SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB
D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI
bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN
fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by
Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF7zCCA9egAwIBAgIQ
f/Mn4/Qs3Qmdp7lrbBs+RzANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI
RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTA3
MDc0MTEyWhcNMjAxMTA3MDc0MTExWjBgMREwDwYDVQQKDAhFcmljc3NvbjESMBAGA1UEAwwJQm8g
QnVybWFuMSUwIwYJKoZIhvcNAQkBFhZiby5idXJtYW5AZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdl
cmFiYnVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsc7/WHPCPFn8MtdlAsXwPnl7
w0tSyOiso36JZ2OOE6Ztn7+8EmlhFZXV4ThcCyeJOZJG1CM8yIfs3k74gqyblT51tF89wOBarJVi
HQtcf9Jvp4OoYuhRqRda9hUeI8Z4tfqnXQ2OppGecD71Bg4nmovTzsEy3JM7Cd5A7foSGjdoDG5y
szolpQxx/+CJdYF9B2EfVgahCF8MYKCQhW40EaTJFPQm4/uZIQZPbxFw8PgpEIDV/IhG7izKr3gH
n/MNqtCD1yK+itPAlB7ZRAyhBR3qV/qpXU82koT8byMATE7iqmGZnx1k7XwbPE9rdli2cpTMVZ9y
R3nYSL3dnG09lwIDAQABo4IBvDCCAbgwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVz
dC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0
MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxo
dHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5j
ZXIwIQYDVR0RBBowGIEWYm8uYnVybWFuQGVyaWNzc29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQB
gg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25l
cmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFOqTTQsD
K500lkyW3F7vkHyeBQtoMB8GA1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB
/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEAy+psdt+fJhnRrYmmLqFMtDDk9CFzkdfjEQFRBNaz
KnIQmBKXGN7UevdGKMgZXjxvO1JljkvjfbPov7IycBac/6y6+kp4hHtkP6/hdPPADxFb2X5/58Wg
c4lWPTCvi8mn+bRtyrH9VAT03M7qIVMOpuq+OTzWVaRZphUT9mDamtcBjsX9UfQ5UsKpFb7Pt8eP
ZQf77LNHv0neNir7irCWgXdYHOksTzN0rCQG7YVyXWTaddlLiBvi2O18fsT3FgopnHhdv4HBG4LH
FtAjqs3PW9W4NhxgEH/1H+U7exFe9+6ZoTaN4D209Jt05Eq74hZSa39Wfnwg+tlr9c62RJ+z97ek
PDpenOo4SV0V4fL4O5d5cjdsFNIpXrrPt0pc5sXsYOTuIvsEgkdDDFP5Ezwu1IgMcX8RTvsEXai/
OIeEMq7lIzJ+h9/gd9rIn9dV4oYaY9X5u9M220+GCb0jcfWeBuQN4+2lbgevqRjU43Oa/cXYGCrQ
vDfdEqT09xMvxM/X1f8HXLw/ikyYlWf0QD4vJ8vE/fVi4NnjASUB8Uge/5daZE/Bg3axh2oywVGW
z8Ecx57ACKhaUUQ16B/Eq6WFalse9yoBP3pKkzkmWOAoLNPnko9TBZD1pQ1Z59AleTT6BmqKThzl
i58mANeLPJQ4JYxpopY6uun7xQZ2LADRi3gwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7Ljr
MA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNv
bmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UE
BhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFs
IENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PB
qjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOw
mZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/
JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSg
Ie8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpy
aRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvo
TvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZ
xf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQ
of5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2
hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggr
BgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNv
bTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3Rl
bGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr
BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh
c29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlh
c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYI
KwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAf
BgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWM
O7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Ha
n1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pj
WxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVt
Lcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8
Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2
PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHe
P+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B
8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M
5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC
/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz
b24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQf/Mn4/Qs3Qmdp7lrbBs+RzAJBgUrDgMCGgUAoIIBfDAY
BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTA0MTUwNzQzMzFaMCMG
CSqGSIb3DQEJBDEWBBQpyHfrwKdp/C7wA/YZQ8RP87i62zBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqG
SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3
EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz
b24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQf/Mn4/Qs3Qmdp7lrbBs+RzBsBgsqhkiG9w0BCRACCzFd
oFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBO
TCBJbmRpdmlkdWFsIENBIHYzAhB/8yfj9CzdCZ2nuWtsGz5HMA0GCSqGSIb3DQEBAQUABIIBADA1
beiM1YTsCcUgzSuyKD+gX63JGTLBIQAgDo33YrCGW5rr9btHho6BG2gKJhwfGm5dJfSnupN4iBMz
ivYamMBtVMG+A1zMhnog3IYzLUTJxGhrw1sAFxgQIqGO7zuMYcUCQgRUf8539QUeY6dJJvDPMvwg
B1gLJ16nmkYBBqkMeTRcZx39peRaCuBsjFwzdeQno/zOGTlr29LcFGh2nbFFzxgiPrBUlAtgUdwN
0SLzBlbNXH2CYVtVY4StdJehYT5dRZB5re0d/v+ZTfH6hOQeA5LY2HM8p3rtlljK+qWChRx/Ri43
utZIA2JLGXT65MSeXhcgbvuHDfH7whG0WpcAAAAAAAA=

------=_NextPart_000_0006_01D4F36F.AF8E6050--


From nobody Mon Apr 15 01:02:59 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C2812009C for ; Mon, 15 Apr 2019 01:02:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dL0G7O39n60F for ; Mon, 15 Apr 2019 01:02:55 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40060.outbound.protection.outlook.com [40.107.4.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C279112004B for ; Mon, 15 Apr 2019 01:02:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XczIKExSrIMOGbs3vGsJ870G+FOzCh4b/pSWPVMEA0A=; b=dZhcVlAl/CU2wymLnjg+Fb7IxQsyF+rZ6HGwC3KtztBae4pJgcjJ4WUyFmI+Fl/t2S2kHLMcEYXVvtjE3+ynsKOpdWpU4X36btmjF2frNdVxzYJLrffFQM4Vq2YQxvx9aTslfTZxjjv81/zKOsZVXZnOe1R9aTVCjhlQ64IfiU0=
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2444.eurprd07.prod.outlook.com (10.168.130.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Mon, 15 Apr 2019 08:02:51 +0000
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b161:fb77:e4ea:4723]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b161:fb77:e4ea:4723%3]) with mapi id 15.20.1813.009; Mon, 15 Apr 2019 08:02:51 +0000
From: Magnus Westerlund 
To: Paul Kyzivat , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] Last Call:  (SDP: Session Description Protocol) to Proposed Standard
Thread-Index: AQHU4L35G0bkeH37hEyuzO/M/jMwpA==
Date: Mon, 15 Apr 2019 08:02:51 +0000
Message-ID: 
References: <155326592304.23020.8256337045285295468.idtracker@ietfa.amsl.com>  <6E58094ECC8D8344914996DAD28F1CCD18CDB636@dggemm526-mbx.china.huawei.com>  
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; 
x-originating-ip: [192.176.1.87]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2a0d5bb4-5ee2-428e-3ebf-08d6c178c23e
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR0701MB2444; 
x-ms-traffictypediagnostic: HE1PR0701MB2444:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: 
x-forefront-prvs: 000800954F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(39860400002)(366004)(376002)(396003)(189003)(199004)(71190400001)(2501003)(81156014)(81166006)(14454004)(305945005)(8676002)(93886005)(446003)(66066001)(8936002)(5660300002)(7736002)(71200400001)(74316002)(6436002)(486006)(476003)(229853002)(52536014)(86362001)(53546011)(7696005)(316002)(105586002)(106356001)(99286004)(76176011)(53936002)(55016002)(25786009)(14444005)(102836004)(6506007)(256004)(9686003)(6306002)(26005)(68736007)(44832011)(2906002)(3846002)(6116002)(6246003)(478600001)(97736004)(33656002)(966005)(186003)(2171002)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2444; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: kX+ThB+GMBSdFxmPrfDaeRxl6w+pzCfaleD/HL7dlZY7ZjakYAsjI34im77YSG41171Dq0fdIOQIlZ/V5vTEJdubtQmuA0EjejswNXGlNbIZnAJ5xB0vbPtWRxU9cCDuzKn1qbXg4IKGr2xALh2U8biaRL7ur/ncvVVw3r8JsidosXa2HsStnO5uu8F3h1qRoUPhNuihwaQDS+VN7n2fc9RdvkNQwRepEj39YLp+CcQPFJtvbidievCVAXpQ9RWrg5P7Ap6xBo2C8raw9n0QwJHk2RGd3kkYNST1H7vQmx+dtCF5e6NQTYY6CRSQlW3wDlWtcEzj5uX/bPAU4Jkew/lMcGQTOFNtQ7csczz0Pr8Ti3deBRYwCr0XpjgKjuYgXxvT4lMD0uYKPgAhyVppDkRumc+Z35Hyn/0/T/iQ6CU=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2a0d5bb4-5ee2-428e-3ebf-08d6c178c23e
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2019 08:02:51.7058 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2444
Archived-At: 
Subject: Re: [MMUSIC] Last Call:  (SDP: Session Description Protocol) to Proposed Standard
X-BeenThere: mmusic@ietf.org
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: Mon, 15 Apr 2019 08:02:58 -0000

Hi Paul,=0A=
=0A=
If I attempt to interpret what you are saying as conclusion it has=0A=
several implications, or am I missunderstanding you?=0A=
=0A=
1. Obsolete a=3Dcharset attribute. The only other options would be to=0A=
define a small set of attribute to which it applies like "i=3D".=0A=
=0A=
2. Clarify section 5 that using UTF-8 characters without NUL, CR, LF in=0A=
attribute values and textual fields are okay.=0A=
=0A=
3. Define how attribute values that may contain NUL, CR and LF use a=0A=
specified escaping mechanism=0A=
=0A=
4. Define an escaping mechanism that applies to SDP and UTF-8 strings=0A=
=0A=
5. Legacy warning in attempting to use escaping mechanism in old=0A=
attributes.=0A=
=0A=
Is this a fair summary?=0A=
=0A=
Cheers=0A=
=0A=
Magnus=0A=
=0A=
=0A=
=0A=
On 2019-04-12 17:45, Paul Kyzivat wrote:=0A=
> On 4/12/19 4:59 AM, Magnus Westerlund wrote:=0A=
>> Hi,=0A=
>>=0A=
>> To be clear, I am not proposing that any existing attribute would be =0A=
>> forced to suddenly accept UTF-8 strings with no charset restriction. =0A=
>> Simply that new attribute's values can be defined to be UTF-8 in =0A=
>> general. I think the important distinction here is that a parser must be=
 =0A=
>> ready to accept any UTF-8 character as the sender can't know if a =0A=
>> particular charset limitation applies to a specific consumer. However, =
=0A=
>> in form I don't see a problem of the SDP itself informing the consumer =
=0A=
>> that there is a charset limitation applied in this document.=0A=
>>=0A=
>> My interpretation of the current situation is that it we hesitate to use=
 =0A=
>> UTF-8 fields due to the uncertainty in the requirements on consumers of =
=0A=
>> SDP.=0A=
> After re-reviewing the text, I think we may have a can of worms here =0A=
> that has existed a long time, perhaps from the beginning. Let me explain:=
=0A=
>=0A=
> Section 5 says:=0A=
>=0A=
>     An SDP description is entirely textual.  SDP field names and=0A=
>     attribute names use only the US-ASCII subset of UTF-8, but textual=0A=
>     fields and attribute values MAY use the full ISO 10646 character set=
=0A=
>     in UTF-8 encoding, or some other character set defined by the=0A=
>     "a=3Dcharset:" attribute.=0A=
>=0A=
> Section 6.10 (charset attribute) says:=0A=
>=0A=
>     The charset specified MUST be one of those registered in the IANA=0A=
>     Character Sets registry (http://www.iana.org/assignments/character-=
=0A=
>     sets), such as ISO-8859-1.=0A=
>     ...=0A=
>     Note that a character set specified MUST still prohibit the use of=0A=
>     bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR).  Character sets requiring=
=0A=
>     the use of these characters MUST define a quoting mechanism that=0A=
>     prevents these bytes from appearing within text fields.=0A=
>=0A=
> The charsets registry has a *lot* of entries, including a lot of ancient =
=0A=
> obsolete ones not vaguely related to ascii. (E.g., EBCDIC-related ones.) =
=0A=
> Many of these refer to RFC1345, which seems to be a pre-unicode attempt =
=0A=
> to rationalize character sets. The charsets registry also includes =0A=
> UTF-16 and UTF-32. It is really hard to understand how certain parts of =
=0A=
> an SDP body might be in UTF-8 while other parts are in UTF-32.=0A=
>=0A=
> I can't make any sense of:=0A=
>=0A=
>     Character sets requiring=0A=
>     the use of these characters MUST define a quoting mechanism that=0A=
>     prevents these bytes from appearing within text fields.=0A=
>=0A=
> AFAIK character sets don't define quoting mechanisms. Also, I don't know =
=0A=
> what it means for a charset to require use of particular characters. And =
=0A=
> this text is very sloppy in muddling the use of "character" and "byte".=
=0A=
>=0A=
> The bottom line is that this is a mess. I'm not sure if it ever could =0A=
> have worked. Nor do I understand what usage it was trying to =0A=
> accommodate. (Note that most of this stuff is largely unchanged since =0A=
> RFC2327.)=0A=
>=0A=
> Perhaps all the charset-dependent stuff should be obsoleted.=0A=
>=0A=
> 	Thanks,=0A=
> 	Paul=0A=
>=0A=
> 	=0A=
>=0A=
> _______________________________________________=0A=
> mmusic mailing list=0A=
> mmusic@ietf.org=0A=
> https://www.ietf.org/mailman/listinfo/mmusic=0A=
>=0A=
=0A=
-- =0A=
=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A=
----------------------------------------------------------------------=0A=
=0A=


From nobody Mon Apr 15 01:13:29 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3E3120140 for ; Mon, 15 Apr 2019 01:13:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-mO1ymyFb6l for ; Mon, 15 Apr 2019 01:13:26 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70040.outbound.protection.outlook.com [40.107.7.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8AEE1200C3 for ; Mon, 15 Apr 2019 01:13:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MQ11ZvPtAf3R17AbWlSgrk2qu2szac3SsDHYIz5NuP4=; b=cLwiUhArHq0fb1HLrtvskhndeUSXUmlSczviMd+sDQUNprRsmM7HFoHzsB/zTqBChWaJdFz7xamplhJs4P3r6byjz+8vGZWVsvWiRe/MNJITYegsuUl6O25N7l0s/Ezkdil2o7fUysIxh7k6zSYE4x4silcEuKhgXXexk5lUieo=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3178.eurprd07.prod.outlook.com (10.170.245.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Mon, 15 Apr 2019 08:13:22 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184%2]) with mapi id 15.20.1813.009; Mon, 15 Apr 2019 08:13:22 +0000
From: Christer Holmberg 
To: Roman Shpount 
CC: Flemming Andreasen , mmusic WG 
Thread-Topic: [MMUSIC] FQDN support in ice-sip-sdp
Thread-Index: AQHU6jzz/50YAJx2kEqY4siuQ2NZYqY0606AgADVT4CAAEAVAP//1AeAgADQ14CAAETnAIAAnHWAgAD8QQCAAGHdAIACtQAAgACv5gCAANoNAA==
Date: Mon, 15 Apr 2019 08:13:22 +0000
Message-ID: <6EA23696-949C-40CF-BEBE-006A59856BDF@ericsson.com>
References:    <3DD3D8D6-9B13-4F9D-80DD-F89B69240708@ericsson.com>   <98CF630B-5CCD-4CE4-84B4-81A4C53979DC@ericsson.com>    <1552A692-1020-43CA-B15E-92595729EE8B@ericsson.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.16.1.190220
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-originating-ip: [89.166.49.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6424e401-9163-4b10-7d3e-08d6c17a3a2b
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB3178; 
x-ms-traffictypediagnostic: HE1PR07MB3178:
x-microsoft-antispam-prvs: 
x-forefront-prvs: 000800954F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(136003)(366004)(39860400002)(199004)(189003)(99286004)(478600001)(5660300002)(14454004)(14444005)(256004)(83716004)(25786009)(71200400001)(44832011)(476003)(7736002)(93886005)(82746002)(6512007)(305945005)(186003)(2906002)(102836004)(71190400001)(53936002)(26005)(33656002)(2616005)(486006)(54906003)(58126008)(316002)(66066001)(11346002)(446003)(8936002)(106356001)(86362001)(76176011)(6506007)(6246003)(97736004)(6486002)(36756003)(6436002)(105586002)(81156014)(81166006)(6916009)(4326008)(229853002)(68736007)(3846002)(8676002)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3178; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: frF9avUqzg07JJXIwAjtcb8KeoZk3YqDDvMnQBWlP3c2/ym8QthYS38KNC8wB6YVh8Aow3UNuRhmLCT+o+oNEj/dziaxj4tMDOQC+bqcYrkPJU2wtltZTf6wrGXuxfZA8YVKc1gth1tF3p+OIwKn38eTxnSjQbYddTmzAorYFiZq4vnPArS4u1tPeCWlJcM1fRIUUe++IEdnsQj5IZqaF+VIXLUDS6/OrYWZq9i1LEuiWH+FVbAg1l9W0gy7I8dYVo7AK+X1znIYzx9C8A5NUrPMtbfDaOEUi/7mfRo1CiCMKTLVcL6yGjqbpalX/mKN1hxLhxBzuTn9rL5l4RoNqHXhGkorqEuSp/cym/gjuHPbY9b+TwXMJkzePh2uIHVeO46krJY3Us4Vsb6o1w6DDHsTRfz6l5Tt+wIM9ta5S7E=
Content-Type: text/plain; charset="utf-8"
Content-ID: <5B66819B9E3CD941927874EE138282F0@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6424e401-9163-4b10-7d3e-08d6c17a3a2b
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2019 08:13:22.2080 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3178
Archived-At: 
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp
X-BeenThere: mmusic@ietf.org
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: Mon, 15 Apr 2019 08:13:28 -0000

SGksDQoNCj4+PiBCdXQsIHRoZSBvdGhlciByZWFzb24gd2FzIHRvIGNvcnJlY3QgaXNzdWVzIGFu
ZCB1bnNwZWNpZmllZCBjYXNlcyBmb3VuZCBpbiBSRkMgNTI0NSwgYW5kIEZRRE4gc2VlbXMgdG8g
YmUgb25lIHN1Y2ggaXNzdWUuIA0KPj4+IFVuZm9ydHVuYXRlbHkgd2UgZGlkbid0IGRldGVjdCBp
dCBiZWZvcmUgcHVibGlzaGluZyBSRkMgODQ0NSwgc28gYW55IGdlbmVyaWMgSUNFIEZRRE4gcHJv
Y2VkdXJlcyB3b3VsZCBoYXZlIHRvIGJlIGluIGEgc2VwYXJhdGUgZHJhZnQuDQo+Pg0KPj4gQWdh
aW4sIEkgZG9uJ3QgaGF2ZSBhIHN0cm9uZyBvcGluaW9uIG9uIHdoZXRoZXIgdGhlIFNEUCBzcGVj
aWZpYyBwYXJ0cyBvZiBGUUROIGFyZSBpbiBpY2Utc2lwLXNkcCBvciBpbiBhIHNlcGFyYXRlIGRy
YWZ0Lg0KPsKgDQo+IEkgdGhpbmsgdGhlIHF1ZXN0aW9uIGlzIGlmIEZRRE4gaXMganVzdCBhbm90
aGVyIHdheSB0byBlbmNvZGUgYSBzaW5nbGUgSVAgYWRkcmVzcyBvciBpZiBGUUROIHJlc29sdXRp
b24gYWZmZWN0cyBJQ0Ugbm9taW5hdGlvbiBwcm9jZXNzLiANCj4gSWYgd2UgZGVjaWRlIHRoYXQg
ZGVtYXJjYXRpb24gcG9pbnQgYmV0d2VlbiBJQ0UgY2FuZGlkYXRlIHNpZ25hbGluZyAoaWNlLXNp
cC1zZHApIGFuZCBJQ0Ugbm9taW5hdGlvbiBpKFJGQyA4NDQ1KSBzIHRoZSBsaXN0IG9mIGNhbmRp
ZGF0ZXMgDQo+IHdpdGggSVAgYWRkcmVzc2VzLCB0aGVuIGhhbmRsaW5nIEZRRE4gZmFsbHMgdW5k
ZXIgc2lnbmFsaW5nIChpY2Utc2lwLXNkcCkuIElmIHlvdSB0aGluayBETlMgcmVzb2x1dGlvbiBh
ZmZlY3RzIElDRSBub21pbmF0aW9uIHByb2Nlc3MsIHRoZW4gd2Ugd2lsbCANCj4gbmVlZCBhIHNl
cGFyYXRlIGRyYWZ0IGZvciBoYW5kbGluZyBjYW5kaWRhdGVzIHdpdGggRlFETi4gSSB0aGluayBm
b3JtZXIgaXMgdGhlIGNhc2UgYW5kIHdlIGNhbiBwdXQgRlFETiBoYW5kbGluZyBpbiBpY2Utc2lw
LXNkcC4NCg0KQXNzdW1pbmcgdGhlIEZRRE4gaXMgc3BsaXQgaW50byBzZXBhcmF0ZSBjYW5kaWRh
dGVzLCBhbmQgZWFjaCBjYW5kaWRhdGUgaXMgcHJvY2Vzc2VkIGp1c3QgbGlrZSBhbnkgb3RoZXIg
Y2FuZGlkYXRlLCBJIGRvbid0IHRoaW5rIHRoZSBub21pbmF0aW9uIHByb2Nlc3MgaXMgYWZmZWN0
ZWQuIEl0IGFsc28gbWVhbnMgdGhhdCBpZiBJIG5vbWluYXRlIHRoZSBJUHY2ICJ2ZXJzaW9uIiBv
ZiBhIGNhbmRpZGF0ZSwgSSBhbSBub3QgYWxsb3dlZCB0byBzd2l0Y2ggdG8gdGhlIElQdjQgInZl
cnNpb24iIC0gZXZlbiBpZiB0aGUgY29ubmVjdGl2aXR5IGNoZWNrcyBoYXZlIGJlZW4gc3VjY2Vz
c2Z1bC4gSSBhbSBvbmx5IGFsbG93ZWQgdG8gdXNlIHRoZSB0cmFuc3BvcnQgYXNzb2NpYXRlZCB3
aXRoIHRoZSBub21pbmF0ZWQgY2FuZGlkYXRlLg0KDQo+PiBLZWVwIGluIG1pbmQgdGhhdCB3ZSBh
bHNvIG5lZWQgdG8gZGVjaWRlIG9uIHdoZXRoZXIgaWNlLXBhYyBzaG91bGQgYmUgYW4gaWNlLXNp
cC1zZHAgZGVwZW5kZW5jeSwgaW4gd2hpY2ggY2FzZSB0aGUgDQo+PiBwdWJsaWNhdGlvbiBtYXkg
Z2V0IGRlbGF5ZWQgYW55d2F5IChldmVudGhvdWdoIHdlIGhvcGUgdG8gZmluYWxpemUgaWNlLXBh
YyBwcmV0dHkgZmFzdCkuDQo+wqANCj4gSSBkbyBub3QgdGhpbmsgaWNlLXNpcC1zZHAgbmVlZHMg
dG8gaGF2ZSBpY2UtcGFjIGFzIGRlcGVuZGVuY3ksIGJ1dCBJIGFtIGdvaW5nIHRvIGJyaW5nIHRo
aXMgdXAgaW4gYW5vdGhlciB0aHJlYWQuIA0KPg0KPiBJIHdhbnRlZCB0byBjb25jZW50cmF0ZSBv
biBGUUROIGZpcnN0IGFuZCB0aGVuIGFkZHJlc3Mgb3RoZXIgaWNlLXNpcC1zZHAgaXNzdWVzLCBz
dWNoIGFzIHRoZSBmYWN0IHRoYXQgU0RQIG9mZmVyIGNhbiBjb250YWluIGFuIGVtcHR5IGNhbmRp
ZGF0ZSBsaXN0Lg0KDQpZZXMuIEkgZGlkIG5vdCB3YW50IHRvIGRpc2N1c3MgaWNlLXBhYyBpbiB0
aGlzIHRocmVhZCwgYnV0IHNpbXBseSBwb2ludCBvdXQgdGhhdCBiZWNhdXNlIG9mIGl0IHdlIE1B
WSBoYXZlIGEgZGVwZW5kZW5jeSBhbHJlYWR5Lg0KDQo+Pj4gRmlndXJpbmcgb3V0IGhvdyB0byBo
YW5kbGUgbXVsdGlwbGUgcmVzdWx0cyBwZXIgRE5TIHF1ZXJ5IGNlcnRhaW5seSB3YXJyYW50cyBh
IHNlcGFyYXRlIGRyYWZ0IGFuZCBzaG91bGQgYmUgb3V0IG9mIHNjb3BlLsKgDQo+Pg0KPj4gV2Ug
YWxzbyBuZWVkIHRvIGtlZXAgaW4gbWluZCB0aGF0LCBldmVuIHRob3VnaCBhIHNpbmdsZSBETlMg
cmVxdWVzdCBvbmx5IHJldHVybnMgYSBzaW5nbGUgYWRkcmVzcywgaWYgc29tZSBraW5kIG9mIGxv
YWQgYmFsYW5jaW5nIGlzIHVzZWQgDQo+PiBkaWZmZXJlbnQgRE5TIHJlcXVlc3RzIG1heSByZXR1
cm4gYSBkaWZmZXJlbnQgYWRkcmVzcy4gUGVyaGFwcyB3ZSBuZWVkIHRvIGNvdmVyIHRoYXQgYnkg
c2F5aW5nIHRoYXQgYW4gSUNFIGFnZW50IG11c3Qgbm90IGNoYW5nZSB0aGUgDQo+PiBJUCBhZGRy
ZXNzOnBvcnQgYXNzb2NpYXRlZCB3aXRoIGEgY2FuZGlkYXRlLg0KPg0KPiBUaGlzIGlzIHBhcnQg
b2YgdGhlIHByb2JsZW0gd2l0aCBETlMuIE9uZSBhZ2VudCBjYW4gcHVibGlzaCBGUUROIHRoYXQg
cG9pbnRzIHRvIGEgc2luZ2xlIElQLCBidXQgd2hlbiBhbm90aGVyIGFnZW50IHJ1bnMgdGhlIERO
UyBxdWVyeSwgDQo+IGl0IGNhbiByZXR1cm4gbW9yZSB0aGVuIG9uZSByZXN1bHQgKHN1Y2ggYXMg
RE5TNjQpLCBkaWZmZXJlbnQgcmVzdWx0IChzb21lIHNvcnQgb2YgTkFUIG9yIHByb3h5KSBvciBu
byByZXN1bHRzLi4gRE5TIG5ldHdvcmsgY2FuIGJlIGFkdmVyc2FyaWFsIA0KPiBhbmQgZGVsaWJl
cmF0ZWx5IHNlbmQgdHJhZmZpYyB0aHJvdWdoIGEgcHJveHkgZm9yIG1hbi1vbi10aGUtbWlkZGxl
IGF0dGFjay4gSSB3b3VsZCBwcmVmZXIgdG8gbGltaXQgd2hhdCB3ZSByZXF1aXJlIHRvIGVhY2gg
b2YgdGhlIGFnZW50cyBhbmQgDQo+IHRoZW4gYWxsb3cgY29ubmVjdGl2aXR5IGNoZWNrcyB0byBz
b3J0IHRoaXMgb3V0LiBTbyBmYXIgdGhlIHJlcXVpcmVtZW50cyBhcmUgdGhhdCBhZ2VudCB0aGF0
IGNyZWF0ZXMgdGhlIGNhbmRpZGF0ZSBsaXN0IHNob3VsZCBvbmx5IHVzZSBGUUROIHRoYXQgDQo+
IHBvaW50cyB0byBzaW5nbGUgYWRkcmVzcyBvZiBnaXZlbiB0eXBlIGFuZCBhZ2VudCByZWNlaXZp
bmcgdGhlIGNhbmRpZGF0ZSBsaXN0IHNob3VsZCBvbmx5IHVzZSBjYW5kaWRhdGUgbGluZXMgdGhh
dCBwcm9kdWNlIGEgc2luZ2xlIGFkZHJlc3MuDQoNClllcy4NCg0KPj4+IGEuIERlZmluZSBob3cg
dG8gc3BlY2lmeSBhZGRyZXNzIHR5cGUgaW4gY2FuZGlkYXRlIGxpbmUuIFRoaXMgaXMgY2VydGFp
bmx5IGFuIFNEUCBwcm9ibGVtIGFuZCBJIHRoaW5rIGlzIGEgcHJlLXJlcXVpc2l0ZSB0byB1c2lu
ZyBhbnkgYWRkcmVzc2VzLCBzdWNoIGFzIA0KPj4+IEZRRE4sIHdoZXJlIGFkZHJlc3MgdHlwZSBp
cyBub24tb2J2aW91cw0KPj4NCj4+IEhPVyB0byBkZWZpbmUgdGhlIGFkZHJlc3MgdHlwZSBpbiBh
IGNhbmRpZGF0ZSBsaXRlIGlzIGZvciBzdXJlIGFuIFNEUCBwcm9ibGVtLiBCdXQsIHRoZSBmYWN0
IHRoYXQgdGhlIGFkZHJlc3MgdHlwZSBuZWVkcyB0byBiZSANCj4+IHByb3ZpZGVkIGZvciBhIGNh
bmRpZGF0ZSBpcyBhbiBJQ0UgcHJvYmxlbS4gDQo+wqANCj4gQXMgSSBoYXZlIG1lbnRpb25lZCBl
YXJsaWVyLCB0aGlzIGlzIHRoZSBxdWVzdGlvbiBvZiBkZWZpbmluZyByZXNwb25zaWJpbGl0aWVz
IG9mIHNpZ25hbGluZyB2cyBhY3R1YWwgSUNFIHByb2Nlc3NpbmcuIEROUyByZXNvbHV0aW9uIGRv
ZXMgbm90IGhhdmUgdG8gYmUgcGFydCBvZiBJQ0UgcHJvY2Vzc2luZyBhbmQgY2FuIGJlIHBhcnQg
b2Ygc2lnbmFsaW5nLiBJQ0UgcHJvY2Vzc2luZyBjYW4gYWx3YXlzIHN0YXJ0IHdpdGggdGhlIGxp
c3Qgb2YgY2FuZGlkYXRlcyB3aXRoIGFkZHJlc3NlcyBhbHJlYWR5IHJlc29sdmVkLg0KDQpZZXMu
DQoNCj4+IGIuIFNwZWNpZnkgdGhhdCBpZiBhZ2VudCBjb21wbGlhbnQgd2l0aCBpY2Utc2lwLXNk
cCB1c2VzIEZRRE4gY29udGFjdC1hZGRyZXNzLCBpdCBNVVNUIHNwZWNpZnkgYWRkcnR5cGUgZm9y
IHRoZSBjYW5kaWRhdGUuDQo+DQo+IERvIHdlIGtub3cgaG93IGFuIGV4aXN0aW5nIGltcGxlbWVu
dGF0aW9uIHdvdWxkIHByb2Nlc3MgdGhlIGFkZHJ0eXBlPyBBcmUgdGhlcmUgYW55IHByb2NlZHVy
ZXMgcmVnYXJkaW5nIHVuc3VwcG9ydGVkIGNhbmRpZGF0ZSBwcm9wZXJ0aWVzPw0KPg0KPiBTaW5j
ZSBJIGp1c3QgaW52ZW50ZWQgYWRkcnR5cGUsIEkgZG8gbm90IHRoaW5rIGFueXRoaW5nIHdvdWxk
IHByb2Nlc3MgaXQuDQoNCkkgd2FzIHRoaW5raW5nIGFib3V0IHVuc3VwcG9ydGVkIHByb3BlcnRp
ZXMgaW4gZ2VuZXJhbC4NCg0KPj4+IFVuc3VwcG9ydGVkIGNhbmRpZGF0ZSBwcm9wZXJ0aWVzIGFy
ZSBzdXBwb3NlZCB0byBiZSBpZ25vcmVkLiBXZSBzZWUgYSBsb3Qgb2YgdW5zdXBwb3J0ZWQgcHJv
cGVydGllcyBpbiB0aGUgd2lsZCwgc3VjaCBhcyAiZ2VuZXJhdGlvbiIgYW5kICJuZXR3b3JrLWlk
Ii4gDQo+Pj4gVGhlc2UgZXh0cmEgY2FuZGlkYXRlIGF0dHJpYnV0ZXMgZG8gbm90IHNlZW0gdG8g
Y2F1c2UgYW55IGludGVyb3AgaXNzdWVzLCBzbyBJIGRvIG5vdCB0aGluayBhZGRpbmcgYSBuZXcg
Y2FuZGlkYXRlIHR5cGUgYXR0cmlidXRlIHdvdWxkIGJlIGEgcHJvYmxlbQ0KPj4+DQo+Pj4gYy4g
U3BlY2lmeSB0aGF0IGlmIEZRRE4gcmVzb2x2ZXMgdG8gYSBzaW5nbGUgYWRkcmVzcyBmb3IgdGhl
IHNwZWNpZmllZCBmYW1pbHkgdGhlbiB0aGF0IHRoaXMgYWRkcmVzcyBpcyB1c2VkIGZvciB0aGlz
IGNhbmRpZGF0ZS4gQ2FuZGlkYXRlIGxpbmVzIHdpdGggDQo+Pj4gRlFETiByZXR1cm5pbmcgbXVs
dGlwbGUgcmVzdWx0cyBwZXIgcXVlcnkgTVVTVCBiZSBpZ25vcmVkIHVudGlsIHRoZWlyIGhhbmRs
aW5nIGlzIGRlZmluZWQgaW4gYSBmdXR1cmUgZHJhZnQNCj4+Pg0KPj4+IGQuIFNwZWNpZnkgd2hh
dCB0byBkbyB3aXRoIEZRRE4gd2l0aG91dCBhZGRyZXNzIHR5cGUgc3BlY2lmaWVkIHN1Y2ggYXMg
U0RQIGZyb20gbGVnYWN5IFJGQyA1MjQ1IGltcGxlbWVudGF0aW9ucy4gV2UgY2FuIGdvIHdpdGgg
dHJ5IEFBQUEgcmVzb2x1dGlvbiANCj4+PiBmaXJzdCBhbmQgdXNlIGlmIHNpbmdsZSBhZGRyZXNz
IGlzIHJldHVybmVkLiBJZiBub3RoaW5nIGlzIHJldHVybmVkIGZyb20gQUFBQSBxdWVyeSwgdHJ5
IEEgcXVlcnkuIElmIHNpbmdsZSBhZGRyZXNzIGlzIHJldHVybmVkLCB1c2VkIHRoYXQgYWRkcmVz
cywgaWdub3JlIA0KPj4+IHRoZSBjYW5kaWRhdGUgbGluZSBvdGhlcndpc2UuIFRoaXMgbWF0Y2hl
cyBSRkMgNTI0NSBsYW5ndWFnZSBhbmQgc2hvdWxkIHdvcmsgaW4gYWxsIHRoZSBzYW1lIHNpdHVh
dGlvbnMgd2hlcmUgUkZDIDUyNDUgaW1wbGVtZW50YXRpb25zIHdlcmUgd29ya2luZy4NCj4+DQo+
PiBkKSB3b3JrcyBhc3N1bWluZyBib3RoIElDRSBhZ2VudHMgZ2V0IHRoZSBzYW1lIElQIGFkZHJl
c3M6cG9ydCBmcm9tIEROUy4NCj4NCj4gT3B0aW9uIGTCoCBpcyBiZXN0IGVmZm9ydCBmb3IgaW50
ZXJvcCB3aXRoIGN1cnJlbnQgUkZDIDUyNDUgaW1wbGVtZW50YXRpb25zLiBJdCB3b3VsZCB3b3Jr
IGluIHRoZSBzYW1lIGNhc2VzIHdoZW4gUkZDIDUyNDUgaW1wbGVtZW50YXRpb24gd291bGQuIEkg
YW0gbm90IHN1cmUgYW55IGN1cnJlbnQgUkZDIDUyNDUgaW1wbGVtZW50YXRpb25zIGFjdHVhbGx5
IHVzZSBGUUROLCBidXQgaWYgc3VjaCBpbXBsZW1lbnRhdGlvbnMgZG8gZXhpc3QsIHRoaXMgaXMg
d2hhdCBSRkMgNTI0NSBzcGVjaWZpZWQuDQo+DQo+Pj4gV2hhdCBkbyB5b3UgdGhpbms/DQo+Pg0K
Pj4gSSB0aGluayB5b3Ugc3VnZ2VzdGlvbiBpcyBnb29kLiBCdXQsIGFzIEkgaGF2ZSBpbmRpY2F0
ZWQsIEkgd291bGQgbGlrZSB0byBoYXZlIGEgZ2VuZXJpYyBJQ0UgRlFETiBkcmFmdCB0aGF0IGlj
ZS1zaXAtc2RwIChvciBhIHNlcGFyYXRlIE1NVVNJQyBkcmFmdCkgcmVmZXJlbmNlcy4NCj4+DQo+
PiBTaW1pbGFybHkgdG8gaWNlLXBhYywgSSB0aGluayBzdWNoIGRyYWZ0IGNvdWxkIGJlIHByb2R1
Y2VkIHJlbGF0aXZlbHkgZmFzdC4gSXQgbW9yZSBvciBsZXNzIG9ubHkgbmVlZHMgdG8gc2F5IHRo
YXQ6DQo+Pg0KPj4gMSkgQW4gSUNFIGFnZW50IHRoYXQgdXNlcyBGUUROIG5lZWRzIHRvIHByb3Zp
ZGUgb25lIGNhbmRpZGF0ZSBwZXIgYWRkcmVzcyBmYW1pbHksIGFuZCBpbmRpY2F0ZSB0aGUgYWRk
cnR5cGUgZm9yIGVhY2ggb2YgdGhvc2UgY2FuZGlkYXRlcy4NCj4+IDIpIFNvbWUgdGV4dCByZWdh
cmRpbmcgYmFja3dhcmQgY29tcGF0aWJpbGl0eS4gRG8gd2UgYXNzdW1lIHNvbWUgZGVmYXVsdCBi
ZWhhdmlvciBieSBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMsIG9yIGRvIHdlIHJlcXVpcmUgYW4g
SUNFIG9wdGlvbj8NCj4NCj4gSSBkbyBub3QgdGhpbmsgd2UgbmVlZCBhbiBJQ0Ugb3B0aW9uLiBJ
IHRoaW5rIHByZXNlbmNlIG9mIGFkZHJ0eXBlIGNhbiBiZSBzdWZmaWNpZW50Lg0KDQpCdXQgaWYg
dGhlIHBlZXIgSUNFIGFnZW50IGRvZXMgbm90IHN1cHBvcnQgaXQsIGFuZCB0aGUgRlFETiByZXNv
bHZlcyBpbnRvIGJvdGggSVB2NCBhbmQgSVB2Niwgd2UgZG9uJ3Qga25vdyB3aGF0IHZlcnNpb24g
aXQgd2lsbCB1c2UuDQoNCj4gVGhpcyBiZWluZyBzYWlkIHdlIG5lZWQgdG8gZGVjaWRlIHR3byB0
aGluZ3M6DQo+DQo+IDEuIERvZXMgRlFETiByZXNvbHV0aW9uIGJlbG9uZ3MgdG8gSUNFIHByb2Nl
c3Npbmc/IEluIHRoaXMgY2FzZSBjYW5kaWRhdGUgbGlzdCBpbmNsdWRlcyBGUUROIHdpdGggYWRk
cmVzcyB0eXBlIGFuZCBJQ0UgcHJvY2Vzc2luZyBkZXNjcmliZXMgaG93IEZRRE4gYXJlIHJlc29s
dmVkIGFuZCBjb252ZXJ0ZWQgdG8gYWRkcmVzc2VzLiANCj4gT3IsIGFsdGVybmF0aXZlbHksIGRv
ZXMgRlFETiByZXNvbHV0aW9uIGJlbG9uZ3MgdG8gSUNFIHNpZ25hbGluZz8gSW4gdGhpcyBjYXNl
IGNhbmRpZGF0ZSBsaXN0IGluY2x1ZGVzIHJlc29sdmVkIGFkZHJlc3MgYW5kIElDRSBhZ2VudCBk
ZWFscyB3aXRoIGFkZHJlc3NlcyBvbmx5Lg0KDQpUaGF0IHdvdWxkIG5vdCB3b3JrIHdpdGggbURO
UywgcmlnaHQ/DQoNCj4gMi4gRG8gd2Ugc3BlY2lmeSBob3cgdG8gZGVhbCB3aXRoIEZRRE4gaW4g
aWNlLXNpcC1zZHAgb3IgZG8gd2Ugc3BlY2lmeSBpbiBpY2Utc2lwLXNkcCB0aGF0IEZRRE4gbXVz
dCBiZSBpZ25vcmVkIGFuZCB0aGVpciBoYW5kbGluZyBpcyBkZWZpbmVkIGluIHNvbWUgb3RoZXIg
ZHJhZnQ/DQoNClBlcmhhcHMgdGhlIGJlc3QgdGhpbmcgd291bGQgc2ltcGx5IHRvIHByb2R1Y2Ug
YSBzZXBhcmF0ZSBkcmFmdCwgdG8gZ2V0IHNvbWUgdGV4dC4gV2UgY2FuIHRoZW4gZGVjaWRlIHdo
ZXRoZXIgdG8gbWVyZ2UgaXQgaW50byBpY2Utc2lwLXNkcC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0
ZXINCg0K


From nobody Mon Apr 15 01:26:11 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD11A1200B9; Mon, 15 Apr 2019 01:26:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level: 
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbV-cgv100G8; Mon, 15 Apr 2019 01:25:58 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140041.outbound.protection.outlook.com [40.107.14.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D9C12009C; Mon, 15 Apr 2019 01:25:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=70vj1VGp7ojeTWr077C0YUz2sfM8rANs8ELncuxB6So=; b=ZFTtUJ/JDbElXw5FddiKv7IMbwa5naMsxjiNKnIhx/r0OKQlznOUVFS/EGtA5t1FPkd74T1KLVoqakOWYRSpF9qcjg447EwqZe9LxWYTlNGhkhcYS076wgKBizaUGHF3pCpKPyCnBJ3n598GnIavA/q5cdDMC2fCl3sAiIL6Osk=
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2505.eurprd07.prod.outlook.com (10.168.123.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Mon, 15 Apr 2019 08:25:54 +0000
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b161:fb77:e4ea:4723]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b161:fb77:e4ea:4723%3]) with mapi id 15.20.1813.009; Mon, 15 Apr 2019 08:25:54 +0000
From: Magnus Westerlund 
To: "Roni Even (A)" 
CC: "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-data-channel-sdpneg@ietf.org" , "mmusic@ietf.org" , Adam Roach , The IESG 
Thread-Topic: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)
Thread-Index: AQHU66fNA40h4UsP7kq3a/Vv5QT6wQ==
Date: Mon, 15 Apr 2019 08:25:54 +0000
Message-ID: 
References: <155446588097.13196.6373243259627185094.idtracker@ietfa.amsl.com> <1afcb116-36cb-be51-81ac-e78fc52c9255@nostrum.com>   <6E58094ECC8D8344914996DAD28F1CCD18CDC02D@dggemm526-mbx.china.huawei.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; 
x-originating-ip: [192.176.1.87]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 745467f4-f01b-4893-91a6-08d6c17bfa26
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR0701MB2505; 
x-ms-traffictypediagnostic: HE1PR0701MB2505:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: 
x-forefront-prvs: 000800954F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(376002)(346002)(366004)(39860400002)(51444003)(199004)(189003)(4326008)(33656002)(5660300002)(71190400001)(71200400001)(54906003)(2906002)(478600001)(99286004)(74316002)(9686003)(54896002)(316002)(790700001)(186003)(3846002)(6116002)(256004)(236005)(55016002)(229853002)(53546011)(102836004)(6306002)(26005)(81166006)(81156014)(446003)(6916009)(14444005)(8676002)(7736002)(97736004)(476003)(106356001)(6506007)(68736007)(6436002)(8936002)(7696005)(25786009)(66066001)(86362001)(6246003)(44832011)(52536014)(966005)(486006)(76176011)(606006)(93886005)(53936002)(105586002)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2505; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Qy6d6nW/1Jyd8ZCXnczlQSVZRqVNzW7Y4WplFHEdZY51FR/+wvIf4YNvERbeWC18haAW3SJYB2tXoqR2jUIlulCa7XvAAZ5dFHamYRm14VF1/dyvLGCA8iD8agN6Uo+3Q9ejT8ix69en7sSu+dZQ887UWkQJe6jB9V3+KgOeKcZRjPWmD6kNmPjFxLIdhUy6Pvwo9zLkvVST8RCn2h8elFHqFDF3qbrePplPPc/quOyOpESJslVYMF929sP2ZuRpdIkrp8k1uCQ/oeTlnAylgxBKA06sWkZ3Enk+67/nyx0gfeaU7XHDX371CH0EgWraEk03WG3DbaHHbnuxbDUTuD11kjTI8Ng6oxDmWo3pUOjlaltlpRYm/z7BE5iUFMwgcwsJ7a5gImiZ+RMKgVqZzhHEA+FMeIAcbQhIW62Xqos=
Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB2522A34E3190EF29659B1178952B0HE1PR0701MB2522_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 745467f4-f01b-4893-91a6-08d6c17bfa26
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2019 08:25:54.0182 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2505
Archived-At: 
Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)
X-BeenThere: mmusic@ietf.org
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: Mon, 15 Apr 2019 08:26:02 -0000

--_000_HE1PR0701MB2522A34E3190EF29659B1178952B0HE1PR0701MB2522_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi,

I think you need to split this into two parts. One is the general quoting o=
f the UTF-8 string in the label parameter. The other part is the serializat=
ion of the WebRTC label into an UTF-8 string.

Also, I don't get my head around the USVString if that has any additional d=
ata in addition to the sequence of the Unicode scalar values and if there a=
re any action that are needed to be done in the seralization to an UTF-8 st=
ring?

Cheers

Magnus


On 2019-04-15 07:04, Roni Even (A) wrote:
Hi Magnus,
I responded to your comments and this is currently the only open comment fr=
om all the comments that we got  that I need to address

I think that the text proposed by Adam make sense so I suggest adding to se=
ction 5.1.3 the following text




=93In order to communicate with WEbRTC API the label attribute should

  *   Serialize the WebRTC label as a UTF-8 string
  *   Treat the UTF-8 serialization as a series of bytes
  *   For each byte in the serialization:
     *   If the byte can be expressed as a `quoted-char`, do so
     *   Otherwise, express the byte as an `escaped-char`.
=93

Does this sound reasonable to you

Regards
Roni


From: Adam Roach [mailto:adam@nostrum.com]
Sent: Tuesday, April 09, 2019 7:50 PM
To: Magnus Westerlund; The IESG
Cc: mmusic-chairs@ietf.org; draft-ietf-mmusi=
c-data-channel-sdpneg@ietf.org; mmusic@ietf.org
Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data=
-channel-sdpneg-25: (with DISCUSS and COMMENT)

On 4/9/19 4:00 AM, Magnus Westerlund wrote:
On 2019-04-08 17:55, Adam Roach wrote:
On 4/5/19 7:04 AM, Magnus Westerlund via Datatracker wrote:

----------------------------------------------------------------------

DISCUSS:

----------------------------------------------------------------------



There might be a serious issue in label definition.



5.1.3.  Label Parameter



   The 'label' parameter indicates the name of the channel.  It

   represents a label that can be used to distinguish, in the context of

   the WebRTC API [WebRtcAPI], an RTCDataChannel object from other

   RTCDataChannel objects.  This parameter maps to the 'Label' parameter

   defined in [I-D.ietf-rtcweb-data-protocol].  The 'label' parameter is

   optional.  If it is not present, then its value defaults to the empty

   string.



  label-opt       =3D "label=3D" quoted-string

  quoted-string   =3D DQUOTE *(quoted-char / escaped-char) DQUOTE

  quoted-char     =3D SP / quoted-visible

  quoted-visible  =3D %x21 / %x23-24 / %x26-7E ; VCHAR without " or %

  escaped-char    =3D "%" HEXDIG HEXDIG



I interpret that as the intention is to enable the SDP Attribute to carry t=
he

label as defined in W3C API. That value is in the current candidatate

specification an https://www.w3.org/TR/webrtc/ as an USVSsting

(https://heycam.github.io/webidl/#idl-USVString). And in the reference version

of the WebRTC API as an DOMstring. Both are not limited to ASCII and may

contain any Unicode characters. Thus the escaping mechanism defined appear =
to

be insufficient.



I think the "quoted-string" need a definition of what type of string this t=
ruly

are so that it is clear what a character in the string is.



In addition the specification of escaping is undersspecified. I would recom=
mend

at least adding discussion of the need and how to escape DQUOTE and % that =
can

be relatively common operations.



I can see that this could benefit from some explicit detail about how to co=
nvert the cited USVString string into the "quoted-string" construct defined=
 here. I think this roughly consists of:

  *   Serialize the WebRTC label as a UTF-8 string
  *   Treat the UTF-8 serialization as a series of bytes
  *   For each byte in the serialization:

     *   If the byte can be expressed as a `quoted-char`, do so
     *   Otherwise, express the byte as an `escaped-char`.

Would including text to that effect satisfy your concern?

Yes it would be clear what is expected. However, I fail to understand why o=
ne need to ASCIIify and escape the UTF-8 encoded characters where one could=
 simply define the label value as an UTF-8 string something that is compati=
ble with SDP specification. Wouldn't that reduce the set of characters need=
ing escaping to a much smaller set.



That's a little tricky. RFC 4566: "SDP also allows other character sets suc=
h as ISO 8859-1 to be used when desired."

Even if we just constrain this to SIP, RFC 3261: "When no explicit charset =
parameter is provided by the sender, media subtypes of the 'text' type are =
defined to have a default charset value of 'UTF-8'."

So there's a bias towards UTF-8, but no strict requirement.

I'd support a short document that deprecated non-UTF-8 encodings of SDP so =
that specifications like this one could simply assume that the full charact=
er set can be used directly, but that's not the current state of affairs.

/a


--

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

--_000_HE1PR0701MB2522A34E3190EF29659B1178952B0HE1PR0701MB2522_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable







Hi,







I think you need to split this into two part=
s. One is the general quoting of the UTF-8 string in the label parameter. T=
he other part is the serialization of the WebRTC label into an UTF-8 string=
.










Also, I don't get my head around the USVStri=
ng if that has any additional data in addition to the sequence of the Unico=
de scalar values and if there are any action that are needed to be done in =
the seralization to an UTF-8 string?










Cheers







Magnus














On 2019-04-15 07:04, Roni Even (A) wrote:









Hi Magnus,


I responded to your comme=
nts and this is currently the only open comment from all the comments that =
we got  that I need to address


 <=
/p>

I think that the text pro=
posed by Adam make sense so I suggest adding to section 5.1.3 the following=
 text



 <=
/p>

 <=
/p>

 <=
/p>

 <=
/p>

=93In order to communicate with WEbRTC API the label=
 attribute should


    

  • 
Serialize the WebRTC label as a UTF-8 string
  • 
Treat the UTF-8 serialization as a series of bytes
  • 
For each byte in the serialization:

      

    • 
If the byte can be expressed as a `quoted-char`, do so
    • 
Otherwise, express the byte as an `escaped-char`.
    



=93


 


Does this sound reasonable to you


 


Regards


Roni


 <=
/p>

 <=
/p>





From: Adam Roach [mailto:adam@nostrum.com]


Sent: Tuesday, April 09, 2019 7:50 PM

To: Magnus Westerlund; The IESG

Cc: 
mmusic-chairs@ietf.org; 
draft-ietf-mmusic-data-channel-sdpneg@ietf.org; 
mmusic@ietf.org

Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmus=
ic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)






 




On 4/9/19 4:00 AM, Magnus Westerlund wrote:








On 2019-04-08 17:55, Adam Roach wrote:







On 4/5/19 7:04 AM, Magnus Westerlund via Datatracker=
 wrote:






----------------------------------------------------------------------=



DISCUSS:


----------------------------------------------------------------------=



 


There might be a serious issue in label definition.


 


5.1.3.  Label Parameter


 


   The 'label' parameter indicates the name of the channel.&=
nbsp; It


   represents a label that can be used to distinguish, in th=
e context of


   the WebRTC API [WebRtcAPI], an RTCDataChannel object from=
 other


   RTCDataChannel objects.  This parameter maps to the =
'Label' parameter


   defined in [I-D.ietf-rtcweb-data-protocol].  The 'la=
bel' parameter is


   optional.  If it is not present, then its value defa=
ults to the empty


   string.


 


  label-opt       =3D "label=
=3D" quoted-string


  quoted-string   =3D DQUOTE *(quoted-char / escaped-ch=
ar) DQUOTE


  quoted-char     =3D SP / quoted-visible


  quoted-visible  =3D %x21 / %x23-24 / %x26-7E ; VCHAR witho=
ut " or %


  escaped-char    =3D "%" HEXDIG HEXDIG<=
o:p>


 


I interpret that as the intention is to enable the SDP Attribute to ca=
rry the


label as defined in W3C API. That value is in the current candidatate<=
o:p>


specification an https://www.w3.org/TR/webrtc/ as an USVSsting<=
/pre>

(https://heycam.github.io/webidl/#=
idl-USVString). And in the reference version


of the WebRTC API as an DOMstring. Both are not limited to ASCII and m=
ay


contain any Unicode characters. Thus the escaping mechanism defined ap=
pear to


be insufficient.


 


I think the "quoted-string" need a definition of what type o=
f string this truly


are so that it is clear what a character in the string is.<=
/pre>

 


In addition the specification of escaping is undersspecified. I would =
recommend


at least adding discussion of the need and how to escape DQUOTE and % =
that can


be relatively common operations.




 


I can see that this could benefit from some explicit detail about how to=
 convert the cited USVString string into the "quoted-string" cons=
truct defined here. I think this roughly consists of:


    

  • 
Serialize the WebRTC label as a UTF-8 string
  • 
Treat the UTF-8 serialization as a series of bytes
  • 
For each byte in the serialization:


    

      

    • 
If the byte can be expressed as a `quoted-char`, do so
    • 
Otherwise, express the byte as an `escaped-char`.
    



Would including text to that effect satisfy your concern?




Yes it would be clear what is expected. However, I fail to understand wh=
y one need to ASCIIify and escape the UTF-8 encoded characters where one co=
uld simply define the label value as an UTF-8 string something that is comp=
atible with SDP specification. Wouldn't
 that reduce the set of characters needing escaping to a much smaller set. =





 


That's a little tricky. RFC 4566: "SDP also allows other character =
sets such as ISO 8859-1 to be used when desired."



Even if we just constrain this to SIP, RFC 3261: "When no explicit =
charset parameter is provided by the sender, media subtypes of the 'text' t=
ype are defined to have a default charset value of 'UTF-8'."


So there's a bias towards UTF-8, but no strict requirement.

I'd support a short document that deprecated non-UTF-8 encodings of SDP =
so that specifications like this one could simply assume that the full char=
acter set can be used directly, but that's not the current state of affairs=
.


/a











-- =0A=
=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.=
com=0A=
----------------------------------------------------------------------



--_000_HE1PR0701MB2522A34E3190EF29659B1178952B0HE1PR0701MB2522_--


From nobody Mon Apr 15 02:48:09 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D406120158; Mon, 15 Apr 2019 02:48:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.19
X-Spam-Level: 
X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuOh7UacoVTK; Mon, 15 Apr 2019 02:48:05 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA13712003F; Mon, 15 Apr 2019 02:48:04 -0700 (PDT)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id D7C158BB2A4E058B5E28; Mon, 15 Apr 2019 10:48:02 +0100 (IST)
Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 15 Apr 2019 10:48:02 +0100
Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 15 Apr 2019 10:48:02 +0100
Received: from DGGEMM422-HUB.china.huawei.com (10.1.198.39) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Mon, 15 Apr 2019 10:48:01 +0100
Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.138]) by dggemm422-hub.china.huawei.com ([10.1.198.39]) with mapi id 14.03.0415.000; Mon, 15 Apr 2019 17:47:54 +0800
From: "Roni Even (A)" 
To: Magnus Westerlund 
CC: "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-data-channel-sdpneg@ietf.org" , "mmusic@ietf.org" , Adam Roach , The IESG 
Thread-Topic: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)
Thread-Index: AQHU66fNA40h4UsP7kq3a/Vv5QT6waY9BUHg
Date: Mon, 15 Apr 2019 09:47:54 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18CDC132@dggemm526-mbx.china.huawei.com>
References: <155446588097.13196.6373243259627185094.idtracker@ietfa.amsl.com> <1afcb116-36cb-be51-81ac-e78fc52c9255@nostrum.com>   <6E58094ECC8D8344914996DAD28F1CCD18CDC02D@dggemm526-mbx.china.huawei.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.202.102]
Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD18CDC132dggemm526mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)
X-BeenThere: mmusic@ietf.org
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: Mon, 15 Apr 2019 09:48:09 -0000

--_000_6E58094ECC8D8344914996DAD28F1CCD18CDC132dggemm526mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Magnus,
The current ABNF for quoted string is a double quoted string of bytes where=
 non printable characters are escaped using %.  So do you suggest that if n=
eed to convert to UTF-8 . the quoted string should be a string of bytes wit=
hout the escape char?
When receiving the label or subprotocol from WebRTC you need to serialize s=
o that it will be converted to a quoted string.

Roni

From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
Sent: Monday, April 15, 2019 11:26 AM
To: Roni Even (A)
Cc: mmusic-chairs@ietf.org; draft-ietf-mmusic-data-channel-sdpneg@ietf.org;=
 mmusic@ietf.org; Adam Roach; The IESG
Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data=
-channel-sdpneg-25: (with DISCUSS and COMMENT)

Hi,

I think you need to split this into two parts. One is the general quoting o=
f the UTF-8 string in the label parameter. The other part is the serializat=
ion of the WebRTC label into an UTF-8 string.

Also, I don't get my head around the USVString if that has any additional d=
ata in addition to the sequence of the Unicode scalar values and if there a=
re any action that are needed to be done in the seralization to an UTF-8 st=
ring?

Cheers

Magnus


On 2019-04-15 07:04, Roni Even (A) wrote:
Hi Magnus,
I responded to your comments and this is currently the only open comment fr=
om all the comments that we got  that I need to address

I think that the text proposed by Adam make sense so I suggest adding to se=
ction 5.1.3 the following text




"In order to communicate with WEbRTC API the label attribute should

  *   Serialize the WebRTC label as a UTF-8 string
  *   Treat the UTF-8 serialization as a series of bytes
  *   For each byte in the serialization:

     *   If the byte can be expressed as a `quoted-char`, do so
     *   Otherwise, express the byte as an `escaped-char`.
"

Does this sound reasonable to you

Regards
Roni


From: Adam Roach [mailto:adam@nostrum.com]
Sent: Tuesday, April 09, 2019 7:50 PM
To: Magnus Westerlund; The IESG
Cc: mmusic-chairs@ietf.org; draft-ietf-mmusi=
c-data-channel-sdpneg@ietf.org; mmusic@ietf.org
Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data=
-channel-sdpneg-25: (with DISCUSS and COMMENT)

On 4/9/19 4:00 AM, Magnus Westerlund wrote:
On 2019-04-08 17:55, Adam Roach wrote:
On 4/5/19 7:04 AM, Magnus Westerlund via Datatracker wrote:

----------------------------------------------------------------------

DISCUSS:

----------------------------------------------------------------------



There might be a serious issue in label definition.



5.1.3.  Label Parameter



   The 'label' parameter indicates the name of the channel.  It

   represents a label that can be used to distinguish, in the context of

   the WebRTC API [WebRtcAPI], an RTCDataChannel object from other

   RTCDataChannel objects.  This parameter maps to the 'Label' parameter

   defined in [I-D.ietf-rtcweb-data-protocol].  The 'label' parameter is

   optional.  If it is not present, then its value defaults to the empty

   string.



  label-opt       =3D "label=3D" quoted-string

  quoted-string   =3D DQUOTE *(quoted-char / escaped-char) DQUOTE

  quoted-char     =3D SP / quoted-visible

  quoted-visible  =3D %x21 / %x23-24 / %x26-7E ; VCHAR without " or %

  escaped-char    =3D "%" HEXDIG HEXDIG



I interpret that as the intention is to enable the SDP Attribute to carry t=
he

label as defined in W3C API. That value is in the current candidatate

specification an https://www.w3.org/TR/webrtc/ as an USVSsting

(https://heycam.github.io/webidl/#idl-USVString). And in the reference version

of the WebRTC API as an DOMstring. Both are not limited to ASCII and may

contain any Unicode characters. Thus the escaping mechanism defined appear =
to

be insufficient.



I think the "quoted-string" need a definition of what type of string this t=
ruly

are so that it is clear what a character in the string is.



In addition the specification of escaping is undersspecified. I would recom=
mend

at least adding discussion of the need and how to escape DQUOTE and % that =
can

be relatively common operations.



I can see that this could benefit from some explicit detail about how to co=
nvert the cited USVString string into the "quoted-string" construct defined=
 here. I think this roughly consists of:

  *   Serialize the WebRTC label as a UTF-8 string
  *   Treat the UTF-8 serialization as a series of bytes
  *   For each byte in the serialization:

     *   If the byte can be expressed as a `quoted-char`, do so
     *   Otherwise, express the byte as an `escaped-char`.

Would including text to that effect satisfy your concern?

Yes it would be clear what is expected. However, I fail to understand why o=
ne need to ASCIIify and escape the UTF-8 encoded characters where one could=
 simply define the label value as an UTF-8 string something that is compati=
ble with SDP specification. Wouldn't that reduce the set of characters need=
ing escaping to a much smaller set.



That's a little tricky. RFC 4566: "SDP also allows other character sets suc=
h as ISO 8859-1 to be used when desired."

Even if we just constrain this to SIP, RFC 3261: "When no explicit charset =
parameter is provided by the sender, media subtypes of the 'text' type are =
defined to have a default charset value of 'UTF-8'."

So there's a bias towards UTF-8, but no strict requirement.

I'd support a short document that deprecated non-UTF-8 encodings of SDP so =
that specifications like this one could simply assume that the full charact=
er set can be used directly, but that's not the current state of affairs.

/a



--



Magnus Westerlund



----------------------------------------------------------------------

Network Architecture & Protocols, Ericsson Research

----------------------------------------------------------------------

Ericsson AB                 | Phone  +46 10 7148287

Torshamnsgatan 23           | Mobile +46 73 0949079

SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com

----------------------------------------------------------------------

--_000_6E58094ECC8D8344914996DAD28F1CCD18CDC132dggemm526mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Magnus,


The current ABNF for quot=
ed string is a double quoted string of bytes where non printable characters=
 are escaped using %.  So do you suggest that if need to
 convert to UTF-8 . the quoted string should be a string of bytes without t=
he escape char?


When receiving the label =
or subprotocol from WebRTC you need to serialize so that it will be convert=
ed to a quoted string.


 <=
/p>

Roni

 <=
/p>





From: Magnus Westerlund [mailto:magnus.westerlund@erics=
son.com]


Sent: Monday, April 15, 2019 11:26 AM

To: Roni Even (A)

Cc: mmusic-chairs@ietf.org; draft-ietf-mmusic-data-channel-sdpneg@ie=
tf.org; mmusic@ietf.org; Adam Roach; The IESG

Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmus=
ic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)






 




Hi,






 






I think you need to split this into two parts. One i=
s the general quoting of the UTF-8 string in the label parameter. The other=
 part is the serialization of the WebRTC label into an UTF-8 string.







 






Also, I don't get my head around the USVString if th=
at has any additional data in addition to the sequence of the Unicode scala=
r values and if there are any action that are needed to be done in the sera=
lization to an UTF-8 string?







 






Cheers






 






Magnus






 






 






On 2019-04-15 07:04, Roni Even (A) wrote:=







Hi Magnus,


I responded to your comme=
nts and this is currently the only open comment from all the comments that =
we got  that I need to address


 <=
/p>

I think that the text pro=
posed by Adam make sense so I suggest adding to section 5.1.3 the following=
 text



 <=
/p>

 <=
/p>

 <=
/p>

 <=
/p>

“In order to communicate with WEbRTC API the l=
abel attribute should


    

  • 
Serialize the WebRTC label as a UTF-8 string
  • 
Treat the UTF-8 serialization as a series of bytes
  • 
For each byte in the serialization: 


    

      

    • 
If the byte can be expressed as a `quoted-char`, do so
    • 
Otherwise, express the byte as an `escaped-char`.
    



“


 


Does this sound reasonable to you


 


Regards


Roni


 <=
/p>

 <=
/p>





From: Adam Roach [m=
ailto:adam@nostrum.com]


Sent: Tuesday, April 09, 2019 7:50 PM

To: Magnus Westerlund; The IESG

Cc: mmusic-chairs@ietf.org=
; 
draft-ietf-mmusic-data-channel-sdpneg@ietf.org; 
mmusic@ietf.org

Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmus=
ic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)






 




On 4/9/19 4:00 AM, Magnus Westerlund wrote:








On 2019-04-08 17:55, Adam Roach wrote:







On 4/5/19 7:04 AM, Magnus Westerlund via Datatracker=
 wrote:






----------------------------------------------------------------------=



DISCUSS:


----------------------------------------------------------------------=



 


There might be a serious issue in label definition.


 


5.1.3.  Label Parameter


 


   The 'label' parameter indicates the name of the channel.&=
nbsp; It


   represents a label that can be used to distinguish, in th=
e context of


   the WebRTC API [WebRtcAPI], an RTCDataChannel object from=
 other


   RTCDataChannel objects.  This parameter maps to the =
'Label' parameter


   defined in [I-D.ietf-rtcweb-data-protocol].  The 'la=
bel' parameter is


   optional.  If it is not present, then its value defa=
ults to the empty


   string.


 


  label-opt       =3D "label=
=3D" quoted-string


  quoted-string   =3D DQUOTE *(quoted-char / escaped-ch=
ar) DQUOTE


  quoted-char     =3D SP / quoted-visible


  quoted-visible  =3D %x21 / %x23-24 / %x26-7E ; VCHAR witho=
ut " or %


  escaped-char    =3D "%" HEXDIG HEXDIG<=
o:p>


 


I interpret that as the intention is to enable the SDP Attribute to ca=
rry the


label as defined in W3C API. That value is in the current candidatate<=
o:p>


specification an https://www=
.w3.org/TR/webrtc/ as an USVSsting


(https://heycam.github.io/webidl/#idl-USVString). And i=
n the reference version


of the WebRTC API as an DOMstring. Both are not limited to ASCII and m=
ay


contain any Unicode characters. Thus the escaping mechanism defined ap=
pear to


be insufficient.


 


I think the "quoted-string" need a definition of what type o=
f string this truly


are so that it is clear what a character in the string is.<=
/pre>

 


In addition the specification of escaping is undersspecified. I would =
recommend


at least adding discussion of the need and how to escape DQUOTE and % =
that can


be relatively common operations.




 


I can see that this could benefit from some explicit detail about how to=
 convert the cited USVString string into the "quoted-string" cons=
truct defined here. I think this roughly consists of:


    

  • 
Serialize the WebRTC label as a UTF-8 string
  • 
Treat the UTF-8 serialization as a series of bytes
  • 
For each byte in the serialization:


    

      

    • 
If the byte can be expressed as a `quoted-char`, do so
    • 
Otherwise, express the byte as an `escaped-char`.
    



Would including text to that effect satisfy your concern?




Yes it would be clear what is expected. However, I fail to understand wh=
y one need to ASCIIify and escape the UTF-8 encoded characters where one co=
uld simply define the label value as an UTF-8 string something that is comp=
atible with SDP specification. Wouldn't
 that reduce the set of characters needing escaping to a much smaller set. =





 


That's a little tricky. RFC 4566: "SDP also allows other character =
sets such as ISO 8859-1 to be used when desired."



Even if we just constrain this to SIP, RFC 3261: "When no explicit =
charset parameter is provided by the sender, media subtypes of the 'text' t=
ype are defined to have a default charset value of 'UTF-8'."


So there's a bias towards UTF-8, but no strict requirement.

I'd support a short document that deprecated non-UTF-8 encodings of SDP =
so that specifications like this one could simply assume that the full char=
acter set can be used directly, but that's not the current state of affairs=
.


/a




 


-- 


 


Magnus Westerlund 


 


----------------------------------------------------------------------=



Network Architecture & Protocols, Ericsson Research

----------------------------------------------------------------------=



Ericsson AB          =
;       | Phone  +46 10 7148287=



Torshamnsgatan 23         =
;  | Mobile +46 73 0949079


SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com


----------------------------------------------------------------------=







--_000_6E58094ECC8D8344914996DAD28F1CCD18CDC132dggemm526mbxchi_--


From nobody Mon Apr 15 14:40:57 2019
Return-Path: 
X-Original-To: mmusic@ietf.org
Delivered-To: mmusic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6C9120242 for ; Mon, 15 Apr 2019 14:40:56 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <155536445650.10794.10363694540811650106.idtracker@ietfa.amsl.com>
Date: Mon, 15 Apr 2019 14:40:56 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [MMUSIC] Milestones changed for mmusic WG
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Apr 2019 21:40:57 -0000

Changed milestone "Submit SDP Negotiation of MSRP over Data Channels as
Proposed Standard", set state to active from review, accepting new milestone.

URL: https://datatracker.ietf.org/wg/mmusic/about/


From nobody Mon Apr 15 14:52:58 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42517120258; Mon, 15 Apr 2019 14:52:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.68
X-Spam-Level: 
X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwU4cqDAiNmf; Mon, 15 Apr 2019 14:52:55 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A3F01200F6; Mon, 15 Apr 2019 14:52:55 -0700 (PDT)
Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x3FLqgKQ022456 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 15 Apr 2019 16:52:44 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1555365165; bh=MQhdegU8UJFY8FtiXzz3uCLcZ8cZLUjE7sHzVt2a9D0=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=v9X9BmOjLsYkNR5hHDZHEW1V4QOcm570m1waQdPLjwBdGTOv5frjQVrXjRgUiPlU9 ai8DJQo1qttlGN8Z6cS0S4LkJ2hGtyUUePsyJSf8VXYkbDQq9+hb8PhdVjiV+RGbuN FI4h1kt6rKvFs0hSycjTetNoKJ1f6lH9q694bqc0=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at
To: Magnus Westerlund , "Roni Even (A)" 
Cc: "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-data-channel-sdpneg@ietf.org" , "mmusic@ietf.org" , The IESG 
References: <155446588097.13196.6373243259627185094.idtracker@ietfa.amsl.com> <1afcb116-36cb-be51-81ac-e78fc52c9255@nostrum.com>   <6E58094ECC8D8344914996DAD28F1CCD18CDC02D@dggemm526-mbx.china.huawei.com> 
From: Adam Roach 
Message-ID: <9b3e9f00-7a2c-f8e1-4f94-8004df115590@nostrum.com>
Date: Mon, 15 Apr 2019 16:52:37 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)
X-BeenThere: mmusic@ietf.org
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: Mon, 15 Apr 2019 21:52:56 -0000

On 4/15/19 3:25 AM, Magnus Westerlund wrote:
> Hi,
>
> I think you need to split this into two parts. One is the general 
> quoting of the UTF-8 string in the label parameter. The other part is 
> the serialization of the WebRTC label into an UTF-8 string.


I'm not sure what you mean by the second operation ("the other part") 
here. A USVString represents a sequence of Unicode codepoints ("USV" 
stands for "Unicode Scalar Values"). The procedure for going from a 
sequence of Unicode code points to a UTF-8 string is defined in RFC 
3629. Are you simply asking for a reference to RFC 3629 here?


> Also, I don't get my head around the USVString if that has any 
> additional data in addition to the sequence of the Unicode scalar 
> values and if there are any action that are needed to be done in the 
> seralization to an UTF-8 string?


I'm pretty comfortable asserting that the answers are "no" and "no" 
respectively. While it's not part of the spec, MDN (which hews very 
close to an "as built" description of web standards) makes this pretty 
clear: "USVString is equivalent to DOMString except for not allowing 
unpaired surrogate codepoints."

/a


From nobody Mon Apr 15 16:15:46 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFB3120287 for ; Mon, 15 Apr 2019 16:15:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2v4_S2pjHfjR for ; Mon, 15 Apr 2019 16:15:43 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A4C01201BF for ; Mon, 15 Apr 2019 16:15:42 -0700 (PDT)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x3FNFehF013871 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 15 Apr 2019 19:15:41 -0400
To: mmusic@ietf.org
References: <155326592304.23020.8256337045285295468.idtracker@ietfa.amsl.com>  <6E58094ECC8D8344914996DAD28F1CCD18CDB636@dggemm526-mbx.china.huawei.com>   
From: Paul Kyzivat 
Message-ID: <908d2e27-b2f6-c14d-373f-e1e5fc900adf@alum.mit.edu>
Date: Mon, 15 Apr 2019 19:15:40 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [MMUSIC] Last Call:  (SDP: Session Description Protocol) to Proposed Standard
X-BeenThere: mmusic@ietf.org
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: Mon, 15 Apr 2019 23:15:45 -0000

On 4/15/19 4:02 AM, Magnus Westerlund wrote:
> Hi Paul,
> 
> If I attempt to interpret what you are saying as conclusion it has
> several implications, or am I missunderstanding you?
> 
> 1. Obsolete a=charset attribute. The only other options would be to
> define a small set of attribute to which it applies like "i=".

That is what I am suggesting. I can't see how it ever could have worked 
*in general* for arbitrary charset values. And at this point I don't see 
a need.

Alternatively, restrict the charsets which can work to those which have 
some benign values.

IMO the most troublesome charsets are those that are wider than one 
byte, like UTF-16 or UTF-32, since they would have to coexist with the 
rest of the sdp being the ascii subset of UTF-8. Also troublesome are 
charsets not vaguely related to ascii, like the variants of EBCDIC.

> 2. Clarify section 5 that using UTF-8 characters without NUL, CR, LF in
> attribute values and textual fields are okay.

That would amount to limiting charset to UTF-8, which is same as 
deprecating it.

> 3. Define how attribute values that may contain NUL, CR and LF use a
> specified escaping mechanism

Right now it says that the charset must define an escaping mechanism, 
without saying how that might happen. AFAIK *none* of the charsets 
define an escaping mechanism.

But I also don't see how one could define such a mechanism independent 
of the charset since it must presumably reserve some character(s) from 
that charset to introduce the escape.

> 4. Define an escaping mechanism that applies to SDP and UTF-8 strings
> 
> 5. Legacy warning in attempting to use escaping mechanism in old
> attributes.

Not sure what to say about 4 & 5.

> Is this a fair summary?

Whatever.

I'm hoping I'm missing something about how this was intended to work in 
the first place.

	Thanks,
	Paul

> Cheers
> 
> Magnus
> 
> 
> 
> On 2019-04-12 17:45, Paul Kyzivat wrote:
>> On 4/12/19 4:59 AM, Magnus Westerlund wrote:
>>> Hi,
>>>
>>> To be clear, I am not proposing that any existing attribute would be
>>> forced to suddenly accept UTF-8 strings with no charset restriction.
>>> Simply that new attribute's values can be defined to be UTF-8 in
>>> general. I think the important distinction here is that a parser must be
>>> ready to accept any UTF-8 character as the sender can't know if a
>>> particular charset limitation applies to a specific consumer. However,
>>> in form I don't see a problem of the SDP itself informing the consumer
>>> that there is a charset limitation applied in this document.
>>>
>>> My interpretation of the current situation is that it we hesitate to use
>>> UTF-8 fields due to the uncertainty in the requirements on consumers of
>>> SDP.
>> After re-reviewing the text, I think we may have a can of worms here
>> that has existed a long time, perhaps from the beginning. Let me explain:
>>
>> Section 5 says:
>>
>>      An SDP description is entirely textual.  SDP field names and
>>      attribute names use only the US-ASCII subset of UTF-8, but textual
>>      fields and attribute values MAY use the full ISO 10646 character set
>>      in UTF-8 encoding, or some other character set defined by the
>>      "a=charset:" attribute.
>>
>> Section 6.10 (charset attribute) says:
>>
>>      The charset specified MUST be one of those registered in the IANA
>>      Character Sets registry (http://www.iana.org/assignments/character-
>>      sets), such as ISO-8859-1.
>>      ...
>>      Note that a character set specified MUST still prohibit the use of
>>      bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR).  Character sets requiring
>>      the use of these characters MUST define a quoting mechanism that
>>      prevents these bytes from appearing within text fields.
>>
>> The charsets registry has a *lot* of entries, including a lot of ancient
>> obsolete ones not vaguely related to ascii. (E.g., EBCDIC-related ones.)
>> Many of these refer to RFC1345, which seems to be a pre-unicode attempt
>> to rationalize character sets. The charsets registry also includes
>> UTF-16 and UTF-32. It is really hard to understand how certain parts of
>> an SDP body might be in UTF-8 while other parts are in UTF-32.
>>
>> I can't make any sense of:
>>
>>      Character sets requiring
>>      the use of these characters MUST define a quoting mechanism that
>>      prevents these bytes from appearing within text fields.
>>
>> AFAIK character sets don't define quoting mechanisms. Also, I don't know
>> what it means for a charset to require use of particular characters. And
>> this text is very sloppy in muddling the use of "character" and "byte".
>>
>> The bottom line is that this is a mess. I'm not sure if it ever could
>> have worked. Nor do I understand what usage it was trying to
>> accommodate. (Note that most of this stuff is largely unchanged since
>> RFC2327.)
>>
>> Perhaps all the charset-dependent stuff should be obsoleted.
>>
>> 	Thanks,
>> 	Paul
>>
>> 	
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
> 


From nobody Tue Apr 16 01:47:34 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B1312046B for ; Tue, 16 Apr 2019 01:47:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ei_i1xxn3Bc for ; Tue, 16 Apr 2019 01:47:29 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80047.outbound.protection.outlook.com [40.107.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CBCA120468 for ; Tue, 16 Apr 2019 01:47:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l9bXLFE9h+iKzt08Jqo38GWvZQWclGAQGvWHmg5bGy8=; b=glxrcHe8Uab82z+MvU4xrWt/DTCgvhDcjPYzW1V3jNBpvDUIYyg/KiQBuaiEGgqoaCzPbLACbL/vkm7JhC/9EWqTca4/qTcNBywHQsDi8etcpRrnjmBhesOcdC6ickSycss4a9xYGrGHSov4QHmv0P0bvv4X9mOwuNE1WT31YiY=
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2427.eurprd07.prod.outlook.com (10.168.124.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Tue, 16 Apr 2019 08:47:25 +0000
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b161:fb77:e4ea:4723]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b161:fb77:e4ea:4723%3]) with mapi id 15.20.1813.009; Tue, 16 Apr 2019 08:47:25 +0000
From: Magnus Westerlund 
To: Paul Kyzivat , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] Last Call:  (SDP: Session Description Protocol) to Proposed Standard
Thread-Index: AQHU4L35G0bkeH37hEyuzO/M/jMwpA==
Date: Tue, 16 Apr 2019 08:47:25 +0000
Message-ID: 
References: <155326592304.23020.8256337045285295468.idtracker@ietfa.amsl.com>  <6E58094ECC8D8344914996DAD28F1CCD18CDB636@dggemm526-mbx.china.huawei.com>    <908d2e27-b2f6-c14d-373f-e1e5fc900adf@alum.mit.edu>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; 
x-originating-ip: [192.176.1.83]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6885d9f5-74a3-402c-b8e1-08d6c2482641
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR0701MB2427; 
x-ms-traffictypediagnostic: HE1PR0701MB2427:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: 
x-forefront-prvs: 000947967F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(366004)(376002)(396003)(39860400002)(199004)(189003)(110136005)(53936002)(9686003)(256004)(3846002)(14444005)(6306002)(6246003)(2171002)(305945005)(52536014)(25786009)(476003)(486006)(8676002)(76176011)(66066001)(74316002)(966005)(446003)(81156014)(44832011)(5660300002)(14454004)(102836004)(7696005)(6506007)(186003)(86362001)(81166006)(26005)(53546011)(71200400001)(71190400001)(106356001)(68736007)(93886005)(33656002)(229853002)(316002)(8936002)(7736002)(6436002)(2501003)(99286004)(55016002)(478600001)(105586002)(6116002)(97736004)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2427; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: uG0PfYIaimjUXUBodAvBqMXf56zrsLU+tGnV/4RRXaOTEpBn3WkxIfQS3QGXviKNu50IJ/PjoeJWZyBCohCnjSIj0aUn2+NDkvwEFtGqVwX7qwVwVXfjw5O6fisnPKH78/35O74VRnZxXsjXNHhYp+dCsWbg9+6I97POmSH6MHdsPSVAaxgxakVAgSlK4MVDXzutKc5FgJgB6ghzeI9/yuyxexbv9vnaaVcP0vokJIX5XBhdojkOBwvQxMITLL0a93uKKhvipjvAParL67jmsBHd2x4UpandFeDlSPMjAG+018fMMardApSuaxSInq67Ay1DJPbG+qGd+CK1lEvD/4yp6BdWZVNW8jaIx0/r0zdkHLP4PVCT9C1nIC90Hwr28Lz1ktqcdwJaWOiOoeWzzpapX0uHr6nRNBo551OM/aI=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6885d9f5-74a3-402c-b8e1-08d6c2482641
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2019 08:47:25.2627 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2427
Archived-At: 
Subject: Re: [MMUSIC] Last Call:  (SDP: Session Description Protocol) to Proposed Standard
X-BeenThere: mmusic@ietf.org
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: Tue, 16 Apr 2019 08:47:33 -0000

Hi Paul,=0A=
=0A=
I think this needs input from more people.=0A=
=0A=
I did make a mistake in my thinking about the charset encodings. With=0A=
UTF-8 there are only US-ASCII that are a pure sub-set of UTF-8 when=0A=
encoded. So you are right about the implications.=0A=
=0A=
Cheers=0A=
=0A=
Magnus=0A=
=0A=
On 2019-04-16 01:17, Paul Kyzivat wrote:=0A=
> On 4/15/19 4:02 AM, Magnus Westerlund wrote:=0A=
>> Hi Paul,=0A=
>>=0A=
>> If I attempt to interpret what you are saying as conclusion it has=0A=
>> several implications, or am I missunderstanding you?=0A=
>>=0A=
>> 1. Obsolete a=3Dcharset attribute. The only other options would be to=0A=
>> define a small set of attribute to which it applies like "i=3D".=0A=
> That is what I am suggesting. I can't see how it ever could have worked =
=0A=
> *in general* for arbitrary charset values. And at this point I don't see =
=0A=
> a need.=0A=
>=0A=
> Alternatively, restrict the charsets which can work to those which have =
=0A=
> some benign values.=0A=
>=0A=
> IMO the most troublesome charsets are those that are wider than one =0A=
> byte, like UTF-16 or UTF-32, since they would have to coexist with the =
=0A=
> rest of the sdp being the ascii subset of UTF-8. Also troublesome are =0A=
> charsets not vaguely related to ascii, like the variants of EBCDIC.=0A=
>=0A=
>> 2. Clarify section 5 that using UTF-8 characters without NUL, CR, LF in=
=0A=
>> attribute values and textual fields are okay.=0A=
> That would amount to limiting charset to UTF-8, which is same as =0A=
> deprecating it. =0A=
=0A=
=0A=
>=0A=
>> 3. Define how attribute values that may contain NUL, CR and LF use a=0A=
>> specified escaping mechanism=0A=
> Right now it says that the charset must define an escaping mechanism, =0A=
> without saying how that might happen. AFAIK *none* of the charsets =0A=
> define an escaping mechanism.=0A=
>=0A=
> But I also don't see how one could define such a mechanism independent =
=0A=
> of the charset since it must presumably reserve some character(s) from =
=0A=
> that charset to introduce the escape.=0A=
>=0A=
>> 4. Define an escaping mechanism that applies to SDP and UTF-8 strings=0A=
>>=0A=
>> 5. Legacy warning in attempting to use escaping mechanism in old=0A=
>> attributes.=0A=
> Not sure what to say about 4 & 5.=0A=
>=0A=
>> Is this a fair summary?=0A=
> Whatever.=0A=
>=0A=
> I'm hoping I'm missing something about how this was intended to work in =
=0A=
> the first place.=0A=
>=0A=
> 	Thanks,=0A=
> 	Paul=0A=
>=0A=
>> Cheers=0A=
>>=0A=
>> Magnus=0A=
>>=0A=
>>=0A=
>>=0A=
>> On 2019-04-12 17:45, Paul Kyzivat wrote:=0A=
>>> On 4/12/19 4:59 AM, Magnus Westerlund wrote:=0A=
>>>> Hi,=0A=
>>>>=0A=
>>>> To be clear, I am not proposing that any existing attribute would be=
=0A=
>>>> forced to suddenly accept UTF-8 strings with no charset restriction.=
=0A=
>>>> Simply that new attribute's values can be defined to be UTF-8 in=0A=
>>>> general. I think the important distinction here is that a parser must =
be=0A=
>>>> ready to accept any UTF-8 character as the sender can't know if a=0A=
>>>> particular charset limitation applies to a specific consumer. However,=
=0A=
>>>> in form I don't see a problem of the SDP itself informing the consumer=
=0A=
>>>> that there is a charset limitation applied in this document.=0A=
>>>>=0A=
>>>> My interpretation of the current situation is that it we hesitate to u=
se=0A=
>>>> UTF-8 fields due to the uncertainty in the requirements on consumers o=
f=0A=
>>>> SDP.=0A=
>>> After re-reviewing the text, I think we may have a can of worms here=0A=
>>> that has existed a long time, perhaps from the beginning. Let me explai=
n:=0A=
>>>=0A=
>>> Section 5 says:=0A=
>>>=0A=
>>>      An SDP description is entirely textual.  SDP field names and=0A=
>>>      attribute names use only the US-ASCII subset of UTF-8, but textual=
=0A=
>>>      fields and attribute values MAY use the full ISO 10646 character s=
et=0A=
>>>      in UTF-8 encoding, or some other character set defined by the=0A=
>>>      "a=3Dcharset:" attribute.=0A=
>>>=0A=
>>> Section 6.10 (charset attribute) says:=0A=
>>>=0A=
>>>      The charset specified MUST be one of those registered in the IANA=
=0A=
>>>      Character Sets registry (http://www.iana.org/assignments/character=
-=0A=
>>>      sets), such as ISO-8859-1.=0A=
>>>      ...=0A=
>>>      Note that a character set specified MUST still prohibit the use of=
=0A=
>>>      bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR).  Character sets requir=
ing=0A=
>>>      the use of these characters MUST define a quoting mechanism that=
=0A=
>>>      prevents these bytes from appearing within text fields.=0A=
>>>=0A=
>>> The charsets registry has a *lot* of entries, including a lot of ancien=
t=0A=
>>> obsolete ones not vaguely related to ascii. (E.g., EBCDIC-related ones.=
)=0A=
>>> Many of these refer to RFC1345, which seems to be a pre-unicode attempt=
=0A=
>>> to rationalize character sets. The charsets registry also includes=0A=
>>> UTF-16 and UTF-32. It is really hard to understand how certain parts of=
=0A=
>>> an SDP body might be in UTF-8 while other parts are in UTF-32.=0A=
>>>=0A=
>>> I can't make any sense of:=0A=
>>>=0A=
>>>      Character sets requiring=0A=
>>>      the use of these characters MUST define a quoting mechanism that=
=0A=
>>>      prevents these bytes from appearing within text fields.=0A=
>>>=0A=
>>> AFAIK character sets don't define quoting mechanisms. Also, I don't kno=
w=0A=
>>> what it means for a charset to require use of particular characters. An=
d=0A=
>>> this text is very sloppy in muddling the use of "character" and "byte".=
=0A=
>>>=0A=
>>> The bottom line is that this is a mess. I'm not sure if it ever could=
=0A=
>>> have worked. Nor do I understand what usage it was trying to=0A=
>>> accommodate. (Note that most of this stuff is largely unchanged since=
=0A=
>>> RFC2327.)=0A=
>>>=0A=
>>> Perhaps all the charset-dependent stuff should be obsoleted.=0A=
>>>=0A=
>>> 	Thanks,=0A=
>>> 	Paul=0A=
>>>=0A=
>>> 	=0A=
>>>=0A=
>>> _______________________________________________=0A=
>>> mmusic mailing list=0A=
>>> mmusic@ietf.org=0A=
>>> https://www.ietf.org/mailman/listinfo/mmusic=0A=
>>>=0A=
> _______________________________________________=0A=
> mmusic mailing list=0A=
> mmusic@ietf.org=0A=
> https://www.ietf.org/mailman/listinfo/mmusic=0A=
>=0A=
=0A=
-- =0A=
=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A=
----------------------------------------------------------------------=0A=
=0A=


From nobody Tue Apr 16 03:04:41 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B835112047E; Tue, 16 Apr 2019 03:04:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHorK6dVVkpZ; Tue, 16 Apr 2019 03:04:28 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50077.outbound.protection.outlook.com [40.107.5.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 257D4120128; Tue, 16 Apr 2019 03:04:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RXItOdim92wCAmi/e5nrTvCWIGTwIFfIq79gsxNG6Ww=; b=M5qSBcMPsgv+p70iHBQUF/d4suv2cIN9VNNQeO+wwxqMf7pzwbyE4nMl5l8erO+xAtFJHgM3z0rWailoIAAZN9PiZHaLulGEmFrLqqSXev057xRS66a7Uat49a4s3TGXS/e/NCLQcUnIGE0qDrwoqWEQPYhOwXEu/hGFghuneJc=
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2667.eurprd07.prod.outlook.com (10.168.188.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.8; Tue, 16 Apr 2019 10:04:25 +0000
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b161:fb77:e4ea:4723]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b161:fb77:e4ea:4723%3]) with mapi id 15.20.1813.009; Tue, 16 Apr 2019 10:04:25 +0000
From: Magnus Westerlund 
To: Adam Roach , "Roni Even (A)" 
CC: "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-data-channel-sdpneg@ietf.org" , "mmusic@ietf.org" , The IESG 
Thread-Topic: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)
Thread-Index: AQHU66fNA40h4UsP7kq3a/Vv5QT6wQ==
Date: Tue, 16 Apr 2019 10:04:25 +0000
Message-ID: 
References: <155446588097.13196.6373243259627185094.idtracker@ietfa.amsl.com> <1afcb116-36cb-be51-81ac-e78fc52c9255@nostrum.com>   <6E58094ECC8D8344914996DAD28F1CCD18CDC02D@dggemm526-mbx.china.huawei.com>  <9b3e9f00-7a2c-f8e1-4f94-8004df115590@nostrum.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; 
x-originating-ip: [192.176.1.83]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 508412b0-785a-4e89-430f-08d6c252e7fc
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR0701MB2667; 
x-ms-traffictypediagnostic: HE1PR0701MB2667:
x-microsoft-antispam-prvs: 
x-forefront-prvs: 000947967F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(39860400002)(136003)(376002)(346002)(199004)(189003)(106356001)(55016002)(93886005)(478600001)(2906002)(8676002)(44832011)(97736004)(105586002)(486006)(52536014)(66066001)(86362001)(7736002)(6436002)(305945005)(53936002)(33656002)(9686003)(14454004)(229853002)(74316002)(6506007)(81166006)(81156014)(7696005)(5660300002)(476003)(14444005)(76176011)(99286004)(4326008)(8936002)(102836004)(446003)(53546011)(186003)(68736007)(110136005)(54906003)(71200400001)(71190400001)(25786009)(3846002)(26005)(6116002)(316002)(256004)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2667; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Ddu/2XOO6eY1qZ3qi3YZpucZBUZo9o4CMN+451Nfc3IO//zyYviGvWZRyH18ICkPjple0O3NAk9AUCaVP27JTRpEhDVqo93xhkV/Et+7xozU0AZAM7D2Dx/x19Qx+jyQLmNd2h8I2XqlYNoNM3DTN8JqEocRn9GEb/S3wDa9WXw1X6h1STbnTWnktJVfi0kdIENQ5k8Wkav68PmnqC3UgZLHDIPNJhjYyFxlN75x7wYk/2Q7jcjEjmTAfITqpb45w2rQYSCMZIXU9n4zmgFCaaSmj6U1j67zXnknPKNUaIGQhrhNq2id67pkMnbZFSCmUxO6OUMhwEsoaVDBLDdzGxxDq0EJe/jO2m8UIuCCa4mRLtmn2cll7ygoKy64qu4oPXaNqvn7Q1iGXJG6gXUK3GA+c8s++3CSlD98n/WXXQs=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 508412b0-785a-4e89-430f-08d6c252e7fc
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2019 10:04:25.3408 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2667
Archived-At: 
Subject: Re: [MMUSIC] Magnus Westerlund's Discuss on draft-ietf-mmusic-data-channel-sdpneg-25: (with DISCUSS and COMMENT)
X-BeenThere: mmusic@ietf.org
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: Tue, 16 Apr 2019 10:04:32 -0000

On 2019-04-15 23:53, Adam Roach wrote:=0A=
> On 4/15/19 3:25 AM, Magnus Westerlund wrote:=0A=
>> Hi,=0A=
>>=0A=
>> I think you need to split this into two parts. One is the general =0A=
>> quoting of the UTF-8 string in the label parameter. The other part is =
=0A=
>> the serialization of the WebRTC label into an UTF-8 string.=0A=
>=0A=
> I'm not sure what you mean by the second operation ("the other part") =0A=
> here. A USVString represents a sequence of Unicode codepoints ("USV" =0A=
> stands for "Unicode Scalar Values"). The procedure for going from a =0A=
> sequence of Unicode code points to a UTF-8 string is defined in RFC =0A=
> 3629. Are you simply asking for a reference to RFC 3629 here?=0A=
=0A=
The reason I was asking for a split is that the SDP attributes parameter=0A=
label takes an UTF-8 string. While in the specific case of WebRTC there=0A=
is a mapping from W3C specs USVString to this UTF-8 string. Thus, I want=0A=
to ensure that there is a seperation between what basically a mapping=0A=
from the W3C API, which possibly should be done by W3C rather than IETF.=0A=
And the general operation that needs to be applied for any UTF-8 String=0A=
used as Data channel label.=0A=
=0A=
If RFC 3629 defines the procedure then lets reference it.=0A=
=0A=
=0A=
>=0A=
>> Also, I don't get my head around the USVString if that has any =0A=
>> additional data in addition to the sequence of the Unicode scalar =0A=
>> values and if there are any action that are needed to be done in the =0A=
>> seralization to an UTF-8 string?=0A=
>=0A=
> I'm pretty comfortable asserting that the answers are "no" and "no" =0A=
> respectively. While it's not part of the spec, MDN (which hews very =0A=
> close to an "as built" description of web standards) makes this pretty =
=0A=
> clear: "USVString is equivalent to DOMString except for not allowing =0A=
> unpaired surrogate codepoints."=0A=
=0A=
Okay, if that is the case, then I guess not more are really needed.=0A=
=0A=
Cheers=0A=
=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A=
----------------------------------------------------------------------=0A=
=0A=


From nobody Tue Apr 16 17:18:12 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA7F1201BF for ; Tue, 16 Apr 2019 17:18:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level: 
X-Spam-Status: No, score=-1.89 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, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMq2qWrZOdzH for ; Tue, 16 Apr 2019 17:18:09 -0700 (PDT)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57521120199 for ; Tue, 16 Apr 2019 17:18:09 -0700 (PDT)
Received: by mail-pl1-x636.google.com with SMTP id y6so11107507pll.13 for ; Tue, 16 Apr 2019 17:18:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s92/C/PjFiJdVHn/Zs8r/uLsfHGHX0WAmn1PuNCdm+k=; b=kHyFEtJLRND/DK/28RMuikQny7Q0IvDlq6Jxu346e7qAAYrDEorx4XyDgKTvbC1QAM 0R7t7UDd5lFsmZ4zNeuPcDm24EbyockVpaObc13/sDGGYpTUx1/L47N51DjG+4QibI+f tn1eKd39dkSWDymu5DztI8y/AfDMAtTwTT5y+vnPhCXuuhpl63CRQZEc2n2ITrYFGB5d zqBULc/IjcU6FEpCUW1lCV3mm4tVZgWasXdLPFctnoCahFp4UfuKvdYl5djGwFlCcqyB crW9yi9Geq2DTsar+dpaK6F5aHFezClG998QMDkE77gDIs81wG3Us2om7PhydxOXFoxm 7O6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=s92/C/PjFiJdVHn/Zs8r/uLsfHGHX0WAmn1PuNCdm+k=; b=ecQ92mzJUvczr1E3DL7fSzMETs4q0ktF5f8KEPg2if2ePy+PAf+Xscb192bc1JJMew 3WwvpP6nWbfg9SVZHeltwHHkCMTI7vAP6Nep+cWcSvKuXrrqGNslLQtRrmj1SZzBYh14 jWwgxS56uaLKUF3FDhtKixisJvgCBTM48z3I0cJtgypQYFLtYHnDKp0nOe5cQpyEPgMw mSgEhFoCUSrYob/l0yXgLwiH5Xh0OjiTjRwrDXchZt+hVMHP4h5w0Rbx3NdT22sMZMcT w+BJzkEzDS2CCqsBfxAnoX7Bm2mQiK1+bEI6WYWYY9KWXIrFdspGgDDSlyCwSimet1Yo I/uw==
X-Gm-Message-State: APjAAAVSUkwklSWDgjhbriDIaihGCX5FPxqjsLhARsOxFXKvHzk0QUKn bHakK/kCWYZ7grgLnSEQGcy/gtLaJas=
X-Google-Smtp-Source: APXvYqxqkOViLp3DZDf+zt3e0n5tb0LafH6qwk5QVp6HfXnqCIugOGJ+qCwFoDT5jQY2tspGe9WlFg==
X-Received: by 2002:a17:902:42:: with SMTP id 60mr47525664pla.79.1555460288606;  Tue, 16 Apr 2019 17:18:08 -0700 (PDT)
Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com. [209.85.214.173]) by smtp.gmail.com with ESMTPSA id b15sm72947637pgg.90.2019.04.16.17.18.07 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Apr 2019 17:18:07 -0700 (PDT)
Received: by mail-pl1-f173.google.com with SMTP id f36so11135674plb.5 for ; Tue, 16 Apr 2019 17:18:07 -0700 (PDT)
X-Received: by 2002:a17:902:7c8c:: with SMTP id y12mr85263992pll.209.1555460287040;  Tue, 16 Apr 2019 17:18:07 -0700 (PDT)
MIME-Version: 1.0
References:    <3DD3D8D6-9B13-4F9D-80DD-F89B69240708@ericsson.com>   <98CF630B-5CCD-4CE4-84B4-81A4C53979DC@ericsson.com>    <1552A692-1020-43CA-B15E-92595729EE8B@ericsson.com>  <6EA23696-949C-40CF-BEBE-006A59856BDF@ericsson.com>
In-Reply-To: <6EA23696-949C-40CF-BEBE-006A59856BDF@ericsson.com>
From: Roman Shpount 
Date: Tue, 16 Apr 2019 20:17:54 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Christer Holmberg 
Cc: Flemming Andreasen , mmusic WG 
Content-Type: multipart/alternative; boundary="000000000000df15070586aed172"
Archived-At: 
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp
X-BeenThere: mmusic@ietf.org
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, 17 Apr 2019 00:18:11 -0000

--000000000000df15070586aed172
Content-Type: text/plain; charset="UTF-8"

Hi,

On Mon, Apr 15, 2019 at 4:13 AM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> >> 1) An ICE agent that uses FQDN needs to provide one candidate per
> address family, and indicate the addrtype for each of those candidates.
> >> 2) Some text regarding backward compatibility. Do we assume some
> default behavior by existing implementations, or do we require an ICE
> option?
> >
> > I do not think we need an ICE option. I think presence of addrtype can
> be sufficient.
>
> But if the peer ICE agent does not support it, and the FQDN resolves into
> both IPv4 and IPv6, we don't know what version it will use.
>

I do not think adding ICE option will help. Unsupported ICE options are
simply ignored so we end up not knowing what address remote agent is using.
Unfortunately FQDN was not well defined in RFC 5245. "Fortunately" I have
not seen anybody actually implementing FQDN In the worst case ICE
nomination fails.  This is no different then having no connectivity for
this specific candidate. Also, if FQDN handling is part of ice-sip-sdp,
then agent should already include ice2 option.

> This being said we need to decide two things:
> >
> > 1. Does FQDN resolution belongs to ICE processing? In this case
> candidate list includes FQDN with address type and ICE processing describes
> how FQDN are resolved and converted to addresses.
> > Or, alternatively, does FQDN resolution belongs to ICE signaling? In
> this case candidate list includes resolved address and ICE agent deals with
> addresses only.
>
> That would not work with mDNS, right?
>
> > 2. Do we specify how to deal with FQDN in ice-sip-sdp or do we specify
> in ice-sip-sdp that FQDN must be ignored and their handling is defined in
> some other draft?
>
> Perhaps the best thing would simply to produce a separate draft, to get
> some text. We can then decide whether to merge it into ice-sip-sdp.
>

I can probably describe this in ice-sip-sdp in about 3 paragraphs. The
background and other text for a new draft will make is much bigger effort.
How about I put together a pull request for ice-sip-sdp and then we can
decide if this requires a new draft?

Regards,
______________
Roman Shpount

--000000000000df15070586aed172
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

On Mon, Apr 15, 2019 at 4:13 AM Christer Holmberg <=
;christ=
er.holmberg@ericsson.com> wrote:
>> 1) An ICE agent that uses FQDN needs to pr=
ovide one candidate per address family, and indicate the addrtype for each =
of those candidates.

>> 2) Some text regarding backward compatibility. Do we assume some d=
efault behavior by existing implementations, or do we require an ICE option=
?

>

> I do not think we need an ICE option. I think presence of addrtype can=
 be sufficient.



But if the peer ICE agent does not support it, and the FQDN resolves into b=
oth IPv4 and IPv6, we don't know what version it will use.
=C2=A0
I do not think adding ICE option will help. Unsup=
ported ICE options are simply ignored so we end up not knowing what address=
 remote agent is using. Unfortunately FQDN was not well defined in RFC 5245=
. "Fortunately" I have not seen anybody actually implementing FQD=
N In the worst case ICE nomination fails.=C2=A0 This is no different then h=
aving no connectivity for this specific candidate. Also, if FQDN handling i=
s part of ice-sip-sdp, then agent should already include ice2 option.
=


> This being said we need to decide two things:

>

> 1. Does FQDN resolution belongs to ICE processing? In this case candid=
ate list includes FQDN with address type and ICE processing describes how F=
QDN are resolved and converted to addresses. 

> Or, alternatively, does FQDN resolution belongs to ICE signaling? In t=
his case candidate list includes resolved address and ICE agent deals with =
addresses only.



That would not work with mDNS, right?



> 2. Do we specify how to deal with FQDN in ice-sip-sdp or do we specify=
 in ice-sip-sdp that FQDN must be ignored and their handling is defined in =
some other draft?



Perhaps the best thing would simply to produce a separate draft, to get som=
e text. We can then decide whether to merge it into ice-sip-sdp.

I can probably describe this in ice-sip-sdp in ab=
out 3 paragraphs. The background and other text for a new draft will make i=
s much bigger effort. How about I put together a pull request for ice-sip-s=
dp and then we can decide if this requires a new draft?

Regards,
______________
Roman Shpount
<=
br>
=C2=A0


--000000000000df15070586aed172--


From nobody Wed Apr 17 22:14:24 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2C4120355 for ; Wed, 17 Apr 2019 22:14:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syfBwZV45n6n for ; Wed, 17 Apr 2019 22:14:18 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60084.outbound.protection.outlook.com [40.107.6.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D042B120304 for ; Wed, 17 Apr 2019 22:14:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3zJZfXWdq9e0wpvqpHPCyBo1aeVPcG1RLeM8owTyO6M=; b=MN0IYJH0w6dJF9bjweLRQVeyac6AXGg4YyoyBjemFyKj45maTx5h6SsfGKZQ7YFyTs/AhV5X90amejVF/XZBu6eIJnOB6AN8XEarOh40YZZLFa2KXmZMZ+yRywahWxAenT7c6zNXrEIBvlWThDlzvPdyLX/DXUrrO9vkz8q5WEs=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3451.eurprd07.prod.outlook.com (10.170.247.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.3; Thu, 18 Apr 2019 05:14:14 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184%2]) with mapi id 15.20.1813.013; Thu, 18 Apr 2019 05:14:14 +0000
From: Christer Holmberg 
To: Roman Shpount 
CC: Flemming Andreasen , mmusic WG 
Thread-Topic: [MMUSIC] FQDN support in ice-sip-sdp
Thread-Index: AQHU6jzz/50YAJx2kEqY4siuQ2NZYqY0606AgADVT4CAAEAVAP//1AeAgADQ14CAAETnAIAAnHWAgAD8QQCAAGHdAIACtQAAgACv5gCAANoNAIACbYkAgAHj6pg=
Date: Thu, 18 Apr 2019 05:14:14 +0000
Message-ID: 
References:    <3DD3D8D6-9B13-4F9D-80DD-F89B69240708@ericsson.com>   <98CF630B-5CCD-4CE4-84B4-81A4C53979DC@ericsson.com>    <1552A692-1020-43CA-B15E-92595729EE8B@ericsson.com>  <6EA23696-949C-40CF-BEBE-006A59856BDF@ericsson.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-originating-ip: [2001:14bb:42:6704:49bf:cc7a:912:ee76]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8b6d2d31-a3f0-4c4e-0a8a-08d6c3bcb349
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB3451; 
x-ms-traffictypediagnostic: HE1PR07MB3451:
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0011612A55
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(346002)(366004)(136003)(376002)(189003)(199004)(74316002)(53936002)(7736002)(46003)(25786009)(11346002)(446003)(6916009)(6506007)(4326008)(53546011)(236005)(99286004)(6436002)(478600001)(81156014)(476003)(8936002)(97736004)(6246003)(14454004)(9686003)(68736007)(7696005)(8676002)(55016002)(486006)(81166006)(54896002)(52536014)(256004)(316002)(54906003)(44832011)(2906002)(102836004)(6116002)(76176011)(14444005)(186003)(33656002)(71200400001)(86362001)(93886005)(229853002)(5660300002)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3451; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: U0mxF7ZEH2Rshl40fSKQEGsTvm/PmdShX4gu8d/u0Wlswy8lnhinKVPwav8nEzEa4K5VOT5mld6AW+iBJ/Nqxn4xM7yykCgAK/SjAKNIh/iN5VsYlJcCrJz/7eb746bEnFa/qqvAk9jhg4rG5V9gXfm+XUV5RUswBQvbXdw6Mynq5iekK/m4avIqNsl/9wpFfc1TAhW8gGcIHdjW9imRGcyVWFYCNDZvYZDvnDtljdDwgpdkmWz4ma6jZW76yr5brR52kzQsR4uiA7LWLm8roroYeBI6c3/nEe32IAZc+xPP5hKOt44p9W/gjqLS3FvI7++dAA0htiqy2tgHY+UY+o/qS6Foa/4h5BIMmmlheaspWKwv6/+m57Jk6lklcLlF1yeitg7u97hbmxJBvQhQEicfwHkBRxnMC4x50isGv7Q=
Content-Type: multipart/alternative; boundary="_000_HE1PR07MB316110FB4568C8B72760F21293260HE1PR07MB3161eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8b6d2d31-a3f0-4c4e-0a8a-08d6c3bcb349
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 05:14:14.7609 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3451
Archived-At: 
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp
X-BeenThere: mmusic@ietf.org
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: Thu, 18 Apr 2019 05:14:22 -0000

--_000_HE1PR07MB316110FB4568C8B72760F21293260HE1PR07MB3161eurp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Roman,

I think a pull request would be good. Then we have text to look at - no mat=
ter where it will end up.

I also suggest to try to keep the generic text separated from the SDP speci=
fics, so it can easily be moved elsewhere if needed.

Regarding agents that don=92t understand the addrtype parameter, perhaps we=
 could define a default IP version of an FDQN returns multiple (unless such=
 default already exists somewhere)? It will of course not help with 5245 im=
plementations, but at least new implementations will have predicatable func=
tionality.

Regards,

Christer
________________________________
From: Roman Shpount 
Sent: Wednesday, April 17, 2019 3:17:54 AM
To: Christer Holmberg
Cc: Flemming Andreasen; mmusic WG
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp

Hi,

On Mon, Apr 15, 2019 at 4:13 AM Christer Holmberg > wrote:
>> 1) An ICE agent that uses FQDN needs to provide one candidate per addres=
s family, and indicate the addrtype for each of those candidates.
>> 2) Some text regarding backward compatibility. Do we assume some default=
 behavior by existing implementations, or do we require an ICE option?
>
> I do not think we need an ICE option. I think presence of addrtype can be=
 sufficient.

But if the peer ICE agent does not support it, and the FQDN resolves into b=
oth IPv4 and IPv6, we don't know what version it will use.

I do not think adding ICE option will help. Unsupported ICE options are sim=
ply ignored so we end up not knowing what address remote agent is using. Un=
fortunately FQDN was not well defined in RFC 5245. "Fortunately" I have not=
 seen anybody actually implementing FQDN In the worst case ICE nomination f=
ails.  This is no different then having no connectivity for this specific c=
andidate. Also, if FQDN handling is part of ice-sip-sdp, then agent should =
already include ice2 option.

> This being said we need to decide two things:
>
> 1. Does FQDN resolution belongs to ICE processing? In this case candidate=
 list includes FQDN with address type and ICE processing describes how FQDN=
 are resolved and converted to addresses.
> Or, alternatively, does FQDN resolution belongs to ICE signaling? In this=
 case candidate list includes resolved address and ICE agent deals with add=
resses only.

That would not work with mDNS, right?

> 2. Do we specify how to deal with FQDN in ice-sip-sdp or do we specify in=
 ice-sip-sdp that FQDN must be ignored and their handling is defined in som=
e other draft?

Perhaps the best thing would simply to produce a separate draft, to get som=
e text. We can then decide whether to merge it into ice-sip-sdp.

I can probably describe this in ice-sip-sdp in about 3 paragraphs. The back=
ground and other text for a new draft will make is much bigger effort. How =
about I put together a pull request for ice-sip-sdp and then we can decide =
if this requires a new draft?

Regards,
______________
Roman Shpount



--_000_HE1PR07MB316110FB4568C8B72760F21293260HE1PR07MB3161eurp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable






Hi Roman,



I think a pull request would be good. Then we have text to look at - no mat=
ter where it will end up.



I also suggest to try to keep the generic text separated from the SDP speci=
fics, so it can easily be moved elsewhere if needed.



Regarding agents that don=92t understand the addrtype parameter, perhaps we=
 could define a default IP version of an FDQN returns multiple (unless such=
 default already exists somewhere)? It will of course not help with 5245 im=
plementations, but at least new implementations
 will have predicatable functionality.



Regards,



Christer




From: Roman Shpount <rom=
an@telurix.com>

Sent: Wednesday, April 17, 2019 3:17:54 AM

To: Christer Holmberg

Cc: Flemming Andreasen; mmusic WG

Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp

 








Hi,















On Mon, Apr 15, 2019 at 4:13 AM Chr=
ister Holmberg <christer.holmberg@ericsson.com> wrote:





>> 1) An ICE agent that uses FQDN needs to provide one candidate per =
address family, and indicate the addrtype for each of those candidates.

>> 2) Some text regarding backward compatibility. Do we assume some d=
efault behavior by existing implementations, or do we require an ICE option=
?

>

> I do not think we need an ICE option. I think presence of addrtype can=
 be sufficient.



But if the peer ICE agent does not support it, and the FQDN resolves into b=
oth IPv4 and IPv6, we don't know what version it will use.




 


I do not think adding ICE option will help. Unsupported ICE options ar=
e simply ignored so we end up not knowing what address remote agent is usin=
g. Unfortunately FQDN was not well defined in RFC 5245. "Fortunately&q=
uot; I have not seen anybody actually implementing
 FQDN In the worst case ICE nomination fails.  This is no different th=
en having no connectivity for this specific candidate. Also, if FQDN handli=
ng is part of ice-sip-sdp, then agent should already include ice2 option.









> This being said we need to decide two things:

>

> 1. Does FQDN resolution belongs to ICE processing? In this case candid=
ate list includes FQDN with address type and ICE processing describes how F=
QDN are resolved and converted to addresses.


> Or, alternatively, does FQDN resolution belongs to ICE signaling? In t=
his case candidate list includes resolved address and ICE agent deals with =
addresses only.



That would not work with mDNS, right?



> 2. Do we specify how to deal with FQDN in ice-sip-sdp or do we specify=
 in ice-sip-sdp that FQDN must be ignored and their handling is defined in =
some other draft?



Perhaps the best thing would simply to produce a separate draft, to get som=
e text. We can then decide whether to merge it into ice-sip-sdp.









I can probably describe this in ice-sip-sdp in about 3 paragraphs. The=
 background and other text for a new draft will make is much bigger effort.=
 How about I put together a pull request for ice-sip-sdp and then we can de=
cide if this requires a new draft?







Regards,


______________


Roman Shpount







 










--_000_HE1PR07MB316110FB4568C8B72760F21293260HE1PR07MB3161eurp_--


From nobody Sun Apr 21 09:06:03 2019
Return-Path: 
X-Original-To: mmusic@ietf.org
Delivered-To: mmusic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBD312008A; Sun, 21 Apr 2019 09:06:00 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: mmusic@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: mmusic@ietf.org
Message-ID: <155586276077.9700.12708725897033868038@ietfa.amsl.com>
Date: Sun, 21 Apr 2019 09:06:00 -0700
Archived-At: 
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-10.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 21 Apr 2019 16:06:01 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia Session Control WG of the IETF.

        Title           : MSRP over Data Channels
        Authors         : Keith Drage
                          Maridi R. Makaraju (Raju)
                          Juergen Stoetzer-Bradler
                          Richard Ejzak
                          Jerome Marcon
                          Jose M. Recio
	Filename        : draft-ietf-mmusic-msrp-usage-data-channel-10.txt
	Pages           : 18
	Date            : 2019-04-21

Abstract:
   This document specifies how the Message Session Relay Protocol (MSRP)
   can be instantiated as a data channel sub-protocol, using the SDP
   offer/answer exchange-based generic data channel negotiation
   framework.  Two network configurations are documented: a WebRTC end-
   to-end configuration (connecting two MSRP over data channel
   endpoints), and a gateway configuration (connecting an MSRP over data
   channel endpoint with an MSRP over TCP or TLS endpoint).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-msrp-usage-data-channel/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-mmusic-msrp-usage-data-channel-10
https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-msrp-usage-data-channel-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msrp-usage-data-channel-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Sun Apr 21 13:24:46 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2A812018A for ; Sun, 21 Apr 2019 13:24:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1vqAXVEUTey for ; Sun, 21 Apr 2019 13:24:42 -0700 (PDT)
Received: from mail-vk1-xa2e.google.com (mail-vk1-xa2e.google.com [IPv6:2607:f8b0:4864:20::a2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A4CF120186 for ; Sun, 21 Apr 2019 13:24:42 -0700 (PDT)
Received: by mail-vk1-xa2e.google.com with SMTP id d30so224294vkl.10 for ; Sun, 21 Apr 2019 13:24:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bVcaGkwUxxymKe0P8k/E3SlXjlv2rWvfTPNTBo2nY7k=; b=bLtEx8w5gy5OHUlwHnmknKNqIefO9GXr8MjUlj34lDntZf7RF5gdRk6/5hjh7rg0yM yFpMv3jVn0eT0SGW6yqNkUOwuq7o7MiMz7hBNnPT/n2O7MLxRKF1GagNzNJsDuk6DtlA y78bKqoyjGXUQZQ7TjllL/f9zhlYlnjz+kYFD6wS7IO+2JWJLcK3V75YF+zQ2CIr+18l WhrMT3yQRt6znQn0zibgecyUpRYOHQ0FCdouKIN4mJ1BGMyUQjpFMLboBYEJmhR0XzsZ FyB7IV/cMXWBMNuFv9JLVWMNiA+SRt89iU2VDzz6qEsmc6Qwt5yBvQdx+h9MS0EPqwL9 v1DQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bVcaGkwUxxymKe0P8k/E3SlXjlv2rWvfTPNTBo2nY7k=; b=hZbALm5D3fznZvUcmxWj3KNOTjIqu1g8/HmMP+PYDg63KwWN/KrrWXuyWDGxig6GxC JDIRcrCQIQl9NZlUpLZejzrcASEJ4BL4WSO0IJV2+K1XORyJOuEj5206ke/PxYxrCjYT LbyM5jKfh/GYj1dqo+RZbHFSLj5MpdjaGY17Fhi3w7jSptHiRNeTHwa1teZs7+p1rPiI loFHLI0uT6tkrgmPkhtsYdffLgN2M2onjOe8lIdghdMqS3qoxFvZrjj9O3bsbEbvc1yr WHlwOjbLu07Xp+I8IOscO5Zd2ttmJvAEO4xcy97XJEowj5PGoBEfXn29OnS6ZnRPp4hm d2Vg==
X-Gm-Message-State: APjAAAWoDvnufEdoygrYbmORA0hhcF8KTDdX7FuRHHlgPrGWmlpWm/VZ vAVVI95nZ5TO2ozgWpd3PB7/CdvCM+vxHODb3Tk=
X-Google-Smtp-Source: APXvYqx+LyyZbeLpIvoF1x64QgNrUQ3xbrt/48fxtX/YGZZssAOlV229Yj8pYPOP3S3D8ruuMm5UCYgLpeZG2kDSYuw=
X-Received: by 2002:a1f:8d45:: with SMTP id p66mr8005606vkd.21.1555878281259;  Sun, 21 Apr 2019 13:24:41 -0700 (PDT)
MIME-Version: 1.0
References:    <3DD3D8D6-9B13-4F9D-80DD-F89B69240708@ericsson.com>   <98CF630B-5CCD-4CE4-84B4-81A4C53979DC@ericsson.com>    <1552A692-1020-43CA-B15E-92595729EE8B@ericsson.com>  <6EA23696-949C-40CF-BEBE-006A59856BDF@ericsson.com>  
In-Reply-To: 
From: Suhas Nandakumar 
Date: Sun, 21 Apr 2019 13:24:30 -0700
Message-ID: 
To: Christer Holmberg 
Cc: Flemming Andreasen , Roman Shpount , mmusic WG 
Content-Type: multipart/alternative; boundary="00000000000044af5105871024f8"
Archived-At: 
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp
X-BeenThere: mmusic@ietf.org
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: Sun, 21 Apr 2019 20:24:45 -0000

--00000000000044af5105871024f8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Roman

   Do you have an ETA on the pull request

Thanks
Suhas

On Wed, Apr 17, 2019 at 10:14 PM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi Roman,
>
> I think a pull request would be good. Then we have text to look at - no
> matter where it will end up.
>
> I also suggest to try to keep the generic text separated from the SDP
> specifics, so it can easily be moved elsewhere if needed.
>
> Regarding agents that don=E2=80=99t understand the addrtype parameter, pe=
rhaps we
> could define a default IP version of an FDQN returns multiple (unless suc=
h
> default already exists somewhere)? It will of course not help with 5245
> implementations, but at least new implementations will have predicatable
> functionality.
>
> Regards,
>
> Christer
> ------------------------------
> *From:* Roman Shpount 
> *Sent:* Wednesday, April 17, 2019 3:17:54 AM
> *To:* Christer Holmberg
> *Cc:* Flemming Andreasen; mmusic WG
> *Subject:* Re: [MMUSIC] FQDN support in ice-sip-sdp
>
> Hi,
>
> On Mon, Apr 15, 2019 at 4:13 AM Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
> >> 1) An ICE agent that uses FQDN needs to provide one candidate per
> address family, and indicate the addrtype for each of those candidates.
> >> 2) Some text regarding backward compatibility. Do we assume some
> default behavior by existing implementations, or do we require an ICE
> option?
> >
> > I do not think we need an ICE option. I think presence of addrtype can
> be sufficient.
>
> But if the peer ICE agent does not support it, and the FQDN resolves into
> both IPv4 and IPv6, we don't know what version it will use.
>
>
> I do not think adding ICE option will help. Unsupported ICE options are
> simply ignored so we end up not knowing what address remote agent is usin=
g.
> Unfortunately FQDN was not well defined in RFC 5245. "Fortunately" I have
> not seen anybody actually implementing FQDN In the worst case ICE
> nomination fails.  This is no different then having no connectivity for
> this specific candidate. Also, if FQDN handling is part of ice-sip-sdp,
> then agent should already include ice2 option.
>
> > This being said we need to decide two things:
> >
> > 1. Does FQDN resolution belongs to ICE processing? In this case
> candidate list includes FQDN with address type and ICE processing describ=
es
> how FQDN are resolved and converted to addresses.
> > Or, alternatively, does FQDN resolution belongs to ICE signaling? In
> this case candidate list includes resolved address and ICE agent deals wi=
th
> addresses only.
>
> That would not work with mDNS, right?
>
> > 2. Do we specify how to deal with FQDN in ice-sip-sdp or do we specify
> in ice-sip-sdp that FQDN must be ignored and their handling is defined in
> some other draft?
>
> Perhaps the best thing would simply to produce a separate draft, to get
> some text. We can then decide whether to merge it into ice-sip-sdp.
>
>
> I can probably describe this in ice-sip-sdp in about 3 paragraphs. The
> background and other text for a new draft will make is much bigger effort=
.
> How about I put together a pull request for ice-sip-sdp and then we can
> decide if this requires a new draft?
>
> Regards,
> ______________
> Roman Shpount
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

--00000000000044af5105871024f8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Roman

=C2=A0 =C2=A0Do you have an ETA on the pull request

Thanks
Suhas
On Wed, Apr 17, 2019 at 10:14 PM Ch=
rister Holmberg <chris=
ter.holmberg@ericsson.com> wrote:






Hi Roman,



I think a pull request would be good. Then we have text to look at - no mat=
ter where it will end up.



I also suggest to try to keep the generic text separated from the SDP speci=
fics, so it can easily be moved elsewhere if needed.



Regarding agents that don=E2=80=99t understand the addrtype parameter, perh=
aps we could define a default IP version of an FDQN returns multiple (unles=
s such default already exists somewhere)? It will of course not help with 5=
245 implementations, but at least new implementations
 will have predicatable functionality.



Regards,



Christer




From: Roman Shpoun=
t <roman@telurix.=
com>

Sent: Wednesday, April 17, 2019 3:17:54 AM

To: Christer Holmberg

Cc: Flemming Andreasen; mmusic WG

Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp

=C2=A0








Hi,















On Mon, Apr 15, 2019 at 4:=
13 AM Christer Holmberg <christer.holmberg@ericsson.com> wrote:





>> 1) An ICE agent that uses FQDN needs to provide one candidate per =
address family, and indicate the addrtype for each of those candidates.

>> 2) Some text regarding backward compatibility. Do we assume some d=
efault behavior by existing implementations, or do we require an ICE option=
?

>

> I do not think we need an ICE option. I think presence of addrtype can=
 be sufficient.



But if the peer ICE agent does not support it, and the FQDN resolves into b=
oth IPv4 and IPv6, we don't know what version it will use.




=C2=A0


I do not think adding ICE option will help. Unsupported ICE options ar=
e simply ignored so we end up not knowing what address remote agent is usin=
g. Unfortunately FQDN was not well defined in RFC 5245. "Fortunately&q=
uot; I have not seen anybody actually implementing
 FQDN In the worst case ICE nomination fails.=C2=A0 This is no different th=
en having no connectivity for this specific candidate. Also, if FQDN handli=
ng is part of ice-sip-sdp, then agent should already include ice2 option.










> This being said we need to decide two things:

>

> 1. Does FQDN resolution belongs to ICE processing? In this case candid=
ate list includes FQDN with address type and ICE processing describes how F=
QDN are resolved and converted to addresses.


> Or, alternatively, does FQDN resolution belongs to ICE signaling? In t=
his case candidate list includes resolved address and ICE agent deals with =
addresses only.



That would not work with mDNS, right?



> 2. Do we specify how to deal with FQDN in ice-sip-sdp or do we specify=
 in ice-sip-sdp that FQDN must be ignored and their handling is defined in =
some other draft?



Perhaps the best thing would simply to produce a separate draft, to get som=
e text. We can then decide whether to merge it into ice-sip-sdp.









I can probably describe this in ice-sip-sdp in about 3 paragraphs. The=
 background and other text for a new draft will make is much bigger effort.=
 How about I put together a pull request for ice-sip-sdp and then we can de=
cide if this requires a new draft?







Regards,


______________


Roman Shpount







=C2=A0










_______________________________________________

mmusic mailing list

mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic




--00000000000044af5105871024f8--


From nobody Sun Apr 21 15:07:47 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD981201C3; Sun, 21 Apr 2019 15:07:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qFIr54X16Jw; Sun, 21 Apr 2019 15:07:42 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79774120175; Sun, 21 Apr 2019 15:07:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14949; q=dns/txt; s=iport; t=1555884462; x=1557094062; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=ss6luDAV00BoblMFCCdU8kMTeaZaOYKKdfdyg3P8jQo=; b=mchbQZg6hzRbHpOD4OhC2G3/zrCgDDJiZhPMmAPqNpomgvlwuWSqQY+U 9ai1cz0ZjcqRx8u8sgZ+8l4VsXE900upt/IG9r6ECgvS/OslNMeS2ldoY DQmBtkgxFo1+B4DoylAsyZty0GMw4svKGSy6Ezti9JWX/TupbOQpsG8p2 U=;
X-IronPort-AV: E=Sophos;i="5.60,379,1549929600";  d="scan'208,217";a="265186271"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Apr 2019 22:07:40 +0000
Received: from [10.118.10.21] (rtp-fandreas-2-8814.cisco.com [10.118.10.21]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTP id x3LM7dL1012344; Sun, 21 Apr 2019 22:07:40 GMT
To: Martin Thomson , Bo Burman , mmusic , Jon Peterson , Cullen Jennings , "'Eric Rescorla'" 
Cc: "draft-ietf-mmusic-sdp-uks@ietf.org" 
References:     <69e1ed84-7bae-4258-897b-a6d36716c261@www.fastmail.com> <718ce899-166c-b793-c7d4-84bb5fcceea5@cisco.com>   <4a6a7d47-bd49-ed20-561e-ed4223f2d190@cisco.com> <0de3648b-e750-41a7-819d-59d1bbf5ad70@www.fastmail.com>
From: Flemming Andreasen 
Message-ID: 
Date: Sun, 21 Apr 2019 18:07:39 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <0de3648b-e750-41a7-819d-59d1bbf5ad70@www.fastmail.com>
Content-Type: multipart/alternative; boundary="------------B10221D3CFAAFC5DCD554D96"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.118.10.21, rtp-fandreas-2-8814.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: 
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-uks-03
X-BeenThere: mmusic@ietf.org
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: Sun, 21 Apr 2019 22:07:46 -0000

This is a multi-part message in MIME format.
--------------B10221D3CFAAFC5DCD554D96
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit



On 4/8/19 8:20 PM, Martin Thomson wrote:
> On Tue, Apr 9, 2019, at 06:48, Flemming Andreasen wrote:
>>   Offers and SIP Requests are not the same. In RFC 3725 Flow 2 and 3, it
>> is the controller that generates the SIP Requests and the endpoints
>> that generate the SIP Responses and to quote RFC 8224, Section 3:
>>
>>   Note that the scope of this document is limited to providing an
>>   identity assurance for SIP requests; solving this problem for SIP
>>   responses is outside the scope of this work (see [RFC4916]).
> Right.  What is relevant here is the offers and answers, not the SIP requests.  RFC 3725 shows only inconsequential offers being generated by the controller.
This is where we differ. In the SIP case, the attack you describe is 
predicated on a mismatch between the Identity information provided in 
the SIP request and the (assumed) identity of the SDP in an offer, thus 
the SIP requests are indeed very relevant to the discussion.

> In the RFC 8224 context, this remains true, but it is hard to see why (more on that below).
>
>>   Thus, I still don't see how you get these endpoint Identity assertions
>> sent across with 3PCC. Maybe we need somebody else to chime in at this
>> point.
>>
>>   Jon/Cullen/Ekr: As authors of RFC 8224, can you help shed light on
>> this part of the thread ?
> [...]
>
>> Ok - I think you are saying a bit
>> more actually. Using the terminology of RFC 8224, I believe you are
>> assuming that the attacker controls the Authentication Service (which I
>> see as more than the signaling channel). If that is the case, then I
>> would suggest clarifying that in the text.
> I don't believe that is the case.  But I see now the angle you are concerned about.  Because RFC 8224 doesn't consider 3PCC, we might have a problem in the sense that 3PCC doesn't work at all with SIP Identity, but let's see if we can work out what it looks like.
>
> Note that "signing" as imagined in RFC 8224 depends on there being SDP to sign.  If there is SDP and it is not bogus, then there is potentially a binding between the a=fingerprint attributes and some identity.  Whether that is in the SIP Identity header field (RFC 8224) or the SDP itself (WebRTC), the result is the same.
Maybe so, but the flows and feasibility of the attacks are not, and that 
is an important distinction:
- 3PCC is defined for SIP, and SIP Identity is only defined for SIP Requests
- WebRTC Identity on the other hand is defined as an SDP attribute, and 
it is included in SDP offers (and optionally answers)

> For 3PCC with RFC 8224, either the controller is responsible for signing, the signing is performed by proxies near A and B (proxies that are not shown in the figure), or by A and B directly.  The point of the signature is to protect against attack between the point that the signature is added and where it is removed.  If the controller is both signing and consuming signatures, that would be pointless because they would be trusted by both A and B, so we'll ignore that case.   Therefore, we assume that signatures happen closer to A or B (or both) so that the signatures serve a purpose.
>
> So we have:  A---AuthSvcA---...---AuthSvcB---B with a controller somewhere on the signaling path between the two ends.  Generally, RFC 8224 assumes that the path from A to its Authentication Service is "trusted", so the attack is on the path between the two Authentication Services.  The controller can be anywhere, because we're not assuming anything about that.
Agreed so far.
> You might wonder whether the controller can generate bogus SDP that can be signed, but that is a constraint on deployment, not on security.
I disagree - it is a constraint on the overall feasibility of the 
attack. If we can't construct a deployment scenario that enables the 
attack, then the attack is not practically feasible, and then why are we 
concerned with it ?

To be more specific, the signature covering the SDP is generated by the 
authentication service above, and you stated (and I agree) that the 
attack cannot happen between A and AuthSvcA. Given that, how can the 
controller generate bogus SDP that gets signed (with a signature 
covering the "From: A", "To: B", Date and SDP fingerprint ) ?


>    Bogus SDP generated by a controller that sits on the "untrusted" portion of the signaling path won't be signed and therefore might be rejected, but that just limits the choices the controller has.
I agree it won't be signed, but at that point I don't believe we are in 
the attack scenario the document describes (?)

>   If the controller is on a "trusted" segment, then it might generate SDP for the endpoint nearest to it and have a valid signature over that content.
Sure, but above, you just said that wasn't the attack scenario we were 
contemplating (presumably because it invalidates the premise of SIP 
Identity to begin with)
>
> The attack that we're contemplating acts on the "untrusted" segment of the signaling path.  It operates without collaboration with any of the "trusted" entities.  It relies on being able to intercept and modify signaling on that path segment.  That's all.
I hear you, but you have yet to show me how that is possible. Please 
provide an example SIP flow that demonstrates how this attack is 
realized, 'cause I still don't see it.

>   In all cases other than the nonsensical one where the controller acts as Authentication Service for both parties, the attack we're  considering doesn't depend on the Authentication Service being compromised.
I agree that should be the premise, but I don't see how it is achieved.
> In the extreme case, say that  A and B sign their own SDP/signaling and assert their own identities.  If the controller is the attacker, they control when sessions are established and how.  They can copy-paste signatures between the different messages they receive.
Please provide an example flow that illustrates this in more detail.

Thanks

-- Flemming



--------------B10221D3CFAAFC5DCD554D96
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    

    
On 4/8/19 8:20 PM, Martin Thomson
      wrote:

    

    

      
On Tue, Apr 9, 2019, at 06:48, Flemming Andreasen wrote:


      

        
 Offers and SIP Requests are not the same. In RFC 3725 Flow 2 and 3, it 
is the controller that generates the SIP Requests and the endpoints 
that generate the SIP Responses and to quote RFC 8224, Section 3:

 Note that the scope of this document is limited to providing an
 identity assurance for SIP requests; solving this problem for SIP
 responses is outside the scope of this work (see [RFC4916]). 


      

      
Right.  What is relevant here is the offers and answers, not the SIP requests.  RFC 3725 shows only inconsequential offers being generated by the controller.  

    

    This is where we differ. In the SIP case, the attack you describe is
    predicated on a mismatch between the Identity information provided
    in the SIP request and the (assumed) identity of the SDP in an
    offer, thus the SIP requests are indeed very relevant to the
    discussion. 

    

    

      
In the RFC 8224 context, this remains true, but it is hard to see why (more on that below).



      

        
 Thus, I still don't see how you get these endpoint Identity assertions 
sent across with 3PCC. Maybe we need somebody else to chime in at this 
point. 

 Jon/Cullen/Ekr: As authors of RFC 8224, can you help shed light on 
this part of the thread ?


      

      
[...]



      

        
Ok - I think you are saying a bit 
more actually. Using the terminology of RFC 8224, I believe you are 
assuming that the attacker controls the Authentication Service (which I 
see as more than the signaling channel). If that is the case, then I 
would suggest clarifying that in the text. 


      

      
I don't believe that is the case.  But I see now the angle you are concerned about.  Because RFC 8224 doesn't consider 3PCC, we might have a problem in the sense that 3PCC doesn't work at all with SIP Identity, but let's see if we can work out what it looks like.

Note that "signing" as imagined in RFC 8224 depends on there being SDP to sign.  If there is SDP and it is not bogus, then there is potentially a binding between the a=fingerprint attributes and some identity.  Whether that is in the SIP Identity header field (RFC 8224) or the SDP itself (WebRTC), the result is the same. 

    

    Maybe so, but the flows and feasibility of the attacks are not, and
    that is an important distinction:

    - 3PCC is defined for SIP, and SIP Identity is only defined for SIP
    Requests

    - WebRTC Identity on the other hand is defined as an SDP attribute,
    and it is included in SDP offers (and optionally answers)

    

    

      
For 3PCC with RFC 8224, either the controller is responsible for signing, the signing is performed by proxies near A and B (proxies that are not shown in the figure), or by A and B directly.  The point of the signature is to protect against attack between the point that the signature is added and where it is removed.  If the controller is both signing and consuming signatures, that would be pointless because they would be trusted by both A and B, so we'll ignore that case.   Therefore, we assume that signatures happen closer to A or B (or both) so that the signatures serve a purpose.

So we have:  A---AuthSvcA---...---AuthSvcB---B with a controller somewhere on the signaling path between the two ends.  Generally, RFC 8224 assumes that the path from A to its Authentication Service is "trusted", so the attack is on the path between the two Authentication Services.  The controller can be anywhere, because we're not assuming anything about that.


    

    Agreed so far. 

    

      
You might wonder whether the controller can generate bogus SDP that can be signed, but that is a constraint on deployment, not on security.

    

    I disagree - it is a constraint on the overall feasibility of the
    attack. If we can't construct a deployment scenario that enables the
    attack, then the attack is not practically feasible, and then why
    are we concerned with it ?

    

    To be more specific, the signature covering the SDP is generated by
    the authentication service above, and you stated (and I agree) that
    the attack cannot happen between A and AuthSvcA. Given that, how can
    the controller generate bogus SDP that gets signed (with a signature
    covering the "From: A", "To: B", Date and SDP fingerprint ) ?

    

    

    

      
  Bogus SDP generated by a controller that sits on the "untrusted" portion of the signaling path won't be signed and therefore might be rejected, but that just limits the choices the controller has. 

    

    I agree it won't be signed, but at that point I don't believe we are
    in the attack scenario the document describes (?)

    

    

      
 If the controller is on a "trusted" segment, then it might generate SDP for the endpoint nearest to it and have a valid signature over that content.

    

    Sure, but above, you just said that wasn't the attack scenario we
    were contemplating (presumably because it invalidates the premise of
    SIP Identity to begin with) 

    

      

The attack that we're contemplating acts on the "untrusted" segment of the signaling path.  It operates without collaboration with any of the "trusted" entities.  It relies on being able to intercept and modify signaling on that path segment.  That's all. 

    

    I hear you, but you have yet to show me how that is possible. Please
    provide an example SIP flow that demonstrates how this attack is
    realized, 'cause I still don't see it. 

    

    

      
 In all cases other than the nonsensical one where the controller acts as Authentication Service for both parties, the attack we're  considering doesn't depend on the Authentication Service being compromised.  


    

    I agree that should be the premise, but I don't see how it is
    achieved. 

    

      
In the extreme case, say that  A and B sign their own SDP/signaling and assert their own identities.  If the controller is the attacker, they control when sessions are established and how.  They can copy-paste signatures between the different messages they receive.

    

    Please provide an example flow that illustrates this in more detail.
    

    

    Thanks 

    

    -- Flemming 

    

    

    

    

  


--------------B10221D3CFAAFC5DCD554D96--


From nobody Sun Apr 21 16:12:51 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0601202CB; Sun, 21 Apr 2019 16:12:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiTJQ6yYOfXb; Sun, 21 Apr 2019 16:12:39 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60088.outbound.protection.outlook.com [40.107.6.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54AF3120142; Sun, 21 Apr 2019 16:12:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JUX0E6Ak9wgM9MPCalfpMj66nREimidwYuT7M+GOypg=; b=KtX+Sq1KbBpU673Kl6LT62am80psVsWqiDUwZEKtPyA75fElHffV0rmtvwADz58sptvSTBmPe9W7PnJiNiUopyn3IYDSPyoNlYYRWq9lQNNixMb1B5l+rGFi6ySaGffzF7h0s2tKCqN7xNxhZ5L4gA8oz7HjrLCYS7+Oayu2nrE=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3259.eurprd07.prod.outlook.com (10.170.246.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.9; Sun, 21 Apr 2019 23:12:35 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184%2]) with mapi id 15.20.1835.010; Sun, 21 Apr 2019 23:12:35 +0000
From: Christer Holmberg 
To: "mmusic@ietf.org" , "rtcweb@ietf.org" ,  "clue@ietf.org" 
Thread-Topic: Scope of SDP m= line 'webrtc-datachannel'
Thread-Index: AQHU+Je0/HMXLDHCpUOf+vA6YZZ9Og==
Date: Sun, 21 Apr 2019 23:12:35 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.16.1.190220
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-originating-ip: [176.93.29.18]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3756916f-34ff-4562-cf7f-08d6c6aed74d
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3259; 
x-ms-traffictypediagnostic: HE1PR07MB3259:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0014E2CF50
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(396003)(376002)(39860400002)(136003)(199004)(189003)(58126008)(110136005)(66446008)(6506007)(14454004)(6486002)(6436002)(66066001)(6116002)(36756003)(68736007)(7736002)(66946007)(76116006)(73956011)(66556008)(64756008)(2501003)(2906002)(44832011)(66476007)(86362001)(2201001)(83716004)(186003)(102836004)(8936002)(26005)(81156014)(81166006)(71190400001)(71200400001)(99286004)(5660300002)(606006)(478600001)(450100002)(25786009)(966005)(3846002)(82746002)(97736004)(54896002)(6306002)(2616005)(33656002)(256004)(14444005)(476003)(486006)(236005)(6512007)(53936002)(316002)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3259; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Ly4tRHBlMTBfmdlixAnRumQF1QqR1ALYKbP4Q3HA5DQgoRvhY5gqYN8epWRKqkcitOFEwIACKEbmpIK2NQ805bw0U6SA7M4nvNhcsmnw6gx209rYIo4GdeXFGTyJYP0NNDzxSS0oauTe3WXvQLh70gg8ErbzgfFFmYqAkrqQK1ny4S7AMaAhXB7ZrGr/MyJugpiN9P/+mOg+XLRpzLuVNA5o+q2Hwt1FbSC92ISkpwmcJhv5KA0arQ9B6GSbtVTwJEzAR29n8U4hPv8Fx7hcvtMRY6nfK7FWmhSkO5zj434gHFVdUu9RE/bfBYsda12fTW3o1+Su53VbyLsM8/qdbcovTg6JY/JYLnLhcJ+wQKG14J520+vCfZv8MPOtXkplwEz0g2j/JIa+fXrbVOdPRWR6lYctwkU6B1GfYb4ZLBI=
Content-Type: multipart/alternative; boundary="_000_D591F3E7EBC84844A0FA6ED64DD2B5F6ericssoncom_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3756916f-34ff-4562-cf7f-08d6c6aed74d
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2019 23:12:35.6712 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3259
Archived-At: 
Subject: [MMUSIC] Scope of SDP m= line 'webrtc-datachannel'
X-BeenThere: mmusic@ietf.org
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: Sun, 21 Apr 2019 23:12:42 -0000

--_000_D591F3E7EBC84844A0FA6ED64DD2B5F6ericssoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGksDQoNCkkgYW0gY3Jvc3MtcG9zdGluZyB0aGlzIG9uIG11bHRpcGxlIGxpc3QsIHRvIG1ha2Ug
cGVvcGxlIGF3YXJlIG9mIHRoZSBpc3N1ZS4gSG93ZXZlciwgSSBhc2sgdGhhdCBhbnkgY29tbWVu
dHMgYW5kIGRpc2N1c3Npb25zIHRha2UgcGxhY2Ugb24gdGhlIE1NVVNJQyBsaXN0IG9ubHkuDQoN
CkkgZm91bmQgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQgaW4gc2VjdGlvbiA0LjUgb2YgZHJhZnQt
aWV0Zi1tbXVzaWMtc2N0cC1zZHA6DQoNCiAgIOKAnE5PVEU6ICd3ZWJydGMtZGF0YWNoYW5uZWwn
IGluZGljYXRlcyB0aGUgV2ViUlRDIERhdGEgQ2hhbm5lbA0KICAgRXN0YWJsaXNobWVudCBQcm90
b2NvbCBkZWZpbmVkIGluIFtJLUQuaWV0Zi1ydGN3ZWItZGF0YS1wcm90b2NvbF0u4oCdDQoNCklu
IGFkZGl0aW9uLCBpbiB0aGUgSUFOQSByZWdpc3RyYXRpb24gb2Yg4oCYd2VicnRjLWRhdGFjaGFu
bmVs4oCZIChzZWN0aW9uIDE1LjMpLCBkcmFmdC1pZXRmLXJ0Y3dlYi1kYXRhLXByb3RvY29sIGlz
IHJlZmVyZW5jZWQuDQoNClRvIHJlZnJlc2ggZXZlcnlvbmUsIGRyYWZ0LWlldGYtcnRjd2ViLWRh
dGEtcHJvdG9jb2wgZGVmaW5lcyBEQ0VQICh0aGUgaW5iYW5kIHByb3RvY29sIGZvciBoYW5kbGlu
ZyBXZWJSVEMgRGF0YSBDaGFubmVscyksIGFuZCDigJh3ZWJydGMtZGF0YWNoYW5uZWzigJkgaXMg
dXNlZCBpbiB0aGUgU0RQIG09IGxpbmUgd2hlbiBlc3RhYmxpc2hpbmcgYW4gU0NUUCBhc3NvY2lh
dGlvbiBmb3Igc3VjaCBjaGFubmVsLg0KDQpIb3dldmVyLCBib3RoIGRyYWZ0LWlldGYtbW11c2lj
LWRhdGFjaGFubmVsLXNkcC1uZWcgYW5kIGRyYWZ0LWlldGYtY2x1ZS1kYXRhLWNoYW5uZWwgdXNl
IOKAmHdlYnJ0Yy1kYXRhY2hhbm5lbOKAmSBpbiB0aGUg4oCcbT3igJ0gbGluZSwgYW5kIHRob3Nl
IGRyYWZ0cyBkbyBub3QgdXNlIERDRVAuDQoNCk15IHN1Z2dlc3Rpb24gdG8gZml4IHRoaXMgaXMg
dG8gbW9kaWZ5IHRoZSB0ZXh0IGluIGRyYWZ0LWlldGYtbW11c2ljLXNjdHAtc2RwLCB0byBhbHdh
eXMgdXNlIOKAmHdlYnJ0Yy1kYXRhY2hhbm5lbOKAmSBmb3IgV2ViUlRDIERhdGEgQ2hhbm5lbHMg
4oCTIG5vIG1hdHRlciB3aGV0aGVyIERDRVAgaXMgdXNlZCBvciBub3QuDQoNCkkgaGF2ZSBjcmVh
dGVkIGEgcHVsbCByZXF1ZXN0Og0KDQpodHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtc2N0
cC1zZHAvcHVsbC8xNQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0K

--_000_D591F3E7EBC84844A0FA6ED64DD2B5F6ericssoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw
cmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv
cm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm
b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFp
bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uSFRNTFBy
ZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi
Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt
YXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7
bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt
c2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h
cmdpbjo3MC44NXB0IDIuMGNtIDcwLjg1cHQgMi4wY207fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw
YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRkki
IGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u
MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+
SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dCI+SSBhbSBjcm9zcy1wb3N0aW5nIHRoaXMgb24gbXVsdGlwbGUgbGlzdCwgdG8gbWFrZSBwZW9w
bGUgYXdhcmUgb2YgdGhlIGlzc3VlLiBIb3dldmVyLCBJIGFzayB0aGF0IGFueSBjb21tZW50cyBh
bmQgZGlzY3Vzc2lvbnMgdGFrZSBwbGFjZSBvbiB0aGUgTU1VU0lDIGxpc3Qgb25seS48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdCI+SSBmb3VuZCB0aGUgZm9sbG93aW5nIHN0YXRlbWVudCBpbiBzZWN0aW9uIDQuNSBvZiBk
cmFmdC1pZXRmLW1tdXNpYy1zY3RwLXNkcDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IOKAnE5PVEU6ICd3ZWJy
dGMtZGF0YWNoYW5uZWwnIGluZGljYXRlcyB0aGUgV2ViUlRDIERhdGEgQ2hhbm5lbDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEVzdGFibGlzaG1lbnQgUHJvdG9jb2wgZGVmaW5l
ZCBpbiBbSS1ELmlldGYtcnRjd2ViLWRhdGEtcHJvdG9jb2xdLuKAnTxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JbiBh
ZGRpdGlvbiwgaW4gdGhlIElBTkEgcmVnaXN0cmF0aW9uIG9mIOKAmHdlYnJ0Yy1kYXRhY2hhbm5l
bOKAmSAoc2VjdGlvbiAxNS4zKSwgZHJhZnQtaWV0Zi1ydGN3ZWItZGF0YS1wcm90b2NvbCBpcyBy
ZWZlcmVuY2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UbyByZWZyZXNoIGV2ZXJ5b25lLCBkcmFmdC1pZXRmLXJ0
Y3dlYi1kYXRhLXByb3RvY29sIGRlZmluZXMgRENFUCAodGhlIGluYmFuZCBwcm90b2NvbCBmb3Ig
aGFuZGxpbmcgV2ViUlRDIERhdGEgQ2hhbm5lbHMpLCBhbmQg4oCYd2VicnRjLWRhdGFjaGFubmVs
4oCZIGlzIHVzZWQgaW4gdGhlIFNEUCBtPSBsaW5lIHdoZW4gZXN0YWJsaXNoaW5nDQogYW4gU0NU
UCBhc3NvY2lhdGlvbiBmb3Igc3VjaCBjaGFubmVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Ib3dldmVyLCBib3Ro
IGRyYWZ0LWlldGYtbW11c2ljLWRhdGFjaGFubmVsLXNkcC1uZWcgYW5kIGRyYWZ0LWlldGYtY2x1
ZS1kYXRhLWNoYW5uZWwgdXNlIOKAmHdlYnJ0Yy1kYXRhY2hhbm5lbOKAmSBpbiB0aGUg4oCcbT3i
gJ0gbGluZSwgYW5kIHRob3NlIGRyYWZ0cyBkbyBub3QgdXNlIERDRVAuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk15
IHN1Z2dlc3Rpb24gdG8gZml4IHRoaXMgaXMgdG8gbW9kaWZ5IHRoZSB0ZXh0IGluIGRyYWZ0LWll
dGYtbW11c2ljLXNjdHAtc2RwLCB0byBhbHdheXMgdXNlIOKAmHdlYnJ0Yy1kYXRhY2hhbm5lbOKA
mSBmb3IgV2ViUlRDIERhdGEgQ2hhbm5lbHMg4oCTIG5vIG1hdHRlciB3aGV0aGVyIERDRVAgaXMg
dXNlZCBvciBub3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkgaGF2ZSBjcmVhdGVkIGEgcHVsbCByZXF1ZXN0Ojxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2NkaDR1
L2RyYWZ0LXNjdHAtc2RwL3B1bGwvMTUiPjxzcGFuIGxhbmc9IkVOLVVTIj5odHRwczovL2dpdGh1
Yi5jb20vY2RoNHUvZHJhZnQtc2N0cC1zZHAvcHVsbC8xNTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0i
RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5DaHJpc3RlcjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
L2JvZHk+DQo8L2h0bWw+DQo=

--_000_D591F3E7EBC84844A0FA6ED64DD2B5F6ericssoncom_--


From nobody Mon Apr 22 01:34:25 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28201120059 for ; Mon, 22 Apr 2019 01:34:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMa5fp88LRpT for ; Mon, 22 Apr 2019 01:34:20 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20056.outbound.protection.outlook.com [40.107.2.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83D95120043 for ; Mon, 22 Apr 2019 01:34:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jLIdktK+G6XpspDYyX083RTPiauo/SuG6HrzdWxKpq0=; b=IS6YtI77ez0jDgFW6NGUu45YDYAatCS0vgQ6fpfCBTsq7JsJfxQzrMBPYaEBAHjcuEILLk35u+WnDPjhEbA2wO4ZOYy67LnJHxvIA5XLiNX6SFQZiRlFZ9LIZjWIcBO2piKySgUswpv8JTsEcMLVaB5kMXuKYczP/oz4Vjhix1w=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3388.eurprd07.prod.outlook.com (10.170.247.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.12; Mon, 22 Apr 2019 08:34:07 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184%2]) with mapi id 15.20.1835.010; Mon, 22 Apr 2019 08:34:07 +0000
From: Christer Holmberg 
To: Suhas Nandakumar 
CC: Flemming Andreasen , Roman Shpount , mmusic WG 
Thread-Topic: [MMUSIC] FQDN support in ice-sip-sdp
Thread-Index: AQHU6jzz/50YAJx2kEqY4siuQ2NZYqY0606AgADVT4CAAEAVAP//1AeAgADQ14CAAETnAIAAnHWAgAD8QQCAAGHdAIACtQAAgACv5gCAANoNAIACbYkAgAHj6piABbaIAIAA/iQA
Date: Mon, 22 Apr 2019 08:34:07 +0000
Message-ID: <5A629925-38A9-43E5-8666-E7100120EFA5@ericsson.com>
References:    <3DD3D8D6-9B13-4F9D-80DD-F89B69240708@ericsson.com>   <98CF630B-5CCD-4CE4-84B4-81A4C53979DC@ericsson.com>    <1552A692-1020-43CA-B15E-92595729EE8B@ericsson.com>  <6EA23696-949C-40CF-BEBE-006A59856BDF@ericsson.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.16.1.190220
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-originating-ip: [176.93.29.18]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 00a2c47a-bf93-434f-bb8a-08d6c6fd4922
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB3388; 
x-ms-traffictypediagnostic: HE1PR07MB3388:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00159D1518
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(376002)(346002)(396003)(366004)(199004)(189003)(6506007)(53546011)(2616005)(8676002)(6116002)(6246003)(229853002)(2906002)(33656002)(53936002)(76176011)(102836004)(790700001)(36756003)(82746002)(486006)(4326008)(186003)(81156014)(81166006)(11346002)(446003)(6436002)(476003)(6486002)(3846002)(14444005)(64756008)(93886005)(6512007)(14454004)(66556008)(25786009)(478600001)(66476007)(66066001)(6306002)(236005)(68736007)(54896002)(66446008)(86362001)(54906003)(58126008)(73956011)(1411001)(256004)(606006)(7736002)(26005)(316002)(6916009)(8936002)(76116006)(66946007)(97736004)(83716004)(5660300002)(71200400001)(71190400001)(44832011)(99286004)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3388; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: MufaGIwpdKdbUu5i0Zbg0eLN4I93Ww41MAd1iRLNyVVnrGLm13kaOd5v2m4m6a6UUaW6yX5afMJ+PnaehZVVAd0Gv/CulX8/KqkE/7IiArDtjSMmxVB24RKIZeekW3Qee9Q2vmyeFcty0HsANrgutOTMYXdFUwOfXqjqr7zoTc6M39BL5D++B3HWrkEcxqiA7b09+RJcE7wFTfDrAlJc6bXpf8ATONUc9oLt/QHK85ANjCbiQR0+jjGfo+Zbw2fJ0MQwJy1hVJOPUE/9TXuhZy8/kFf+iKgF+uUXh7Eu3FJ9mj3W71vOVvj0hD9VKKb8Ejt4at/kBmeUW63M8llo5ncjqjMNO3olL6UilhVkHmmFZDbP7Wz6nfkQH17aR7NNRFSexi7IxdbK+ngs+mKqdalzPx5zbIS0KrpRYqK0RvM=
Content-Type: multipart/alternative; boundary="_000_5A62992538A943E58666E7100120EFA5ericssoncom_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 00a2c47a-bf93-434f-bb8a-08d6c6fd4922
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2019 08:34:07.4231 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3388
Archived-At: 
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp
X-BeenThere: mmusic@ietf.org
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: Mon, 22 Apr 2019 08:34:23 -0000

--_000_5A62992538A943E58666E7100120EFA5ericssoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGksDQoNClRoZSBkcmFmdCBjb250YWlucyB0aGUgZm9sbG93aW5nIHRleHQgaW4gdGhlIEFja25v
d2xlZGdlbWVudHMgc2VjdGlvbjoNCg0KICAg4oCcVGhhbmtzIHRvIFRob21hcyBTdGFjaCBmb3Ig
dGV4dCBoZWxwLCBSb21hbiBTaHBvdW50IGZvciBzdWdnZXN0aW5nDQogICBSVENQIGNhbmRpZGF0
ZSBoYW5kbGluZyBhbmQgU2ltb24gUGVycmVhdWx0IGZvciBhZHZpc2luZyBvbiBJUFY2DQogICBh
ZGRyZXNzIHNlbGVjdGlvbiB3aGVuIGNhbmRpZGF0ZS1hZGRyZXNzIGluY2x1ZGVzIEZRRE4u4oCd
DQoNCkkgYW0gbm90IHJlYWxseSBzdXJlIHdoYXQg4oCcYWR2aXNpbmcgb24gSVB2NiBhZGRyZXNz
IHNlbGVjdGlvbuKAnSBtZWFucywgYW5kIEkgY2Fu4oCZdCBmaW5kIGFueSB0ZXh0IGluIHRoZSBk
cmFmdCB0aGF0IHdvdWxkIGJlIHJlbGF0ZWQgdG8gdGhpcy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0
ZXINCg0KRnJvbTogU3VoYXMgTmFuZGFrdW1hciA8c3VoYXNpZXRmQGdtYWlsLmNvbT4NCkRhdGU6
IFN1bmRheSwgMjEgQXByaWwgMjAxOSBhdCAyMy4yNA0KVG86IENocmlzdGVyIEhvbG1iZXJnIDxj
aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpDYzogRmxlbW1pbmcgQW5kcmVhc2VuIDxm
YW5kcmVhc0BjaXNjby5jb20+LCBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbT4sICJt
bXVzaWNAaWV0Zi5vcmciIDxtbXVzaWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW01NVVNJQ10g
RlFETiBzdXBwb3J0IGluIGljZS1zaXAtc2RwDQoNCkhpIFJvbWFuDQoNCiAgIERvIHlvdSBoYXZl
IGFuIEVUQSBvbiB0aGUgcHVsbCByZXF1ZXN0DQoNClRoYW5rcw0KU3VoYXMNCg0KT24gV2VkLCBB
cHIgMTcsIDIwMTkgYXQgMTA6MTQgUE0gQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1i
ZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4g
d3JvdGU6DQpIaSBSb21hbiwNCg0KSSB0aGluayBhIHB1bGwgcmVxdWVzdCB3b3VsZCBiZSBnb29k
LiBUaGVuIHdlIGhhdmUgdGV4dCB0byBsb29rIGF0IC0gbm8gbWF0dGVyIHdoZXJlIGl0IHdpbGwg
ZW5kIHVwLg0KDQpJIGFsc28gc3VnZ2VzdCB0byB0cnkgdG8ga2VlcCB0aGUgZ2VuZXJpYyB0ZXh0
IHNlcGFyYXRlZCBmcm9tIHRoZSBTRFAgc3BlY2lmaWNzLCBzbyBpdCBjYW4gZWFzaWx5IGJlIG1v
dmVkIGVsc2V3aGVyZSBpZiBuZWVkZWQuDQoNClJlZ2FyZGluZyBhZ2VudHMgdGhhdCBkb27igJl0
IHVuZGVyc3RhbmQgdGhlIGFkZHJ0eXBlIHBhcmFtZXRlciwgcGVyaGFwcyB3ZSBjb3VsZCBkZWZp
bmUgYSBkZWZhdWx0IElQIHZlcnNpb24gb2YgYW4gRkRRTiByZXR1cm5zIG11bHRpcGxlICh1bmxl
c3Mgc3VjaCBkZWZhdWx0IGFscmVhZHkgZXhpc3RzIHNvbWV3aGVyZSk/IEl0IHdpbGwgb2YgY291
cnNlIG5vdCBoZWxwIHdpdGggNTI0NSBpbXBsZW1lbnRhdGlvbnMsIGJ1dCBhdCBsZWFzdCBuZXcg
aW1wbGVtZW50YXRpb25zIHdpbGwgaGF2ZSBwcmVkaWNhdGFibGUgZnVuY3Rpb25hbGl0eS4NCg0K
UmVnYXJkcywNCg0KQ2hyaXN0ZXINCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpG
cm9tOiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJp
eC5jb20+Pg0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxNywgMjAxOSAzOjE3OjU0IEFNDQpUbzog
Q2hyaXN0ZXIgSG9sbWJlcmcNCkNjOiBGbGVtbWluZyBBbmRyZWFzZW47IG1tdXNpYyBXRw0KU3Vi
amVjdDogUmU6IFtNTVVTSUNdIEZRRE4gc3VwcG9ydCBpbiBpY2Utc2lwLXNkcA0KDQpIaSwNCg0K
T24gTW9uLCBBcHIgMTUsIDIwMTkgYXQgNDoxMyBBTSBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0
ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv
bi5jb20+PiB3cm90ZToNCj4+IDEpIEFuIElDRSBhZ2VudCB0aGF0IHVzZXMgRlFETiBuZWVkcyB0
byBwcm92aWRlIG9uZSBjYW5kaWRhdGUgcGVyIGFkZHJlc3MgZmFtaWx5LCBhbmQgaW5kaWNhdGUg
dGhlIGFkZHJ0eXBlIGZvciBlYWNoIG9mIHRob3NlIGNhbmRpZGF0ZXMuDQo+PiAyKSBTb21lIHRl
eHQgcmVnYXJkaW5nIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkuIERvIHdlIGFzc3VtZSBzb21lIGRl
ZmF1bHQgYmVoYXZpb3IgYnkgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zLCBvciBkbyB3ZSByZXF1
aXJlIGFuIElDRSBvcHRpb24/DQo+DQo+IEkgZG8gbm90IHRoaW5rIHdlIG5lZWQgYW4gSUNFIG9w
dGlvbi4gSSB0aGluayBwcmVzZW5jZSBvZiBhZGRydHlwZSBjYW4gYmUgc3VmZmljaWVudC4NCg0K
QnV0IGlmIHRoZSBwZWVyIElDRSBhZ2VudCBkb2VzIG5vdCBzdXBwb3J0IGl0LCBhbmQgdGhlIEZR
RE4gcmVzb2x2ZXMgaW50byBib3RoIElQdjQgYW5kIElQdjYsIHdlIGRvbid0IGtub3cgd2hhdCB2
ZXJzaW9uIGl0IHdpbGwgdXNlLg0KDQpJIGRvIG5vdCB0aGluayBhZGRpbmcgSUNFIG9wdGlvbiB3
aWxsIGhlbHAuIFVuc3VwcG9ydGVkIElDRSBvcHRpb25zIGFyZSBzaW1wbHkgaWdub3JlZCBzbyB3
ZSBlbmQgdXAgbm90IGtub3dpbmcgd2hhdCBhZGRyZXNzIHJlbW90ZSBhZ2VudCBpcyB1c2luZy4g
VW5mb3J0dW5hdGVseSBGUUROIHdhcyBub3Qgd2VsbCBkZWZpbmVkIGluIFJGQyA1MjQ1LiAiRm9y
dHVuYXRlbHkiIEkgaGF2ZSBub3Qgc2VlbiBhbnlib2R5IGFjdHVhbGx5IGltcGxlbWVudGluZyBG
UUROIEluIHRoZSB3b3JzdCBjYXNlIElDRSBub21pbmF0aW9uIGZhaWxzLiAgVGhpcyBpcyBubyBk
aWZmZXJlbnQgdGhlbiBoYXZpbmcgbm8gY29ubmVjdGl2aXR5IGZvciB0aGlzIHNwZWNpZmljIGNh
bmRpZGF0ZS4gQWxzbywgaWYgRlFETiBoYW5kbGluZyBpcyBwYXJ0IG9mIGljZS1zaXAtc2RwLCB0
aGVuIGFnZW50IHNob3VsZCBhbHJlYWR5IGluY2x1ZGUgaWNlMiBvcHRpb24uDQoNCj4gVGhpcyBi
ZWluZyBzYWlkIHdlIG5lZWQgdG8gZGVjaWRlIHR3byB0aGluZ3M6DQo+DQo+IDEuIERvZXMgRlFE
TiByZXNvbHV0aW9uIGJlbG9uZ3MgdG8gSUNFIHByb2Nlc3Npbmc/IEluIHRoaXMgY2FzZSBjYW5k
aWRhdGUgbGlzdCBpbmNsdWRlcyBGUUROIHdpdGggYWRkcmVzcyB0eXBlIGFuZCBJQ0UgcHJvY2Vz
c2luZyBkZXNjcmliZXMgaG93IEZRRE4gYXJlIHJlc29sdmVkIGFuZCBjb252ZXJ0ZWQgdG8gYWRk
cmVzc2VzLg0KPiBPciwgYWx0ZXJuYXRpdmVseSwgZG9lcyBGUUROIHJlc29sdXRpb24gYmVsb25n
cyB0byBJQ0Ugc2lnbmFsaW5nPyBJbiB0aGlzIGNhc2UgY2FuZGlkYXRlIGxpc3QgaW5jbHVkZXMg
cmVzb2x2ZWQgYWRkcmVzcyBhbmQgSUNFIGFnZW50IGRlYWxzIHdpdGggYWRkcmVzc2VzIG9ubHku
DQoNClRoYXQgd291bGQgbm90IHdvcmsgd2l0aCBtRE5TLCByaWdodD8NCg0KPiAyLiBEbyB3ZSBz
cGVjaWZ5IGhvdyB0byBkZWFsIHdpdGggRlFETiBpbiBpY2Utc2lwLXNkcCBvciBkbyB3ZSBzcGVj
aWZ5IGluIGljZS1zaXAtc2RwIHRoYXQgRlFETiBtdXN0IGJlIGlnbm9yZWQgYW5kIHRoZWlyIGhh
bmRsaW5nIGlzIGRlZmluZWQgaW4gc29tZSBvdGhlciBkcmFmdD8NCg0KUGVyaGFwcyB0aGUgYmVz
dCB0aGluZyB3b3VsZCBzaW1wbHkgdG8gcHJvZHVjZSBhIHNlcGFyYXRlIGRyYWZ0LCB0byBnZXQg
c29tZSB0ZXh0LiBXZSBjYW4gdGhlbiBkZWNpZGUgd2hldGhlciB0byBtZXJnZSBpdCBpbnRvIGlj
ZS1zaXAtc2RwLg0KDQpJIGNhbiBwcm9iYWJseSBkZXNjcmliZSB0aGlzIGluIGljZS1zaXAtc2Rw
IGluIGFib3V0IDMgcGFyYWdyYXBocy4gVGhlIGJhY2tncm91bmQgYW5kIG90aGVyIHRleHQgZm9y
IGEgbmV3IGRyYWZ0IHdpbGwgbWFrZSBpcyBtdWNoIGJpZ2dlciBlZmZvcnQuIEhvdyBhYm91dCBJ
IHB1dCB0b2dldGhlciBhIHB1bGwgcmVxdWVzdCBmb3IgaWNlLXNpcC1zZHAgYW5kIHRoZW4gd2Ug
Y2FuIGRlY2lkZSBpZiB0aGlzIHJlcXVpcmVzIGEgbmV3IGRyYWZ0Pw0KDQpSZWdhcmRzLA0KX19f
X19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYu
b3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL21tdXNpYw0K

--_000_5A62992538A943E58666E7100120EFA5ericssoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <6F9F3854C6189040AC4804EF9B1AD604@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg
MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg
MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h
bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv
dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6
dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJ
e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0
ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z
aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAubXNvbm9ybWFsMCwg
bGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFs
Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4w
cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxl
MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli
cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0
ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28t
c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsN
Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp
b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDIuMGNtIDcwLjg1
cHQgMi4wY207fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48
L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i
ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z
byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9
ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8
L2hlYWQ+DQo8Ym9keSBsYW5nPSJGSSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2
IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgZHJhZnQgY29udGFpbnMgdGhl
IGZvbGxvd2luZyB0ZXh0IGluIHRoZSBBY2tub3dsZWRnZW1lbnRzIHNlY3Rpb246PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IOKAnFRoYW5rcyB0byBUaG9t
YXMgU3RhY2ggZm9yIHRleHQgaGVscCwgUm9tYW4gU2hwb3VudCBmb3Igc3VnZ2VzdGluZzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFJUQ1AgY2FuZGlkYXRlIGhhbmRsaW5nIGFu
ZA0KPGI+U2ltb24gUGVycmVhdWx0IGZvciBhZHZpc2luZyBvbiBJUFY2PG86cD48L286cD48L2I+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGFkZHJlc3Mgc2VsZWN0aW9uIHdoZW4gY2FuZGlk
YXRlLWFkZHJlc3MgaW5jbHVkZXMgRlFETjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
O2NvbG9yOmJsYWNrIj4u4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGFtIG5vdCByZWFsbHkgc3Vy
ZSB3aGF0IOKAnGFkdmlzaW5nIG9uIElQdjYgYWRkcmVzcyBzZWxlY3Rpb27igJ0gbWVhbnMsIGFu
ZCBJIGNhbuKAmXQgZmluZCBhbnkgdGV4dCBpbiB0aGUgZHJhZnQgdGhhdCB3b3VsZCBiZSByZWxh
dGVkIHRvIHRoaXMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz
LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+U3VoYXMgTmFuZGFrdW1hciAmbHQ7c3Vo
YXNpZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+U3VuZGF5LCAyMSBBcHJpbCAy
MDE5IGF0IDIzLjI0PGJyPg0KPGI+VG86IDwvYj5DaHJpc3RlciBIb2xtYmVyZyAmbHQ7Y2hyaXN0
ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+RmxlbW1pbmcgQW5k
cmVhc2VuICZsdDtmYW5kcmVhc0BjaXNjby5jb20mZ3Q7LCBSb21hbiBTaHBvdW50ICZsdDtyb21h
bkB0ZWx1cml4LmNvbSZndDssICZxdW90O21tdXNpY0BpZXRmLm9yZyZxdW90OyAmbHQ7bW11c2lj
QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW01NVVNJQ10gRlFETiBzdXBw
b3J0IGluIGljZS1zaXAtc2RwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgUm9tYW48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO0RvIHlvdSBo
YXZlIGFuIEVUQSBvbiB0aGUgcHVsbCByZXF1ZXN0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3VoYXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXByIDE3LCAyMDE5IGF0IDEwOjE0IFBN
IENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdA
ZXJpY3Nzb24uY29tIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90
ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw
dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5IaSBSb21hbiw8YnI+DQo8YnI+DQpJIHRoaW5rIGEgcHVsbCByZXF1ZXN0IHdv
dWxkIGJlIGdvb2QuIFRoZW4gd2UgaGF2ZSB0ZXh0IHRvIGxvb2sgYXQgLSBubyBtYXR0ZXIgd2hl
cmUgaXQgd2lsbCBlbmQgdXAuPGJyPg0KPGJyPg0KSSBhbHNvIHN1Z2dlc3QgdG8gdHJ5IHRvIGtl
ZXAgdGhlIGdlbmVyaWMgdGV4dCBzZXBhcmF0ZWQgZnJvbSB0aGUgU0RQIHNwZWNpZmljcywgc28g
aXQgY2FuIGVhc2lseSBiZSBtb3ZlZCBlbHNld2hlcmUgaWYgbmVlZGVkLjxicj4NCjxicj4NClJl
Z2FyZGluZyBhZ2VudHMgdGhhdCBkb27igJl0IHVuZGVyc3RhbmQgdGhlIGFkZHJ0eXBlIHBhcmFt
ZXRlciwgcGVyaGFwcyB3ZSBjb3VsZCBkZWZpbmUgYSBkZWZhdWx0IElQIHZlcnNpb24gb2YgYW4g
RkRRTiByZXR1cm5zIG11bHRpcGxlICh1bmxlc3Mgc3VjaCBkZWZhdWx0IGFscmVhZHkgZXhpc3Rz
IHNvbWV3aGVyZSk/IEl0IHdpbGwgb2YgY291cnNlIG5vdCBoZWxwIHdpdGggNTI0NSBpbXBsZW1l
bnRhdGlvbnMsIGJ1dCBhdCBsZWFzdCBuZXcgaW1wbGVtZW50YXRpb25zDQogd2lsbCBoYXZlIHBy
ZWRpY2F0YWJsZSBmdW5jdGlvbmFsaXR5Ljxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0K
Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNl
bnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIwIiB3aWR0aD0iMTAw
JSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fNDgxNTQwMjk2MTUyNjcwMjk1
MGRpdlJwbHlGd2RNc2ciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNv
bG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4gUm9t
YW4gU2hwb3VudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXguY29tIiB0YXJnZXQ9
Il9ibGFuayI+cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBXZWRu
ZXNkYXksIEFwcmlsIDE3LCAyMDE5IDM6MTc6NTQgQU08YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVy
IEhvbG1iZXJnPGJyPg0KPGI+Q2M6PC9iPiBGbGVtbWluZyBBbmRyZWFzZW47IG1tdXNpYyBXRzxi
cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW01NVVNJQ10gRlFETiBzdXBwb3J0IGluIGljZS1zaXAt
c2RwPC9zcGFuPiA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwv
cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPk9uIE1vbiwgQXByIDE1LCAyMDE5IGF0IDQ6MTMgQU0gQ2hyaXN0ZXIgSG9sbWJlcmcg
Jmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdl
dD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt
YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZndDsmZ3Q7IDEpIEFuIElDRSBhZ2VudCB0aGF0IHVzZXMgRlFETiBuZWVkcyB0byBwcm92aWRl
IG9uZSBjYW5kaWRhdGUgcGVyIGFkZHJlc3MgZmFtaWx5LCBhbmQgaW5kaWNhdGUgdGhlIGFkZHJ0
eXBlIGZvciBlYWNoIG9mIHRob3NlIGNhbmRpZGF0ZXMuPGJyPg0KJmd0OyZndDsgMikgU29tZSB0
ZXh0IHJlZ2FyZGluZyBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LiBEbyB3ZSBhc3N1bWUgc29tZSBk
ZWZhdWx0IGJlaGF2aW9yIGJ5IGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucywgb3IgZG8gd2UgcmVx
dWlyZSBhbiBJQ0Ugb3B0aW9uPzxicj4NCiZndDs8YnI+DQomZ3Q7IEkgZG8gbm90IHRoaW5rIHdl
IG5lZWQgYW4gSUNFIG9wdGlvbi4gSSB0aGluayBwcmVzZW5jZSBvZiBhZGRydHlwZSBjYW4gYmUg
c3VmZmljaWVudC48YnI+DQo8YnI+DQpCdXQgaWYgdGhlIHBlZXIgSUNFIGFnZW50IGRvZXMgbm90
IHN1cHBvcnQgaXQsIGFuZCB0aGUgRlFETiByZXNvbHZlcyBpbnRvIGJvdGggSVB2NCBhbmQgSVB2
Niwgd2UgZG9uJ3Qga25vdyB3aGF0IHZlcnNpb24gaXQgd2lsbCB1c2UuPG86cD48L286cD48L3A+
DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvIG5vdCB0
aGluayBhZGRpbmcgSUNFIG9wdGlvbiB3aWxsIGhlbHAuIFVuc3VwcG9ydGVkIElDRSBvcHRpb25z
IGFyZSBzaW1wbHkgaWdub3JlZCBzbyB3ZSBlbmQgdXAgbm90IGtub3dpbmcgd2hhdCBhZGRyZXNz
IHJlbW90ZSBhZ2VudCBpcyB1c2luZy4gVW5mb3J0dW5hdGVseSBGUUROIHdhcyBub3Qgd2VsbCBk
ZWZpbmVkIGluIFJGQyA1MjQ1LiAmcXVvdDtGb3J0dW5hdGVseSZxdW90OyBJIGhhdmUgbm90IHNl
ZW4gYW55Ym9keQ0KIGFjdHVhbGx5IGltcGxlbWVudGluZyBGUUROIEluIHRoZSB3b3JzdCBjYXNl
IElDRSBub21pbmF0aW9uIGZhaWxzLiZuYnNwOyBUaGlzIGlzIG5vIGRpZmZlcmVudCB0aGVuIGhh
dmluZyBubyBjb25uZWN0aXZpdHkgZm9yIHRoaXMgc3BlY2lmaWMgY2FuZGlkYXRlLiBBbHNvLCBp
ZiBGUUROIGhhbmRsaW5nIGlzIHBhcnQgb2YgaWNlLXNpcC1zZHAsIHRoZW4gYWdlbnQgc2hvdWxk
IGFscmVhZHkgaW5jbHVkZSBpY2UyIG9wdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND
QyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp
bi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBUaGlzIGJlaW5nIHNhaWQg
d2UgbmVlZCB0byBkZWNpZGUgdHdvIHRoaW5nczo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAxLiBEb2Vz
IEZRRE4gcmVzb2x1dGlvbiBiZWxvbmdzIHRvIElDRSBwcm9jZXNzaW5nPyBJbiB0aGlzIGNhc2Ug
Y2FuZGlkYXRlIGxpc3QgaW5jbHVkZXMgRlFETiB3aXRoIGFkZHJlc3MgdHlwZSBhbmQgSUNFIHBy
b2Nlc3NpbmcgZGVzY3JpYmVzIGhvdyBGUUROIGFyZSByZXNvbHZlZCBhbmQgY29udmVydGVkIHRv
IGFkZHJlc3Nlcy4NCjxicj4NCiZndDsgT3IsIGFsdGVybmF0aXZlbHksIGRvZXMgRlFETiByZXNv
bHV0aW9uIGJlbG9uZ3MgdG8gSUNFIHNpZ25hbGluZz8gSW4gdGhpcyBjYXNlIGNhbmRpZGF0ZSBs
aXN0IGluY2x1ZGVzIHJlc29sdmVkIGFkZHJlc3MgYW5kIElDRSBhZ2VudCBkZWFscyB3aXRoIGFk
ZHJlc3NlcyBvbmx5Ljxicj4NCjxicj4NClRoYXQgd291bGQgbm90IHdvcmsgd2l0aCBtRE5TLCBy
aWdodD88YnI+DQo8YnI+DQomZ3Q7IDIuIERvIHdlIHNwZWNpZnkgaG93IHRvIGRlYWwgd2l0aCBG
UUROIGluIGljZS1zaXAtc2RwIG9yIGRvIHdlIHNwZWNpZnkgaW4gaWNlLXNpcC1zZHAgdGhhdCBG
UUROIG11c3QgYmUgaWdub3JlZCBhbmQgdGhlaXIgaGFuZGxpbmcgaXMgZGVmaW5lZCBpbiBzb21l
IG90aGVyIGRyYWZ0Pzxicj4NCjxicj4NClBlcmhhcHMgdGhlIGJlc3QgdGhpbmcgd291bGQgc2lt
cGx5IHRvIHByb2R1Y2UgYSBzZXBhcmF0ZSBkcmFmdCwgdG8gZ2V0IHNvbWUgdGV4dC4gV2UgY2Fu
IHRoZW4gZGVjaWRlIHdoZXRoZXIgdG8gbWVyZ2UgaXQgaW50byBpY2Utc2lwLXNkcC48bzpwPjwv
bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg
Y2FuIHByb2JhYmx5IGRlc2NyaWJlIHRoaXMgaW4gaWNlLXNpcC1zZHAgaW4gYWJvdXQgMyBwYXJh
Z3JhcGhzLiBUaGUgYmFja2dyb3VuZCBhbmQgb3RoZXIgdGV4dCBmb3IgYSBuZXcgZHJhZnQgd2ls
bCBtYWtlIGlzIG11Y2ggYmlnZ2VyIGVmZm9ydC4gSG93IGFib3V0IEkgcHV0IHRvZ2V0aGVyIGEg
cHVsbCByZXF1ZXN0IGZvciBpY2Utc2lwLXNkcCBhbmQgdGhlbiB3ZSBjYW4gZGVjaWRlIGlmIHRo
aXMgcmVxdWlyZXMNCiBhIG5ldyBkcmFmdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Sb21hbiBTaHBvdW50PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPGJyPg0KbW11c2ljIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpt
bXVzaWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJyPg0K
PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMiIHRh
cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNp
YzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_5A62992538A943E58666E7100120EFA5ericssoncom_--


From nobody Mon Apr 22 03:37:04 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F0912006E for ; Mon, 22 Apr 2019 03:37:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Yrxu6nKEVlb for ; Mon, 22 Apr 2019 03:36:59 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30059.outbound.protection.outlook.com [40.107.3.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EF39120047 for ; Mon, 22 Apr 2019 03:36:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SWsGsox3PjLeJylDJgb6mYCEai0IAHkW/TCO2mereLA=; b=GL+KnaT+/mOXZguovX1cKY3lrvROoe9n1wpiDtBSzN7u9E7hb/Nol9A8Sbv10Hm5EENwtDrbzaQXBDtc60NrmTK4KYxx3788TIfPoKwg75KFCx6OdsijmsU0sjxFgb0Rg/xpcDr0tX15rzBlWraFn3y4isZDLTbf3WGxgpba8i8=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3516.eurprd07.prod.outlook.com (10.170.248.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.5; Mon, 22 Apr 2019 10:36:56 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184%2]) with mapi id 15.20.1835.010; Mon, 22 Apr 2019 10:36:56 +0000
From: Christer Holmberg 
To: "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-10.txt - Comment on msrp-cema attribute
Thread-Index: AQHU+PdOAq7bCRTG/EWrEZLX3OSx1w==
Date: Mon, 22 Apr 2019 10:36:55 +0000
Message-ID: <61D3ED98-04FA-4746-BCDE-37BD38907803@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.16.1.190220
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-originating-ip: [176.93.29.18]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 13fb5ee7-59da-4846-7211-08d6c70e7117
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3516; 
x-ms-traffictypediagnostic: HE1PR07MB3516:
x-ms-exchange-purlcount: 5
x-microsoft-antispam-prvs: 
x-forefront-prvs: 00159D1518
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(396003)(376002)(346002)(136003)(189003)(199004)(73956011)(6506007)(229853002)(76116006)(66476007)(66556008)(64756008)(66446008)(66946007)(6246003)(53936002)(478600001)(66066001)(71200400001)(71190400001)(256004)(83716004)(3846002)(86362001)(102836004)(5640700003)(36756003)(5660300002)(6116002)(305945005)(26005)(7736002)(6916009)(82746002)(2616005)(33656002)(2501003)(81156014)(316002)(58126008)(6436002)(8676002)(81166006)(2906002)(44832011)(1730700003)(186003)(25786009)(97736004)(6306002)(99286004)(476003)(6512007)(2351001)(68736007)(966005)(8936002)(14454004)(486006)(66574012)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3516; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: nBqwi8QV2CQ3JshnLRplFBYNbDSN6mQZWBgNpttwUwpr8vTRg0FPYe3lrWRHTPsKnWtZ6aOmXgpadj+CCv8CV4QdHQfulL74nZeBMVBxXve2rf3nztN2ZXbaPjjYzJd1d6JudSqgMYvf1Em97Ormj/vSIYLHyJBsFC1eB/vQ3zVu43WrlQb2Y44hcoyyf9CFi1gZFR/eopKYkgj4kChHGlS1+u1/ZgMjPf17L36ZroJOtBn6YZiNRbFwJNLfZ14DhrvzmndKOMogoCzWvGmHGXCC3DKybzTwoBSd6SW+v8Ka63YaYs0J62m8S4BBu1x4xoQOrKo6WmP3O7xHsXPm2wRuYSBO90ri5hbRSCbqL3oN6ZczcLLzg6jEQp7zTWz0EKfkKUkauuU8LeOFmlpSiXmUzr2ODZMAF7OCXfSbVZM=
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 13fb5ee7-59da-4846-7211-08d6c70e7117
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2019 10:36:55.8504 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3516
Archived-At: 
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-10.txt - Comment on msrp-cema attribute
X-BeenThere: mmusic@ietf.org
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: Mon, 22 Apr 2019 10:37:02 -0000

SGksDQoNClNlY3Rpb24gNS4xLjEuMiBzYXlzOg0KDQogICAiVGhlIG1zcnAtY2VtYSBhdHRyaWJ1
dGUgU0hBTEwgYmUgYXNzdW1lZCB0byBiZSBwcmVzZW50IGZvciBldmVyeSBNU1JQDQogICBzZXNz
aW9uIHVzaW5nIGRhdGEgY2hhbm5lbCB0cmFuc3BvcnQsIHNvIHRoZSBpbmNsdXNpb24gb2YgdGhl
IG1zcnAtDQogICBjZW1hIGF0dHJpYnV0ZSBpcyBPUFRJT05BTC4gIFRoaXMgZW5zdXJlcyB0aGF0
IHRoZSBkYXRhIGNoYW5uZWwNCiAgIHRyYW5zcG9ydCBmb3IgdGhlIE1TUlAgc2Vzc2lvbiBpcyBl
c3RhYmxpc2hlZCB3aXRob3V0IHVzaW5nIHRoZSBwYXRoDQogICBhdHRyaWJ1dGUuIg0KDQpGaXJz
dCwgaW4gZ2VuZXJhbCwgSSBkb24ndCB3YW50IGF0dHJpYnV0ZXMgdG8gYmUgImFzc3VtZWQiLiBJ
ZiBhbiBleHRlbnNpb24gKENFTUEgaW4gdGhpcyBjYXNlKSBtYW5kYXRlcyBhbiBhdHRyaWJ1dGUg
dG8gYmUgaW5jbHVkZWQsIGl0IHNoYWxsIGJlIGluY2x1ZGVkLg0KDQpTZWNvbmQsIEkgYW0gbm90
IHN1cmUgSSB1bmRlcnN0YW5kIHRoZSB0ZXh0IG9uICJlbnN1cmluZyB0aGF0IHRoZSBkYXRhIGNo
YW5uZWwgaXMgbm90IGVzdGFibGlzaGVkIHVzaW5nIHRoZSBwYXRoIGF0dHJpYnV0ZSIuIEhvdyB3
b3VsZCB5b3UgZXN0YWJsaXNoIGEgZGF0YSBjaGFubmVsIHVzaW5nIHRoZSBwYXRoIGF0dHJpYnV0
ZT8gDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQrvu79PbiAyMS8wNC8yMDE5LCAxOS4w
NiwgIm1tdXNpYyBvbiBiZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8bW11c2lj
LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4g
d3JvdGU6DQoNCiAgICANCiAgICBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJv
bSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQogICAgVGhpcyBkcmFm
dCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTXVsdGlwYXJ0eSBNdWx0aW1lZGlhIFNlc3Npb24gQ29u
dHJvbCBXRyBvZiB0aGUgSUVURi4NCiAgICANCiAgICAgICAgICAgIFRpdGxlICAgICAgICAgICA6
IE1TUlAgb3ZlciBEYXRhIENoYW5uZWxzDQogICAgICAgICAgICBBdXRob3JzICAgICAgICAgOiBL
ZWl0aCBEcmFnZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWFyaWRpIFIuIE1ha2Fy
YWp1IChSYWp1KQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSnVlcmdlbiBTdG9ldHpl
ci1CcmFkbGVyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSaWNoYXJkIEVqemFrDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKZXJvbWUgTWFyY29uDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBKb3NlIE0uIFJlY2lvDQogICAgCUZpbGVuYW1lICAgICAgICA6IGRy
YWZ0LWlldGYtbW11c2ljLW1zcnAtdXNhZ2UtZGF0YS1jaGFubmVsLTEwLnR4dA0KICAgIAlQYWdl
cyAgICAgICAgICAgOiAxOA0KICAgIAlEYXRlICAgICAgICAgICAgOiAyMDE5LTA0LTIxDQogICAg
DQogICAgQWJzdHJhY3Q6DQogICAgICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgaG93IHRoZSBN
ZXNzYWdlIFNlc3Npb24gUmVsYXkgUHJvdG9jb2wgKE1TUlApDQogICAgICAgY2FuIGJlIGluc3Rh
bnRpYXRlZCBhcyBhIGRhdGEgY2hhbm5lbCBzdWItcHJvdG9jb2wsIHVzaW5nIHRoZSBTRFANCiAg
ICAgICBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UtYmFzZWQgZ2VuZXJpYyBkYXRhIGNoYW5uZWwgbmVn
b3RpYXRpb24NCiAgICAgICBmcmFtZXdvcmsuICBUd28gbmV0d29yayBjb25maWd1cmF0aW9ucyBh
cmUgZG9jdW1lbnRlZDogYSBXZWJSVEMgZW5kLQ0KICAgICAgIHRvLWVuZCBjb25maWd1cmF0aW9u
IChjb25uZWN0aW5nIHR3byBNU1JQIG92ZXIgZGF0YSBjaGFubmVsDQogICAgICAgZW5kcG9pbnRz
KSwgYW5kIGEgZ2F0ZXdheSBjb25maWd1cmF0aW9uIChjb25uZWN0aW5nIGFuIE1TUlAgb3ZlciBk
YXRhDQogICAgICAgY2hhbm5lbCBlbmRwb2ludCB3aXRoIGFuIE1TUlAgb3ZlciBUQ1Agb3IgVExT
IGVuZHBvaW50KS4NCiAgICANCiAgICANCiAgICBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMg
cGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCiAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn
L2RvYy9kcmFmdC1pZXRmLW1tdXNpYy1tc3JwLXVzYWdlLWRhdGEtY2hhbm5lbC8NCiAgICANCiAg
ICBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQogICAgaHR0
cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLW1zcnAtdXNhZ2UtZGF0
YS1jaGFubmVsLTEwDQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9k
cmFmdC1pZXRmLW1tdXNpYy1tc3JwLXVzYWdlLWRhdGEtY2hhbm5lbC0xMA0KICAgIA0KICAgIEEg
ZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCiAgICBodHRw
czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1tbXVzaWMtbXNycC11c2Fn
ZS1kYXRhLWNoYW5uZWwtMTANCiAgICANCiAgICANCiAgICBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h
eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQog
ICAgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0
b29scy5pZXRmLm9yZy4NCiAgICANCiAgICBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxh
YmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQogICAgZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0
LWRyYWZ0cy8NCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KICAgIG1tdXNpYyBtYWlsaW5nIGxpc3QNCiAgICBtbXVzaWNAaWV0Zi5vcmcN
CiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KICAgIA0K
DQo=


From nobody Mon Apr 22 06:24:09 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986DF120025 for ; Mon, 22 Apr 2019 06:24:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ch3m4.com header.b=k7bj4a43; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=T20BkJZn
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6hquW93LgBx for ; Mon, 22 Apr 2019 06:24:05 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9493F120074 for ; Mon, 22 Apr 2019 06:24:05 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 9DBE922040 for ; Mon, 22 Apr 2019 09:24:04 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 22 Apr 2019 09:24:04 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ch3m4.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm3; bh=0 YIIcdKKuudMtfWTU9GCMzLfz9o9yd7wVy86bmkolmA=; b=k7bj4a43oJZMF4fbE h/ItKA2EbWxw7+DoYRtH5VGF9wDiBkihKj3wH9j6nRW+qIAnAdy9wyvUH7KpfJBp tG3RuHGkCE0H5qbqXSysXRGglGbepPPJFHG9kfc+jc0YNBh6GyqlT3/ZcrltvwEF HCUVLAzOYi7ATvAlR9NYzLZbXyWztLmd2XvaMx31dO/2yQcuzT3FC94lJIT9Qwwc ExAee71jsiM06Mpah32hXwuQHyfU2rRs/HeDKQfQ3ZTCo9nBq1lCJirPTogzDGZl rZYg+xGPXl9CJ2hfE4n7KJuP0Zh7iG4FOw62k8DYZMYNR4hZ1HUeE6XaGfWxelYU xH92g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=0YIIcdKKuudMtfWTU9GCMzLfz9o9yd7wVy86bmkol mA=; b=T20BkJZnq9zDZim65ZrFocjAOJNoQMZkPjUj/OKKPD/AqKgu1nBNTZtxL Ke80+BEfTq6xeBWya6mRCiDw5NnKSrNn4g2ifUA4x5wG3P+GctlegbhHmWzNIOAS xHAGc4r3z31eyM5/lR2rVgm0iTFVecWpC8CcVaAxL/RyzpzQ0WninJKf5vOoGmNs E1qPetxfKlDCbPoVXGNqw6Jlp6IfFasPAwT/Mi5aeywTvGfvPB1LXdKUR3Q6Hlds k2/irS4UTZj9HfRN3jLnWNq/z33OyjGN6J73i/FS8+/8x3jEPCUS9USniLainqNd BP1oXEgNHfekZzz4E2p0u0sOZVuSw==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrgeeigdeitdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthejre dttdefjeenucfhrhhomheplfhoshgvucfoucftvggtihhouceojhhoshgvsegthhefmheg rdgtohhmqeenucfkphepieeirdeliedrvddtgedrudegjeenucfrrghrrghmpehmrghilh hfrhhomhepjhhoshgvsegthhefmhegrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy:    
Received: from [192.168.1.187] (unknown [66.96.204.147]) by mail.messagingengine.com (Postfix) with ESMTPA id 77A9910319 for ; Mon, 22 Apr 2019 09:24:03 -0400 (EDT)
To: mmusic@ietf.org
References: <61D3ED98-04FA-4746-BCDE-37BD38907803@ericsson.com>
From: Jose M Recio 
Message-ID: 
Date: Mon, 22 Apr 2019 21:24:01 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <61D3ED98-04FA-4746-BCDE-37BD38907803@ericsson.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: 
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-10.txt - Comment on msrp-cema attribute
X-BeenThere: mmusic@ietf.org
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: Mon, 22 Apr 2019 13:24:07 -0000

On 22/4/19 6:36 PM, Christer Holmberg wrote:
> First, in general, I don't want attributes to be "assumed". If an extension (CEMA in this case) mandates an attribute to be included, it shall be included.

I can rewrite so the attribute is always there. I think the intention is 
to make using legacy MSRP stacks (that may not be supporting CEMA) 
transparently use data transport.

Any comments from the list?

> Second, I am not sure I understand the text on "ensuring that the data channel is not established using the path attribute". How would you establish a data channel using the path attribute?

The way I understand this is "make sure path attribute is ignored for 
setting up the transport".

This is also connected to CEMA being assumed. I believe the overall 
intention of the paragraph is that transport establishment must always 
use CEMA, even if the attribute is not there, and path should never be 
used. So, for data channel transport, CEMA is not optional, as RFC6714 
says. Maybe a rewriting making this more clear is needed.



From nobody Mon Apr 22 12:08:47 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE3B1200E9; Mon, 22 Apr 2019 12:08:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HR7_rZsc34eR; Mon, 22 Apr 2019 12:08:37 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6B27120128; Mon, 22 Apr 2019 12:08:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9058; q=dns/txt; s=iport; t=1555960116; x=1557169716; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=XwFz4oM/tofrRj/Prz2as/Ru8X9Jw+3imBVIlDcxuk0=; b=mGy0SjlIbllWhGjdRKGJS4kJNggTm5RI5ne2tz1mLPv55EP6HC1PwmwC wdRxyt/8qBw9PjSVL+o3lQY8lWb97AtPRQMuLwJ6NhVlnP6PPZNTnpUhq MRt1wBsEGyZVmFtbW0V6hKM6cAqa0a5O3jVdUzpXc+Cpl5UHgtijkugIV k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BVAADQEL5c/5xdJa1mGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBVAMBAQELAYEOgQJoUTMohA6TKIFgLYlIiQmHdRAYAQqEBEYChiM?= =?us-ascii?q?jNwYOAQMBAQQBAQIBAm0cDIVLAQEBAwEBIUsbCQIYKgICJzAGAQwGAgEBgx4?= =?us-ascii?q?BgXQUD4s9m2WBLx+FKIRdBoEyAYtJF4FAP4ERJ4JrPoJhAQGEa4JXBKZWCYI?= =?us-ascii?q?Khg+MFQYbgguGKYNBiR+IeoMKgR6FH44mgWUiKIEuTSMVO4JshX2FFIVbIwM?= =?us-ascii?q?wkHIBAQ?=
X-IronPort-AV: E=Sophos;i="5.60,382,1549929600";  d="scan'208,217";a="539064283"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Apr 2019 19:08:35 +0000
Received: from [10.118.10.21] (rtp-fandreas-2-8814.cisco.com [10.118.10.21]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTP id x3MJ8YHK006499; Mon, 22 Apr 2019 19:08:34 GMT
To: Christer Holmberg , "mmusic@ietf.org" , "rtcweb@ietf.org" , "clue@ietf.org" 
References: 
From: Flemming Andreasen 
Message-ID: <62f7a5fe-a78e-4c80-cc96-e73b18c12629@cisco.com>
Date: Mon, 22 Apr 2019 15:08:34 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------CD0390048F45B55C26CA224E"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.118.10.21, rtp-fandreas-2-8814.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: 
Subject: Re: [MMUSIC] [rtcweb] Scope of SDP m= line 'webrtc-datachannel'
X-BeenThere: mmusic@ietf.org
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: Mon, 22 Apr 2019 19:08:39 -0000

This is a multi-part message in MIME format.
--------------CD0390048F45B55C26CA224E
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Folks

Please take a look at the proposed update below and let the authors and 
MMUSIC chairs know if you have any concerns with this change (by April 29).

Thanks

-- Flemming (as MMUSIC co-chair)

On 4/21/19 7:12 PM, Christer Holmberg wrote:
>
> Hi,
>
> I am cross-posting this on multiple list, to make people aware of the 
> issue. However, I ask that any comments and discussions take place on 
> the MMUSIC list only.
>
> I found the following statement in section 4.5 of 
> draft-ietf-mmusic-sctp-sdp:
>
>    “NOTE: 'webrtc-datachannel' indicates the WebRTC Data Channel
>
>    Establishment Protocol defined in [I-D.ietf-rtcweb-data-protocol].â€
>
> In addition, in the IANA registration of ‘webrtc-datachannel’ (section 
> 15.3), draft-ietf-rtcweb-data-protocol is referenced.
>
> To refresh everyone, draft-ietf-rtcweb-data-protocol defines DCEP (the 
> inband protocol for handling WebRTC Data Channels), and 
> ‘webrtc-datachannel’ is used in the SDP m= line when establishing an 
> SCTP association for such channel.
>
> However, both draft-ietf-mmusic-datachannel-sdp-neg and 
> draft-ietf-clue-data-channel use ‘webrtc-datachannel’ in the “m=†
> line, and those drafts do not use DCEP.
>
> My suggestion to fix this is to modify the text in 
> draft-ietf-mmusic-sctp-sdp, to always use ‘webrtc-datachannel’ for 
> WebRTC Data Channels – no matter whether DCEP is used or not.
>
> I have created a pull request:
>
> https://github.com/cdh4u/draft-sctp-sdp/pull/15
>
> Regards,
>
> Christer
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


--------------CD0390048F45B55C26CA224E
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Folks

    

    Please take a look at the proposed update below and let the authors
    and MMUSIC chairs know if you have any concerns with this change (by
    April 29). 

    

    Thanks 

    

    -- Flemming (as MMUSIC co-chair)

    

    
On 4/21/19 7:12 PM, Christer Holmberg
      wrote:

    

    

      
      
      
      

        
Hi,

        
 

        
I
            am cross-posting this on multiple list, to make people aware
            of the issue. However, I ask that any comments and
            discussions take place on the MMUSIC list only.

        
 

        
I
            found the following statement in section 4.5 of
            draft-ietf-mmusic-sctp-sdp:

        
 

        
   “NOTE:
            'webrtc-datachannel' indicates the WebRTC Data Channel

        
   Establishment
            Protocol defined in [I-D.ietf-rtcweb-data-protocol].â€

        
 

        
In
            addition, in the IANA registration of ‘webrtc-datachannel’
            (section 15.3), draft-ietf-rtcweb-data-protocol is
            referenced.

        
 

        
To
            refresh everyone, draft-ietf-rtcweb-data-protocol defines
            DCEP (the inband protocol for handling WebRTC Data
            Channels), and ‘webrtc-datachannel’ is used in the SDP m=
            line when establishing an SCTP association for such channel.

        
 

        
However,
            both draft-ietf-mmusic-datachannel-sdp-neg and
            draft-ietf-clue-data-channel use ‘webrtc-datachannel’ in the
            “m=†line, and those drafts do not use DCEP.

        
 

        
My
            suggestion to fix this is to modify the text in
            draft-ietf-mmusic-sctp-sdp, to always use
            ‘webrtc-datachannel’ for WebRTC Data Channels – no matter
            whether DCEP is used or not.

        
 

        
I
            have created a pull request:

        
 

        
https://github.com/cdh4u/draft-sctp-sdp/pull/15

        
 

        
Regards,

        
 

        
Christer

        
 

        
 

        

        
 

      

      

      

      
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


    

    

  


--------------CD0390048F45B55C26CA224E--


From nobody Mon Apr 22 12:21:41 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5E8120326 for ; Mon, 22 Apr 2019 12:21:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDTO5i9uqGec for ; Mon, 22 Apr 2019 12:21:37 -0700 (PDT)
Received: from smtp74.ord1c.emailsrvr.com (smtp74.ord1c.emailsrvr.com [108.166.43.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CF9B120271 for ; Mon, 22 Apr 2019 12:21:37 -0700 (PDT)
Received: from smtp18.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp18.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 24F27E024F; Mon, 22 Apr 2019 15:21:36 -0400 (EDT)
X-Auth-ID: fluffy@iii.ca
Received: by smtp18.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id BD083E0307;  Mon, 22 Apr 2019 15:21:35 -0400 (EDT)
X-Sender-Id: fluffy@iii.ca
Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Mon, 22 Apr 2019 15:21:36 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_7DF6CF06-AF20-43A7-8A2A-79155DC8AC02"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Cullen Jennings 
In-Reply-To: <62f7a5fe-a78e-4c80-cc96-e73b18c12629@cisco.com>
Date: Mon, 22 Apr 2019 13:21:34 -0600
Cc: Christer Holmberg 
Message-Id: <16128C39-0FA5-4F48-BC28-1D9779DE1F62@iii.ca>
References:  <62f7a5fe-a78e-4c80-cc96-e73b18c12629@cisco.com>
To: "mmusic@ietf.org" 
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: 
Subject: Re: [MMUSIC] [rtcweb] Scope of SDP m= line 'webrtc-datachannel'
X-BeenThere: mmusic@ietf.org
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: Mon, 22 Apr 2019 19:21:39 -0000

--Apple-Mail=_7DF6CF06-AF20-43A7-8A2A-79155DC8AC02
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


The change in Christer's PR looks good to me.=20


> On Apr 22, 2019, at 1:08 PM, Flemming Andreasen  =
wrote:
>=20
> Folks
>=20
> Please take a look at the proposed update below and let the authors =
and MMUSIC chairs know if you have any concerns with this change (by =
April 29).=20
>=20
> Thanks=20
>=20
> -- Flemming (as MMUSIC co-chair)
>=20
> On 4/21/19 7:12 PM, Christer Holmberg wrote:
>> Hi,
>> =20
>> I am cross-posting this on multiple list, to make people aware of the =
issue. However, I ask that any comments and discussions take place on =
the MMUSIC list only.
>> =20
>> I found the following statement in section 4.5 of =
draft-ietf-mmusic-sctp-sdp:
>> =20
>>    =E2=80=9CNOTE: 'webrtc-datachannel' indicates the WebRTC Data =
Channel
>>    Establishment Protocol defined in =
[I-D.ietf-rtcweb-data-protocol].=E2=80=9D
>> =20
>> In addition, in the IANA registration of =E2=80=98webrtc-datachannel=E2=
=80=99 (section 15.3), draft-ietf-rtcweb-data-protocol is referenced.
>> =20
>> To refresh everyone, draft-ietf-rtcweb-data-protocol defines DCEP =
(the inband protocol for handling WebRTC Data Channels), and =
=E2=80=98webrtc-datachannel=E2=80=99 is used in the SDP m=3D line when =
establishing an SCTP association for such channel.
>> =20
>> However, both draft-ietf-mmusic-datachannel-sdp-neg and =
draft-ietf-clue-data-channel use =E2=80=98webrtc-datachannel=E2=80=99 in =
the =E2=80=9Cm=3D=E2=80=9D line, and those drafts do not use DCEP.
>> =20
>> My suggestion to fix this is to modify the text in =
draft-ietf-mmusic-sctp-sdp, to always use             =
=E2=80=98webrtc-datachannel=E2=80=99 for WebRTC Data Channels =E2=80=93 =
no matter whether DCEP is used or not.
>> =20
>> I have created a pull request:
>> =20
>> https://github.com/cdh4u/draft-sctp-sdp/pull/15 =

>> =20
>> Regards,
>> =20
>> Christer
>> =20
>> =20
>> =20
>>=20
>>=20
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org 
>> https://www.ietf.org/mailman/listinfo/rtcweb =

>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


--Apple-Mail=_7DF6CF06-AF20-43A7-8A2A-79155DC8AC02
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



The change in Christer's PR looks good =
to me. 


On Apr 22, 2019, at 1:08 PM, =
Flemming Andreasen <fandreas@cisco.com> wrote:


 =20
    
 =20
  

    Folks

    

    Please take a look at the proposed update below and let the authors
    and MMUSIC chairs know if you have any concerns with this change (by
    April 29). 

    

    Thanks 

    

    -- Flemming (as MMUSIC co-chair)

    

    
On 4/21/19 7:12 PM, Christer Holmberg
      wrote:

    

    
=

      
      
      
      
Hi,
 
I
            am cross-posting this on multiple list, to make people aware
            of the issue. However, I ask that any comments and
            discussions take place on the MMUSIC list only.
 
I
            found the following statement in section 4.5 of
            draft-ietf-mmusic-sctp-sdp:
 
   =
=E2=80=9CNOTE:
            'webrtc-datachannel' indicates the WebRTC Data Channel
   =
Establishment
            Protocol defined in [I-D.ietf-rtcweb-data-protocol].=E2=80=9D<=
o:p class=3D"">
 
In
            addition, in the IANA registration of =
=E2=80=98webrtc-datachannel=E2=80=99
            (section 15.3), draft-ietf-rtcweb-data-protocol is
            referenced.
 
To
            refresh everyone, draft-ietf-rtcweb-data-protocol defines
            DCEP (the inband protocol for handling WebRTC Data
            Channels), and =E2=80=98webrtc-datachannel=E2=80=99 is used =
in the SDP m=3D
            line when establishing an SCTP association for such =
channel.
 
However,
            both draft-ietf-mmusic-datachannel-sdp-neg and
            draft-ietf-clue-data-channel use =E2=80=98webrtc-datachannel=E2=
=80=99 in the
            =E2=80=9Cm=3D=E2=80=9D line, and those drafts do not use =
DCEP.
 
My
            suggestion to fix this is to modify the text in
            draft-ietf-mmusic-sctp-sdp, to always use
            =E2=80=98webrtc-datachannel=E2=80=99 for WebRTC Data =
Channels =E2=80=93 no matter
            whether DCEP is used or not.
 
I
            have created a pull request:
 
https://github.com/cdh4u/draft-sctp-sdp/pull/15
 
Regards,
 
Christer
 
 
 

      

      

      

      
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org=
/mailman/listinfo/rtcweb


    

    

  


_______________________________________________
rtcweb =
mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

=

--Apple-Mail=_7DF6CF06-AF20-43A7-8A2A-79155DC8AC02--


From nobody Mon Apr 22 13:32:12 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B8912038A for ; Mon, 22 Apr 2019 13:32:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgyQaTJ3JCZZ for ; Mon, 22 Apr 2019 13:32:07 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00070.outbound.protection.outlook.com [40.107.0.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27B1912004B for ; Mon, 22 Apr 2019 13:32:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KbBslIb1je8tbwDG7N8CUYk8yU6lD9atv+FQJUaN2h4=; b=P1RSrHI8EnIQg1Kio4DPnTLvjDflI2OSJjYmjXkEkflYvTFm/H2rv2biiK5+p3gCwY5LigtdWX7pllirogYhy+o08U9mPwLlnMe30aRBiZCe6uqqQILK5KmU5zVa8qoXkSelDtQCEWbQAmMrJJAzmx69aVz6mk9aiPk3VYCReO8=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4234.eurprd07.prod.outlook.com (20.176.166.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.11; Mon, 22 Apr 2019 20:32:04 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184%2]) with mapi id 15.20.1835.010; Mon, 22 Apr 2019 20:32:04 +0000
From: Christer Holmberg 
To: Jose M Recio , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-10.txt - Comment on msrp-cema attribute
Thread-Index: AQHU+PdOAq7bCRTG/EWrEZLX3OSx16ZIK12AgACp4oA=
Date: Mon, 22 Apr 2019 20:32:03 +0000
Message-ID: 
References: <61D3ED98-04FA-4746-BCDE-37BD38907803@ericsson.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.16.1.190220
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-originating-ip: [176.93.29.18]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b7563cfa-6385-49cc-525d-08d6c76194c9
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB4234; 
x-ms-traffictypediagnostic: HE1PR07MB4234:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00159D1518
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(136003)(366004)(376002)(346002)(199004)(189003)(83716004)(71190400001)(71200400001)(81166006)(8936002)(256004)(14454004)(36756003)(8676002)(33656002)(6506007)(44832011)(25786009)(82746002)(2616005)(2501003)(81156014)(478600001)(486006)(966005)(476003)(11346002)(446003)(6116002)(3846002)(2906002)(26005)(305945005)(7736002)(76176011)(186003)(66066001)(58126008)(6246003)(99286004)(5660300002)(86362001)(316002)(76116006)(110136005)(97736004)(53936002)(102836004)(66556008)(6436002)(66446008)(68736007)(6512007)(6306002)(66476007)(66946007)(229853002)(64756008)(73956011)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4234; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: sOUcAgwwpqrYvBgFotK6UgBgTty6pZZwWM/lcHUYZgS3vcbCZT1/OBNghM+UYBXvHf6SO1q1myHpN8hDE1fpQ028re6c+/lfoO5uG+diV0YFvGFpKBd1DsfTTTwOWFclref6amlL2LFM6KW7RoGCcfArjPBfi0C3Fc2/hUvk0IOM+KJWGUhGrL/mey4IE5SgNgfhQCOmt7BplRS4oA9vegygYcVZnu1LubNukG79zOjtPCbqTEmG78M6wUTT0byziasE6DEtnPFY8VMt89gCsiLeom9e/jxLEyZY8tzIshJiEVtW43JjJx8CheeyRPeJicoz+BXJf2Q++AvMNJ7fND/JmGboF0GjCoUKtsKRS2Esqsd2sOYznr27lLauxEa+HL6B4YQgLUaWt2dhYSH7rJNlcANOd0JjbF4IGjLa0fo=
Content-Type: text/plain; charset="utf-8"
Content-ID: <0E351BFD5D191242BE0615C812B2028F@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b7563cfa-6385-49cc-525d-08d6c76194c9
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2019 20:32:04.0019 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4234
Archived-At: 
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-10.txt - Comment on msrp-cema attribute
X-BeenThere: mmusic@ietf.org
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: Mon, 22 Apr 2019 20:32:11 -0000

SGksDQoNCj4+IEZpcnN0LCBpbiBnZW5lcmFsLCBJIGRvbid0IHdhbnQgYXR0cmlidXRlcyB0byBi
ZSAiYXNzdW1lZCIuIElmIGFuIGV4dGVuc2lvbiAoQ0VNQSBpbiB0aGlzIGNhc2UpIG1hbmRhdGVz
IGFuIGF0dHJpYnV0ZSB0byBiZSBpbmNsdWRlZCwgaXQgc2hhbGwgYmUgaW5jbHVkZWQuDQo+ICAg
IA0KPiAgICBJIGNhbiByZXdyaXRlIHNvIHRoZSBhdHRyaWJ1dGUgaXMgYWx3YXlzIHRoZXJlLiBJ
IHRoaW5rIHRoZSBpbnRlbnRpb24gaXMgDQo+ICAgIHRvIG1ha2UgdXNpbmcgbGVnYWN5IE1TUlAg
c3RhY2tzICh0aGF0IG1heSBub3QgYmUgc3VwcG9ydGluZyBDRU1BKSANCj4gICAgdHJhbnNwYXJl
bnRseSB1c2UgZGF0YSB0cmFuc3BvcnQuDQogIA0KSSB0aGluayB3ZSBmaXJzdCBuZWVkIHRvIHRo
aW5rIHdoZXRoZXIgaXQgaXMgbmVlZGVkLg0KDQpLZWVwIGluIG1pbmQgKGFuZCB0aGF0IHNob3Vs
ZCBwcm9iYWJseSBiZXR0ZXIgZGVzY3JpYmVkIGluIHRoZSBkb2N1bWVudCkgdGhhdCB0aGUgbm9y
bWFsIE1TUlAgcm91dGluZyBwcm9jZWR1cmVzIGRvbid0IGFwcGx5LiBUaGUgTVNSUCBtZXNzYWdl
cyB3aWxsIGJlIHJvdXRlZCBpbiB0aGUgZGF0YSBjaGFubmVsLCB3aGljaCBpcyBlc3RhYmxpc2hl
ZCBiZXR3ZWVuIHRoZSBTSVAgcGVlcnMgKG9yIHdoYXRldmVyIHNpZ25hbGluZyBwcm90b2NvbCBp
cyB1c2VkKS4gSSBndWVzcyBwcm94aWVzIGFuZCBhcHBsaWNhdGlvbiBzZXJ2ZXJzIGNhbiBsb29r
IGF0IHRoZSB0b3AtbW9zdCBwYXRoIGF0dHJpYnV0ZSwgYnV0IHRoYXQgaXMgbm90IGdvaW5nIHRv
IGJlIHRoZSBwcmltYXJ5IHJvdXRpbmcgaW5wdXQuIEkgZG9uJ3QgdGhpbmsgdGhlIGRyYWZ0IHNh
eXMgYW55dGhpbmcgYWJvdXQgdGhhdCAtIGl0IGp1c3Qgc2VlbXMgdG8gYXNzdW1lIHRoYXQgdGhl
IGRhdGEgY2hhbm5lbCB3aWxsIGVuZCB1cCBpbiB0aGUgaW50ZW5kZWQgTVNSUCBwZWVyLg0KDQpJ
ZiB0aGVyZSB0aGVuIGlzIGEgZ2F0ZXdheSB0aGF0IGZvcndhcmRzIHRoZSBNU1JQIG1lc3NhZ2Vz
IHRvd2FyZHMgYSBsZWdhY3kgTVNSUCBlbmRwb2ludCBpdCBtYXkgdXNlIENFTUEsIGJ1dCB0aGF0
J3MgYSBzZXBhcmF0ZSB0aGluZy4NCg0KPj4gU2Vjb25kLCBJIGFtIG5vdCBzdXJlIEkgdW5kZXJz
dGFuZCB0aGUgdGV4dCBvbiAiZW5zdXJpbmcgdGhhdCB0aGUgZGF0YSBjaGFubmVsIGlzIG5vdCBl
c3RhYmxpc2hlZCB1c2luZyB0aGUgcGF0aCBhdHRyaWJ1dGUiLiBIb3cgd291bGQgeW91IA0KPj4g
ZXN0YWJsaXNoIGEgZGF0YSBjaGFubmVsIHVzaW5nIHRoZSBwYXRoIGF0dHJpYnV0ZT8NCj4gICAg
DQo+ICAgIFRoZSB3YXkgSSB1bmRlcnN0YW5kIHRoaXMgaXMgIm1ha2Ugc3VyZSBwYXRoIGF0dHJp
YnV0ZSBpcyBpZ25vcmVkIGZvciANCj4gICAgc2V0dGluZyB1cCB0aGUgdHJhbnNwb3J0Ii4NCj4g
ICAgDQo+ICAgIFRoaXMgaXMgYWxzbyBjb25uZWN0ZWQgdG8gQ0VNQSBiZWluZyBhc3N1bWVkLiBJ
IGJlbGlldmUgdGhlIG92ZXJhbGwgDQo+ICAgIGludGVudGlvbiBvZiB0aGUgcGFyYWdyYXBoIGlz
IHRoYXQgdHJhbnNwb3J0IGVzdGFibGlzaG1lbnQgbXVzdCBhbHdheXMgDQo+ICAgIHVzZSBDRU1B
LCBldmVuIGlmIHRoZSBhdHRyaWJ1dGUgaXMgbm90IHRoZXJlLCBhbmQgcGF0aCBzaG91bGQgbmV2
ZXIgYmUgDQo+ICAgIHVzZWQuIFNvLCBmb3IgZGF0YSBjaGFubmVsIHRyYW5zcG9ydCwgQ0VNQSBp
cyBub3Qgb3B0aW9uYWwsIGFzIFJGQzY3MTQgDQo+ICAgIHNheXMuIE1heWJlIGEgcmV3cml0aW5n
IG1ha2luZyB0aGlzIG1vcmUgY2xlYXIgaXMgbmVlZGVkLg0KICANCkJ1dCB0aGUgdHJhbnNwb3J0
IGVzdGFibGlzaG1lbnQgb2YgYSBkYXRhIGNoYW5uZWwgZG9lcyBub3QgdXNlIENFTUEuDQoNCk1h
eWJlIHRoZXJlIGlzIGEgcmVhc29uIGZvciBhbGwgb2YgdGhpcyAoaXQncyBzdWNoIGEgbG9uZyB0
aW1lIHNpbmNlIEkgbG9va2VkIGF0IGl0KSwgYnV0IGl0IG5lZWRzIHRvIGJlIGNsZWFyIHdoeSB3
ZSBtYW5kYXRlIGNlcnRhaW4gdGhpbmdzLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCiAg
DQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCiAgICBtbXVzaWMgbWFpbGluZyBsaXN0DQogICAgbW11c2ljQGlldGYub3JnDQogICAgaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCiAgICANCg0K


From nobody Mon Apr 22 14:06:52 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEBE120098 for ; Mon, 22 Apr 2019 14:06:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFf_787qq98a for ; Mon, 22 Apr 2019 14:06:48 -0700 (PDT)
Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18939120073 for ; Mon, 22 Apr 2019 14:06:48 -0700 (PDT)
Received: by mail-it1-x136.google.com with SMTP id q19so2296102itk.3 for ; Mon, 22 Apr 2019 14:06:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=n6dmhK+Mm9wgLINuPOMl/0XgkV/lxf1fLD2EH2WfEh8=; b=bTY8VnnbHt9FcV6AFwGfc3/fpTIjX3S9L+DP5fnBV8gITUwXgBuNeimJ5IoSqF/Sjm GWOcknRdtVHdMD78wg+YBeXNgPOqRRxpDiA2+olivuS+eTJlFtEDoHlX4Gl2sSBhG4g/ ZlS9Q1djdpVJSUvGMoQ2hv5YCPLwdVly830DGtPRJXK8l+enW2kpGZnhpfIdUhGTva6A AspGUcUl9PM8NPRjsu+JLagFV/WbkzskPEvAkp139mwigQho6t11SWVPokW630bD6+p6 vORDqKE3/KWcGHLxP7laeojRAd3HoagyhTBq8tiGC3HI2lQao2nfCQHpI18L1rdHGbkw QcjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=n6dmhK+Mm9wgLINuPOMl/0XgkV/lxf1fLD2EH2WfEh8=; b=gh4ZDpPV393v/bNn4sGrCgmmF+BTccZmikY3sx0wvJHfDB+ZNmuUm/btXtYMry9kCM AV63H3DMwJQAWCDzBagfgdmXX+HGsZ5thRr0aAaD8Z3m4e+2RRRa73UpD1I9KQ9f2Vo0 T/gupXD7v0lQKoiCxohrLUtE6YJcjlzHTSSPKmAIxLgioS6mTKV86hXxNsfc/TJyvzsA wBRK1+IGx8l3+24NunMc5wkxLmc9g4737fz1XjpQKHAcuH/58TjdXfUdVn/BxQG0W8TR Pw07JZ5IodRVfVt2xSLtVLnLXkJ42rGN8EcJojVTubt/KkOTwOZXfw7qpcEZmdCoEr/N IYyA==
X-Gm-Message-State: APjAAAUbpzdiV0AaMQBz6nL7bOTUwxwHlzTy64IAcTqg2nSMtMlGsqoG J0sJW7BsG6cnWjIoYXfbZxcF9Knm
X-Google-Smtp-Source: APXvYqygfNGA6hXmx80KswRXWE3NI6DgIrFhZ5F308batmCl4rqtSCcMWv2IRYEP1xjxaDBkur1zCg==
X-Received: by 2002:a24:3288:: with SMTP id j130mr185320ita.104.1555967207303;  Mon, 22 Apr 2019 14:06:47 -0700 (PDT)
Received: from [192.168.1.130] ([71.194.253.108]) by smtp.gmail.com with ESMTPSA id w184sm6604069ita.9.2019.04.22.14.06.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Apr 2019 14:06:46 -0700 (PDT)
To: Christer Holmberg , Jose M Recio , "mmusic@ietf.org" 
References: <61D3ED98-04FA-4746-BCDE-37BD38907803@ericsson.com>  
From: RIchard Ejzak 
Message-ID: <6e4edb12-936d-62b5-b4ff-e05b6d117e75@gmail.com>
Date: Mon, 22 Apr 2019 13:12:48 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-10.txt - Comment on msrp-cema attribute
X-BeenThere: mmusic@ietf.org
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: Mon, 22 Apr 2019 21:06:51 -0000

Hi,

Since I wrote the original text, I should probably reply...

I agree with Christer that the CEMA attribute is not needed.  It was 
originally included to make it clear that the path attribute could not 
be used to establish the data channel.  But this is obvious for this new 
type of transport.  RFC7977 (WebSocket transport for MSRP) handles this 
very nicely by using an .invalid domain name in the path attribute.  I 
suggest adopting this approach for dc.

Richard


On 4/22/19 3:32 PM, Christer Holmberg wrote:
> Hi,
>
>>> First, in general, I don't want attributes to be "assumed". If an extension (CEMA in this case) mandates an attribute to be included, it shall be included.
>>     
>>     I can rewrite so the attribute is always there. I think the intention is
>>     to make using legacy MSRP stacks (that may not be supporting CEMA)
>>     transparently use data transport.
>    
> I think we first need to think whether it is needed.
>
> Keep in mind (and that should probably better described in the document) that the normal MSRP routing procedures don't apply. The MSRP messages will be routed in the data channel, which is established between the SIP peers (or whatever signaling protocol is used). I guess proxies and application servers can look at the top-most path attribute, but that is not going to be the primary routing input. I don't think the draft says anything about that - it just seems to assume that the data channel will end up in the intended MSRP peer.
>
> If there then is a gateway that forwards the MSRP messages towards a legacy MSRP endpoint it may use CEMA, but that's a separate thing.
>
>>> Second, I am not sure I understand the text on "ensuring that the data channel is not established using the path attribute". How would you
>>> establish a data channel using the path attribute?
>>     
>>     The way I understand this is "make sure path attribute is ignored for
>>     setting up the transport".
>>     
>>     This is also connected to CEMA being assumed. I believe the overall
>>     intention of the paragraph is that transport establishment must always
>>     use CEMA, even if the attribute is not there, and path should never be
>>     used. So, for data channel transport, CEMA is not optional, as RFC6714
>>     says. Maybe a rewriting making this more clear is needed.
>    
> But the transport establishment of a data channel does not use CEMA.
>
> Maybe there is a reason for all of this (it's such a long time since I looked at it), but it needs to be clear why we mandate certain things.
>
> Regards,
>
> Christer
>
>
>    
>      
>      _______________________________________________
>      mmusic mailing list
>      mmusic@ietf.org
>      https://www.ietf.org/mailman/listinfo/mmusic
>      
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From nobody Mon Apr 22 21:29:03 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8531120021; Mon, 22 Apr 2019 21:29:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=oRK8H0kC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BWM4B//G
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4QMiwBLYHzc; Mon, 22 Apr 2019 21:29:01 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E154D1200D7; Mon, 22 Apr 2019 21:29:00 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0546622162; Tue, 23 Apr 2019 00:29:00 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Tue, 23 Apr 2019 00:29:00 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=NwDnUqLdOt9a6Ddn7pYPdfPscaMF ryd0dI20eEV3Ii4=; b=oRK8H0kCcgcWz5JFVL8pX90pB6O8NVu5vFBLMYUXr9tk FvudXTsjIFAJmCMC5Uv9ZxoJkYll/9c4ocgBfWgFsOTjx0k90T724jf4W0g7/9X6 nlo3y45i6kAzWb4iBlePnaPZMbn9FFg1tk6ZM/H2SVPJ3L4hnJEunmr8LgNZfII4 lqrXkTcSFj20GETZZdZzHWmT5wQfj+UGGvVEIfdaFJrXrwX3hfxAFX2nmJaXIm3F /wO6qihTAA38T7aeNBh8m+Val2EaKItMM2bKia5iCaygkV0LktYitKoAMMmidJ6W LGj5Mxb0no14x1eFkc1C9YWvuE00inWU8JcaMewfcQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=NwDnUq LdOt9a6Ddn7pYPdfPscaMFryd0dI20eEV3Ii4=; b=BWM4B//G0wqhvT1uRZrCk1 UMMZdgeB9GOxYy6FQhvesun97M8emoNYA8BLFebAFnOSXP3VpmfrFWW+xLr81boY UqSSIJRFzDN4priphWStJ3TBl97q3eyzkvS4NPEoqyM0kNPoCJXfaY+l855PQj9e 8zt5wsDARCrm1dPu3YEA6k2XOxENKAhoiW4JwpyCcIqd/yDckbp+3AGv1tqlL4rf /1VteS+b28UZDs70n3dQ+se/MO9jOOKpUc0cFjZ+3yHAw0lNOgqTd0ewPJYoai2Z MAWLXDSAPM0rEO4v8dLWWkvAsIJE7jZYKzEr78xHrj95fwPOSAxhQjf9LiDTuInA ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrgeejgdejvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucfrrg hrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhu shhtvghrufhiiigvpedt
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 22D167C199; Tue, 23 Apr 2019 00:28:59 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-444-g755619f-fmstable-20190423v1
Mime-Version: 1.0
X-Me-Personality: 92534000
Message-Id: <0cdf21b5-40ce-473c-86be-4d024ecb18a8@www.fastmail.com>
In-Reply-To: 
References:     <69e1ed84-7bae-4258-897b-a6d36716c261@www.fastmail.com> <718ce899-166c-b793-c7d4-84bb5fcceea5@cisco.com>   <4a6a7d47-bd49-ed20-561e-ed4223f2d190@cisco.com> <0de3648b-e750-41a7-819d-59d1bbf5ad70@www.fastmail.com> 
Date: Tue, 23 Apr 2019 00:29:01 -0400
From: "Martin Thomson" 
To: "Flemming Andreasen" , "Bo Burman" , mmusic , "Jon Peterson" , "Cullen Jennings" , "'Eric Rescorla'" 
Cc: "draft-ietf-mmusic-sdp-uks@ietf.org" 
Content-Type: text/plain
Archived-At: 
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-uks-03
X-BeenThere: mmusic@ietf.org
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: Tue, 23 Apr 2019 04:29:03 -0000

On Mon, Apr 22, 2019, at 08:07, Flemming Andreasen wrote:
> > Right.  What is relevant here is the offers and answers, not the SIP requests.  RFC 3725 shows only inconsequential offers being generated by the controller. 
> This is where we differ. In the SIP case, the attack you describe is predicated on a mismatch between the Identity information provided in the SIP request and the (assumed) identity of the SDP in an offer, thus the SIP requests are indeed very relevant to the discussion. 

I see your point below.  I missed the bit in RFC 8224 where it has to be a request. I was concentrating on the properties of the assertions, not the protocol integration.  I agree that it's important.

If 3PCC as described in RFC 3725 never produces a scenario where a request is bound to valid SDP, then 8224 + 3725 won't ever intersect.  Looking again with that constraint in mind (that it has to be a request), I see no scenario where 8224 and 3725 could be used together unless the controller is also the authorization service.  That arrangement would rule the controller out as an attacker we care about, because it has to be trusted by definition.   (More below.)

This doesn't invalidate the other aspects of the attack, just that this attack isn't valid when both 8224 and 3725 are used.  SIP identity can be used on calls without 3PCC and the text here applies to those uses.  Or 3PCC can be used without SIP identity (maybe the WebRTC identity is used) and the attack would be relevant.

It might be good to categorically say that 3PCC - as described in RFC 3725 - is incompatible with RFC 8224.  Would that help clarify this bit?


On the specific flows:

Flow I might work if the controller was the Authorization Service for A.  Or the controller was between A and its Authorization Service.
Flow II only works if the controller is the Authorization Service for both A and B.
Flows III and IV might work if the controller was the Authorization Service for B.  Or the controller was between B and its Authorization Service.

I base this on the fact that any non-trivial offers only appear in 200 responses.  So the first place that the message appears in a request is at the controller.  This puts the controller on a "trusted" segment of the signaling path.


From nobody Mon Apr 22 22:56:54 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD0512004D for ; Mon, 22 Apr 2019 22:56:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiYdReyGvgmf for ; Mon, 22 Apr 2019 22:56:49 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50043.outbound.protection.outlook.com [40.107.5.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE2D6120223 for ; Mon, 22 Apr 2019 22:56:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=P05/nxcuTK3NtUNbHuTcwhW5FgzIjexM6AAH/JCHHYU=; b=kLhLw9ZxPDpC+W+5WRLBOiXziGlPFrtCo3SdMBJJcij7crf1F+vt7fY0SwnirGSv2FBfDvVPB1WV5mVnRqHy79N5wZqPB9iL/DRLsugkedESLXBkuAEU5T17o6wqHqUy2SPx5oI8IPpbpTPfMaIktxEfZeBdQ2HLpoUx4f0Cobs=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4282.eurprd07.prod.outlook.com (20.176.166.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.9; Tue, 23 Apr 2019 05:56:45 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184%2]) with mapi id 15.20.1835.010; Tue, 23 Apr 2019 05:56:45 +0000
From: Christer Holmberg 
To: RIchard Ejzak , Jose M Recio , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-10.txt - Comment on msrp-cema attribute
Thread-Index: AQHU+PdOAq7bCRTG/EWrEZLX3OSx16ZIK12AgACp4oD//6bNAIAA9vmA
Date: Tue, 23 Apr 2019 05:56:45 +0000
Message-ID: <3C803301-CDD4-4977-97B1-82FC5D8A06E3@ericsson.com>
References: <61D3ED98-04FA-4746-BCDE-37BD38907803@ericsson.com>   <6e4edb12-936d-62b5-b4ff-e05b6d117e75@gmail.com>
In-Reply-To: <6e4edb12-936d-62b5-b4ff-e05b6d117e75@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.16.1.190220
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-originating-ip: [176.72.255.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 495214d5-784c-4d85-4681-08d6c7b077e2
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB4282; 
x-ms-traffictypediagnostic: HE1PR07MB4282:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0016DEFF96
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(376002)(346002)(136003)(366004)(189003)(199004)(64756008)(66556008)(66446008)(316002)(36756003)(110136005)(5660300002)(6486002)(58126008)(6436002)(2906002)(6506007)(73956011)(7736002)(256004)(305945005)(6116002)(3846002)(76176011)(86362001)(53546011)(102836004)(6512007)(6306002)(99286004)(66476007)(68736007)(93886005)(66946007)(186003)(81156014)(82746002)(76116006)(6246003)(97736004)(26005)(476003)(66066001)(25786009)(44832011)(8936002)(81166006)(14454004)(486006)(83716004)(2501003)(966005)(229853002)(33656002)(11346002)(478600001)(446003)(53936002)(71190400001)(8676002)(71200400001)(2616005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4282; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: nGZmXTFFk/gMKMbZYSNo06sd7AhJyyiqwbkAoac4SaeKSwYmIinxfV4MQgUutPC7nFN5FSS0SfqcUtpGXF9O3MuS3xwJvyLkkeLzArjWjvDvS/miQ/hPnMeTYn8urhe1GoZ3alybEftmscHGjoFF2fx7G+tZi2QEerTVzL1FZQvKMNF07etqLYhmbJtqDLVvGFSJpiE93en+kKhmKOj8+cmM0LQt0gOjE807rdOrs0gcpuIiPIyvmqxQEBh2h9CbhZlY2L9nY60ZEnfl/VLdQ3YUc96mA/QnhvDDhK00m/Y0Hm0+CFlG/3vP6JAkMI+lUYqH4ufoNglQ10W+C3o7Ne0r9W9r1CBm4fbimf8Pt5LTVo8jj5+C4h0SA+Wd/xsxBCoT7Nsm9NCRiVMsoeyUsaqvtj4pi1bE9n5wjfkIsVk=
Content-Type: text/plain; charset="utf-8"
Content-ID: <6FB335601F7D514E9FFD9D9A92FE4B0D@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 495214d5-784c-4d85-4681-08d6c7b077e2
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2019 05:56:45.7592 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4282
Archived-At: 
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-10.txt - Comment on msrp-cema attribute
X-BeenThere: mmusic@ietf.org
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: Tue, 23 Apr 2019 05:56:53 -0000

SGkgUmljaGFyZCwNCg0KTG9uZyB0aW1lIG5vIHNlZSAtIGhvcGVmdWxseSB5b3UgYXJlIGZpbmUg
X18NCiAgICANCj4gICAgU2luY2UgSSB3cm90ZSB0aGUgb3JpZ2luYWwgdGV4dCwgSSBzaG91bGQg
cHJvYmFibHkgcmVwbHkuLi4NCj4gICAgDQo+ICAgIEkgYWdyZWUgd2l0aCBDaHJpc3RlciB0aGF0
IHRoZSBDRU1BIGF0dHJpYnV0ZSBpcyBub3QgbmVlZGVkLiAgSXQgd2FzIA0KPiAgICBvcmlnaW5h
bGx5IGluY2x1ZGVkIHRvIG1ha2UgaXQgY2xlYXIgdGhhdCB0aGUgcGF0aCBhdHRyaWJ1dGUgY291
bGQgbm90IA0KPiAgICBiZSB1c2VkIHRvIGVzdGFibGlzaCB0aGUgZGF0YSBjaGFubmVsLiAgQnV0
IHRoaXMgaXMgb2J2aW91cyBmb3IgdGhpcyBuZXcgDQo+ICAgIHR5cGUgb2YgdHJhbnNwb3J0LiAg
UkZDNzk3NyAoV2ViU29ja2V0IHRyYW5zcG9ydCBmb3IgTVNSUCkgaGFuZGxlcyB0aGlzIA0KPiAg
ICB2ZXJ5IG5pY2VseSBieSB1c2luZyBhbiAuaW52YWxpZCBkb21haW4gbmFtZSBpbiB0aGUgcGF0
aCBhdHRyaWJ1dGUuICBJIA0KPiAgICBzdWdnZXN0IGFkb3B0aW5nIHRoaXMgYXBwcm9hY2ggZm9y
IGRjLg0KICANCk15IHBvaW50IGlzIHRoYXQgdGhlIHBhdGggYXR0cmlidXRlIGlzIG5vdCB1c2Vk
IGZvciBlc3RhYmxpc2hpbmcgdGhlIHRyYW5zcG9ydCB0byBiZWdpbiB3aXRoOiB0aGUgU0RQIGMv
bT0gbGluZXMgYXJlIHVzZWQgZm9yIHRoYXQuDQoNClRoZXJlIGFyZW4ndCBldmVuIGdvaW5nIHRv
IGJlIGFueSAicmVhbCIgcGF0aCBhdHRyaWJ1dGVzIC0gdGhleSB3aWxsIGJlIGVuY2Fwc3VsYXRl
ZCB3aXRoaW4gZGNzYSBhdHRyaWJ1dGVzLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCiAg
ICANCiAgICANCiAgICBPbiA0LzIyLzE5IDM6MzIgUE0sIENocmlzdGVyIEhvbG1iZXJnIHdyb3Rl
Og0KICAgID4gSGksDQogICAgPg0KICAgID4+PiBGaXJzdCwgaW4gZ2VuZXJhbCwgSSBkb24ndCB3
YW50IGF0dHJpYnV0ZXMgdG8gYmUgImFzc3VtZWQiLiBJZiBhbiBleHRlbnNpb24gKENFTUEgaW4g
dGhpcyBjYXNlKSBtYW5kYXRlcyBhbiBhdHRyaWJ1dGUgdG8gYmUgaW5jbHVkZWQsIGl0IHNoYWxs
IGJlIGluY2x1ZGVkLg0KICAgID4+ICAgICANCiAgICA+PiAgICAgSSBjYW4gcmV3cml0ZSBzbyB0
aGUgYXR0cmlidXRlIGlzIGFsd2F5cyB0aGVyZS4gSSB0aGluayB0aGUgaW50ZW50aW9uIGlzDQog
ICAgPj4gICAgIHRvIG1ha2UgdXNpbmcgbGVnYWN5IE1TUlAgc3RhY2tzICh0aGF0IG1heSBub3Qg
YmUgc3VwcG9ydGluZyBDRU1BKQ0KICAgID4+ICAgICB0cmFuc3BhcmVudGx5IHVzZSBkYXRhIHRy
YW5zcG9ydC4NCiAgICA+ICAgIA0KICAgID4gSSB0aGluayB3ZSBmaXJzdCBuZWVkIHRvIHRoaW5r
IHdoZXRoZXIgaXQgaXMgbmVlZGVkLg0KICAgID4NCiAgICA+IEtlZXAgaW4gbWluZCAoYW5kIHRo
YXQgc2hvdWxkIHByb2JhYmx5IGJldHRlciBkZXNjcmliZWQgaW4gdGhlIGRvY3VtZW50KSB0aGF0
IHRoZSBub3JtYWwgTVNSUCByb3V0aW5nIHByb2NlZHVyZXMgZG9uJ3QgYXBwbHkuIFRoZSBNU1JQ
IG1lc3NhZ2VzIHdpbGwgYmUgcm91dGVkIGluIHRoZSBkYXRhIGNoYW5uZWwsIHdoaWNoIGlzIGVz
dGFibGlzaGVkIGJldHdlZW4gdGhlIFNJUCBwZWVycyAob3Igd2hhdGV2ZXIgc2lnbmFsaW5nIHBy
b3RvY29sIGlzIHVzZWQpLiBJIGd1ZXNzIHByb3hpZXMgYW5kIGFwcGxpY2F0aW9uIHNlcnZlcnMg
Y2FuIGxvb2sgYXQgdGhlIHRvcC1tb3N0IHBhdGggYXR0cmlidXRlLCBidXQgdGhhdCBpcyBub3Qg
Z29pbmcgdG8gYmUgdGhlIHByaW1hcnkgcm91dGluZyBpbnB1dC4gSSBkb24ndCB0aGluayB0aGUg
ZHJhZnQgc2F5cyBhbnl0aGluZyBhYm91dCB0aGF0IC0gaXQganVzdCBzZWVtcyB0byBhc3N1bWUg
dGhhdCB0aGUgZGF0YSBjaGFubmVsIHdpbGwgZW5kIHVwIGluIHRoZSBpbnRlbmRlZCBNU1JQIHBl
ZXIuDQogICAgPg0KICAgID4gSWYgdGhlcmUgdGhlbiBpcyBhIGdhdGV3YXkgdGhhdCBmb3J3YXJk
cyB0aGUgTVNSUCBtZXNzYWdlcyB0b3dhcmRzIGEgbGVnYWN5IE1TUlAgZW5kcG9pbnQgaXQgbWF5
IHVzZSBDRU1BLCBidXQgdGhhdCdzIGEgc2VwYXJhdGUgdGhpbmcuDQogICAgPg0KICAgID4+PiBT
ZWNvbmQsIEkgYW0gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHRoZSB0ZXh0IG9uICJlbnN1cmluZyB0
aGF0IHRoZSBkYXRhIGNoYW5uZWwgaXMgbm90IGVzdGFibGlzaGVkIHVzaW5nIHRoZSBwYXRoIGF0
dHJpYnV0ZSIuIEhvdyB3b3VsZCB5b3UNCiAgICA+Pj4gZXN0YWJsaXNoIGEgZGF0YSBjaGFubmVs
IHVzaW5nIHRoZSBwYXRoIGF0dHJpYnV0ZT8NCiAgICA+PiAgICAgDQogICAgPj4gICAgIFRoZSB3
YXkgSSB1bmRlcnN0YW5kIHRoaXMgaXMgIm1ha2Ugc3VyZSBwYXRoIGF0dHJpYnV0ZSBpcyBpZ25v
cmVkIGZvcg0KICAgID4+ICAgICBzZXR0aW5nIHVwIHRoZSB0cmFuc3BvcnQiLg0KICAgID4+ICAg
ICANCiAgICA+PiAgICAgVGhpcyBpcyBhbHNvIGNvbm5lY3RlZCB0byBDRU1BIGJlaW5nIGFzc3Vt
ZWQuIEkgYmVsaWV2ZSB0aGUgb3ZlcmFsbA0KICAgID4+ICAgICBpbnRlbnRpb24gb2YgdGhlIHBh
cmFncmFwaCBpcyB0aGF0IHRyYW5zcG9ydCBlc3RhYmxpc2htZW50IG11c3QgYWx3YXlzDQogICAg
Pj4gICAgIHVzZSBDRU1BLCBldmVuIGlmIHRoZSBhdHRyaWJ1dGUgaXMgbm90IHRoZXJlLCBhbmQg
cGF0aCBzaG91bGQgbmV2ZXIgYmUNCiAgICA+PiAgICAgdXNlZC4gU28sIGZvciBkYXRhIGNoYW5u
ZWwgdHJhbnNwb3J0LCBDRU1BIGlzIG5vdCBvcHRpb25hbCwgYXMgUkZDNjcxNA0KICAgID4+ICAg
ICBzYXlzLiBNYXliZSBhIHJld3JpdGluZyBtYWtpbmcgdGhpcyBtb3JlIGNsZWFyIGlzIG5lZWRl
ZC4NCiAgICA+ICAgIA0KICAgID4gQnV0IHRoZSB0cmFuc3BvcnQgZXN0YWJsaXNobWVudCBvZiBh
IGRhdGEgY2hhbm5lbCBkb2VzIG5vdCB1c2UgQ0VNQS4NCiAgICA+DQogICAgPiBNYXliZSB0aGVy
ZSBpcyBhIHJlYXNvbiBmb3IgYWxsIG9mIHRoaXMgKGl0J3Mgc3VjaCBhIGxvbmcgdGltZSBzaW5j
ZSBJIGxvb2tlZCBhdCBpdCksIGJ1dCBpdCBuZWVkcyB0byBiZSBjbGVhciB3aHkgd2UgbWFuZGF0
ZSBjZXJ0YWluIHRoaW5ncy4NCiAgICA+DQogICAgPiBSZWdhcmRzLA0KICAgID4NCiAgICA+IENo
cmlzdGVyDQogICAgPg0KICAgID4NCiAgICA+ICAgIA0KICAgID4gICAgICANCiAgICA+ICAgICAg
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+ICAg
ICAgbW11c2ljIG1haWxpbmcgbGlzdA0KICAgID4gICAgICBtbXVzaWNAaWV0Zi5vcmcNCiAgICA+
ICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCiAgICA+
ICAgICAgDQogICAgPg0KICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCiAgICA+IG1tdXNpYyBtYWlsaW5nIGxpc3QNCiAgICA+IG1tdXNpY0BpZXRm
Lm9yZw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMN
CiAgICANCg0K


From nobody Tue Apr 23 01:42:35 2019
Return-Path: 
X-Original-To: mmusic@ietf.org
Delivered-To: mmusic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF6C1200A4; Tue, 23 Apr 2019 01:42:25 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: mmusic@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: mmusic@ietf.org
Message-ID: <155600894528.32489.5865391189223687914@ietfa.amsl.com>
Date: Tue, 23 Apr 2019 01:42:25 -0700
Archived-At: 
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-data-channel-sdpneg-26.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Apr 2019 08:42:26 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia Session Control WG of the IETF.

        Title           : SDP-based Data Channel Negotiation
        Authors         : Keith Drage
                          Maridi R. Makaraju (Raju)
                          Richard Ejzak
                          Jerome Marcon
                          Roni Even
	Filename        : draft-ietf-mmusic-data-channel-sdpneg-26.txt
	Pages           : 40
	Date            : 2019-04-23

Abstract:
   Data channel setup can be done using either the in-band Data Channel
   Establishment Protocol (DCEP) or using some out-of-band non-DCEP
   protocol.  This document specifies how the SDP (Session Description
   Protocol) offer/answer exchange can be used to achieve an out-of-band
   non-DCEP negotiation for establishing a data channel.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-26
https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-data-channel-sdpneg-26

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-data-channel-sdpneg-26


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Apr 23 05:47:24 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE5A120167; Tue, 23 Apr 2019 05:47:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJ6pIt3YqpUp; Tue, 23 Apr 2019 05:47:19 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDFAB12015F; Tue, 23 Apr 2019 05:47:18 -0700 (PDT)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 6489CA5E49A64D750C04; Tue, 23 Apr 2019 13:47:16 +0100 (IST)
Received: from lhreml702-chm.china.huawei.com (10.201.108.51) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 23 Apr 2019 13:47:15 +0100
Received: from lhreml702-chm.china.huawei.com (10.201.108.51) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 23 Apr 2019 13:47:15 +0100
Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Tue, 23 Apr 2019 13:47:15 +0100
Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.138]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0415.000; Tue, 23 Apr 2019 20:47:10 +0800
From: "Roni Even (A)" 
To: Benjamin Kaduk , The IESG 
CC: "draft-ietf-mmusic-data-channel-sdpneg@ietf.org" , Bo Burman , "mmusic-chairs@ietf.org" , "mmusic@ietf.org" 
Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-mmusic-data-channel-sdpneg-25: (with COMMENT)
Thread-Index: AQHU8BG0WtMoUIs+/0m9N797VxlBlqZJspdA
Date: Tue, 23 Apr 2019 12:47:10 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18CDD817@dggemm526-mbx.china.huawei.com>
References: <155495118561.22741.226184336926630062.idtracker@ietfa.amsl.com>
In-Reply-To: <155495118561.22741.226184336926630062.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.202.102]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [MMUSIC] Benjamin Kaduk's No Objection on draft-ietf-mmusic-data-channel-sdpneg-25: (with COMMENT)
X-BeenThere: mmusic@ietf.org
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: Tue, 23 Apr 2019 12:47:22 -0000

SGksDQpUaGFua3MgZm9yIHRoZSByZXZpZXcsIHNlZSBpbmxpbmUNClJvbmkNCg0KLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJlbmphbWluIEthZHVrIHZpYSBEYXRhdHJhY2tlciBb
bWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmddIA0KU2VudDogVGh1cnNkYXksIEFwcmlsIDExLCAyMDE5
IDU6NTMgQU0NClRvOiBUaGUgSUVTRw0KQ2M6IGRyYWZ0LWlldGYtbW11c2ljLWRhdGEtY2hhbm5l
bC1zZHBuZWdAaWV0Zi5vcmc7IEJvIEJ1cm1hbjsgbW11c2ljLWNoYWlyc0BpZXRmLm9yZzsgYm8u
YnVybWFuQGVyaWNzc29uLmNvbTsgbW11c2ljQGlldGYub3JnDQpTdWJqZWN0OiBCZW5qYW1pbiBL
YWR1aydzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLW1tdXNpYy1kYXRhLWNoYW5uZWwtc2Rw
bmVnLTI1OiAod2l0aCBDT01NRU5UKQ0KDQpCZW5qYW1pbiBLYWR1ayBoYXMgZW50ZXJlZCB0aGUg
Zm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCmRyYWZ0LWlldGYtbW11c2ljLWRhdGEtY2hh
bm5lbC1zZHBuZWctMjU6IE5vIE9iamVjdGlvbg0KDQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBr
ZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwgZW1haWwgYWRkcmVz
c2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRo
aXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQoNCg0KUGxlYXNlIHJlZmVyIHRv
IGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRt
bA0KZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBv
c2l0aW9ucy4NCg0KDQpUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0
aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv
Yy9kcmFmdC1pZXRmLW1tdXNpYy1kYXRhLWNoYW5uZWwtc2RwbmVnLw0KDQoNCg0KLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLQ0KQ09NTUVOVDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KU2VjdGlvbiA0DQoNCiAgIFRoZSBtZWNo
YW5pc20gaW4gdGhpcyBkb2N1bWVudCBvbmx5IGFwcGxpZXMgdG8gdGhlIFNlc3Npb24NCiAgIERl
c2NyaXB0aW9uIFByb3RvY29sIChTRFApIFtJLUQuaWV0Zi1tbXVzaWMtcmZjNDU2NmJpc10gd2hl
biB1c2VkDQogICB0b2dldGhlciB3aXRoIHRoZSBTRFAgb2ZmZXIvYW5zd2VyIG1lY2hhbmlzbSBb
UkZDMzI2NF0uICBEZWNsYXJhdGl2ZQ0KICAgdXNhZ2Ugb2YgU0RQIGlzIG91dCBvZiBzY29wZSBv
ZiB0aGlzIGRvY3VtZW50LCBhbmQgaXMgdGh1cyB1bmRlZmluZWQuDQoNCm5pdDogdGhpcyB0ZXh0
IGRvZXNuJ3QgYWN0dWFsbHkgc2NvcGUgaXRzZWxmIHRvICJ0aGlzIG1lY2hhbmlzbSIgb3IgdGhl
IFJUQ1dlYiBkYXRhIGNoYW5uZWwsIGFuZCBzZWVtcyB0byBiZSBzYXlpbmcgdGhhdCBhbGwgZGVj
bGFyYXRpdmUgU0RQIGlzIHVuZGVmaW5lZCwgZ2xvYmFsbHkuDQoNClJFOiBjaGFuZ2UgdG8gIiBE
ZWNsYXJhdGl2ZSAgdXNhZ2Ugb2YgU0RQIGlzIG91dCBvZiBzY29wZSBmb3IgdGhpcyBkb2N1bWVu
dCwgYW5kIGlzIHRodXMgdW5kZWZpbmVkLiINCg0KU2VjdGlvbiA1LjEuNw0KDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIFRoZSBvcmRlcmVkIHBhcmFtZXRlciBpcyBvcHRpb25hbCBh
bmQNCiAgIHRha2VzIHR3byB2YWx1ZXM6ICJ0cnVlIiBmb3Igb3JkZXJlZCBhbmQgImZhbHNlIiBm
b3IgdW5vcmRlcmVkDQogICBkZWxpdmVyeSB3aXRoICJ0cnVlIiBhcyB0aGUgZGVmYXVsdCB2YWx1
ZS4gIEFueSBvdGhlciB2YWx1ZSBpcw0KICAgaWdub3JlZCBhbmQgZGVmYXVsdCAib3JkZXJlZD10
cnVlIiBpcyBhc3N1bWVkLiAgWy4uLl0NCg0KVGhpcyBzZWVtcyB0byBiZSBzYXlpbmcgdGhhdCBv
ZmZlcnMgb3IgYW5zd2VycyB0aGF0IGRvIG5vdCBjb25mb3JtIHRvIHRoZSBBQk5GIHdpbGwgYmUg
c3BlY2lhbC1jYXNlZCBhcyBiZWluZyBpZ25vcmVkIChpbnN0ZWFkIG9mIHJlamVjdGVkKSB3aGVu
IHRoZXkgYXBwZWFyIHdoZXJlIG9yZGVyaW5nLXZhbHVlIHNob3VsZCBhcHBlYXIuICBJdCdzIG5v
dCBjbGVhciB0byBtZSB3aHkgd2UgbmVlZCBhIHNwZWNpYWwgY2FzZSBoZXJlLCBzaW5jZSBpbiBT
ZWN0aW9uIDggd2UgZXhwbGljaXRseSBzYXkgdGhhdCBwZWVycyBNVVNUIGNsb3NlIHRoZSByZWxl
dmFudCBkYXRhIGNoYW5uZWwgd2hlbiBzdWNoIGVycm9yIGNhc2VzIG9jY3VyLg0KDQpSRTogdGhp
cyBzdGF0ZW1lbnQgb25seSBhcHBsaWVzIHRvIHRoZSBvcmRlcmVkIHBhcmFtZXRlciwgSSBhbSBu
b3Qgc3VyZSB3aHkgeW91IHRoaW5rIGl0IGlzIGZvciBhbnkgcGFyYW1ldGVyLg0KDQpTZWN0aW9u
IDUuMS44DQoNCklmIHdlIGNoYXNlIGxpbmtzIHRvIGRyYWZ0LWlldGYtcnRjd2ViLWRhdGEtY2hh
bm5lbCB3ZSBmaW5kIHRoYXQgbGFyZ2VyIHZhbHVlcyBpbmRpY2F0ZSBoaWdoZXIgcHJpb3JpdHku
ICBEbyB3ZSB3YW50IHRvIHNob3J0LWNpcmN1aXQgdGhhdCBhbmQgc2F5IHNvIGV4cGxpY2l0bHkg
aGVyZT8NCg0KUkU6IEkgcHJlZmVyIHRvIGtlZXAgdGhlIGxpbmsgc2luY2Ugb3RoZXJ3aXNlIGFu
eSBjaGFuZ2UgaW4gdGhlIHJ0Y3dlYiBkb2N1bWVudCB3aWxsIHJlcXVpcmUgYSBjaGFuZ2UgaGVy
ZS4NCg0KU2VjdGlvbiA1LjINCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVhY2gNCiAgIG9mIHRoZXNlIGF0dHJpYnV0
ZXMgaXMgcmVwcmVzZW50ZWQgYnkgb25lIG5ldyBhdHRyaWJ1dGUgbGluZSwgYW5kIGl0DQogICBp
bmNsdWRlcyB0aGUgY29udGVudHMgb2YgYSBtZWRpYS1sZXZlbCBTRFAgYXR0cmlidXRlIGFscmVh
ZHkgZGVmaW5lZA0KICAgZm9yIHVzZSB3aXRoIHRoaXMgKHN1Yilwcm90b2NvbCBpbiBhbm90aGVy
IElFVEYgKEludGVybmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlKSBkb2N1bWVudC4gIFsu
Li5dDQoNCkRvIHdlIG5lZWQgdG8gbGltaXQgdGhlIGRhdGEtY2hhbm5lbCBzdWJwcm90b2NvbHMg
dG8gdGhvc2Ugc3BlY2lmaWVkIGJ5IHRoZSBJRVRGPyAgT3IgaXMgaXQganVzdCB0aGUgbWVkaWEt
bGV2ZWwgU0RQIGF0dHJpYnV0ZXMgdGhhdCB3ZSBhcmUgdHJ5aW5nIHRvIG1haW50YWluIGNoYW5n
ZSBjb250cm9sIG92ZXI/DQoNClJFOiBpdCBpcyBqdXN0IHRoZSBTRFAgYXR0cmlidXRlcywgdGhp
cyBpcyB0aGUgZGNzYSBzZWN0aW9uLiBTdWIgcHJvdG9jb2xzIGFyZSBzcGVjaWZpZWQgZm9yIGRj
bWFwDQoNCiAgIFRoZSBkZXRhaWxlZCBvZmZlci9hbnN3ZXIgcHJvY2VkdXJlcyBmb3IgdGhlIGRj
c2EgYXR0cmlidXRlIGFyZQ0KICAgZGVwZW5kZW50IG9uIHRoZSBhc3NvY2lhdGVkIHN1Yi1wcm90
b2NvbC4gIElmIG5vIG9mZmVyL2Fuc3dlcg0KICAgcHJvY2VkdXJlcyBleGlzdCBmb3IgdGhlIHN1
Yi1wcm90b2NvbCB3aGVuIHVzZWQgb3V0c2lkZSBvZiB0aGUgZGNzYQ0KICAgYXR0cmlidXRlLCBu
byBzcGVjaWZpY2F0aW9uIGlzIG5lZWRlZCBmb3IgdXNlIHdpdGggZGNzYS4gIFRoZSBJQU5BDQog
ICByZWdpc3RyYXRpb24gcHJvY2VkdXJlcyBmb3IgdGhlIFdlYlNvY2tldCBTdWJwcm90b2NvbCBO
YW1lIFJlZ2lzdHJ5DQogICAoU2VjdGlvbiA5LjEpIGRvIG5vdCBzdHJpY3RseSByZXF1aXJlIGEg
c3BlY2lmaWNhdGlvbiBvZiB0aGUgb2ZmZXIvDQogICBhbnN3ZXIgcHJvY2VkdXJlcyBmb3IgdGhl
IHN1Yi1wcm90b2NvbCB3aGVuIHVzZWQgd2l0aCBkY3NhLiAgSWYgdGhlDQogICBzdWItcHJvdG9j
b2wgaGFzIGRlZmluZWQgb2ZmZXIvYW5zd2VyIHByb2NlZHVyZXMgd2hlbiB1c2VkIG91dHNpZGUg
b2YNCiAgIGRjc2EsIHN1Y2ggYSBzcGVjaWZpY2F0aW9uIGlzIGVuY291cmFnZWQgdG8gZW5zdXJl
IGludGVyb3BlcmFiaWxpdHkuDQogICBJZiB0aGUgc3ViLXByb3RvY29sIGhhcyBkZWZpbmVkIG9m
ZmVyL2Fuc3dlciBwcm9jZWR1cmVzIHdoZW4gdXNlZA0KICAgb3V0c2lkZSBvZiBkY3NhLCBidXQg
bm8gc3BlY2lmaWNhdGlvbiBleGlzdHMgZm9yIHRoZSBvZmZlci9hbnN3ZXINCiAgIHByb2NlZHVy
ZXMgZm9yIHRoZSBzdWItcHJvdG9jb2wgd2hlbiB1c2VkIHdpdGggZGNzYSwgaW1wbGVtZW50YXRp
b25zDQogICBTSE9VTEQgYXNzdW1lIHRoZSB1c2Ugb2YgdGhlIGRlZmF1bHQgdmFsdWVzIGZvciBh
bGwgb3RoZXJ3aXNlLQ0KICAgbmVnb3RpYWJsZSBhbmQgYXBwbGljYWJsZSBzdWItcHJvdG9jb2wg
cGFyYW1ldGVycy4NCg0KSSdtIG5vdCBlbnRpcmVseSBzdXJlIEkgdW5kZXJzdGFuZCB3aGF0IHRo
aXMgcGFyYWdyYXBoIGlzIHRyeWluZyB0byBzYXkuDQpUaGUgZmlyc3Qgc2VudGVuY2UgaXMgY2xl
YXIsIGJ1dCB0aGUgc2Vjb25kIHNlbnRlbmNlIHNlZW1zIHRvIGJlIHNheWluZyB0aGF0IGlmIHRo
ZXJlIGFyZSBubyBPL0EgcHJvY2VkdXJlcyBmb3IgYSBnaXZlbiBzdWJwcm90b2NvbCBvdXRzaWRl
IHRoZSBkYXRhY2hhbm5lbCwgaXQncyBqdXN0IGEgZnJlZSBmb3IgYWxsIGFuZCBJIGNhbiB1c2Ug
aXQgaW4gdGhlIGRhdGEgY2hhbm5lbCBhbmQgbWFrZSB1cCBteSBvd24gcHJvY2VkdXJlcyBmb3Ig
dXNpbmcgdGhlIGRjc2EgYXR0cmlidXRlLg0KSSB1bmRlcnN0YW5kIHRoYXQgSUFOQSBkb2Vzbid0
IHJlcXVpcmUgYSBzcGVjaWZpY2F0aW9uIGZvciB0aGUgc3VicHJvdG9jb2wgd2hlbiBhbGxvY2F0
aW5nIHRoZSBzdWJwcm90b2NvbCBuYW1lLCBidXQgdGhhdCBqdXN0IG1lYW5zIHRoYXQgdGhlcmUg
bWF5IG5vdCBiZSBhIHNwZWNpZmljYXRpb24gYXZhaWxhYmxlIHdoZXRoZXIgb3Igbm90IEkgd2Fu
dCB0byB1c2UgaXQgd2l0aCBkY3NhIC0tIHRoZSBJQU5BIHJlZ2lzdHJ5IGRvZXNuJ3QgY2FyZSBk
aXJlY3RseSBhYm91dCB1c2Ugd2l0aCBkY3NhLiAgSWYgYSBzdWJwcm90b2NvbCBoYXMgZGVmaW5l
ZCBPL0EgcHJvY2VkdXJlcyBvdXRzaWRlIG9mIGRjc2EsIGRvZXNuJ3QgdGhhdCBiYXNpY2FsbHkg
bWVhbiB0aGVyZSdzIGEgc3BlY2lmaWNhdGlvbj8gIFdoeSBkbyB3ZSBuZWVkIHRvIGdvIG91dCBv
ZiBvdXIgd2F5IHRvIGVuY291cmFnZSBhIHNwZWNpZmljYXRpb24gaW4gdGhhdCBjYXNlIChhbmQg
aXMgaXQgYSBzcGVjaWZpY2F0aW9uIG9mIHRoZSBPL0Egc2VtYW50aWNzIHdoZW4gdGhlIHN1YnBy
b3RvY29sIGlzIHVzZWQgb3V0c2lkZSBkY3NhIG9yIHdpdGggZGNzYSk/ICBJbiB0aGUgbGFzdCBz
ZW50ZW5jZSwgSSB0aGluayB3ZSdyZSB0YWxraW5nIGFib3V0IHVzaW5nIGRlZmF1bHRzIGZvciBw
YXJhbWV0ZXJzIHRoYXQgYXJlIG5vdCBleHBsaWNpdGx5IG5lZ290aWF0ZWQgdXNpbmcgZGNzYSwg
YnV0IHdlIGRvbid0IGFjdHVhbGx5IHNheSB0aGF0Lg0KDQpSRS0gU2luY2Ugc3VicHJvdG9jb2xz
IGNhbiBiZSByZWdpc3RlcmVkIHdpdGggSUFOQSBvbiBGQ0ZTIHdlIGNhbm5vdCBhc3N1bWUgdGhh
dCB0aGVyZSB3aWxsIGJlIGEgZG9jdW1lbnQgdGhhdCB3aWxsIGFkZHJlc3MgdGhlIG9mZmVyIGFu
c3dlciBidXQgd2Ugd291bGQgbGlrZSB0byBlbmNvdXJhZ2UgaXQuDQoNClNlY3Rpb24gNS4yLjEN
Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOb3RlIGhv
d2V2ZXIgdGhhdCBub3QgYWxsDQogICBTRFAgYXR0cmlidXRlcyBhcmUgc3VpdGFibGUgYXMgYSAi
YT1kY3NhOiIgcGFyYW1ldGVyLiAgSUFOQSBTRFANCiAgIHBhcmFtZXRlcnMgY29udGFpbnMgdGhl
IGxpc3RzIG9mIElBTkEgKEludGVybmV0IEFzc2lnbmVkIE51bWJlcnMNCiAgIEF1dGhvcml0eSkg
cmVnaXN0ZXJlZCBzZXNzaW9uIGFuZCBtZWRpYSBsZXZlbCBvciBtZWRpYSBsZXZlbCBvbmx5IFNE
UA0KICAgYXR0cmlidXRlcy4NCg0KQW0gSSBzdXBwb3NlZCB0byBpbmZlciB0aGF0IHRoZXNlIGFy
ZSB0aGUgYXR0cmlidXRlcyB0aGF0IGFyZSBzdWl0YWJsZSBmb3IgYT1kY3NhOiBwYXJhbWV0ZXJz
Pw0KDQpSRTogYWRkZWQgdGhlIGZvbGxvd2luZyB0ZXh0IHRvIHRoaXMgc2VjdGlvbjoNCg0KIiBT
RFAgYXR0cmlidXRlcyB0aGF0IGFyZSBvbmx5IGRlZmluZWQgZm9yIHVzZSBhdCB0aGUNCiAgIGRj
c2EgdXNhZ2UgbGV2ZWwsIFNIQUxMIHVzZSB0aGUgZGNzYSB1c2FnZSBsZXZlbCB3aGVuIHJlZ2lz
dGVyaW5nIHRoZQ0KICAgYXR0cmlidXRlLiAgSWYgZXhpc3RpbmcgbWVkaWEgYXR0cmlidXRlcyBh
cmUgdXNlZCBpbiBhIGRhdGFjaGFubmVsDQogICBzdWJwcm90b2NvbCBzcGVjaWZpYyB3YXksIHRo
ZW4gYSBuZXcgZGNzYSB1c2FnZSBsZXZlbA0KICAgTVVTVCBiZSBkZWZpbmVkIGZvciB0aGUgZXhp
c3RpbmcgbWVkaWEgYXR0cmlidXRlLiAgV2hlcmUgdGhlIFNEUA0KICBhdHRyaWJ1dGUgaXMgYXBw
bGljYWJsZSB0byBhIHBhcnRpY3VsYXIgc3VicHJvdG9jb2wvcyB0aGlzIFNIQUxMIGFsc28NCiAg
IGJlIHJlZ2lzdGVyZWQgYnkgaW5kaWNhdGluZyB0aGUgYXBwbGljYWJsZSBzdWJwcm90b2NvbCBp
ZGVudGlmaWVycw0KICAgKHNlZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0
Zi1tbXVzaWMtcmZjNDU2NmJpcy0zNCNzZWN0aW9uLTguNSkgYWxvbmcgd2l0aCB0aGUgZGNzYSB1
c2FnZSBsZXZlbC4NCiINCk5vdGUgdGhhdCByZmM0NTY2YmlzIGNoYW5nZXMgdGhlIHJlZ2lzdHJh
dGlvbiB0YWJsZSBpbiBJQU5BDQoNCiAgIEFzIG9wcG9zZWQgdG8gdGhlIGRhdGEgY2hhbm5lbCAi
YT1kY21hcDoiIGF0dHJpYnV0ZSBwYXJhbWV0ZXJzLCB0aGVzZQ0KICAgcGFyYW1ldGVycyBhcmUg
c3ViamVjdCB0byBvZmZlci9hbnN3ZXIgbmVnb3RpYXRpb24gZm9sbG93aW5nIHRoZQ0KICAgcHJv
Y2VkdXJlcyBkZWZpbmVkIGluIHRoZSBzdWJwcm90b2NvbCBzcGVjaWZpYyBkb2N1bWVudHMuDQoN
CkkgYW0gbm90IHN1cmUgd2hlcmUgd2UgcmVhbGx5IHNheSB0aGF0IHRoZSBhPWRjbWFwOiBwYXJh
bWV0ZXJzIGFyZSBub3Qgc3ViamVjdCB0byBPL0EgbmVnb3RpYXRpb24uDQoNClJFOiBzZWUgc2Vj
dGlvbiA2LjQgLCBkY21hcCBpcyBlaXRoZXIgYWNjZXB0ZWQgYXMgaXMgb3IgcmVqZWN0ZWQuDQoN
ClNlY3Rpb24gNi4xDQoNCiAgIFNDVFAgc3RyZWFtIGlkZW50aWZpZXJzIGFzc29jaWF0ZWQgd2l0
aCBkYXRhIGNoYW5uZWxzIHRoYXQgaGF2ZSBiZWVuDQogICBuZWdvdGlhdGVkIHVzaW5nIERDRVAg
TVVTVCBOT1QgYmUgaW5jbHVkZWQgaW4gU0RQIG9mZmVycyBhbmQgYW5zd2Vycy4NCg0KVGhpcyBz
ZW50ZW5jZSBhcHBlYXJzIGFzIGEgZGVkaWNhdGVkIHBhcmFncmFwaCBhbmQgaXMgZHVwbGljYXRl
ZCBhdCB0aGUgZW5kIG9mIHRoZSBwcmV2aW91cyBwYXJhZ3JhcGg7IHByZXN1bWFibHkgd2Ugb25s
eSBuZWVkIG9uZSBjb3B5IHRoZXJlb2YuLi4NCg0KUkU6IHllcywgdGhhbmtzDQoNClNlY3Rpb24g
Ni4yDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSWYgYW4gU0RQ
IGFuc3dlciBjb250YWlucyBib3RoDQogICBvZiB0aGVzZSBwYXJhbWV0ZXJzIHRoZW4gdGhlIG9m
ZmVyZXIgTVVTVCB0cmVhdCB0aGUgYXNzb2NpYXRlZCBTRFANCiAgIG9mZmVyL2Fuc3dlciBmYWls
ZWQuDQoNCm5pdDogImFzIGZhaWxlZCIsIEkgdGhpbmsuDQoNClJFOiBPSw0KDQpTZWN0aW9uIDYu
NA0KDQpXZSBvbmx5IG1lbnRpb24gdGhhdCB0aGUgZGNtYXAtc3RyZWFtLWlkLCBtYXgtcmV0ciwg
YW5kIG1heC10aW1lIHZhbHVlcyBuZWVkIHRvIG1hdGNoIHRoZSBvZmZlciwgbGVhdmluZyB0aGUg
b3JkZXJpbmcvc3VicHJvdG9jb2wvbGFiZWwvcHJpb3JpdHkNCnRvIGJlIG9taXR0ZWQgYmVjYXVz
ZSB0aGV5IGFyZSBjb252ZXllZCBhdCB0aGUgU0NUUCBsYXllcj8gIFBlcmhhcHMgd2Ugc2hvdWxk
IHN0YXRlIGV4cGxpY2l0bHkgdGhhdCB0aGV5IG5lZWQgdG8gYmUgYWJzZW50Li4uDQoNClJFOiB0
aGV5IGNhbiBiZSBkaWZmZXJlbnQgaW4gZWFjaCBkaXJlY3Rpb24NCg0KU2VjdGlvbiA2LjYNCg0K
RG8gd2Ugd2FudCB0byBzYXkgYW55dGhpbmcgYWJvdXQgdGhlIGFwcHJvcHJpYXRlIHJlc3BvbnNl
IHRvIHJlY2VpdmluZyBjaGFuZ2VkIHZhbHVlcyBmb3IgdGhlIFNEUCBhdHRyaWJ1dGVzL2F0dHJp
YnV0ZSB2YWx1ZXMgaXMgdG8gY2xvc2UgdGhlIGNvcnJlc3BvbmRpbmcgZGF0YSBjaGFubmVsPw0K
DQpSRTogQWRkZWQgdGV4dCBpbiB0aGUgLTI2IHZlcnNpb24gYWJvdXQgdGhpcyBiZWluZyBhcHBs
aWNhdGlvbiBkZXBlbmRlbnQNCg0KU2VjdGlvbiA2LjYuMQ0KDQpJdCBzZWVtcyBsaWtlIHRoZSBz
ZWNvbmQgYnVsbGV0IHBvaW50IG9ubHkgbWFrZXMgc2Vuc2UgYWZ0ZXIgdGhlIGZpcnN0IGhhcyBj
b21wbGV0ZWQsIGFzIHRoZSB0c3ZhcnQgcmV2aWV3ZXIgbm90ZWQ/ICBTcGVjaWZpY2FsbHksIHRo
ZSAiOyBvciINCmF0IHRoZSBlbmQgb2YgdGhlIGZpcnN0IGJ1bGxldCBwb2ludCBkb2Vzbid0IHNl
ZW0gdG8gbWFrZSBtdWNoIHNlbnNlLg0KDQpSRTogYWZ0ZXIgdGhlIGRhdGEgY2hhbm5lbCBpcyBy
ZXNldCB5b3UgY2FuIHVzZSBhIG5ldyBkYXRhIGNoYW5uZWwgd2l0aCBhIG5ldyBkY21hcCB2YWx1
ZSANCg0KU2VjdGlvbiA5LjMNCg0KICAgICAgICAgICAgICAgSWYgZXhpc3RpbmcgbWVkaWEgYXR0
cmlidXRlcyBhcmUgdXNlZCBpbiBhIGRhdGFjaGFubmVsDQogICBzdWJwcm90b2NvbCBzcGVjaWZp
YyB3YXkgKFNlY3Rpb24gNS4yLjEpLCB0aGVuIGEgbmV3IGRjc2EgdXNhZ2UgbGV2ZWwNCiAgIE1V
U1QgYmUgZGVmaW5lZCBmb3IgdGhlIGV4aXN0aW5nIG1lZGlhIGF0dHJpYnV0ZS4gIFsuLi5dDQoN
CkknbSBub3QgZW50aXJlbHkgc3VyZSB0aGF0IEkgdW5kZXJzdGFuZCB3aGF0IHRoaXMgbWVhbnMs
IHRob3VnaCBJJ20gbm90IHJlYWxseSBhbiBleHBlcnQgaW4gU0RQLg0KDQpSRTogdGhpcyBzZWN0
aW9uIHdhcyByZW1vdmVkIHNlZSBteSBjb21tZW50IG9uIHNlY3Rpb24gNS4yLjENCg0KQXBwZW5k
aXggQS4xDQoNCkknbSBub3Qgc3VyZSB0aGF0IEkga25vdyB3aGF0ICJnbGFyZSBzaXR1YXRpb25z
IiBhcmU7IGlzIHRoZXJlIGEgcmVhc29uYWJsZSByZWZlcmVuY2UgdG8gaW5jbHVkZT8NCg0KUkU6
IHRoaXMgaXMgYW4gb2ZmZXIvYW5zd2VyIHRlcm0gaW4gUkZDMzI2NCBhbmQga25vd24gdG8gYW55
b25lIHdobyBpcyBkb2luZyBvZmZlci9hbnN3ZXIgKEkgY2FuIGFkZCBhIHJlZmVyZW5jZSB0byBS
RkMzMjY0KQ0KDQogICBXaGljaCBzZXQgb2Ygc3RyZWFtIGlkZW50aWZpZXJzIGlzIG93bmVkIGJ5
IHdoaWNoIGVuZHBvaW50IGlzDQogICBkZXRlcm1pbmVkIGJ5IGNvbnZlbnRpb24gb3Igb3RoZXIg
bWVhbnMuDQoNCihzcGVjaWZpYyB0byB0aGUgYXBwbGljYXRpb24/KQ0KDQogICAgICBOb3RlOkZv
ciBkYXRhIGNoYW5uZWxzIG5lZ290aWF0ZWQgdmlhIGRpZmZlcmVudCBwcm90b2NvbCBmcm9tDQog
ICAgICBEQ0VQLCBubyBjb252ZW50aW9uIGlzIGRlZmluZWQgYnkgZGVmYXVsdC4NCg0KVGhhdCBz
ZWVtcyBhIGJpdCBtaXNsZWFkaW5nLCBzaW5jZSBTZWN0aW9uIDYuMSBzYXlzIHRoYXQgdGhlIGV2
ZW4vb2RkIHNwbGl0IGFwcGxpZXMgdG8gdGhlIFNEUCBPL0EgbmVnb3RpYXRpb24gY2FzZS4NCg0K
UkU6IHRoaXMgaXMgdHJ1ZSBhbmQgdGhlIG5vdGUgc2F5cyB0aGF0IGZvciBub24gRENFUCB5b3Ug
bmVlZCB0byBzcGVjaWZ5IHRoZSBjb252ZW50aW9uIHdoaWNoIGlzIGRvbmUgaW4gc2VjdGlvbiA2
LjENCg0KDQo=


From nobody Wed Apr 24 01:37:23 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007D5120220; Wed, 24 Apr 2019 01:37:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7qnzlGs7XgW; Wed, 24 Apr 2019 01:37:19 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150079.outbound.protection.outlook.com [40.107.15.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED6441200A4; Wed, 24 Apr 2019 01:37:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GX1TT4AwlxTfHjLxfqLD7GmGR5oyf9W6kimModJc1Ng=; b=Sj4JeqpiMdImQUN50EiyQbU1hKlG8lXGvyDRHOXJMgdlOaF77Q4FTf6kbBXRptSwp2tfniy2pxEh+oHSz9cIxJvrl6azvv4TS57ValZb/2avXa4tafMT+n5Vrc6r9h8vb5tGvZXiG6gvGQenKHTP2zgUq5f2k+X2ePP7j+uyC1w=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4233.eurprd07.prod.outlook.com (20.176.166.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.9; Wed, 24 Apr 2019 08:37:16 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184%2]) with mapi id 15.20.1835.010; Wed, 24 Apr 2019 08:37:16 +0000
From: Christer Holmberg 
To: "mmusic@ietf.org" , Roni Even 
CC: "mmusic-chairs@ietf.org" 
Thread-Topic: SDPNEG: How to disable DCEP
Thread-Index: AQHU+njrOtTA5N+Kv0Ox965sWihq+A==
Date: Wed, 24 Apr 2019 08:37:15 +0000
Message-ID: <8A9AAAC7-FB2D-4884-BAC6-268B98C7A0F0@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.16.1.190220
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-originating-ip: [89.166.49.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 45f5f665-bda3-46be-3a0d-08d6c8900e51
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB4233; 
x-ms-traffictypediagnostic: HE1PR07MB4233:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-forefront-prvs: 00179089FD
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(346002)(136003)(376002)(396003)(189003)(199004)(99286004)(486006)(2616005)(6436002)(44832011)(110136005)(58126008)(6486002)(316002)(66066001)(476003)(14454004)(478600001)(33656002)(186003)(81166006)(81156014)(8676002)(6116002)(3846002)(4744005)(76116006)(66556008)(66476007)(71190400001)(64756008)(66946007)(73956011)(66446008)(71200400001)(256004)(6506007)(26005)(2906002)(8936002)(82746002)(83716004)(102836004)(68736007)(5660300002)(7736002)(4326008)(25786009)(6306002)(54896002)(53936002)(6512007)(86362001)(2501003)(36756003)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4233; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: EtqCqD5WJWtaQ9Dy4a2jRISh7c8GRj6QF3b4coYaxRKLb0KKpl7cGmVYZeNLk8xPfMqVQAm/WGWZFTzkOnEz7mRKomQ4la36gXZYm7HdQq2h6MfgukaqzQwFApsC5hdXyQ+13J1xwyCAJ5OjjT8UVR3GvUIYfAz30nMwdqUvr8aL9ndSAzVQ7qUCm8mT1eS1hXUdFX9QeRJrfcuiZ1oI1kAr8gdmbeHycx/4sNyNJWYzfkjRa9gingqOfKaR/CmPG2a3tVvQKhASIJpKjx/2gvWCNDhzsooP8Ie6Xv72tT8Hw7S92QpQAuLbdkDqOECze9HhJlSl4gaSXUmVOl3rzMxfFHfCZ7PdCxRt7pcCZZsMm10iTLJq+Q5V7GE4zlfjnNs2dO1temzCkf+4GTe18cuSDtONZE7OEsFE5LZ73Wk=
Content-Type: multipart/alternative; boundary="_000_8A9AAAC7FB2D4884BAC6268B98C7A0F0ericssoncom_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 45f5f665-bda3-46be-3a0d-08d6c8900e51
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2019 08:37:15.9032 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4233
Archived-At: 
Subject: [MMUSIC] SDPNEG: How to disable DCEP
X-BeenThere: mmusic@ietf.org
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, 24 Apr 2019 08:37:22 -0000

--_000_8A9AAAC7FB2D4884BAC6268B98C7A0F0ericssoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGksDQoNCkkgaGFkIGFuIG9mZi1saW5lIGRpc2N1c3Npb24gd2l0aCBCbyByZWdhcmRpbmcgaG93
IHRvIGtub3cgd2hldGhlciB0byB1c2UgU0RQTkVHIG9yIERDRVAgZm9yIGEgRGF0YSBDaGFubmVs
Lg0KDQpTZWN0aW9uIDUgc2F5czoNCg0KICAg4oCdVGhpcyBzZWN0aW9uIGRlZmluZXMgdHdvIG5l
dyBTRFAgbWVkaWEtbGV2ZWwgYXR0cmlidXRlcyB0aGF0IGNhbiBiZQ0KICAgdXNlZCB0b2dldGhl
ciB3aXRoIHRoZSBTRFAgT2ZmZXIvQW5zd2VyIG1lY2hhbmlzbSB0byBuZWdvdGlhdGUgZGF0YQ0K
ICAgY2hhbm5lbC1zcGVjaWZpYyBhbmQgc3VicHJvdG9jb2wtc3BlY2lmaWMgcGFyYW1ldGVycyB3
aXRob3V0IHRoZQ0KICAgdXNhZ2Ugb2YgRENFUCBbSS1ELmlldGYtcnRjd2ViLWRhdGEtcHJvdG9j
b2xdLuKAnQ0KDQpEbyB3ZSBjb25zaWRlciB0aGlzIGNsZWFyIGVub3VnaCB0aGF0IHRoZSBwcmVz
ZW5jZSBvZiB0aG9zZSBhdHRyaWJ1dGVzICh3ZWxsLCBvbmx5IGRjbWFwLCBzaW5jZSBkY3NhIGlz
IG9wdGlvbmFsKSB3aWxsIOKAnGRpc2FibGXigJ0gdXNhZ2Ugb2YgRENFUCwgb3IgZG8gd2Ugd2Fu
dCB0byBiZSBtb3JlIGNsZWFyPw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K

--_000_8A9AAAC7FB2D4884BAC6268B98C7A0F0ericssoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <1501C9A86CB0444C83C8941CBEE5B217@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw
cmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv
cm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm
b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFp
bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uSFRNTFBy
ZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi
Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt
YXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7
bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt
c2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h
cmdpbjo3MC44NXB0IDIuMGNtIDcwLjg1cHQgMi4wY207fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw
YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRkki
IGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u
MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+
SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dCI+SSBoYWQgYW4gb2ZmLWxpbmUgZGlzY3Vzc2lvbiB3aXRoIEJvIHJlZ2FyZGluZyBob3cgdG8g
a25vdyB3aGV0aGVyIHRvIHVzZSBTRFBORUcgb3IgRENFUCBmb3IgYSBEYXRhIENoYW5uZWwuPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQiPlNlY3Rpb24gNSBzYXlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsg4oCdVGhpcyBzZWN0aW9u
IGRlZmluZXMgdHdvIG5ldyBTRFAgbWVkaWEtbGV2ZWwgYXR0cmlidXRlcyB0aGF0IGNhbiBiZTxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHVzZWQgdG9nZXRoZXIgd2l0aCB0aGUg
U0RQIE9mZmVyL0Fuc3dlciBtZWNoYW5pc20gdG8gbmVnb3RpYXRlIGRhdGE8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s
b3I6YmxhY2siPiZuYnNwOyZuYnNwOyBjaGFubmVsLXNwZWNpZmljIGFuZCBzdWJwcm90b2NvbC1z
cGVjaWZpYyBwYXJhbWV0ZXJzIHdpdGhvdXQgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz
cDsmbmJzcDsgdXNhZ2Ugb2YgRENFUCBbSS1ELmlldGYtcnRjd2ViLWRhdGEtcHJvdG9jb2xdLuKA
nQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQiPkRvIHdlIGNvbnNpZGVyIHRoaXMgY2xlYXIgZW5vdWdoIHRoYXQgdGhl
IHByZXNlbmNlIG9mIHRob3NlIGF0dHJpYnV0ZXMgKHdlbGwsIG9ubHkgZGNtYXAsIHNpbmNlIGRj
c2EgaXMgb3B0aW9uYWwpIHdpbGwg4oCcZGlzYWJsZeKAnSB1c2FnZSBvZiBEQ0VQLCBvciBkbyB3
ZSB3YW50IHRvIGJlIG1vcmUgY2xlYXI/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UmVnYXJkcyw8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt
bD4NCg==

--_000_8A9AAAC7FB2D4884BAC6268B98C7A0F0ericssoncom_--


From nobody Wed Apr 24 15:25:07 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE4912038B for ; Wed, 24 Apr 2019 15:25:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iED8-6CKOr9 for ; Wed, 24 Apr 2019 15:25:05 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E474612014E for ; Wed, 24 Apr 2019 15:25:04 -0700 (PDT)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x3OMP2aw017172 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 24 Apr 2019 18:25:03 -0400
To: mmusic@ietf.org
References: <8A9AAAC7-FB2D-4884-BAC6-268B98C7A0F0@ericsson.com>
From: Paul Kyzivat 
Message-ID: 
Date: Wed, 24 Apr 2019 18:25:02 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <8A9AAAC7-FB2D-4884-BAC6-268B98C7A0F0@ericsson.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP
X-BeenThere: mmusic@ietf.org
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, 24 Apr 2019 22:25:06 -0000

On 4/24/19 4:37 AM, Christer Holmberg wrote:
> Hi,
> 
> I had an off-line discussion with Bo regarding how to know whether to 
> use SDPNEG or DCEP for a Data Channel.
> 
> Section 5 says:
> 
>     â€This section defines two new SDP media-level attributes that can be
> 
>     used together with the SDP Offer/Answer mechanism to negotiate data
> 
>     channel-specific and subprotocol-specific parameters without the
> 
>     usage of DCEP [I-D.ietf-rtcweb-data-protocol].â€
> 
> Do we consider this clear enough that the presence of those attributes 
> (well, only dcmap, since dcsa is optional) will “disable†usage of DCEP, 
> or do we want to be more clear?

The distribution of specs across multiple documents makes it really 
fuzzy what is normative for what.

Perhaps something should be said about the validity of using a 
webrtc-datachannel media stream for establishing data channels via SDP 
with dcmap and/or DCEP. I don't think this is said anywhere else.

	Thanks,
	Paul


From nobody Thu Apr 25 04:08:14 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73BE3120161 for ; Thu, 25 Apr 2019 04:08:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ch3m4.com header.b=gLsz05u2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GuoM28Ww
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKqbPMPCbIDY for ; Thu, 25 Apr 2019 04:08:10 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FF4F12004D for ; Thu, 25 Apr 2019 04:08:10 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 466AB2129D; Thu, 25 Apr 2019 07:08:09 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 25 Apr 2019 07:08:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ch3m4.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm3; bh=OQgMnKbarj+yW4WPzOxpjQ8Mrn2 7NnoIvvMuWWYC7xk=; b=gLsz05u2GbdchdfQ1Rp0N+mihYosXnXVoyEdR6Sr3nA o9I2lyOaTfZt6Lx7GR0BhInydc/u0Dmn9+oGm68+wE9PbAk3Cj2aGlcLFQq22vPn B5CCEeEYMTPZV4cPLayLIItDEWH1KpdQ2uKqjZyzENd+SjHm6vNL6cvvGBGVgcmD aG8I5xPgOsg0FlrXwa2P5zzJnEXW3KN64tCdpDsrGyrHWIun7qV+rLVQ7RnO/ed5 k1ElQCd3aOC10xfDegv2jiLDOg/FTb2nCeC36ghj0iUL61XtvY9sT39Mtwcj5W1M tJtUEUsL1wzThXJlUfZRtT+zwETx9rbV1kDaIYTCsBg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=OQgMnK barj+yW4WPzOxpjQ8Mrn27NnoIvvMuWWYC7xk=; b=GuoM28Wwrg2MVvUYH3fsTh Vm6DlaSFQWg60naAm/6EpEXoPvJhP6xy84A3B1PNtJEx+Vbwcafk+G/OLbsmWbrY ElK1okvabo02Tn6xHirR3tPhA47b5iheSCz1TdYIfXGmjA5cSiK2yFA5Jlz+nIzV naSNhzkwqqcd8+YfdM//A3afQVLhml8Kyu+BlFIt7ht/UjL6IbSqOW6ktqq3B0S9 EREzQZfZXLUizwFerymdxtpPQZ7DWX7Elh8+S0eC/4v2TQRzbcHdTiGgDBAwHHv4 SYaB0hIX8PEYoB4GbJFeCVFwxDvrFq3/M120ijnMuaMB4OxwQjzOX65geuHa7RcQ ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrheeggdefhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhffkffgfgggjtgesrgdtreertdefjeenucfhrhhomheplfhoshgvucfo ucftvggtihhouceojhhoshgvsegthhefmhegrdgtohhmqeenucfkphepieeirdeliedrvd dtgedrudegjeenucfrrghrrghmpehmrghilhhfrhhomhepjhhoshgvsegthhefmhegrdgt ohhmnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy:    
Received: from [192.168.1.187] (unknown [66.96.204.147]) by mail.messagingengine.com (Postfix) with ESMTPA id 8F3BFE4122; Thu, 25 Apr 2019 07:08:07 -0400 (EDT)
To: Christer Holmberg , RIchard Ejzak , "mmusic@ietf.org" 
References: <61D3ED98-04FA-4746-BCDE-37BD38907803@ericsson.com>   <6e4edb12-936d-62b5-b4ff-e05b6d117e75@gmail.com> <3C803301-CDD4-4977-97B1-82FC5D8A06E3@ericsson.com>
From: Jose M Recio 
Message-ID: <76d14939-23a5-6cb6-0457-8a85a644a589@ch3m4.com>
Date: Thu, 25 Apr 2019 19:08:04 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <3C803301-CDD4-4977-97B1-82FC5D8A06E3@ericsson.com>
Content-Type: multipart/alternative; boundary="------------4C8BAEF631815ECA717FCF46"
Content-Language: en-GB
Archived-At: 
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-10.txt - Comment on msrp-cema attribute
X-BeenThere: mmusic@ietf.org
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: Thu, 25 Apr 2019 11:08:12 -0000

This is a multi-part message in MIME format.
--------------4C8BAEF631815ECA717FCF46
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 23/4/19 1:56 PM, Christer Holmberg wrote:

>>     Since I wrote the original text, I should probably reply...
>>     
>>     I agree with Christer that the CEMA attribute is not needed.  It was
>>     originally included to make it clear that the path attribute could not
>>     be used to establish the data channel.  But this is obvious for this new
>>     type of transport.  RFC7977 (WebSocket transport for MSRP) handles this
>>     very nicely by using an .invalid domain name in the path attribute.  I
>>     suggest adopting this approach for dc.

Would this be a fair summary:

- Paragraph in discussion was meant to prevent using path attribute, but that's a moot point for data channel anyway.

To make this more clear, we can: 1) remove the paragraph, adding a clarification sentence for the reader saying that, due to the nature of the transport, path is not used for dc establishment; and 2) remove all references to cema attribute.

With that, I think mandatory modification of the path is not needed, as it's clear that the address and port parts are not used for dc. It can be added as a way to make it more explicit.


--------------4C8BAEF631815ECA717FCF46
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    

      
On 23/4/19 1:56 PM, Christer Holmberg wrote:   


    

    

      

        
   Since I wrote the original text, I should probably reply...
   
   I agree with Christer that the CEMA attribute is not needed.  It was 
   originally included to make it clear that the path attribute could not 
   be used to establish the data channel.  But this is obvious for this new 
   type of transport.  RFC7977 (WebSocket transport for MSRP) handles this 
   very nicely by using an .invalid domain name in the path attribute.  I 
   suggest adopting this approach for dc.


      

    

    
Would this be a fair summary:

    
- Paragraph in discussion was meant to prevent using path attribute, but that's a moot point for data channel anyway.

    
To make this more clear, we can: 1) remove the paragraph, adding a clarification sentence for the reader saying that, due to the nature of the transport, path is not used for dc establishment; and 2) remove all references to cema attribute.


    
With that, I think mandatory modification of the path is not needed, as it's clear that the address and port parts are not used for dc. It can be added as a way to make it more explicit.



  


--------------4C8BAEF631815ECA717FCF46--


From nobody Thu Apr 25 04:29:36 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6576B1200FE for ; Thu, 25 Apr 2019 04:29:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ch3m4.com header.b=khxYYseU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=8jnq8HLB
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6dLywi0qQhI for ; Thu, 25 Apr 2019 04:29:33 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A5BA120072 for ; Thu, 25 Apr 2019 04:29:33 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id B98A721FED; Thu, 25 Apr 2019 07:29:32 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 25 Apr 2019 07:29:32 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ch3m4.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm3; bh=AE2PSor1ZC7LeiuL8U82fU+n1mp nvBe35Z2SbScu11Q=; b=khxYYseUt0JRCLyi7gfepIYSiXgug7UMWNQGpDLh075 8Ti5jX4nDZ6GUrH/i4403xCZyqupfHRNaqil3S/Fgan3nwJCUsD5htgbpkwVRkwZ o3h6U7Wq0gHrdhHyYqQIs0bNQGc9ceZ5Ottj3I0yvvhcwOX0+ddPp3JTBJfTWujq OK4X9GkFa3/COsQbS0ngx7odN8H+gNU0duZS54Jsz2afS+aYH47NEZ2DjgyICeVt 14CuDYFPOo36Bl9qG/5ODn067f9vv8/Y00pzXSgUSerkCKRR1sgQQxFKe1k2ZcwJ AK/0QK2RF/g5yW4LV0PNfTtIi9jCYHemP8D4kskrrhw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=AE2PSo r1ZC7LeiuL8U82fU+n1mpnvBe35Z2SbScu11Q=; b=8jnq8HLBkHlwdtHo/eKt+9 zSfutgTIldrv3fgxiPZMAhcTV6KdeVdHTSB/8eU9WvLPqs7HNgazKy24U26NUPIM hk69YohETDRJDgsUao2I0LVaIsqEHqCzXvFr7jhr+YKnIRptksYIfgUs+NQz2NXN Tzrmo7VB4+hUFkLjmlh/0cfkguoXWE3J+qAuVuqTjGnxA7iDUVoZjNu7L3q53ElB NZ6sq0a9Ome93/pdrWjN4RZbptYkSpkWz3Hoa8D7blaRPxGqCNPsKr6yHZXPim2G 5S662CQE/VZYUmTgOuaRTL52CiujJoZqOU6RjL0lvs+IMeyF1vwrkPC1speTvLtw ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrheeggdeflecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhffkffgfgggjtgesrgdtreertdefjeenucfhrhhomheplfhoshgvucfo ucftvggtihhouceojhhoshgvsegthhefmhegrdgtohhmqeenucfkphepieeirdeliedrvd dtgedrudegjeenucfrrghrrghmpehmrghilhhfrhhomhepjhhoshgvsegthhefmhegrdgt ohhmnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy:    
Received: from [192.168.1.187] (unknown [66.96.204.147]) by mail.messagingengine.com (Postfix) with ESMTPA id 4E4DBE44D7; Thu, 25 Apr 2019 07:29:31 -0400 (EDT)
To: Christer Holmberg , "mmusic@ietf.org" 
References: <61D3ED98-04FA-4746-BCDE-37BD38907803@ericsson.com>  
From: Jose M Recio 
Message-ID: 
Date: Thu, 25 Apr 2019 19:29:29 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------BEB1D4CE4443D4E85B8FF884"
Content-Language: en-GB
Archived-At: 
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-10.txt - Comment on msrp-cema attribute
X-BeenThere: mmusic@ietf.org
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: Thu, 25 Apr 2019 11:29:36 -0000

This is a multi-part message in MIME format.
--------------BEB1D4CE4443D4E85B8FF884
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 23/4/19 4:32 AM, Christer Holmberg wrote:

> Keep in mind (and that should probably better described in the document) that the normal MSRP routing procedures don't apply. The MSRP messages will be routed in the data channel, which is established between the SIP peers (or whatever signaling protocol is used). I guess proxies and application servers can look at the top-most path attribute, but that is not going to be the primary routing input. I don't think the draft says anything about that - it just seems to assume that the data channel will end up in the intended MSRP peer.

It indeed assumes that the data channel endpoint will be a MSRP peer, 
either another endpoint or a MSRP GW. If that's not clear enough it 
should be made more explicit.

If the endpoint is a GW, messages can be relayed, similar to the 
scenario where the connection to the GW is done using TLS, or 
WebSockets, instead of dc.

--------------BEB1D4CE4443D4E85B8FF884
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    

      
On 23/4/19 4:32 AM, Christer Holmberg wrote:

    

    

      
Keep in mind (and that should probably better described in the document) that the normal MSRP routing procedures don't apply. The MSRP messages will be routed in the data channel, which is established between the SIP peers (or whatever signaling protocol is used). I guess proxies and application servers can look at the top-most path attribute, but that is not going to be the primary routing input. I don't think the draft says anything about that - it just seems to assume that the data channel will end up in the intended MSRP peer.

    

    

    It indeed assumes that the data channel
      endpoint will be a MSRP peer, either another endpoint or a MSRP
      GW. If that's not clear enough it should be made more explicit.

      

    If the endpoint is a GW, messages can be relayed, similar
      to the scenario where the connection to the GW is done using TLS,
      or WebSockets, instead of dc.
  


--------------BEB1D4CE4443D4E85B8FF884--


From nobody Thu Apr 25 18:36:58 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD841201B6 for ; Thu, 25 Apr 2019 18:36:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level: 
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGAneb0H5_IW for ; Thu, 25 Apr 2019 18:36:54 -0700 (PDT)
Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F14A1201BC for ; Thu, 25 Apr 2019 18:36:54 -0700 (PDT)
Received: by mail-pf1-x436.google.com with SMTP id h5so846110pfo.0 for ; Thu, 25 Apr 2019 18:36:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b4OaY+1ajHjd/EVLLe/NAKVCF07AKcXSbeeEiXZXmQI=; b=fSZQebE4PzUYwvnk41Wh3S6IjruV+1nkSYHHjLK1wbMTQxKrsVLuug29wrpq0UU+yh 7HgOhWq3twQ3WQSSZPrqqcIA3hgWY5V3oZRQLd54GeCQxFIYB9eGip8UmGyzZJsDeq12 VQvr7VN2bGItP6t8w08op5+pD6MTY65iF/3GEPJ8AytK8kdThHFJi9a9vCM54U7HqFQA qGt+r64Gi4Y44e4gnsrilDBsH5BvKhqSnVsB/GFX/Gvw2iSeOX/x8n/kqMC1PD/jD3qA KTb+yE14BchJYPRdOmuE70PEH9BQTjhP0YjCa5fe2KV4Er+IrM9O4Q4SRpTLGEdfRkDn sspg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b4OaY+1ajHjd/EVLLe/NAKVCF07AKcXSbeeEiXZXmQI=; b=ZMoNbCph+u5C79zXWjOoIt2wUarU1oZBjHDpvB9+YX0ogSbkaY7ng4CeEoexa1S2f+ VJMVRaUfl4tNgSIuaYEwrG9YyX47ANEHaAeZcPfa3NwZrPjKdC979HfMn+lCU1ueaSCz bd1/yeN6H07tN4uMgUd9CSE25Wf1cwJvE/mXwrr9kV91yySPJ+dJ28jo6soL5lLF8lej R14dYpFGxAmomldUoQ0CtM5+LpZXYc88Zz1xG49yazMCqmZQMAtL8MozW3LPDSh7vINM lErvpo7V5yN5iQdiqmPdjyWr3wFgagDpYsKFgVmrC5dPxIPYq9bPp9t05Sb0n0Cox+R/ pMHA==
X-Gm-Message-State: APjAAAUgmubis6CvFJdD/h7UnN9+hMwc/jJcoDfpgo6MjdiyG/3GNXAp XoAc3142UwxlhLZFVNHHGXbEX4YtT4Q=
X-Google-Smtp-Source: APXvYqwWWPzFfrjwBzEFy4qzeNvzeM9s7m3yi+JhOcMPGfhXaUicK42QJwBE12QigplA7EP4zHbvEg==
X-Received: by 2002:a63:9dc8:: with SMTP id i191mr31135198pgd.91.1556242613351;  Thu, 25 Apr 2019 18:36:53 -0700 (PDT)
Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com. [209.85.210.170]) by smtp.gmail.com with ESMTPSA id z23sm6927683pgu.32.2019.04.25.18.36.51 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Apr 2019 18:36:52 -0700 (PDT)
Received: by mail-pf1-f170.google.com with SMTP id j11so809085pff.13 for ; Thu, 25 Apr 2019 18:36:51 -0700 (PDT)
X-Received: by 2002:aa7:90ca:: with SMTP id k10mr42731372pfk.144.1556242611422;  Thu, 25 Apr 2019 18:36:51 -0700 (PDT)
MIME-Version: 1.0
References:    <3DD3D8D6-9B13-4F9D-80DD-F89B69240708@ericsson.com>   <98CF630B-5CCD-4CE4-84B4-81A4C53979DC@ericsson.com>    <1552A692-1020-43CA-B15E-92595729EE8B@ericsson.com>  <6EA23696-949C-40CF-BEBE-006A59856BDF@ericsson.com>    <5A629925-38A9-43E5-8666-E7100120EFA5@ericsson.com>
In-Reply-To: <5A629925-38A9-43E5-8666-E7100120EFA5@ericsson.com>
From: Roman Shpount 
Date: Thu, 25 Apr 2019 21:36:42 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Christer Holmberg 
Cc: Suhas Nandakumar , Flemming Andreasen , mmusic WG 
Content-Type: multipart/alternative; boundary="00000000000009cafc058764f823"
Archived-At: 
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp
X-BeenThere: mmusic@ietf.org
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: Fri, 26 Apr 2019 01:36:58 -0000

--00000000000009cafc058764f823
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Simon Perreault advised to remove FQDN support from the definition of
connection-address. We are now trying to figure out a way to add FQDN
support back.
_____________
Roman Shpount


On Mon, Apr 22, 2019 at 4:34 AM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
>
>
> The draft contains the following text in the Acknowledgements section:
>
>
>
>    =E2=80=9CThanks to Thomas Stach for text help, Roman Shpount for sugge=
sting
>
>    RTCP candidate handling and *Simon Perreault for advising on IPV6*
>
> *   address selection when candidate-address includes FQDN*.=E2=80=9D
>
>
>
> I am not really sure what =E2=80=9Cadvising on IPv6 address selection=E2=
=80=9D means, and
> I can=E2=80=99t find any text in the draft that would be related to this.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From: *Suhas Nandakumar 
> *Date: *Sunday, 21 April 2019 at 23.24
> *To: *Christer Holmberg 
> *Cc: *Flemming Andreasen , Roman Shpount <
> roman@telurix.com>, "mmusic@ietf.org" 
> *Subject: *Re: [MMUSIC] FQDN support in ice-sip-sdp
>
>
>
> Hi Roman
>
>
>
>    Do you have an ETA on the pull request
>
>
>
> Thanks
>
> Suhas
>
>
>
> On Wed, Apr 17, 2019 at 10:14 PM Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
> Hi Roman,
>
> I think a pull request would be good. Then we have text to look at - no
> matter where it will end up.
>
> I also suggest to try to keep the generic text separated from the SDP
> specifics, so it can easily be moved elsewhere if needed.
>
> Regarding agents that don=E2=80=99t understand the addrtype parameter, pe=
rhaps we
> could define a default IP version of an FDQN returns multiple (unless suc=
h
> default already exists somewhere)? It will of course not help with 5245
> implementations, but at least new implementations will have predicatable
> functionality.
>
> Regards,
>
> Christer
> ------------------------------
>
> *From:* Roman Shpount 
> *Sent:* Wednesday, April 17, 2019 3:17:54 AM
> *To:* Christer Holmberg
> *Cc:* Flemming Andreasen; mmusic WG
> *Subject:* Re: [MMUSIC] FQDN support in ice-sip-sdp
>
>
>
> Hi,
>
>
>
> On Mon, Apr 15, 2019 at 4:13 AM Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
> >> 1) An ICE agent that uses FQDN needs to provide one candidate per
> address family, and indicate the addrtype for each of those candidates.
> >> 2) Some text regarding backward compatibility. Do we assume some
> default behavior by existing implementations, or do we require an ICE
> option?
> >
> > I do not think we need an ICE option. I think presence of addrtype can
> be sufficient.
>
> But if the peer ICE agent does not support it, and the FQDN resolves into
> both IPv4 and IPv6, we don't know what version it will use.
>
>
>
> I do not think adding ICE option will help. Unsupported ICE options are
> simply ignored so we end up not knowing what address remote agent is usin=
g.
> Unfortunately FQDN was not well defined in RFC 5245. "Fortunately" I have
> not seen anybody actually implementing FQDN In the worst case ICE
> nomination fails.  This is no different then having no connectivity for
> this specific candidate. Also, if FQDN handling is part of ice-sip-sdp,
> then agent should already include ice2 option.
>
>
>
> > This being said we need to decide two things:
> >
> > 1. Does FQDN resolution belongs to ICE processing? In this case
> candidate list includes FQDN with address type and ICE processing describ=
es
> how FQDN are resolved and converted to addresses.
> > Or, alternatively, does FQDN resolution belongs to ICE signaling? In
> this case candidate list includes resolved address and ICE agent deals wi=
th
> addresses only.
>
> That would not work with mDNS, right?
>
> > 2. Do we specify how to deal with FQDN in ice-sip-sdp or do we specify
> in ice-sip-sdp that FQDN must be ignored and their handling is defined in
> some other draft?
>
> Perhaps the best thing would simply to produce a separate draft, to get
> some text. We can then decide whether to merge it into ice-sip-sdp.
>
>
>
> I can probably describe this in ice-sip-sdp in about 3 paragraphs. The
> background and other text for a new draft will make is much bigger effort=
.
> How about I put together a pull request for ice-sip-sdp and then we can
> decide if this requires a new draft?
>
>
>
> Regards,
>
> ______________
>
> Roman Shpount
>
>
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

--00000000000009cafc058764f823
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Simon Perreault advised to remove FQDN su=
pport from the definition of connection-address. We are now trying to figur=
e out a way to add FQDN support back.
_____________
Roman Shpount

<=
/div>

On Mon, Apr 22, 2019 at 4:34 AM Christer Holmberg <christer.holmberg@ericsson.com> wr=
ote:











Hi,


=C2=A0


The draft contains the followin=
g text in the Acknowledgements section:


=C2=A0


=C2=A0=C2=A0 =E2=80=9CThanks to T=
homas Stach for text help, Roman Shpount for suggesting


=C2=A0=C2=A0 RTCP candidate handl=
ing and
Simon Perreault for advising on IPV6


=C2=A0=C2=A0 address selection=
 when candidate-address includes FQDN.=E2=80=
=9D


=C2=A0


I am not really sure what =E2=
=80=9Cadvising on IPv6 address selection=E2=80=9D means, and I can=E2=80=99=
t find any text in the draft that would be related to this.



=C2=A0


Regards,

=C2=A0


Christer

=C2=A0




From: =
Suhas Nandakumar <=
suhasietf@gmail.co=
m>

Date: Sunday, 21 April 2019 at 23.24

To: Christer Holmberg <christer.holmberg@ericsson.com>

Cc: Flemming Andreasen <fandreas@cisco.com>, Roman Shpount <roman@telurix.com>, "<=
a href=3D"mailto:mmusic@ietf.org" target=3D"_blank">mmusic@ietf.org&quo=
t; <mmusic@ietf.org=
>

Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp






=C2=A0








Hi Roman






=C2=A0






=C2=A0 =C2=A0Do you have an ETA on the pull request<=
u>






=C2=A0






Thanks






Suhas




=C2=A0






On Wed, Apr 17, 2019 at 10:14 PM Christer Holmberg &=
lt;chri=
ster.holmberg@ericsson.com> wrote:








Hi Roman,



I think a pull request would be good. Then we have text to look at - no mat=
ter where it will end up.



I also suggest to try to keep the generic text separated from the SDP speci=
fics, so it can easily be moved elsewhere if needed.



Regarding agents that don=E2=80=99t understand the addrtype parameter, perh=
aps we could define a default IP version of an FDQN returns multiple (unles=
s such default already exists somewhere)? It will of course not help with 5=
245 implementations, but at least new implementations
 will have predicatable functionality.



Regards,



Christer










From: Roman Shpount <roman@telurix.com>

Sent: Wednesday, April 17, 2019 3:17:54 AM

To: Christer Holmberg

Cc: Flemming Andreasen; mmusic WG

Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp <=
/u>




=C2=A0












Hi,








=C2=A0












On Mon, Apr 15, 2019 at 4:13 AM Christer Holmberg &l=
t;chris=
ter.holmberg@ericsson.com> wrote:






>> 1) An ICE agent that uses FQDN needs to pro=
vide one candidate per address family, and indicate the addrtype for each o=
f those candidates.

>> 2) Some text regarding backward compatibility. Do we assume some d=
efault behavior by existing implementations, or do we require an ICE option=
?

>

> I do not think we need an ICE option. I think presence of addrtype can=
 be sufficient.



But if the peer ICE agent does not support it, and the FQDN resolves into b=
oth IPv4 and IPv6, we don't know what version it will use.






=C2=A0






I do not think adding ICE option will help. Unsuppor=
ted ICE options are simply ignored so we end up not knowing what address re=
mote agent is using. Unfortunately FQDN was not well defined in RFC 5245. &=
quot;Fortunately" I have not seen anybody
 actually implementing FQDN In the worst case ICE nomination fails.=C2=A0 T=
his is no different then having no connectivity for this specific candidate=
. Also, if FQDN handling is part of ice-sip-sdp, then agent should already =
include ice2 option.






















=C2=A0






> This being said we need to decide two things:
>

> 1. Does FQDN resolution belongs to ICE processing? In this case candid=
ate list includes FQDN with address type and ICE processing describes how F=
QDN are resolved and converted to addresses.


> Or, alternatively, does FQDN resolution belongs to ICE signaling? In t=
his case candidate list includes resolved address and ICE agent deals with =
addresses only.



That would not work with mDNS, right?



> 2. Do we specify how to deal with FQDN in ice-sip-sdp or do we specify=
 in ice-sip-sdp that FQDN must be ignored and their handling is defined in =
some other draft?



Perhaps the best thing would simply to produce a separate draft, to get som=
e text. We can then decide whether to merge it into ice-sip-sdp.<=
/u>






=C2=A0






I can probably describe this in ice-sip-sdp in about=
 3 paragraphs. The background and other text for a new draft will make is m=
uch bigger effort. How about I put together a pull request for ice-sip-sdp =
and then we can decide if this requires
 a new draft?






=C2=A0






Regards,






______________






Roman Shpount






=C2=A0






=C2=A0












_______________________________________________

mmusic mailing list

mmusic@ietf.org
=
https://www.ietf.org/mailman/listinfo/mmusic















--00000000000009cafc058764f823--


From nobody Fri Apr 26 00:02:39 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE8712008C for ; Fri, 26 Apr 2019 00:02:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHThT53WuyGk for ; Fri, 26 Apr 2019 00:02:34 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60076.outbound.protection.outlook.com [40.107.6.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611E8120182 for ; Fri, 26 Apr 2019 00:02:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xbSP2fe8aOdcXlHkix75G3l0zKRYPtn4Vl7NyqH6T5k=; b=Byuy1QoyeeYlNMdOYDk2wHnzhhpcWskDA03I+ypJECSqVYrvGXJA0GQj480cFRySF5WTZRWLllxxujoujU8EmDKfsdzsseFrVz1W/0GXbCzTbWW6gewF+Ook6uxAzE0tB7qUMIM+mQqLDbU3rp0LOcm6GQGKt/qqwyL9KVyTpXo=
Received: from VI1PR07MB3167.eurprd07.prod.outlook.com (10.175.243.17) by VI1PR07MB5536.eurprd07.prod.outlook.com (20.178.15.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.5; Fri, 26 Apr 2019 07:02:30 +0000
Received: from VI1PR07MB3167.eurprd07.prod.outlook.com ([fe80::d925:d8b5:d1df:4706]) by VI1PR07MB3167.eurprd07.prod.outlook.com ([fe80::d925:d8b5:d1df:4706%4]) with mapi id 15.20.1856.004; Fri, 26 Apr 2019 07:02:30 +0000
From: Christer Holmberg 
To: Roman Shpount 
CC: Suhas Nandakumar , Flemming Andreasen , mmusic WG 
Thread-Topic: [MMUSIC] FQDN support in ice-sip-sdp
Thread-Index: AQHU6jzz/50YAJx2kEqY4siuQ2NZYqY0606AgADVT4CAAEAVAP//1AeAgADQ14CAAETnAIAAnHWAgAD8QQCAAGHdAIACtQAAgACv5gCAANoNAIACbYkAgAHj6piABbaIAIAA/iQAgAWiagCAAI1QgA==
Date: Fri, 26 Apr 2019 07:02:30 +0000
Message-ID: <52CE9A69-B709-41CD-9BE8-A59EE44D55A7@ericsson.com>
References:    <3DD3D8D6-9B13-4F9D-80DD-F89B69240708@ericsson.com>   <98CF630B-5CCD-4CE4-84B4-81A4C53979DC@ericsson.com>    <1552A692-1020-43CA-B15E-92595729EE8B@ericsson.com>  <6EA23696-949C-40CF-BEBE-006A59856BDF@ericsson.com>    <5A629925-38A9-43E5-8666-E7100120EFA5@ericsson.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.18.0.190414
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-originating-ip: [89.166.49.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f9ae2e52-5cfc-4378-a75c-08d6ca152643
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB5536; 
x-ms-traffictypediagnostic: VI1PR07MB5536:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: 
x-forefront-prvs: 001968DD50
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(396003)(39860400002)(346002)(366004)(189003)(199004)(76116006)(6116002)(71200400001)(76176011)(97736004)(91956017)(6436002)(14454004)(7736002)(11346002)(446003)(5660300002)(36756003)(2616005)(82746002)(73956011)(966005)(2906002)(4326008)(478600001)(66946007)(66446008)(66476007)(99286004)(58126008)(790700001)(6916009)(54906003)(71190400001)(64756008)(66556008)(5070765005)(316002)(486006)(81166006)(14444005)(68736007)(6506007)(81156014)(8936002)(8676002)(86362001)(3846002)(102836004)(53546011)(25786009)(517774005)(26005)(44832011)(66066001)(6512007)(476003)(6306002)(54896002)(606006)(236005)(186003)(440504004)(53936002)(229853002)(93886005)(33656002)(6246003)(83716004)(256004)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB5536; H:VI1PR07MB3167.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: +/TJIQwQTr4IQu31ktEHbLq4oouIY62iUbSHlCWoLfgIRKhUepogYoU2iicCZwcyYufCnx9KliTXiYrvqfC1joMsIJwXYjq+hLbccK1SUzNX2kLerGHQ1VMqPvhpcPOcfcvNC7/6m+Oih0aYtH3IXmW31cmK98c5tf1xbOZzupK7H31WuZjpxkiKhwRFG6gDw98QVTfAktkkykO7AZr69ZW48VKKUR5Aq4NNxsuq6xvV8VeR3cttfKDQdE7rmwH7PFbLcB2R8QAWAn4YJLU+inheELxnWkwGIJ1WUBweXDqBiWVmIx7MZ7YFdEbI3AmX/qXaLX1RUzFHniJx/7yXCAx2FbmcMCq/JRZVJmqgzpMg+OkPe5FydvzS6+4fMmmkuBADnl+gy+mP4wbNWrX1ZJpBbAuGBc+4qXAq09odH0A=
Content-Type: multipart/alternative; boundary="_000_52CE9A69B70941CD9BE8A59EE44D55A7ericssoncom_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f9ae2e52-5cfc-4378-a75c-08d6ca152643
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2019 07:02:30.3446 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5536
Archived-At: 
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp
X-BeenThere: mmusic@ietf.org
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: Fri, 26 Apr 2019 07:02:38 -0000

--_000_52CE9A69B70941CD9BE8A59EE44D55A7ericssoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGksDQoNCj5TaW1vbiBQZXJyZWF1bHQgYWR2aXNlZCB0byByZW1vdmUgRlFETiBzdXBwb3J0IGZy
b20gdGhlIGRlZmluaXRpb24gb2YgY29ubmVjdGlvbi1hZGRyZXNzLiBXZSBhcmUgbm93IHRyeWlu
ZyB0byBmaWd1cmUgb3V0IGEgd2F5IHRvIGFkZCBGUUROIHN1cHBvcnQgYmFjay4NClBlcmhhcHMg
dGhlIHRleHQgc2hvdWxkIHRoZW4gc2F5IHNvbWV0aGluZyBsaWtlIOKAnGZvciBhZHZpc2luZyBv
biB1c2FnZSBvZiBGUUROIGluIHRoZSBjYW5kaWRhdGUtYWRkcmVzc+KAnSwgb3Igc29tZXRoaW5n
IGxpa2UgdGhhdC4g4oCcQWRkcmVzcyBzZWxlY3Rpb27igJ0gc291bmRzIGNvbmZ1c2luZy4NCg0K
UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoN
Cg0KT24gTW9uLCBBcHIgMjIsIDIwMTkgYXQgNDozNCBBTSBDaHJpc3RlciBIb2xtYmVyZyA8Y2hy
aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj
c3Nvbi5jb20+PiB3cm90ZToNCkhpLA0KDQpUaGUgZHJhZnQgY29udGFpbnMgdGhlIGZvbGxvd2lu
ZyB0ZXh0IGluIHRoZSBBY2tub3dsZWRnZW1lbnRzIHNlY3Rpb246DQoNCiAgIOKAnFRoYW5rcyB0
byBUaG9tYXMgU3RhY2ggZm9yIHRleHQgaGVscCwgUm9tYW4gU2hwb3VudCBmb3Igc3VnZ2VzdGlu
Zw0KICAgUlRDUCBjYW5kaWRhdGUgaGFuZGxpbmcgYW5kIFNpbW9uIFBlcnJlYXVsdCBmb3IgYWR2
aXNpbmcgb24gSVBWNg0KICAgYWRkcmVzcyBzZWxlY3Rpb24gd2hlbiBjYW5kaWRhdGUtYWRkcmVz
cyBpbmNsdWRlcyBGUUROLuKAnQ0KDQpJIGFtIG5vdCByZWFsbHkgc3VyZSB3aGF0IOKAnGFkdmlz
aW5nIG9uIElQdjYgYWRkcmVzcyBzZWxlY3Rpb27igJ0gbWVhbnMsIGFuZCBJIGNhbuKAmXQgZmlu
ZCBhbnkgdGV4dCBpbiB0aGUgZHJhZnQgdGhhdCB3b3VsZCBiZSByZWxhdGVkIHRvIHRoaXMuDQoN
ClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IFN1aGFzIE5hbmRha3VtYXIgPHN1aGFzaWV0
ZkBnbWFpbC5jb208bWFpbHRvOnN1aGFzaWV0ZkBnbWFpbC5jb20+Pg0KRGF0ZTogU3VuZGF5LCAy
MSBBcHJpbCAyMDE5IGF0IDIzLjI0DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhv
bG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t
Pj4NCkNjOiBGbGVtbWluZyBBbmRyZWFzZW4gPGZhbmRyZWFzQGNpc2NvLmNvbTxtYWlsdG86ZmFu
ZHJlYXNAY2lzY28uY29tPj4sIFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPG1haWx0
bzpyb21hbkB0ZWx1cml4LmNvbT4+LCAibW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0
Zi5vcmc+IiA8bW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+Pg0KU3ViamVj
dDogUmU6IFtNTVVTSUNdIEZRRE4gc3VwcG9ydCBpbiBpY2Utc2lwLXNkcA0KDQpIaSBSb21hbg0K
DQogICBEbyB5b3UgaGF2ZSBhbiBFVEEgb24gdGhlIHB1bGwgcmVxdWVzdA0KDQpUaGFua3MNClN1
aGFzDQoNCk9uIFdlZCwgQXByIDE3LCAyMDE5IGF0IDEwOjE0IFBNIENocmlzdGVyIEhvbG1iZXJn
IDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJn
QGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGkgUm9tYW4sDQoNCkkgdGhpbmsgYSBwdWxsIHJlcXVl
c3Qgd291bGQgYmUgZ29vZC4gVGhlbiB3ZSBoYXZlIHRleHQgdG8gbG9vayBhdCAtIG5vIG1hdHRl
ciB3aGVyZSBpdCB3aWxsIGVuZCB1cC4NCg0KSSBhbHNvIHN1Z2dlc3QgdG8gdHJ5IHRvIGtlZXAg
dGhlIGdlbmVyaWMgdGV4dCBzZXBhcmF0ZWQgZnJvbSB0aGUgU0RQIHNwZWNpZmljcywgc28gaXQg
Y2FuIGVhc2lseSBiZSBtb3ZlZCBlbHNld2hlcmUgaWYgbmVlZGVkLg0KDQpSZWdhcmRpbmcgYWdl
bnRzIHRoYXQgZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSBhZGRydHlwZSBwYXJhbWV0ZXIsIHBlcmhh
cHMgd2UgY291bGQgZGVmaW5lIGEgZGVmYXVsdCBJUCB2ZXJzaW9uIG9mIGFuIEZEUU4gcmV0dXJu
cyBtdWx0aXBsZSAodW5sZXNzIHN1Y2ggZGVmYXVsdCBhbHJlYWR5IGV4aXN0cyBzb21ld2hlcmUp
PyBJdCB3aWxsIG9mIGNvdXJzZSBub3QgaGVscCB3aXRoIDUyNDUgaW1wbGVtZW50YXRpb25zLCBi
dXQgYXQgbGVhc3QgbmV3IGltcGxlbWVudGF0aW9ucyB3aWxsIGhhdmUgcHJlZGljYXRhYmxlIGZ1
bmN0aW9uYWxpdHkuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KRnJvbTogUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb208bWFp
bHRvOnJvbWFuQHRlbHVyaXguY29tPj4NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTcsIDIwMTkg
MzoxNzo1NCBBTQ0KVG86IENocmlzdGVyIEhvbG1iZXJnDQpDYzogRmxlbW1pbmcgQW5kcmVhc2Vu
OyBtbXVzaWMgV0cNClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBGUUROIHN1cHBvcnQgaW4gaWNlLXNp
cC1zZHANCg0KSGksDQoNCk9uIE1vbiwgQXByIDE1LCAyMDE5IGF0IDQ6MTMgQU0gQ2hyaXN0ZXIg
SG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIu
aG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQo+PiAxKSBBbiBJQ0UgYWdlbnQgdGhhdCB1
c2VzIEZRRE4gbmVlZHMgdG8gcHJvdmlkZSBvbmUgY2FuZGlkYXRlIHBlciBhZGRyZXNzIGZhbWls
eSwgYW5kIGluZGljYXRlIHRoZSBhZGRydHlwZSBmb3IgZWFjaCBvZiB0aG9zZSBjYW5kaWRhdGVz
Lg0KPj4gMikgU29tZSB0ZXh0IHJlZ2FyZGluZyBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LiBEbyB3
ZSBhc3N1bWUgc29tZSBkZWZhdWx0IGJlaGF2aW9yIGJ5IGV4aXN0aW5nIGltcGxlbWVudGF0aW9u
cywgb3IgZG8gd2UgcmVxdWlyZSBhbiBJQ0Ugb3B0aW9uPw0KPg0KPiBJIGRvIG5vdCB0aGluayB3
ZSBuZWVkIGFuIElDRSBvcHRpb24uIEkgdGhpbmsgcHJlc2VuY2Ugb2YgYWRkcnR5cGUgY2FuIGJl
IHN1ZmZpY2llbnQuDQoNCkJ1dCBpZiB0aGUgcGVlciBJQ0UgYWdlbnQgZG9lcyBub3Qgc3VwcG9y
dCBpdCwgYW5kIHRoZSBGUUROIHJlc29sdmVzIGludG8gYm90aCBJUHY0IGFuZCBJUHY2LCB3ZSBk
b24ndCBrbm93IHdoYXQgdmVyc2lvbiBpdCB3aWxsIHVzZS4NCg0KSSBkbyBub3QgdGhpbmsgYWRk
aW5nIElDRSBvcHRpb24gd2lsbCBoZWxwLiBVbnN1cHBvcnRlZCBJQ0Ugb3B0aW9ucyBhcmUgc2lt
cGx5IGlnbm9yZWQgc28gd2UgZW5kIHVwIG5vdCBrbm93aW5nIHdoYXQgYWRkcmVzcyByZW1vdGUg
YWdlbnQgaXMgdXNpbmcuIFVuZm9ydHVuYXRlbHkgRlFETiB3YXMgbm90IHdlbGwgZGVmaW5lZCBp
biBSRkMgNTI0NS4gIkZvcnR1bmF0ZWx5IiBJIGhhdmUgbm90IHNlZW4gYW55Ym9keSBhY3R1YWxs
eSBpbXBsZW1lbnRpbmcgRlFETiBJbiB0aGUgd29yc3QgY2FzZSBJQ0Ugbm9taW5hdGlvbiBmYWls
cy4gIFRoaXMgaXMgbm8gZGlmZmVyZW50IHRoZW4gaGF2aW5nIG5vIGNvbm5lY3Rpdml0eSBmb3Ig
dGhpcyBzcGVjaWZpYyBjYW5kaWRhdGUuIEFsc28sIGlmIEZRRE4gaGFuZGxpbmcgaXMgcGFydCBv
ZiBpY2Utc2lwLXNkcCwgdGhlbiBhZ2VudCBzaG91bGQgYWxyZWFkeSBpbmNsdWRlIGljZTIgb3B0
aW9uLg0KDQo+IFRoaXMgYmVpbmcgc2FpZCB3ZSBuZWVkIHRvIGRlY2lkZSB0d28gdGhpbmdzOg0K
Pg0KPiAxLiBEb2VzIEZRRE4gcmVzb2x1dGlvbiBiZWxvbmdzIHRvIElDRSBwcm9jZXNzaW5nPyBJ
biB0aGlzIGNhc2UgY2FuZGlkYXRlIGxpc3QgaW5jbHVkZXMgRlFETiB3aXRoIGFkZHJlc3MgdHlw
ZSBhbmQgSUNFIHByb2Nlc3NpbmcgZGVzY3JpYmVzIGhvdyBGUUROIGFyZSByZXNvbHZlZCBhbmQg
Y29udmVydGVkIHRvIGFkZHJlc3Nlcy4NCj4gT3IsIGFsdGVybmF0aXZlbHksIGRvZXMgRlFETiBy
ZXNvbHV0aW9uIGJlbG9uZ3MgdG8gSUNFIHNpZ25hbGluZz8gSW4gdGhpcyBjYXNlIGNhbmRpZGF0
ZSBsaXN0IGluY2x1ZGVzIHJlc29sdmVkIGFkZHJlc3MgYW5kIElDRSBhZ2VudCBkZWFscyB3aXRo
IGFkZHJlc3NlcyBvbmx5Lg0KDQpUaGF0IHdvdWxkIG5vdCB3b3JrIHdpdGggbUROUywgcmlnaHQ/
DQoNCj4gMi4gRG8gd2Ugc3BlY2lmeSBob3cgdG8gZGVhbCB3aXRoIEZRRE4gaW4gaWNlLXNpcC1z
ZHAgb3IgZG8gd2Ugc3BlY2lmeSBpbiBpY2Utc2lwLXNkcCB0aGF0IEZRRE4gbXVzdCBiZSBpZ25v
cmVkIGFuZCB0aGVpciBoYW5kbGluZyBpcyBkZWZpbmVkIGluIHNvbWUgb3RoZXIgZHJhZnQ/DQoN
ClBlcmhhcHMgdGhlIGJlc3QgdGhpbmcgd291bGQgc2ltcGx5IHRvIHByb2R1Y2UgYSBzZXBhcmF0
ZSBkcmFmdCwgdG8gZ2V0IHNvbWUgdGV4dC4gV2UgY2FuIHRoZW4gZGVjaWRlIHdoZXRoZXIgdG8g
bWVyZ2UgaXQgaW50byBpY2Utc2lwLXNkcC4NCg0KSSBjYW4gcHJvYmFibHkgZGVzY3JpYmUgdGhp
cyBpbiBpY2Utc2lwLXNkcCBpbiBhYm91dCAzIHBhcmFncmFwaHMuIFRoZSBiYWNrZ3JvdW5kIGFu
ZCBvdGhlciB0ZXh0IGZvciBhIG5ldyBkcmFmdCB3aWxsIG1ha2UgaXMgbXVjaCBiaWdnZXIgZWZm
b3J0LiBIb3cgYWJvdXQgSSBwdXQgdG9nZXRoZXIgYSBwdWxsIHJlcXVlc3QgZm9yIGljZS1zaXAt
c2RwIGFuZCB0aGVuIHdlIGNhbiBkZWNpZGUgaWYgdGhpcyByZXF1aXJlcyBhIG5ldyBkcmFmdD8N
Cg0KUmVnYXJkcywNCl9fX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxp
c3QNCm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg==

--_000_52CE9A69B70941CD9BE8A59EE44D55A7ericssoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <547E1535D437DB40BEED0767A8AA4DF4@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg
MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg
MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h
bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv
dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6
dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29u
b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt
c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsN
Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1z
aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVt
YWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh
dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K
QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44
NXB0IDIuMGNtIDcwLjg1cHQgMi4wY207fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT
ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk
ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t
PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K
PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+
PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGSSIgbGluaz0iYmx1ZSIgdmxpbms9
InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+SGksPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDtTaW1vbiBQZXJyZWF1bHQgYWR2aXNlZCB0byByZW1v
dmUgRlFETiBzdXBwb3J0IGZyb20gdGhlIGRlZmluaXRpb24gb2YgY29ubmVjdGlvbi1hZGRyZXNz
Lg0KPC9zcGFuPldlIGFyZSBub3cgdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgYSB3YXkgdG8gYWRkIEZR
RE4gc3VwcG9ydCBiYWNrLjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlBlcmhhcHMgdGhlIHRleHQgc2hvdWxk
IHRoZW4gc2F5IHNvbWV0aGluZyBsaWtlIOKAnGZvciBhZHZpc2luZyBvbiB1c2FnZSBvZiBGUURO
IGluIHRoZSBjYW5kaWRhdGUtYWRkcmVzc+KAnSwgb3Igc29tZXRoaW5nIGxpa2UgdGhhdC4g4oCc
QWRkcmVzcyBzZWxlY3Rpb27igJ0gc291bmRzIGNvbmZ1c2luZy48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
PlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5fX19fX19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3VudDxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEFwciAyMiwg
MjAxOSBhdCA0OjM0IEFNIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hy
aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j
b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow
Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgZHJhZnQgY29udGFpbnMgdGhlIGZvbGxv
d2luZyB0ZXh0IGluIHRoZSBBY2tub3dsZWRnZW1lbnRzIHNlY3Rpb246PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyDigJxUaGFua3MgdG8gVGhvbWFz
IFN0YWNoIGZvciB0ZXh0IGhlbHAsIFJvbWFuIFNocG91bnQgZm9yIHN1Z2dlc3Rpbmc8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFJUQ1AgY2FuZGlkYXRlIGhhbmRsaW5nIGFu
ZA0KPGI+U2ltb24gUGVycmVhdWx0IGZvciBhZHZpc2luZyBvbiBJUFY2PC9iPjwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYWRkcmVzcyBzZWxlY3Rpb24gd2hlbiBjYW5k
aWRhdGUtYWRkcmVzcyBpbmNsdWRlcyBGUUROPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv
dDs7Y29sb3I6YmxhY2siPi7igJ08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGFtIG5vdCByZWFs
bHkgc3VyZSB3aGF0IOKAnGFkdmlzaW5nIG9uIElQdjYgYWRkcmVzcyBzZWxlY3Rpb27igJ0gbWVh
bnMsIGFuZCBJIGNhbuKAmXQgZmluZCBhbnkgdGV4dCBpbiB0aGUgZHJhZnQgdGhhdCB3b3VsZCBi
ZSByZWxhdGVkIHRvIHRoaXMuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRzLDwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t
VVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gbGFuZz0iRU4tVVMiPkNocmlzdGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG
IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwv
c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlN1aGFz
IE5hbmRha3VtYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpzdWhhc2lldGZAZ21haWwuY29tIiB0YXJn
ZXQ9Il9ibGFuayI+c3VoYXNpZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9i
PlN1bmRheSwgMjEgQXByaWwgMjAxOSBhdCAyMy4yNDxicj4NCjxiPlRvOiA8L2I+Q2hyaXN0ZXIg
SG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j
b20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0
Ozxicj4NCjxiPkNjOiA8L2I+RmxlbW1pbmcgQW5kcmVhc2VuICZsdDs8YSBocmVmPSJtYWlsdG86
ZmFuZHJlYXNAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZmFuZHJlYXNAY2lzY28uY29tPC9h
PiZndDssIFJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNv
bSIgdGFyZ2V0PSJfYmxhbmsiPnJvbWFuQHRlbHVyaXguY29tPC9hPiZndDssICZxdW90OzxhIGhy
ZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tbXVzaWNAaWV0Zi5v
cmc8L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciIHRhcmdl
dD0iX2JsYW5rIj5tbXVzaWNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5S
ZTogW01NVVNJQ10gRlFETiBzdXBwb3J0IGluIGljZS1zaXAtc2RwPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhp
IFJvbWFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDsgJm5ic3A7RG8geW91IGhhdmUgYW4gRVRBIG9uIHRoZSBwdWxsIHJlcXVl
c3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPlRoYW5rczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj5TdWhhczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPk9uIFdlZCwgQXByIDE3LCAyMDE5IGF0IDEwOjE0IFBNIENocmlzdGVyIEhvbG1iZXJn
ICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJn
ZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti
b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7
bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgUm9tYW4s
PGJyPg0KPGJyPg0KSSB0aGluayBhIHB1bGwgcmVxdWVzdCB3b3VsZCBiZSBnb29kLiBUaGVuIHdl
IGhhdmUgdGV4dCB0byBsb29rIGF0IC0gbm8gbWF0dGVyIHdoZXJlIGl0IHdpbGwgZW5kIHVwLjxi
cj4NCjxicj4NCkkgYWxzbyBzdWdnZXN0IHRvIHRyeSB0byBrZWVwIHRoZSBnZW5lcmljIHRleHQg
c2VwYXJhdGVkIGZyb20gdGhlIFNEUCBzcGVjaWZpY3MsIHNvIGl0IGNhbiBlYXNpbHkgYmUgbW92
ZWQgZWxzZXdoZXJlIGlmIG5lZWRlZC48YnI+DQo8YnI+DQpSZWdhcmRpbmcgYWdlbnRzIHRoYXQg
ZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSBhZGRydHlwZSBwYXJhbWV0ZXIsIHBlcmhhcHMgd2UgY291
bGQgZGVmaW5lIGEgZGVmYXVsdCBJUCB2ZXJzaW9uIG9mIGFuIEZEUU4gcmV0dXJucyBtdWx0aXBs
ZSAodW5sZXNzIHN1Y2ggZGVmYXVsdCBhbHJlYWR5IGV4aXN0cyBzb21ld2hlcmUpPyBJdCB3aWxs
IG9mIGNvdXJzZSBub3QgaGVscCB3aXRoIDUyNDUgaW1wbGVtZW50YXRpb25zLCBidXQgYXQgbGVh
c3QgbmV3IGltcGxlbWVudGF0aW9ucw0KIHdpbGwgaGF2ZSBwcmVkaWNhdGFibGUgZnVuY3Rpb25h
bGl0eS48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVyPG86cD48L286cD48
L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFs
aWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMCIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0K
PC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXy0yMzUxMzY3MDQ1NDg0MzM4NjI4bV80ODE1NDAyOTYx
NTI2NzAyOTUwZGl2UnBseUZ3ZE1zZyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFu
IHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpi
bGFjayI+IFJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNv
bSIgdGFyZ2V0PSJfYmxhbmsiPnJvbWFuQHRlbHVyaXguY29tPC9hPiZndDs8YnI+DQo8Yj5TZW50
OjwvYj4gV2VkbmVzZGF5LCBBcHJpbCAxNywgMjAxOSAzOjE3OjU0IEFNPGJyPg0KPGI+VG86PC9i
PiBDaHJpc3RlciBIb2xtYmVyZzxicj4NCjxiPkNjOjwvYj4gRmxlbW1pbmcgQW5kcmVhc2VuOyBt
bXVzaWMgV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtNTVVTSUNdIEZRRE4gc3VwcG9ydCBp
biBpY2Utc2lwLXNkcDwvc3Bhbj4gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpLDxiciBjbGVhcj0iYWxsIj4N
CjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIE1vbiwgQXByIDE1LCAyMDE5IGF0IDQ6MTMgQU0g
Q2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Bl
cmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j
b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow
Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PiZndDsmZ3Q7IDEpIEFuIElDRSBhZ2VudCB0aGF0IHVzZXMgRlFETiBuZWVkcyB0byBwcm92aWRl
IG9uZSBjYW5kaWRhdGUgcGVyIGFkZHJlc3MgZmFtaWx5LCBhbmQgaW5kaWNhdGUgdGhlIGFkZHJ0
eXBlIGZvciBlYWNoIG9mIHRob3NlIGNhbmRpZGF0ZXMuPGJyPg0KJmd0OyZndDsgMikgU29tZSB0
ZXh0IHJlZ2FyZGluZyBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LiBEbyB3ZSBhc3N1bWUgc29tZSBk
ZWZhdWx0IGJlaGF2aW9yIGJ5IGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucywgb3IgZG8gd2UgcmVx
dWlyZSBhbiBJQ0Ugb3B0aW9uPzxicj4NCiZndDs8YnI+DQomZ3Q7IEkgZG8gbm90IHRoaW5rIHdl
IG5lZWQgYW4gSUNFIG9wdGlvbi4gSSB0aGluayBwcmVzZW5jZSBvZiBhZGRydHlwZSBjYW4gYmUg
c3VmZmljaWVudC48YnI+DQo8YnI+DQpCdXQgaWYgdGhlIHBlZXIgSUNFIGFnZW50IGRvZXMgbm90
IHN1cHBvcnQgaXQsIGFuZCB0aGUgRlFETiByZXNvbHZlcyBpbnRvIGJvdGggSVB2NCBhbmQgSVB2
Niwgd2UgZG9uJ3Qga25vdyB3aGF0IHZlcnNpb24gaXQgd2lsbCB1c2UuPG86cD48L286cD48L3A+
DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBkbyBu
b3QgdGhpbmsgYWRkaW5nIElDRSBvcHRpb24gd2lsbCBoZWxwLiBVbnN1cHBvcnRlZCBJQ0Ugb3B0
aW9ucyBhcmUgc2ltcGx5IGlnbm9yZWQgc28gd2UgZW5kIHVwIG5vdCBrbm93aW5nIHdoYXQgYWRk
cmVzcyByZW1vdGUgYWdlbnQgaXMgdXNpbmcuIFVuZm9ydHVuYXRlbHkgRlFETiB3YXMgbm90IHdl
bGwNCiBkZWZpbmVkIGluIFJGQyA1MjQ1LiAmcXVvdDtGb3J0dW5hdGVseSZxdW90OyBJIGhhdmUg
bm90IHNlZW4gYW55Ym9keSBhY3R1YWxseSBpbXBsZW1lbnRpbmcgRlFETiBJbiB0aGUgd29yc3Qg
Y2FzZSBJQ0Ugbm9taW5hdGlvbiBmYWlscy4mbmJzcDsgVGhpcyBpcyBubyBkaWZmZXJlbnQgdGhl
biBoYXZpbmcgbm8gY29ubmVjdGl2aXR5IGZvciB0aGlzIHNwZWNpZmljIGNhbmRpZGF0ZS4gQWxz
bywgaWYgRlFETiBoYW5kbGluZyBpcyBwYXJ0IG9mIGljZS1zaXAtc2RwLCB0aGVuDQogYWdlbnQg
c2hvdWxkIGFscmVhZHkgaW5jbHVkZSBpY2UyIG9wdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp
ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44
cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQi
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mZ3Q7IFRoaXMgYmVpbmcgc2FpZCB3ZSBuZWVkIHRv
IGRlY2lkZSB0d28gdGhpbmdzOjxicj4NCiZndDs8YnI+DQomZ3Q7IDEuIERvZXMgRlFETiByZXNv
bHV0aW9uIGJlbG9uZ3MgdG8gSUNFIHByb2Nlc3Npbmc/IEluIHRoaXMgY2FzZSBjYW5kaWRhdGUg
bGlzdCBpbmNsdWRlcyBGUUROIHdpdGggYWRkcmVzcyB0eXBlIGFuZCBJQ0UgcHJvY2Vzc2luZyBk
ZXNjcmliZXMgaG93IEZRRE4gYXJlIHJlc29sdmVkIGFuZCBjb252ZXJ0ZWQgdG8gYWRkcmVzc2Vz
Lg0KPGJyPg0KJmd0OyBPciwgYWx0ZXJuYXRpdmVseSwgZG9lcyBGUUROIHJlc29sdXRpb24gYmVs
b25ncyB0byBJQ0Ugc2lnbmFsaW5nPyBJbiB0aGlzIGNhc2UgY2FuZGlkYXRlIGxpc3QgaW5jbHVk
ZXMgcmVzb2x2ZWQgYWRkcmVzcyBhbmQgSUNFIGFnZW50IGRlYWxzIHdpdGggYWRkcmVzc2VzIG9u
bHkuPGJyPg0KPGJyPg0KVGhhdCB3b3VsZCBub3Qgd29yayB3aXRoIG1ETlMsIHJpZ2h0Pzxicj4N
Cjxicj4NCiZndDsgMi4gRG8gd2Ugc3BlY2lmeSBob3cgdG8gZGVhbCB3aXRoIEZRRE4gaW4gaWNl
LXNpcC1zZHAgb3IgZG8gd2Ugc3BlY2lmeSBpbiBpY2Utc2lwLXNkcCB0aGF0IEZRRE4gbXVzdCBi
ZSBpZ25vcmVkIGFuZCB0aGVpciBoYW5kbGluZyBpcyBkZWZpbmVkIGluIHNvbWUgb3RoZXIgZHJh
ZnQ/PGJyPg0KPGJyPg0KUGVyaGFwcyB0aGUgYmVzdCB0aGluZyB3b3VsZCBzaW1wbHkgdG8gcHJv
ZHVjZSBhIHNlcGFyYXRlIGRyYWZ0LCB0byBnZXQgc29tZSB0ZXh0LiBXZSBjYW4gdGhlbiBkZWNp
ZGUgd2hldGhlciB0byBtZXJnZSBpdCBpbnRvIGljZS1zaXAtc2RwLjxvOnA+PC9vOnA+PC9wPg0K
PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgY2FuIHBy
b2JhYmx5IGRlc2NyaWJlIHRoaXMgaW4gaWNlLXNpcC1zZHAgaW4gYWJvdXQgMyBwYXJhZ3JhcGhz
LiBUaGUgYmFja2dyb3VuZCBhbmQgb3RoZXIgdGV4dCBmb3IgYSBuZXcgZHJhZnQgd2lsbCBtYWtl
IGlzIG11Y2ggYmlnZ2VyIGVmZm9ydC4gSG93IGFib3V0IEkgcHV0IHRvZ2V0aGVyIGEgcHVsbA0K
IHJlcXVlc3QgZm9yIGljZS1zaXAtc2RwIGFuZCB0aGVuIHdlIGNhbiBkZWNpZGUgaWYgdGhpcyBy
ZXF1aXJlcyBhIG5ldyBkcmFmdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19fX19fX19fPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJvbWFuIFNocG91bnQ8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX188YnI+DQptbXVzaWMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i
bWFpbHRvOm1tdXNpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1tdXNpY0BpZXRmLm9yZzwv
YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21t
dXNpYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vbW11c2ljPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5
Pg0KPC9odG1sPg0K

--_000_52CE9A69B70941CD9BE8A59EE44D55A7ericssoncom_--


From nobody Fri Apr 26 02:37:47 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F901202F0 for ; Fri, 26 Apr 2019 02:37:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLap-OLu3yFs for ; Fri, 26 Apr 2019 02:37:42 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150057.outbound.protection.outlook.com [40.107.15.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E966120075 for ; Fri, 26 Apr 2019 02:37:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=c3BKKk5rUg5HmJjP1ry8vX/TVs9rwOyhJRyPEYlLndQ=; b=WkI3cVreqwGGEqyXTudjqQCXxRS8zArBunso+pMTdeh8jWrwDaIvEZfk+KzvVA4tfrpEKKB0onXmROxwQIIFARfsbEyHHdGNSsj3kE6GUkk1EcNn+ehf4szPfbQNaV6RTVoQk48KINv4w5XmS7vdTXdDSO0APvJG7Nc5xgtRTjI=
Received: from VI1PR07MB3167.eurprd07.prod.outlook.com (10.175.243.17) by VI1PR07MB5966.eurprd07.prod.outlook.com (20.178.81.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.5; Fri, 26 Apr 2019 09:37:39 +0000
Received: from VI1PR07MB3167.eurprd07.prod.outlook.com ([fe80::d925:d8b5:d1df:4706]) by VI1PR07MB3167.eurprd07.prod.outlook.com ([fe80::d925:d8b5:d1df:4706%4]) with mapi id 15.20.1856.004; Fri, 26 Apr 2019 09:37:39 +0000
From: Christer Holmberg 
To: Paul Kyzivat , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] SDPNEG: How to disable DCEP
Thread-Index: AQHU+njrOtTA5N+Kv0Ox965sWihq+KZL5CwAgAKAjYA=
Date: Fri, 26 Apr 2019 09:37:39 +0000
Message-ID: <81169C37-95F2-418A-A221-CCC623392CD2@ericsson.com>
References: <8A9AAAC7-FB2D-4884-BAC6-268B98C7A0F0@ericsson.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.18.0.190414
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-originating-ip: [89.166.49.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c85851d3-7f13-45fd-5862-08d6ca2ad324
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB5966; 
x-ms-traffictypediagnostic: VI1PR07MB5966:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: 
x-forefront-prvs: 001968DD50
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(39860400002)(346002)(396003)(366004)(189003)(199004)(76116006)(2501003)(2171002)(66556008)(478600001)(66946007)(229853002)(64756008)(66446008)(73956011)(91956017)(66476007)(7736002)(68736007)(256004)(6512007)(8676002)(966005)(76176011)(53936002)(305945005)(186003)(2906002)(14454004)(3846002)(53546011)(5660300002)(6506007)(6116002)(26005)(6246003)(97736004)(33656002)(102836004)(81166006)(81156014)(8936002)(110136005)(58126008)(486006)(71200400001)(71190400001)(44832011)(316002)(83716004)(66066001)(446003)(11346002)(25786009)(86362001)(82746002)(2616005)(36756003)(6306002)(6486002)(6436002)(99286004)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB5966; H:VI1PR07MB3167.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: YZQU3fdvh7NZWwmb+uy5Jy2V81Z54FV2KKsPopUBSLeSlfuXzNGM+jtuYiMuxM98qcAuorLL05UMrviTdTDFnG0UOFHsQv2CgY2Rb4VlbspDgvyFFYrABopmWTR78iFuepNqn//0NFxZfYfx6qc4ibgH5SKMolYygdqZgV9YwiZVziebC7+cOCIY3uqBELtapOg9Vk8a/55NNfY8TAlypvL7In+J9NSKViWdpM4gqNKdY1GjhsC0Il+MSxcN3U9s1CILQ1qz3k3v5cxwIbxH8AK2KKtlFsXiz/W6E7OkwLSFvUPCcLCDD+Bn6d8602StfHdWAjYhchsPzViZ5K4q7XctF8LCOuRiXA6pzgOPZGo8D7syddETz1QVRvPedieSvFH2JJnVgc9PctQ3aHSu1W64MF9CLBBKLiXAm7u5sdg=
Content-Type: text/plain; charset="utf-8"
Content-ID: <5C80FEC2344E6046895C236BD21E9CB0@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c85851d3-7f13-45fd-5862-08d6ca2ad324
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2019 09:37:39.8496 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5966
Archived-At: 
Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP
X-BeenThere: mmusic@ietf.org
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: Fri, 26 Apr 2019 09:37:45 -0000

SGkgUGF1bCwNCg0KU28sIHdoYXQgaXMgeW91ciBzdWdnZXN0aW9uPyBfXw0KDQpSZWdhcmRzLA0K
DQpDaHJpc3Rlcg0KDQrvu79PbiAyNS8wNC8yMDE5LCAxLjI1LCAibW11c2ljIG9uIGJlaGFsZiBv
ZiBQYXVsIEt5eml2YXQiIDxtbXVzaWMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgcGt5
eml2YXRAYWx1bS5taXQuZWR1PiB3cm90ZToNCg0KICAgIE9uIDQvMjQvMTkgNDozNyBBTSwgQ2hy
aXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQogICAgPiBIaSwNCiAgICA+IA0KICAgID4gSSBoYWQgYW4g
b2ZmLWxpbmUgZGlzY3Vzc2lvbiB3aXRoIEJvIHJlZ2FyZGluZyBob3cgdG8ga25vdyB3aGV0aGVy
IHRvIA0KICAgID4gdXNlIFNEUE5FRyBvciBEQ0VQIGZvciBhIERhdGEgQ2hhbm5lbC4NCiAgICA+
IA0KICAgID4gU2VjdGlvbiA1IHNheXM6DQogICAgPiANCiAgICA+ICAgICDigJ1UaGlzIHNlY3Rp
b24gZGVmaW5lcyB0d28gbmV3IFNEUCBtZWRpYS1sZXZlbCBhdHRyaWJ1dGVzIHRoYXQgY2FuIGJl
DQogICAgPiANCiAgICA+ICAgICB1c2VkIHRvZ2V0aGVyIHdpdGggdGhlIFNEUCBPZmZlci9BbnN3
ZXIgbWVjaGFuaXNtIHRvIG5lZ290aWF0ZSBkYXRhDQogICAgPiANCiAgICA+ICAgICBjaGFubmVs
LXNwZWNpZmljIGFuZCBzdWJwcm90b2NvbC1zcGVjaWZpYyBwYXJhbWV0ZXJzIHdpdGhvdXQgdGhl
DQogICAgPiANCiAgICA+ICAgICB1c2FnZSBvZiBEQ0VQIFtJLUQuaWV0Zi1ydGN3ZWItZGF0YS1w
cm90b2NvbF0u4oCdDQogICAgPiANCiAgICA+IERvIHdlIGNvbnNpZGVyIHRoaXMgY2xlYXIgZW5v
dWdoIHRoYXQgdGhlIHByZXNlbmNlIG9mIHRob3NlIGF0dHJpYnV0ZXMgDQogICAgPiAod2VsbCwg
b25seSBkY21hcCwgc2luY2UgZGNzYSBpcyBvcHRpb25hbCkgd2lsbCDigJxkaXNhYmxl4oCdIHVz
YWdlIG9mIERDRVAsIA0KICAgID4gb3IgZG8gd2Ugd2FudCB0byBiZSBtb3JlIGNsZWFyPw0KICAg
IA0KICAgIFRoZSBkaXN0cmlidXRpb24gb2Ygc3BlY3MgYWNyb3NzIG11bHRpcGxlIGRvY3VtZW50
cyBtYWtlcyBpdCByZWFsbHkgDQogICAgZnV6enkgd2hhdCBpcyBub3JtYXRpdmUgZm9yIHdoYXQu
DQogICAgDQogICAgUGVyaGFwcyBzb21ldGhpbmcgc2hvdWxkIGJlIHNhaWQgYWJvdXQgdGhlIHZh
bGlkaXR5IG9mIHVzaW5nIGEgDQogICAgd2VicnRjLWRhdGFjaGFubmVsIG1lZGlhIHN0cmVhbSBm
b3IgZXN0YWJsaXNoaW5nIGRhdGEgY2hhbm5lbHMgdmlhIFNEUCANCiAgICB3aXRoIGRjbWFwIGFu
ZC9vciBEQ0VQLiBJIGRvbid0IHRoaW5rIHRoaXMgaXMgc2FpZCBhbnl3aGVyZSBlbHNlLg0KICAg
IA0KICAgIAlUaGFua3MsDQogICAgCVBhdWwNCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIG1tdXNpYyBtYWlsaW5nIGxpc3QNCiAg
ICBtbXVzaWNAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL21tdXNpYw0KICAgIA0KDQo=


From nobody Fri Apr 26 08:16:38 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE201205CB for ; Fri, 26 Apr 2019 08:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHKlydyHFlMb for ; Fri, 26 Apr 2019 08:16:23 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 968731204B2 for ; Fri, 26 Apr 2019 08:15:56 -0700 (PDT)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x3QFFq4t014355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 26 Apr 2019 11:15:52 -0400
To: Christer Holmberg , "mmusic@ietf.org" 
References: <8A9AAAC7-FB2D-4884-BAC6-268B98C7A0F0@ericsson.com>  <81169C37-95F2-418A-A221-CCC623392CD2@ericsson.com>
From: Paul Kyzivat 
Message-ID: <563cf2bd-474a-8fef-ceaf-e2c72ebc6dc4@alum.mit.edu>
Date: Fri, 26 Apr 2019 11:15:52 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <81169C37-95F2-418A-A221-CCC623392CD2@ericsson.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP
X-BeenThere: mmusic@ietf.org
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: Fri, 26 Apr 2019 15:16:37 -0000

On 4/26/19 5:37 AM, Christer Holmberg wrote:
> Hi Paul,
> 
> So, what is your suggestion? __

It looks to me like the 2nd paragraph of Appendix A is the right place 
for this:

    A WebRTC application creates a data channel by providing a number of
    setup parameters (subprotocol, label, maximal number of
    retransmissions, maximal retransmission time, order of delivery,
    priority).  The application also specifies if it wants to make use of
    the negotiation using the DCEP [I-D.ietf-rtcweb-data-protocol], or if
    the application intends to negotiate data channels using the SDP
    offer/answer protocol.

I'm inclined to tweak the above as follows:

    ...
    the application intends to negotiate data channels using the SDP
    offer/answer protocol, or both.

And then, the note at the end of the section can be augmented:

    Note: The above SDP media description does not contain any channel-
    specific information. If data channels are to be negotiated using
    SDP, then the above will be supplemented as specified in Sections
    6.3 and 6.4.

But I'm not sure about "The application also specifies...". Is this 
referring to something specific in the webrtc API? If so, does it permit 
both? The presence of dcmap in the SDP will indicate the intent to use 
SDP negotiation, but must this first be enabled in the API?

	Thanks,
	Paul

> Regards,
> 
> Christer
> 
> On 25/04/2019, 1.25, "mmusic on behalf of Paul Kyzivat"  wrote:
> 
>      The distribution of specs across multiple documents makes it really
>      fuzzy what is normative for what.
>      
>      Perhaps something should be said about the validity of using a
>      webrtc-datachannel media stream for establishing data channels via SDP
>      with dcmap and/or DCEP. I don't think this is said anywhere else.


From nobody Fri Apr 26 13:43:01 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF0A1205F4 for ; Fri, 26 Apr 2019 13:43:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=turbobridge.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iY0rY0RrJYOg for ; Fri, 26 Apr 2019 13:42:56 -0700 (PDT)
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 808D51205FF for ; Fri, 26 Apr 2019 13:42:56 -0700 (PDT)
Received: by mail-pl1-x62b.google.com with SMTP id o7so2073385pll.13 for ; Fri, 26 Apr 2019 13:42:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=turbobridge.com; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=wd9XwhHGx799ZsoRAeel1et8IUtw+S3561AIhn3rJJw=; b=SV4hSNN4kFi3p5hDVcX1Ftn/kngWfVdBJG5Ayl0Gve3QwVUKiu0SKCZi0L3R+ZKfHp fO50E64hoASS2B7LzFA1SWavkd0nDhbCnWJ1VPVZSg1lG3JEvgBCj2adBq9PM0QDxkX7 3fXsg16nQp/6iWQba2+c5zwSs2ut9dKMGrL3k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=wd9XwhHGx799ZsoRAeel1et8IUtw+S3561AIhn3rJJw=; b=pH/qfExcTD6vkcPd+AVXHqBf5gfY4mLXEJKJjUqsCUNKSUMP9mAnBs5zbeKDkIY/6k w1XM1rZleGelIPmcwOzesYlMw3TUZmbG8O2QICfEytQMtYXJ3NCOODrpk9vNB0XGoTpm 6mnki9DYCXvYHaafhzUzUfAa+ARbsEnt2+CMXLE5iaQkX8PDa/ZChzuKdlZ6QBD8Xiuc y9SAGBO+oAqhhONuejFPnpCQllZADH+mZRU52W7Y0S27J7Z7XJaZk9Jh3Lu5xpen59Wn 8OHUIETCiB1ENVZDGrHdbKeMyZt9n3ptNJ/vvtm5N7b1sYUk43Eq6Oc/MdkqB/79kep2 A40w==
X-Gm-Message-State: APjAAAVjiLMeDy35VSBp7imPqgEO+eqRnYYjc4Md8scv4ZyhK3g0oaCl /OI/kGzLXLYuZjtsW65Bj+iBBZEAtew=
X-Google-Smtp-Source: APXvYqzM3bd6AmN7ztLcSysp0muTP5gYaws5JaDlOUE7HOl1DZs2b7MJvlvoa/DHhvfG/JH49i4q6g==
X-Received: by 2002:a17:902:bd4b:: with SMTP id b11mr47568882plx.68.1556311375270;  Fri, 26 Apr 2019 13:42:55 -0700 (PDT)
Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com. [209.85.214.179]) by smtp.gmail.com with ESMTPSA id r24sm35040018pfd.120.2019.04.26.13.42.54 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Apr 2019 13:42:54 -0700 (PDT)
Received: by mail-pl1-f179.google.com with SMTP id o5so2079798pls.12 for ; Fri, 26 Apr 2019 13:42:54 -0700 (PDT)
X-Received: by 2002:a17:902:86:: with SMTP id a6mr47600198pla.277.1556311373922;  Fri, 26 Apr 2019 13:42:53 -0700 (PDT)
MIME-Version: 1.0
From: Roman Shpount 
Date: Fri, 26 Apr 2019 16:42:45 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: mmusic WG 
Cc: Christer Holmberg 
Content-Type: multipart/alternative; boundary="0000000000009a47a6058774fa9d"
Archived-At: 
Subject: [MMUSIC] Empty candidate lists in ice-sip-sdp offers and answers
X-BeenThere: mmusic@ietf.org
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: Fri, 26 Apr 2019 20:43:00 -0000

--0000000000009a47a6058774fa9d
Content-Type: text/plain; charset="UTF-8"

Hi All,

One more topic for discussion regarding the changes proposed in ice-sip-sdp
pull request ( https://github.com/suhasHere/ice-sip-sdp/pull/1 )

Since it is legal for the ICE agent to reject all the candidates due to
unsupported connection address type or due to FQDN not being resolvable, I
thought it makes sense to allow both offers and answers with no candidates.
It was never explicitly stated in RFC 5245 that such offers are illegal, so
I added the following notes to the Offer/Answer procedures to explicitly
allow them.

In the Sending the Initial Offer section I have added the following note:

NOTE: It is valid for an offer "m=" line to include no SDP candidate
attributes and default destination correspond to IP address values
"0.0.0.0"/"::" and port value of "9". This implies that offering agent is
only going to use peer reflexive candidates or that additional candidates
would be provided in subsequent signaling messages.


In the Sending the Initial Answer section I have added the following:

NOTE: It is valid for an answer "m=" line to include no SDP candidate
attributes and default destination correspond to IP address values
"0.0.0.0"/"::" and port value of "9". This implies that answering agent is
only going to use peer reflexive  candidates or that additional candidates
would be provided in subsequent signaling messages.

NOTE: Since it is possible that no candidates were provided in the offer,
or that all candidates in the offer where skipped due to unsupported
address type or FQDN name resolution failure, ICE nomination process can
start with no remote candidates. This, however, does not indicate an
immediate ICE nomination failure. See <> for more
details.


In the Receiving the Initial Answer section I have added the following:

NOTE: Since it is possible that no candidates were provided in the answer,
or that all candidates in the answer where skipped due to unsupported
address type or FQDN name resolution failure, ICE nomination process can
start with no remote candidates. This, however, does not indicate an
immediate ICE nomination failure. See <> for more
details.


I wanted to get the group's opinion regarding:

1. Allowing offers and answers with no candidates
2. Adding a reference to draft-holmberg-ice-pac regarding how such session
descriptions or session descriptions where all candidates were rejected are
handled.

Regards,
___________________________________________
Roman Shpount | CTO | Cell: +1(202) 262-8672
4905 Del Ray Ave, Suite 300 | Bethesda, MD 20814
TurboBridge

--0000000000009a47a6058774fa9d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi All,
One more topic for discussion regarding the changes proposed i=
n ice-sip-sdp pull request (

https://github.=
com/suhasHere/ice-sip-sdp/pull/1=C2=A0)

Since =
it is legal for the ICE agent to reject all the candidates due to unsupport=
ed connection address type or due to FQDN not being resolvable, I thought i=
t makes sense to allow both offers and answers with no candidates. It was n=
ever explicitly stated in RFC 5245 that such offers are illegal, so I added=
 the following notes to the Offer/Answer procedures to explicitly allow the=
m.

In the=C2=A0Sending the Initial Offer section I=
 have added the following note:

NOTE: It is valid for an offer "m=3D" line to in=
clude no SDP candidate attributes and default destination correspond to IP =
address values "0.0.0.0"/"::" and port value of "9=
". This implies that offering agent is only going to use peer reflexiv=
e candidates or that additional candidates would be provided in subsequent =
signaling messages.

In the=C2=A0Sending the Initial Answer section I hav=
e added the following:

NOTE: It is valid for an answer "m=3D"=
; line to include no SDP candidate attributes and default destination corre=
spond to IP address values "0.0.0.0"/"::" and port valu=
e of "9". This implies that answering agent is only going to use =
peer reflexive=C2=A0 candidates or that additional candidates would be prov=
ided in subsequent signaling messages.
<=
/div>

=

NOTE: Since it is possible that no candi=
dates were provided in the offer,=C2=A0 or that all candidates in the offer=
 where skipped due to unsupported address type or FQDN name resolution fail=
ure, ICE nomination process can start with no remote candidates. This, howe=
ver, does not indicate an immediate ICE nomination failure. See <<dra=
ft-holmberg-ice-pac>> for more details.
=


In the=C2=A0Receivin=
g the Initial Answer section I have added the following:=C2=A0
NOTE: Since it is possible that no candidates were provided i=
n the answer, or that all candidates in the answer where skipped due to uns=
upported address type or FQDN name resolution failure, ICE nomination proce=
ss can start with no remote candidates. This, however, does not indicate an=
 immediate ICE nomination failure. See <<draft-holmberg-ice-pac>&g=
t; for more details.
<=
div dir=3D"ltr">
=C2=A0
I wanted to get the group's opinion regarding:

1. Allowing offers and answers with no candidates
2. Adding a r=
eference to draft-holmberg-ice-pac regarding how such session descriptions =
or session descriptions where all candidates were rejected are handled.

Regards,
______________________=
_____________________
Roman Shpount | CTO=
 | Cell: +1(202) 262-8672
4905 Del Ray Av=
e, Suite 300 | Bethesda, MD 20814
TurboBr=
idge


--0000000000009a47a6058774fa9d--


From nobody Fri Apr 26 13:49:12 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF27120600 for ; Fri, 26 Apr 2019 13:49:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfKAM-e5bBAC for ; Fri, 26 Apr 2019 13:49:09 -0700 (PDT)
Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 012F21205F5 for ; Fri, 26 Apr 2019 13:49:08 -0700 (PDT)
Received: by mail-pl1-x62c.google.com with SMTP id n8so2084880plp.10 for ; Fri, 26 Apr 2019 13:49:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Tea1/BovZOAuu8CVqX9m4+NtXLo70UDSmCpqU9cCG/I=; b=nEnBnva6Xhoj2qQx50ewATxNk4fc95kYmEEqYeC8AK2a8qtxVnQ6fGROnkEvZxCW3M oIj0r1J+i2sIcUaBKzbZJQlOdmt+FubaztcJGA+tsCdXW2YIITTIVlaQQLEz9PDtFrsT R/qMf/PfIt8AUJfWtEHgWS3vOV4/cTscIXrAsBXKr4oQz1d/o+9uUV6ruU1n1tfuxl9A mxpo9SP+rExzddCM/H02wUh+5S621n6nDbDhFX1PpP5aF7TFdStFEpej8Uf41kDCFu0E pARwB5Z/nD9uhcZq/wCGokbWiQej+Ya/nrQbkpPF+K9diyYk6hcgWWzi255SuTOmnJsi qxiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Tea1/BovZOAuu8CVqX9m4+NtXLo70UDSmCpqU9cCG/I=; b=QWmbNrsB0MQTgW5I0LEWyE/TxO9kjWP0MG4y4pEh3TdcN4eeekHsXWPBK2YaLB3Zfj xKTuN29HgbiZDZbwpZ+jDyEpt9FX7P5x7tYgAY2KniZTkP5ZDLfAZGMjllwhS05RSCjb An8C5xjAQCNAKC2FSeemvZ9AOi101JSvVbMU5NamjZIGFz6ekuVTBbS1T75nYoIlpEbu ENuDqfQWkffnIzlHMmwi0yDx2wpavmSB21sQ9WUml9PbHwrcTEE1TVifF14i3I8PR5I/ NamP4Q6bNV+yIhH3JiyINZcOS77Vlynp9ErKPl2ZUfA9e/k4zoEDnn6lNOXNPGLzX4Ky iDdQ==
X-Gm-Message-State: APjAAAUkxLHk1/PBoFN6aKdSmydp1/Nj+S7fHEruaP4iV/7/ng8ttxXA BKk7Ue7GBvVAUxrkTfu1LhFimoRnxfY=
X-Google-Smtp-Source: APXvYqxcfkblI/080h2hYt1DWTp9HaG4/QQE/2gESp6fLn8RlVVQCLg77BqrsAkwg7aoOCyPD7Kn5A==
X-Received: by 2002:a17:902:bcc6:: with SMTP id o6mr42653293pls.275.1556311748308;  Fri, 26 Apr 2019 13:49:08 -0700 (PDT)
Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com. [209.85.215.178]) by smtp.gmail.com with ESMTPSA id a6sm40255460pfn.181.2019.04.26.13.49.07 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Apr 2019 13:49:07 -0700 (PDT)
Received: by mail-pg1-f178.google.com with SMTP id f6so2141862pgs.8 for ; Fri, 26 Apr 2019 13:49:07 -0700 (PDT)
X-Received: by 2002:a62:b61a:: with SMTP id j26mr47982127pff.203.1556311747481;  Fri, 26 Apr 2019 13:49:07 -0700 (PDT)
MIME-Version: 1.0
From: Roman Shpount 
Date: Fri, 26 Apr 2019 16:48:59 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: mmusic WG 
Content-Type: multipart/alternative; boundary="000000000000de55790587751091"
Archived-At: 
Subject: [MMUSIC] Is ice-mismatch media or session level?
X-BeenThere: mmusic@ietf.org
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: Fri, 26 Apr 2019 20:49:11 -0000

--000000000000de55790587751091
Content-Type: text/plain; charset="UTF-8"

Hi All,

This is another change related to
https://github.com/suhasHere/ice-sip-sdp/pull/1

RFC 5245 defined ice-mismatch as session level attribute. Draft ice-sip-sdp
changed it to media-level and rewrote some of the text that ICE mismatch
will occur per m= line. Considering that this is not a backwards compatible
change I have reverted this and changed ice-mismatch to session level.

Please let me know what you think.
_____________
Roman Shpount

--000000000000de55790587751091
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi All,

This is anothe=
r change related to=C2=A0

https://github.=
com/suhasHere/ice-sip-sdp/pull/1=C2=A0

RFC 524=
5 defined=C2=A0ice-mismatch as session level attribute. Draft ice-sip-sdp c=
hanged it to media-level and rewrote some of the text that ICE mismatch wil=
l occur per m=3D line. Considering that this is not a backwards compatible =
change I have reverted this and changed ice-mismatch=C2=A0to session level.=


Please let me know what you think.
_____________
Roman S=
hpount


--000000000000de55790587751091--


From nobody Fri Apr 26 13:59:05 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A3C1201EF for ; Fri, 26 Apr 2019 13:59:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SO-f-pINvDmi for ; Fri, 26 Apr 2019 13:59:02 -0700 (PDT)
Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A729120139 for ; Fri, 26 Apr 2019 13:59:02 -0700 (PDT)
Received: by mail-pf1-x436.google.com with SMTP id t21so2281938pfh.2 for ; Fri, 26 Apr 2019 13:59:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=dScM0W830qoBbH9v86xSGBkhjHcCJZX0OYoRQPNSXMA=; b=oPHj0y+me0sb9koaEkr/QDY3P9D9XfKdGZVtdg4UWI9gRjWI/FxTPBpfO8b+MkRVNl OJbU/Rt4Csb407yOXoQEhOnQUSX/nhaVdGzO3sYCV4fcnrJs2Ua5M4sgsh5NIAaw3qPk R/48Dg3iw0R6AzSkx3s/QR0cR4HfwWNCdg49Vq+/sGC++63Uv2iYJOMnWG76ey9QyKu9 Q3kYZMjo1dRQzndHtHKHRjTggIlcKyMlePW3DyBnq8TshjkTGS4QWfV/FyLlvPpK4S/b 0GV2TiMpzfSyIRGW+wME1JfL/+yNOqNWN5M5K2SlGlofG4Zg5EMK3FTqh0WUT6LR30ZA DXNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=dScM0W830qoBbH9v86xSGBkhjHcCJZX0OYoRQPNSXMA=; b=HmumxYr8qk/H2XXucadw/RmsMrBv86Qp8Ch8FUU2G/5wBwddGFcSCnqGpUZgVfhwfx mGg8mGa8effNb5wBH3eEEmKVNLLxrCYxWFnHgNded5S6cfKdF9o7EcWOnlCr8xfDVsyA AH5MgDVmJwO1gWeHW8xDuKPafUgRdBQ32SC1EDaf5sFn+XlZEqvVTnYaYPRkXac7259I uh8A2Jsgf4zYl1vu6mX6ZQH+2K94dP1cbKC0ek23AvBuJOsm4dzoM1T7R7+pT3JkF2Ht MzwwnK/k90RMFjFopZrBkvLUN8G/ZxG26mXlruoWirCd5ynC5fTDqNs/EovrGDNknhkt Vehw==
X-Gm-Message-State: APjAAAVfVYLx+VfC+eYC+p0jcrLxYn7WExP6liqkqkG/2uXhXJ2IzSIK yl8ORJlSHPYMhKkQp7aJBVWHrC/ajBg=
X-Google-Smtp-Source: APXvYqw6CFr4HfPEJmH2NTEmP6o2NzYWJMCGHx6Ie+RxxnNnpLBCKlwv9+9+/DyVfj3LRGxUeBdNaw==
X-Received: by 2002:a63:2c4c:: with SMTP id s73mr45609487pgs.42.1556312341483;  Fri, 26 Apr 2019 13:59:01 -0700 (PDT)
Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com. [209.85.214.176]) by smtp.gmail.com with ESMTPSA id u5sm37645491pfm.121.2019.04.26.13.59.00 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Apr 2019 13:59:00 -0700 (PDT)
Received: by mail-pl1-f176.google.com with SMTP id y3so1268294plp.0 for ; Fri, 26 Apr 2019 13:59:00 -0700 (PDT)
X-Received: by 2002:a17:902:86:: with SMTP id a6mr47662568pla.277.1556312340621;  Fri, 26 Apr 2019 13:59:00 -0700 (PDT)
MIME-Version: 1.0
From: Roman Shpount 
Date: Fri, 26 Apr 2019 16:58:52 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: mmusic WG 
Content-Type: multipart/alternative; boundary="00000000000038ed2505877534cf"
Archived-At: 
Subject: [MMUSIC] Handling the transport protocol and default candidate in the answer
X-BeenThere: mmusic@ietf.org
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: Fri, 26 Apr 2019 20:59:04 -0000

--00000000000038ed2505877534cf
Content-Type: text/plain; charset="UTF-8"

Hi All,

One more change regarding the
https://github.com/suhasHere/ice-sip-sdp/pull/1

 There is one scenario which was not well covered in ice-sip-sdp which was
described in JSEP.

Imagine end point receives an offer which contains both UDP and TCP
candidates. Default candidate for this offer is set to TCP based transport.
Answering end point only contains UDP based candidates.

There are two questions:

1. What transport protocol should the answering end point put in the m=
line?
2. What address and port should answering end point put in c= and m= line
as a default destination?

My suggestion is that answering end point should put the same transport
protocol in the answer as was specified in the offer. Since none of the
candidates match the transport protocol in the m= line, end point should
use dummy address "0.0.0.0"/"::" and port value of "9". This should also
prevent the ICE mismatch during the answer handling that could otherwise
cause answer handling according to RFC 3264 rules.

In order to specify this I have added the following note to Sending the
Initial Answer section:

NOTE: In each "m=" line, the answerer MUST use the same transport protocol
as was used in the offer "m=" line. If none of the candidates in the "m="
line in the answer use the same transport protocol as indicated in the
offer "m=" line, then, in order to avoid ICE mismatch, default destination
should be set to IP address values "0.0.0.0"/"::" and port value of "9".


Please let me know what you think.
_____________
Roman Shpount

--00000000000038ed2505877534cf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi All,=


One more change regarding the=C2=A0

https://github.=
com/suhasHere/ice-sip-sdp/pull/1=C2=A0

=C2=A0T=
here is one scenario which was not well covered in ice-sip-sdp which was de=
scribed in JSEP.

Imagine end point receives an off=
er which contains both UDP and TCP candidates. Default candidate for this o=
ffer is set to TCP based transport. Answering end point only contains UDP b=
ased candidates.

There are two questions:

1. What transport protocol should the answering end point =
put in the m=3D line?
2. What address and port should answering e=
nd point put in c=3D and m=3D line as a default destination?

=

My suggestion is that answering end point should put the same tr=
ansport protocol in the answer as was specified in the offer. Since none of=
 the candidates match the transport protocol in the m=3D line, end point sh=
ould use dummy address=C2=A0"0.0.0.0"/"::" and port val=
ue of "9". This should also prevent the ICE mismatch during the a=
nswer handling that could otherwise cause answer handling according to RFC =
3264 rules.

In order to specify this I have added =
the following note to=C2=A0Sending the Initial Answer section:
NOTE: In each "m=3D" line, the answerer MUST use the same transp=
ort protocol as was used in the offer "m=3D" line. If none of the=
 candidates in the "m=3D"=C2=A0 line in the answer use the same t=
ransport protocol as indicated in the=C2=A0 offer "m=3D" line, th=
en, in order to avoid ICE mismatch, default destination should be set to IP=
 address values "0.0.0.0"/"::" and port value of "=
9".

Please let me know what you =
think.
_____________Roman Shpount


--00000000000038ed2505877534cf--


From nobody Fri Apr 26 14:04:07 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873B7120614 for ; Fri, 26 Apr 2019 14:03:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_wlwQPmySLH for ; Fri, 26 Apr 2019 14:03:51 -0700 (PDT)
Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46276120626 for ; Fri, 26 Apr 2019 14:03:51 -0700 (PDT)
Received: by mail-pl1-x62a.google.com with SMTP id z8so2119640pln.4 for ; Fri, 26 Apr 2019 14:03:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=NtUVdgrWNizefPmU1HRbpVnev4AieAXXb4GFK2/aCKY=; b=Z1SbWYhb+zlh0DpY3OKAaLe2WAsIht0wUjAllTEu2/QdhVALUhHgcaWvHdto+bEcvp KT9K0jGs1s7x8kr3Oy0+UnBGYVWfmisYUk44v+GDtKkN9Id1PUTYroCST0MOafQBwTB7 uiKX8YtXI8x5Os6fC03Ka1NBs8ePloRtUoRBnoUH1LiVrQBsDx2X/Xt17xINiUWsit1M gNhw0uLlt5t4wr2aKiA80+we2fxlFj1dtjDaWp868qx7aIAxX/gzKMFz1qFGxm//La/b 0aBRazdDTEI1dL8ITtcrDA+O51mzBVxhjzaOt22Nc+TBQgLbgbAIlePWhhkouY0wDiLS 2wCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NtUVdgrWNizefPmU1HRbpVnev4AieAXXb4GFK2/aCKY=; b=kVSZmFiZdChftfbZ+fmbuHLkaTiOkLg6nqikfDHi1nWaGKgRSCJyQJc1CuC3F3x/+f kNrcxHLn92xRzMOz2XdKTotmc3neS87wkFZaDnxLGpnYIg1no5vFq7c0wSv343NyNQTN c6VXZxMCNgA8Sdlxb8MiHpZ8X5qFvFPR/G98GRZxcExUiTId48u68clxuO3rEgcgIVPN b2Ql12ovcuFxG81xqOLS5LODRx0oQzPw1IMt4bNN4d2ZOd1W8DLpNA0CmU8fQmlaSOuR xMRgCN6aS6cxZjbYDRmMKqIdDLKmMM7TEZaShAo1ZdPuSN5kw2pUGy8sn0rjljwVAEp3 pyPQ==
X-Gm-Message-State: APjAAAVQeyrqzUWIJD2aVhVrBHPYjtdEmDYHik8NHRufp98XpwKOr0lc wm8X9RnDXePfin1HPrvmoOo1QXf3HPw=
X-Google-Smtp-Source: APXvYqzs97tdceYp3n1k3NP+uyji5uw0TT4yhKXlA7xtNSOSRQeJoaz5SbS4NOn7TBUlyjqQw62MDQ==
X-Received: by 2002:a17:902:a9c7:: with SMTP id b7mr47624722plr.145.1556312630451;  Fri, 26 Apr 2019 14:03:50 -0700 (PDT)
Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com. [209.85.215.180]) by smtp.gmail.com with ESMTPSA id l184sm53260541pfc.98.2019.04.26.14.03.49 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Apr 2019 14:03:50 -0700 (PDT)
Received: by mail-pg1-f180.google.com with SMTP id z9so2150258pgu.10 for ; Fri, 26 Apr 2019 14:03:49 -0700 (PDT)
X-Received: by 2002:a63:df43:: with SMTP id h3mr46334908pgj.294.1556312629655;  Fri, 26 Apr 2019 14:03:49 -0700 (PDT)
MIME-Version: 1.0
From: Roman Shpount 
Date: Fri, 26 Apr 2019 17:03:41 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: mmusic WG 
Content-Type: multipart/alternative; boundary="0000000000007340b3058775456b"
Archived-At: 
Subject: [MMUSIC] Minor correction to ICE RTP/RTCP handling
X-BeenThere: mmusic@ietf.org
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: Fri, 26 Apr 2019 21:04:06 -0000

--0000000000007340b3058775456b
Content-Type: text/plain; charset="UTF-8"

Hi All,

One more change related to  https://github.com/suhasHere/ice-sip-sdp/pull/1

In the current version of ice-sip-sdp, it was specified that agent MUST
include SDP candidate attributes for both the RTP and RTCP components if
RTCP is used. I think this is incorrect if RTCP mux only is used, only
candidate attributes for RTP must be included. To address this I have
changed the RTP/RTCP Considerations section.

Old Text:

If an agent utilizes both RTP and RTCP, the agent MUST include SDP
candidate attributes for both the RTP and RTCP components in the "m="
section.

If an agent uses separate ports for RTP and RTCP, the agent MUST include
an  SDP rtcp attribute in the "m=" section, as described in <>. In
the cases  where the port number for the RTCP is one higher than the RTP
port and RTCP  component address is same as the address of the RTP
component, the SDP rtcp  attribute MAY be omitted.


New Text:

If an agent utilizes both RTP and RTCP, and separate ports are used for RTP
and RTCP, the agent MUST include SDP candidate attributes for both the RTP
and RTCP components and SDP rtcp attribute SHOULD be included in the "m="
section, as  described in <>. In the cases  where the port number
for the RTCP is one higher than the RTP port and RTCP component address is
same as the address of the RTP component, the SDP rtcp attribute MAY be
omitted.


Please let me know what you think.
_____________
Roman Shpount

--0000000000007340b3058775456b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi All,

One more change related to=C2=A0

https://github.=
com/suhasHere/ice-sip-sdp/pull/1=C2=A0

In the =
current version of ice-sip-sdp, it was specified that agent MUST include SD=
P candidate attributes for both the RTP and RTCP components if RTCP is used=
. I think this is incorrect if RTCP mux only is used, only candidate attrib=
utes for RTP must be included. To address this I have changed the=C2=A0RTP/=
RTCP Considerations section.

Old Text:
<=
br>
If an agent utilizes bo=
th RTP and RTCP, the agent MUST include SDP candidate attributes for both t=
he RTP and RTCP components in the "m=3D" section.

If an agent uses separate ports for RTP and RT=
CP, the agent MUST include an=C2=A0 SDP rtcp attribute in the "m=3D&qu=
ot; section, as described in <<RFC3605>>. In the cases=C2=A0 wh=
ere the port number for the RTCP is one higher than the RTP port and RTCP=
=C2=A0 component address is same as the address of the RTP component, the S=
DP rtcp=C2=A0 attribute MAY be omitted.
=


New Text:

<=
blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px">
If an age=
nt utilizes both RTP and RTCP, and separate ports are used for RTP and RTCP=
, the agent MUST include SDP candidate attributes for both the RTP and RTCP=
 components and SDP rtcp attribute SHOULD be included in the "m=3D&quo=
t; section, as=C2=A0 described in <<RFC3605>>. In the cases=C2=
=A0 where the port number for the RTCP is one higher than the RTP port and =
RTCP component address is same as the address of the RTP component, the SDP=
 rtcp attribute MAY be omitted.

Please let me know what you think.
_____________
Roman Shpount


--0000000000007340b3058775456b--


From nobody Sat Apr 27 10:49:00 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B21A120183 for ; Sat, 27 Apr 2019 10:48:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbqWkr2osCpJ for ; Sat, 27 Apr 2019 10:48:55 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10086.outbound.protection.outlook.com [40.107.1.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 152C01200BA for ; Sat, 27 Apr 2019 10:48:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DoVfINqSZnjt2p5lk0GrKo/ZYQAsK3HvMUzvpz3kZ68=; b=ClEeWr/9TYRsLp0jXb5KtW6pYlqxXSzvhOE5Tkss4emwxNeVw4SDbLCggEoKMFBNFJeMRzU0FWKU8xqyn9z38KuEgDljEx04gEF1IDdr5Tmli8vDprlPLz99Lgs2rTBa/6gfQocw+/h1ksNwIzDEUX88xEbOuxsG4oa4lUF+P1I=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3404.eurprd07.prod.outlook.com (10.170.247.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.4; Sat, 27 Apr 2019 17:48:48 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::c999:f848:9abc:d321]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::c999:f848:9abc:d321%6]) with mapi id 15.20.1856.007; Sat, 27 Apr 2019 17:48:48 +0000
From: Christer Holmberg 
To: Roman Shpount , mmusic WG 
Thread-Topic: [MMUSIC] Is ice-mismatch media or session level?
Thread-Index: AQHU/HGLgDWzhK5lWUSPRp9gP7WzBaZQSMD3
Date: Sat, 27 Apr 2019 17:48:48 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-originating-ip: [176.93.0.86]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: dd623dd3-7f08-4e22-dc41-08d6cb389a31
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3404; 
x-ms-traffictypediagnostic: HE1PR07MB3404:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0020414413
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(376002)(136003)(39860400002)(396003)(53754006)(189003)(199004)(5660300002)(66066001)(236005)(6606003)(71190400001)(110136005)(71200400001)(74316002)(7736002)(97736004)(99286004)(53546011)(76176011)(68736007)(6506007)(966005)(33656002)(86362001)(14454004)(102836004)(7696005)(9686003)(6306002)(186003)(44832011)(54896002)(26005)(486006)(229853002)(3846002)(55016002)(25786009)(53936002)(81166006)(81156014)(6246003)(6436002)(2906002)(606006)(6116002)(8936002)(52536014)(4744005)(446003)(316002)(76116006)(66946007)(11346002)(66476007)(66556008)(64756008)(66446008)(1015004)(73956011)(256004)(478600001)(19627405001)(476003)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3404; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 9c3O+GU4XwB4lk+Rbfgjg7WlXVL3yowkQ1+aNXnt5q/ymLPCemrb5nKhWKGU4K5mQymtusf7R8vQGI5eiGQPgNj5OsSB/Ztx9wMzVkTWCuB1DfcVJEs4btcorEKWJQnI4WFlmtJqkchU5qkp0vqh3/dzBxfk/CdPDr8dwObEWnXXGGwtbkGQ9dvZ2/+mV943VjKiINZmd4HjD1ilJP4G0x2pcff1CAQWNsHFtHu7AwMX3bfg9mkZQfDCyU7imhOf60TYRW+HuBMD4SGchWVrxzezFWM9QwZMwynO34x3t3Nx1dMbUm/QHsrIcxF0zYn2kjvJCbwFNgGav49sQsVkjgbIdgHxl37EmGogyF/X/sC9x3sGC3NUwFXzhZ0k8VQeTj6aNfnceYBs5ZVGov7oQbsKLq6BrEOojEqXHnMNcx8=
Content-Type: multipart/alternative; boundary="_000_HE1PR07MB3161E1BDB1E2439E1A9CE785933F0HE1PR07MB3161eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dd623dd3-7f08-4e22-dc41-08d6cb389a31
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2019 17:48:48.3560 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3404
Archived-At: 
Subject: Re: [MMUSIC] Is ice-mismatch media or session level?
X-BeenThere: mmusic@ietf.org
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: Sat, 27 Apr 2019 17:48:58 -0000

--_000_HE1PR07MB3161E1BDB1E2439E1A9CE785933F0HE1PR07MB3161eurp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Hi,

Before we just change something back we need to think what the reason for t=
he change to media-level was. Could it be related to RTCWEB?

Regards,

Christer


________________________________
From: mmusic  on behalf of Roman Shpount 
Sent: Friday, April 26, 2019 11:48 PM
To: mmusic WG
Subject: [MMUSIC] Is ice-mismatch media or session level?

Hi All,

This is another change related to  https://github.com/suhasHere/ice-sip-sdp=
/pull/1

RFC 5245 defined ice-mismatch as session level attribute. Draft ice-sip-sdp=
 changed it to media-level and rewrote some of the text that ICE mismatch w=
ill occur per m=3D line. Considering that this is not a backwards compatibl=
e change I have reverted this and changed ice-mismatch to session level.

Please let me know what you think.
_____________
Roman Shpount

--_000_HE1PR07MB3161E1BDB1E2439E1A9CE785933F0HE1PR07MB3161eurp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable














Hi,






Before we just change something back we need to think what the reason =
for the change to media-level was. Could it be related to RTCWEB? 






Regards,







Christer











From: mmusic <mmusic-bou=
nces@ietf.org> on behalf of Roman Shpount <roman@telurix.com>

Sent: Friday, April 26, 2019 11:48 PM

To: mmusic WG

Subject: [MMUSIC] Is ice-mismatch media or session level?

 








Hi All,






This is another change related to  
https://github.com/suhasHere/ice-sip-sdp/pull/1 







RFC 5245 defined ice-mismatch as session level attribute. Draft i=
ce-sip-sdp changed it to media-level and rewrote some of the text that ICE =
mismatch will occur per m=3D line. Considering that this is not a backwards=
 compatible change I have reverted this
 and changed ice-mismatch to session level.







Please let me know what you think.




_____________

Roman Shpount




















--_000_HE1PR07MB3161E1BDB1E2439E1A9CE785933F0HE1PR07MB3161eurp_--


From nobody Sat Apr 27 11:02:19 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307AE1201C5 for ; Sat, 27 Apr 2019 11:02:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZLcm7ZBKDB9 for ; Sat, 27 Apr 2019 11:02:16 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10077.outbound.protection.outlook.com [40.107.1.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0D3B1201A3 for ; Sat, 27 Apr 2019 11:02:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HCZVi+4EHRECl3Bq+2qBa/WOdBv8ylEn65kSEzemw7c=; b=jgtReoobIYloDOQklnISU90CVF9EiYAT+PXAgxL/O3IrhCmj8a4YP7EVbvpffmg1FCl8ePOu1BX/Gi2j25cYZN+ia7GvLO8iBvM86uGKpGYxvL5hLHSQcIFovFcLIVksNWyDTESg7YwK1NGQP/BTPneNe3F1dfXDPL+3avgkCa4=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4250.eurprd07.prod.outlook.com (20.176.166.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.6; Sat, 27 Apr 2019 18:02:13 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::c999:f848:9abc:d321]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::c999:f848:9abc:d321%6]) with mapi id 15.20.1856.007; Sat, 27 Apr 2019 18:02:13 +0000
From: Christer Holmberg 
To: Roman Shpount , mmusic WG 
Thread-Topic: Empty candidate lists in ice-sip-sdp offers and answers
Thread-Index: AQHU/HCocD9pfxgHukmdWkMyMkXu4qZQS3/b
Date: Sat, 27 Apr 2019 18:02:13 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-originating-ip: [176.93.0.86]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c24098c2-e050-43c7-0e69-08d6cb3a79c6
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB4250; 
x-ms-traffictypediagnostic: HE1PR07MB4250:
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0020414413
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(396003)(39860400002)(376002)(136003)(189003)(199004)(14444005)(86362001)(26005)(25786009)(71190400001)(11346002)(476003)(55016002)(446003)(71200400001)(66066001)(6436002)(74316002)(316002)(44832011)(99286004)(8676002)(66476007)(76176011)(14454004)(7696005)(256004)(2906002)(186003)(66446008)(73956011)(76116006)(66946007)(9686003)(7736002)(478600001)(66556008)(68736007)(64756008)(229853002)(52536014)(81166006)(81156014)(33656002)(8936002)(97736004)(486006)(110136005)(6506007)(6116002)(3846002)(5660300002)(305945005)(53936002)(6246003)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4250; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: A3kJdSoNR3kzg/R+/cQx9wWe84EhZ5SHUftfcYRQxCRqRm3RX+K3mPS7upizNk0RkA4Uu827L52Io7gcT8LeCLAB5sKcae88wub0Jz21MPw73SdmMKBa7WSkm+jRHktderkyXSyi3+tT4+qcyaJIHfllzmrQFegN0G2OQlCzxjdr0/HQmac07y/WTT7BhG8W5OoyOx+fynzN8iTRNlsC9WbPG5EURD/XRMhNPa1fIuyQbSLWrPRZ0VfEDDfWCUJR1wXZX45BIBkM/z1405yn4vmr2QtExfKVh27QFH8iMNANmUQxp8qM66UUBDouKkW4p1KkV6yMQhJfRzhk/KiaO1SdXTGjQFWiGnNoG8qJUBHYIzI77jsRc9XYPDM13jjOIcDSddd+NZcQPqSEsDKLoF0lSc12/rCug/j7iN4Ua9w=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c24098c2-e050-43c7-0e69-08d6cb3a79c6
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2019 18:02:13.0219 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4250
Archived-At: 
Subject: Re: [MMUSIC] Empty candidate lists in ice-sip-sdp offers and answers
X-BeenThere: mmusic@ietf.org
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: Sat, 27 Apr 2019 18:02:18 -0000

Hi,

...=20

>NOTE: Since it is possible that no candidates were provided in the offer,=
=A0 or that all candidates in the offer=20
>where skipped due to unsupported address type or FQDN name resolution fail=
ure, ICE nomination process=20
>can start with no remote candidates. This,  however, does not indicate an =
immediate ICE nomination failure.=20
>See <> for more details.
>=20
>In the=A0Receiving the Initial Answer section I have added the following:=
=A0
>
>NOTE: Since it is possible that no candidates were provided in the answer,=
 or that all candidates in the answer=20
>where skipped due to unsupported address type or FQDN name resolution fail=
ure, ICE nomination process can=20
>start with no remote candidates. This,  however, does not indicate an imme=
diate ICE nomination failure.=20
>See <> for more details.=20

I think the text is confusing, because it starts talking about the ICE nomi=
nation process. There are other things that happen before, including the cr=
eation of candidate pairs.

So, I think the text should say that the agent will not be able to create c=
andidate pairs, and it will not be able to start sending connectivity check=
s. Instead it will wait for the peer agent to start sending connectivity ch=
ecks, that the agent will then process as peer reflexive candidates.


>I wanted to get the group's opinion regarding:
>
>1. Allowing offers and answers with no candidates

I am ok with the principle. There seem to be use-cases for it, so...

>2. Adding a reference to draft-holmberg-ice-pac regarding how such session=
 descriptions or session descriptions where all candidates were rejected ar=
e handled.

The reference in the text above is misleading, because to me it sounds like=
 PAC describes how to process offers/answers without candidates. PAC is onl=
y about a timer.

Regards,

Christer


From nobody Sat Apr 27 11:08:08 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8E51201D9 for ; Sat, 27 Apr 2019 11:08:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGQa58RNhxjA for ; Sat, 27 Apr 2019 11:08:05 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10088.outbound.protection.outlook.com [40.107.1.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C5DA1201C8 for ; Sat, 27 Apr 2019 11:08:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dilLc05CpKuQQCNBaiZPSwAIGJYTmGJGtLizRGX3QK8=; b=TJBAXzxQvVEDd7DG58f8QVXAuISIAW0fEYyp1Q0ot/nvpVZRgihY8elfq2pIywRcBwmJBQJzHQvZAo4wt9cE0BsAPsBJDXGwma8WiJIYxJpTebSVWuLPZ+6ZsHNceI8/slerYtq4haKBU+FTB7Y/1QRWU4BIiFGMGH8M0EpOFdI=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4250.eurprd07.prod.outlook.com (20.176.166.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.6; Sat, 27 Apr 2019 18:07:57 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::c999:f848:9abc:d321]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::c999:f848:9abc:d321%6]) with mapi id 15.20.1856.007; Sat, 27 Apr 2019 18:07:57 +0000
From: Christer Holmberg 
To: Jose M Recio , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-10.txt - Comment on msrp-cema attribute
Thread-Index: AQHU+PdOAq7bCRTG/EWrEZLX3OSx16ZIK12AgACp4oCAA+0cgIADkrHn
Date: Sat, 27 Apr 2019 18:07:57 +0000
Message-ID: 
References: <61D3ED98-04FA-4746-BCDE-37BD38907803@ericsson.com>  , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-originating-ip: [176.93.0.86]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ef55a78d-4a8b-4ed6-97ea-08d6cb3b4742
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB4250; 
x-ms-traffictypediagnostic: HE1PR07MB4250:
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0020414413
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(396003)(39860400002)(376002)(136003)(189003)(199004)(51444003)(86362001)(26005)(25786009)(71190400001)(11346002)(476003)(55016002)(446003)(71200400001)(66066001)(6436002)(74316002)(316002)(44832011)(93886005)(99286004)(8676002)(66476007)(76176011)(14454004)(7696005)(256004)(2906002)(186003)(2501003)(66446008)(73956011)(76116006)(66946007)(9686003)(7736002)(478600001)(66556008)(68736007)(64756008)(229853002)(52536014)(81166006)(81156014)(33656002)(8936002)(97736004)(486006)(110136005)(6506007)(6116002)(3846002)(5660300002)(305945005)(53936002)(6246003)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4250; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: RLlJxs4jBT680J5GtehDuWWJH0Y1KfTlMbIO5Y2pWhi+zNZDSQXgidw/UjQtLhLJWZqFQuDB5+d9A8/O/vQLbvUDgKX70QpVGTWdG6PwYTaXyClIHRsv28uqHCnHouNRe8ScyhBei8ji6Ggm81yob6xnYekRPO9g1moSH/Sah5RXN9xHVHBkL1rd/sVAJPd5YnjdxufJMKwPo3xrxLv7s6SKIGr22gF9PLXZSkltm+SGMOkd31mF/0XfbyItvz9F168YqD5Nia0FsNG9UrXCRgIUOIPZUpoacqGDoM5wwiQ3gsSOND/03T6iW5QF+ec52N43miQJtWG5+inT9poMyZZ5E4q1xZSzvuEVaOkw1Xh3+5KSnGs1UNHnIK0OL2wRv6PmzKFNQ3KHTnG7bWrhNpeortb1gWwCfmm+76B1HyY=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ef55a78d-4a8b-4ed6-97ea-08d6cb3b4742
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2019 18:07:57.6860 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4250
Archived-At: 
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-10.txt - Comment on msrp-cema attribute
X-BeenThere: mmusic@ietf.org
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: Sat, 27 Apr 2019 18:08:07 -0000

Hi,

>> Keep in mind (and that should probably better described in the document)=
 that the normal MSRP routing procedures don't apply.=20
>> The MSRP messages will be routed in the data channel, which is establish=
ed between the SIP peers (or whatever signaling protocol=20
>> is used). I guess proxies and application servers can look at the top-mo=
st path attribute, but that is not going to be the primary routing=20
>> input. I don't think the draft says anything about that - it just seems =
to assume that the data channel will end up in the intended MSRP peer. =20
>
> It indeed assumes that the data channel endpoint will be a MSRP peer, eit=
her another endpoint or a MSRP GW. If that's not clear enough it should be =
made more explicit.

I was not talking about the fact that the endpoint will be a MSRP peer/GW, =
but that legacy MSRP routing will not be used.

> If the endpoint is a GW, messages can be relayed, similar to the scenario=
 where the connection to the GW is done using TLS, or WebSockets, instead o=
f dc.     =20

Regarding the GW, I think that also needs more text. For example, *IF* the =
data channel MSRP client inserts multiple path attributes, will the GW then=
 copy paste those in the outgoing legacy MSRP message? I assume it will, bu=
t there is very little detail on the GW procedures.

Regards,

Christer


From nobody Sat Apr 27 23:21:52 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29715120094 for ; Sat, 27 Apr 2019 23:21:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNn_uzRF19wV for ; Sat, 27 Apr 2019 23:21:48 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94FF912001E for ; Sat, 27 Apr 2019 23:21:48 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id C3C21D5515C33A7FB017; Sun, 28 Apr 2019 07:21:46 +0100 (IST)
Received: from lhreml705-chm.china.huawei.com (10.201.108.54) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 28 Apr 2019 07:21:46 +0100
Received: from lhreml705-chm.china.huawei.com (10.201.108.54) by lhreml705-chm.china.huawei.com (10.201.108.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Sun, 28 Apr 2019 07:21:46 +0100
Received: from DGGEMM421-HUB.china.huawei.com (10.1.198.38) by lhreml705-chm.china.huawei.com (10.201.108.54) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Sun, 28 Apr 2019 07:21:45 +0100
Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.138]) by dggemm421-hub.china.huawei.com ([10.1.198.38]) with mapi id 14.03.0415.000; Sun, 28 Apr 2019 14:21:42 +0800
From: "Roni Even (A)" 
To: Paul Kyzivat , Christer Holmberg , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] SDPNEG: How to disable DCEP
Thread-Index: AQHU+njrOtTA5N+Kv0Ox965sWihq+KZLXhAAgAJOQoCAAF5/AIADFOtg
Date: Sun, 28 Apr 2019 06:21:41 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18CDE434@dggemm526-mbx.china.huawei.com>
References: <8A9AAAC7-FB2D-4884-BAC6-268B98C7A0F0@ericsson.com>  <81169C37-95F2-418A-A221-CCC623392CD2@ericsson.com> <563cf2bd-474a-8fef-ceaf-e2c72ebc6dc4@alum.mit.edu>
In-Reply-To: <563cf2bd-474a-8fef-ceaf-e2c72ebc6dc4@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.202.62]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP
X-BeenThere: mmusic@ietf.org
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: Sun, 28 Apr 2019 06:21:50 -0000

SGksDQpJIHRoaW5rIHRoYXQgc2VjdGlvbnMgNi4zIGFuZCA2LjQgdGhhdCBkaXNjdXNzIG9mZmVy
L2Fuc3dlciBzYXkgdGhhdCBkY21hcCBpcyB0aGUgaW5kaWNhdGlvbiBvZiBydWluZyBub24gZGNl
cC4NClRoZSBleGFtcGxlIGluIHNlY3Rpb24gNyBzYXkgdGhhdCBpZiBkY21hcCBpcyByZWplY3Rl
ZCBkY2VwIG1heSBiZSBuZWdvdGlhdGVkLg0KTWF5YmUgdGhpcyBsaW5lIGZvcm0gc2VjdGlvbiA3
IHNob3VsZCBiZSBpbiBzZWN0aW9uIDYuND8NCg0KUm9uaQ0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLQ0KRnJvbTogbW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmddIE9u
IEJlaGFsZiBPZiBQYXVsIEt5eml2YXQNClNlbnQ6IEZyaWRheSwgQXByaWwgMjYsIDIwMTkgNjox
NiBQTQ0KVG86IENocmlzdGVyIEhvbG1iZXJnOyBtbXVzaWNAaWV0Zi5vcmcNClN1YmplY3Q6IFJl
OiBbTU1VU0lDXSBTRFBORUc6IEhvdyB0byBkaXNhYmxlIERDRVANCg0KT24gNC8yNi8xOSA1OjM3
IEFNLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4gSGkgUGF1bCwNCj4gDQo+IFNvLCB3aGF0
IGlzIHlvdXIgc3VnZ2VzdGlvbj8gX18NCg0KSXQgbG9va3MgdG8gbWUgbGlrZSB0aGUgMm5kIHBh
cmFncmFwaCBvZiBBcHBlbmRpeCBBIGlzIHRoZSByaWdodCBwbGFjZSBmb3IgdGhpczoNCg0KICAg
IEEgV2ViUlRDIGFwcGxpY2F0aW9uIGNyZWF0ZXMgYSBkYXRhIGNoYW5uZWwgYnkgcHJvdmlkaW5n
IGEgbnVtYmVyIG9mDQogICAgc2V0dXAgcGFyYW1ldGVycyAoc3VicHJvdG9jb2wsIGxhYmVsLCBt
YXhpbWFsIG51bWJlciBvZg0KICAgIHJldHJhbnNtaXNzaW9ucywgbWF4aW1hbCByZXRyYW5zbWlz
c2lvbiB0aW1lLCBvcmRlciBvZiBkZWxpdmVyeSwNCiAgICBwcmlvcml0eSkuICBUaGUgYXBwbGlj
YXRpb24gYWxzbyBzcGVjaWZpZXMgaWYgaXQgd2FudHMgdG8gbWFrZSB1c2Ugb2YNCiAgICB0aGUg
bmVnb3RpYXRpb24gdXNpbmcgdGhlIERDRVAgW0ktRC5pZXRmLXJ0Y3dlYi1kYXRhLXByb3RvY29s
XSwgb3IgaWYNCiAgICB0aGUgYXBwbGljYXRpb24gaW50ZW5kcyB0byBuZWdvdGlhdGUgZGF0YSBj
aGFubmVscyB1c2luZyB0aGUgU0RQDQogICAgb2ZmZXIvYW5zd2VyIHByb3RvY29sLg0KDQpJJ20g
aW5jbGluZWQgdG8gdHdlYWsgdGhlIGFib3ZlIGFzIGZvbGxvd3M6DQoNCiAgICAuLi4NCiAgICB0
aGUgYXBwbGljYXRpb24gaW50ZW5kcyB0byBuZWdvdGlhdGUgZGF0YSBjaGFubmVscyB1c2luZyB0
aGUgU0RQDQogICAgb2ZmZXIvYW5zd2VyIHByb3RvY29sLCBvciBib3RoLg0KDQpBbmQgdGhlbiwg
dGhlIG5vdGUgYXQgdGhlIGVuZCBvZiB0aGUgc2VjdGlvbiBjYW4gYmUgYXVnbWVudGVkOg0KDQog
ICAgTm90ZTogVGhlIGFib3ZlIFNEUCBtZWRpYSBkZXNjcmlwdGlvbiBkb2VzIG5vdCBjb250YWlu
IGFueSBjaGFubmVsLQ0KICAgIHNwZWNpZmljIGluZm9ybWF0aW9uLiBJZiBkYXRhIGNoYW5uZWxz
IGFyZSB0byBiZSBuZWdvdGlhdGVkIHVzaW5nDQogICAgU0RQLCB0aGVuIHRoZSBhYm92ZSB3aWxs
IGJlIHN1cHBsZW1lbnRlZCBhcyBzcGVjaWZpZWQgaW4gU2VjdGlvbnMNCiAgICA2LjMgYW5kIDYu
NC4NCg0KQnV0IEknbSBub3Qgc3VyZSBhYm91dCAiVGhlIGFwcGxpY2F0aW9uIGFsc28gc3BlY2lm
aWVzLi4uIi4gSXMgdGhpcyByZWZlcnJpbmcgdG8gc29tZXRoaW5nIHNwZWNpZmljIGluIHRoZSB3
ZWJydGMgQVBJPyBJZiBzbywgZG9lcyBpdCBwZXJtaXQgYm90aD8gVGhlIHByZXNlbmNlIG9mIGRj
bWFwIGluIHRoZSBTRFAgd2lsbCBpbmRpY2F0ZSB0aGUgaW50ZW50IHRvIHVzZSBTRFAgbmVnb3Rp
YXRpb24sIGJ1dCBtdXN0IHRoaXMgZmlyc3QgYmUgZW5hYmxlZCBpbiB0aGUgQVBJPw0KDQoJVGhh
bmtzLA0KCVBhdWwNCg0KPiBSZWdhcmRzLA0KPiANCj4gQ2hyaXN0ZXINCj4gDQo+IO+7v09uIDI1
LzA0LzIwMTksIDEuMjUsICJtbXVzaWMgb24gYmVoYWxmIG9mIFBhdWwgS3l6aXZhdCIgPG1tdXNp
Yy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBwa3l6aXZhdEBhbHVtLm1pdC5lZHU+IHdy
b3RlOg0KPiANCj4gICAgICBUaGUgZGlzdHJpYnV0aW9uIG9mIHNwZWNzIGFjcm9zcyBtdWx0aXBs
ZSBkb2N1bWVudHMgbWFrZXMgaXQgcmVhbGx5DQo+ICAgICAgZnV6enkgd2hhdCBpcyBub3JtYXRp
dmUgZm9yIHdoYXQuDQo+ICAgICAgDQo+ICAgICAgUGVyaGFwcyBzb21ldGhpbmcgc2hvdWxkIGJl
IHNhaWQgYWJvdXQgdGhlIHZhbGlkaXR5IG9mIHVzaW5nIGENCj4gICAgICB3ZWJydGMtZGF0YWNo
YW5uZWwgbWVkaWEgc3RyZWFtIGZvciBlc3RhYmxpc2hpbmcgZGF0YSBjaGFubmVscyB2aWEgU0RQ
DQo+ICAgICAgd2l0aCBkY21hcCBhbmQvb3IgRENFUC4gSSBkb24ndCB0aGluayB0aGlzIGlzIHNh
aWQgYW55d2hlcmUgZWxzZS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZw0KaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg==


From nobody Sun Apr 28 04:57:51 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD87120105 for ; Sun, 28 Apr 2019 04:57:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level: 
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLQYS9DqsmDu for ; Sun, 28 Apr 2019 04:57:48 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50053.outbound.protection.outlook.com [40.107.5.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E8991200A1 for ; Sun, 28 Apr 2019 04:57:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IeE+YGep5hAA0haILRI4efeHFIah+GnXssel6VEX0/c=; b=jNeL9zzwVLAZVN2PecYgGTox6c2VHMSY5GbkkdBk5oJtbkIkvBdLRU3M8kCrYsTU+x+t2bvW2ZewfSeezaPnyDo7UJ2RmlXZuhjuQ1NQfDL2XxhaXaojcgn61tJsugkNm1d8DdTrAfyaZtSOFUW8jPNRsqhhp/so5zk+LLzmboA=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3148.eurprd07.prod.outlook.com (10.170.245.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.5; Sun, 28 Apr 2019 11:57:43 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::c999:f848:9abc:d321]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::c999:f848:9abc:d321%6]) with mapi id 15.20.1856.008; Sun, 28 Apr 2019 11:57:43 +0000
From: Christer Holmberg 
To: "Roni Even (A)" , Paul Kyzivat , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] SDPNEG: How to disable DCEP
Thread-Index: AQHU+njrOtTA5N+Kv0Ox965sWihq+KZL5CwAgAKAjYCAACw0AIACj2qAgACQLAA=
Date: Sun, 28 Apr 2019 11:57:43 +0000
Message-ID: 
References: <8A9AAAC7-FB2D-4884-BAC6-268B98C7A0F0@ericsson.com>  <81169C37-95F2-418A-A221-CCC623392CD2@ericsson.com> <563cf2bd-474a-8fef-ceaf-e2c72ebc6dc4@alum.mit.edu> <6E58094ECC8D8344914996DAD28F1CCD18CDE434@dggemm526-mbx.china.huawei.com>
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD18CDE434@dggemm526-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.18.0.190414
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-originating-ip: [176.93.0.86]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cf460266-d801-4bc2-912e-08d6cbd0b913
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3148; 
x-ms-traffictypediagnostic: HE1PR07MB3148:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: 
x-forefront-prvs: 0021920B5A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(39860400002)(136003)(396003)(376002)(13464003)(51444003)(189003)(199004)(305945005)(2906002)(6116002)(7736002)(97736004)(14444005)(6436002)(256004)(3846002)(86362001)(2501003)(76176011)(44832011)(53546011)(446003)(6506007)(99286004)(476003)(102836004)(2616005)(11346002)(486006)(68736007)(186003)(6486002)(316002)(26005)(110136005)(58126008)(6246003)(2171002)(229853002)(71200400001)(71190400001)(93886005)(83716004)(82746002)(66066001)(8676002)(478600001)(76116006)(73956011)(36756003)(966005)(25786009)(81156014)(5660300002)(33656002)(14454004)(66556008)(64756008)(81166006)(6306002)(6512007)(66446008)(53936002)(66476007)(66946007)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3148; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: XWazSm6c5yPX0aj0wA4tglG5kuJw9qaVIbDd9/HryOxUyz45pRuWKZXSkizxp4j9IOLADqKqP4YGxMwG1G/XFWZZ5KAiWNQ2IeKKGNJg1GEIxafp1sNCru9edfB5IBxPi4WjyOAf8HmULXs6y6/kSECtYQ//ygveYIk+vXulDgZ8uaSnicVW2WoNjQLpnN3V+BlRGMu3iRNOL2Vg7nimhsl5nzl0arN6t1zmPVXY9EeiDtEYTCmv8++BlwLM57sxhPCMW6WvXKcut6Yy5pEc1kelTC7E/i3gB84Isrsn7U3Pv9vNW7OZHJJbgJCMKCSn2qO/rUyMW3uJHg9U2IyU+14KmEIAzmNFO4M5ZLcOhgvI1zA+0VZEhtE+9Ox/D9vqnNiWCiI85lOjvEFP7rYZpAmjdWxOb7r7AqpAFro1G+o=
Content-Type: text/plain; charset="utf-8"
Content-ID: <709683C1E38F054CB0FCCCEF8CED8610@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cf460266-d801-4bc2-912e-08d6cbd0b913
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2019 11:57:43.6578 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3148
Archived-At: 
Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP
X-BeenThere: mmusic@ietf.org
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: Sun, 28 Apr 2019 11:57:51 -0000

SGksDQoNCj4gSSB0aGluayB0aGF0IHNlY3Rpb25zIDYuMyBhbmQgNi40IHRoYXQgZGlzY3VzcyBv
ZmZlci9hbnN3ZXIgc2F5IHRoYXQgZGNtYXAgaXMgdGhlIGluZGljYXRpb24gb2YgcnVpbmcgbm9u
IGRjZXAuDQoNClNlY3Rpb24gNi4zIGFuZCA2LjQgZGVzY3JpYmUgaG93IHRvIHVzZSBkY21hcC4N
Cg0KSSB0aGluayBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gZS5nLiwgaGF2ZSBhbiBBcHBsaWNhYmls
aXR5IHNlY3Rpb24gaW4gdGhlIGJlZ2lubmluZyBvZiB0aGUgZG9jdW1lbnQsIHRoYXQgZXhwbGlj
aXRseSBpbmRpY2F0ZXMgdGhhdCB0aGUgcHJvY2VkdXJlcyBpbiB0aGUgZG9jdW1lbnQgYXBwbHkg
d2hlbiBhIGRhdGEgY2hhbm5lbCBpcyBuZWdvdGlhdGVkIHVzaW5nIHRoZSBkY21hcCBhdHRyaWJ1
dGUsIGFuZCB0aGF0IERDRVAgaXMgdGhlbiBub3QgdXNlZC4NCg0KQnV0LCB3aGF0IGlmIGFuIG9m
ZmVyZXIgd2FudHMgdG8gbmVnb3RpYXRlIGEgZGF0YSBjaGFubmVsLCBiZWZvcmUgZGVjaWRpbmcg
d2hhdCBleGFjdGx5IGl0IGlzIGdvaW5nIHRvIGJlIHVzZWQgZm9yLCBidXQgc3RpbGwgd2FudHMg
dG8gaW5kaWNhdGUgdXNhZ2Ugb2YgU0RQTkVHLiBJbmNsdWRpbmcgYW4gZW1wdHkgZGNtYXAgYXR0
cmlidXRlPw0KDQo+ICAgIFRoZSBleGFtcGxlIGluIHNlY3Rpb24gNyBzYXkgdGhhdCBpZiBkY21h
cCBpcyByZWplY3RlZCBkY2VwIG1heSBiZSBuZWdvdGlhdGVkLg0KPiAgICBNYXliZSB0aGlzIGxp
bmUgZm9ybSBzZWN0aW9uIDcgc2hvdWxkIGJlIGluIHNlY3Rpb24gNi40Pw0KDQpOb3JtYXRpdmUg
dGV4dCBzaG91bGQgZGVmaW5pdGVseSBub3QgYmUgaW4gU2VjdGlvbiA3Lg0KDQpIb3dldmVyLCBp
ZiB0aGUgYW5zd2VyZXIgZG9lcyBub3Qgd2FudCB0byB1c2UgU0RQTkVHLCBJIHRoaW5rIGl0J3Mg
dXAgdG8gdGhlIG9mZmVyZXIgdG8gZGVjaWRlIHdoZXRoZXIgdG8gY29udGludWUgdGhlIHNlc3Np
b24gZXN0YWJsaXNobWVudCwgb3IgZmFsbGJhY2sgdG8gRENFUC4gDQoNClJlZ2FyZHMsDQoNCkNo
cmlzdGVyDQoNCg0KDQogICAgDQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICBG
cm9tOiBtbXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m
IFBhdWwgS3l6aXZhdA0KICAgIFNlbnQ6IEZyaWRheSwgQXByaWwgMjYsIDIwMTkgNjoxNiBQTQ0K
ICAgIFRvOiBDaHJpc3RlciBIb2xtYmVyZzsgbW11c2ljQGlldGYub3JnDQogICAgU3ViamVjdDog
UmU6IFtNTVVTSUNdIFNEUE5FRzogSG93IHRvIGRpc2FibGUgRENFUA0KICAgIA0KICAgIE9uIDQv
MjYvMTkgNTozNyBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQogICAgPiBIaSBQYXVsLA0K
ICAgID4gDQogICAgPiBTbywgd2hhdCBpcyB5b3VyIHN1Z2dlc3Rpb24/IF9fDQogICAgDQogICAg
SXQgbG9va3MgdG8gbWUgbGlrZSB0aGUgMm5kIHBhcmFncmFwaCBvZiBBcHBlbmRpeCBBIGlzIHRo
ZSByaWdodCBwbGFjZSBmb3IgdGhpczoNCiAgICANCiAgICAgICAgQSBXZWJSVEMgYXBwbGljYXRp
b24gY3JlYXRlcyBhIGRhdGEgY2hhbm5lbCBieSBwcm92aWRpbmcgYSBudW1iZXIgb2YNCiAgICAg
ICAgc2V0dXAgcGFyYW1ldGVycyAoc3VicHJvdG9jb2wsIGxhYmVsLCBtYXhpbWFsIG51bWJlciBv
Zg0KICAgICAgICByZXRyYW5zbWlzc2lvbnMsIG1heGltYWwgcmV0cmFuc21pc3Npb24gdGltZSwg
b3JkZXIgb2YgZGVsaXZlcnksDQogICAgICAgIHByaW9yaXR5KS4gIFRoZSBhcHBsaWNhdGlvbiBh
bHNvIHNwZWNpZmllcyBpZiBpdCB3YW50cyB0byBtYWtlIHVzZSBvZg0KICAgICAgICB0aGUgbmVn
b3RpYXRpb24gdXNpbmcgdGhlIERDRVAgW0ktRC5pZXRmLXJ0Y3dlYi1kYXRhLXByb3RvY29sXSwg
b3IgaWYNCiAgICAgICAgdGhlIGFwcGxpY2F0aW9uIGludGVuZHMgdG8gbmVnb3RpYXRlIGRhdGEg
Y2hhbm5lbHMgdXNpbmcgdGhlIFNEUA0KICAgICAgICBvZmZlci9hbnN3ZXIgcHJvdG9jb2wuDQog
ICAgDQogICAgSSdtIGluY2xpbmVkIHRvIHR3ZWFrIHRoZSBhYm92ZSBhcyBmb2xsb3dzOg0KICAg
IA0KICAgICAgICAuLi4NCiAgICAgICAgdGhlIGFwcGxpY2F0aW9uIGludGVuZHMgdG8gbmVnb3Rp
YXRlIGRhdGEgY2hhbm5lbHMgdXNpbmcgdGhlIFNEUA0KICAgICAgICBvZmZlci9hbnN3ZXIgcHJv
dG9jb2wsIG9yIGJvdGguDQogICAgDQogICAgQW5kIHRoZW4sIHRoZSBub3RlIGF0IHRoZSBlbmQg
b2YgdGhlIHNlY3Rpb24gY2FuIGJlIGF1Z21lbnRlZDoNCiAgICANCiAgICAgICAgTm90ZTogVGhl
IGFib3ZlIFNEUCBtZWRpYSBkZXNjcmlwdGlvbiBkb2VzIG5vdCBjb250YWluIGFueSBjaGFubmVs
LQ0KICAgICAgICBzcGVjaWZpYyBpbmZvcm1hdGlvbi4gSWYgZGF0YSBjaGFubmVscyBhcmUgdG8g
YmUgbmVnb3RpYXRlZCB1c2luZw0KICAgICAgICBTRFAsIHRoZW4gdGhlIGFib3ZlIHdpbGwgYmUg
c3VwcGxlbWVudGVkIGFzIHNwZWNpZmllZCBpbiBTZWN0aW9ucw0KICAgICAgICA2LjMgYW5kIDYu
NC4NCiAgICANCiAgICBCdXQgSSdtIG5vdCBzdXJlIGFib3V0ICJUaGUgYXBwbGljYXRpb24gYWxz
byBzcGVjaWZpZXMuLi4iLiBJcyB0aGlzIHJlZmVycmluZyB0byBzb21ldGhpbmcgc3BlY2lmaWMg
aW4gdGhlIHdlYnJ0YyBBUEk/IElmIHNvLCBkb2VzIGl0IHBlcm1pdCBib3RoPyBUaGUgcHJlc2Vu
Y2Ugb2YgZGNtYXAgaW4gdGhlIFNEUCB3aWxsIGluZGljYXRlIHRoZSBpbnRlbnQgdG8gdXNlIFNE
UCBuZWdvdGlhdGlvbiwgYnV0IG11c3QgdGhpcyBmaXJzdCBiZSBlbmFibGVkIGluIHRoZSBBUEk/
DQogICAgDQogICAgCVRoYW5rcywNCiAgICAJUGF1bA0KICAgIA0KICAgID4gUmVnYXJkcywNCiAg
ICA+IA0KICAgID4gQ2hyaXN0ZXINCiAgICA+IA0KICAgID4gT24gMjUvMDQvMjAxOSwgMS4yNSwg
Im1tdXNpYyBvbiBiZWhhbGYgb2YgUGF1bCBLeXppdmF0IiA8bW11c2ljLWJvdW5jZXNAaWV0Zi5v
cmcgb24gYmVoYWxmIG9mIHBreXppdmF0QGFsdW0ubWl0LmVkdT4gd3JvdGU6DQogICAgPiANCiAg
ICA+ICAgICAgVGhlIGRpc3RyaWJ1dGlvbiBvZiBzcGVjcyBhY3Jvc3MgbXVsdGlwbGUgZG9jdW1l
bnRzIG1ha2VzIGl0IHJlYWxseQ0KICAgID4gICAgICBmdXp6eSB3aGF0IGlzIG5vcm1hdGl2ZSBm
b3Igd2hhdC4NCiAgICA+ICAgICAgDQogICAgPiAgICAgIFBlcmhhcHMgc29tZXRoaW5nIHNob3Vs
ZCBiZSBzYWlkIGFib3V0IHRoZSB2YWxpZGl0eSBvZiB1c2luZyBhDQogICAgPiAgICAgIHdlYnJ0
Yy1kYXRhY2hhbm5lbCBtZWRpYSBzdHJlYW0gZm9yIGVzdGFibGlzaGluZyBkYXRhIGNoYW5uZWxz
IHZpYSBTRFANCiAgICA+ICAgICAgd2l0aCBkY21hcCBhbmQvb3IgRENFUC4gSSBkb24ndCB0aGlu
ayB0aGlzIGlzIHNhaWQgYW55d2hlcmUgZWxzZS4NCiAgICANCiAgICBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIG1tdXNpYyBtYWlsaW5nIGxpc3QN
CiAgICBtbXVzaWNAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL21tdXNpYw0KICAgIA0KDQo=


From nobody Sun Apr 28 07:09:46 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A0C120123 for ; Sun, 28 Apr 2019 07:09:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tsz3qDGfkyPb for ; Sun, 28 Apr 2019 07:09:42 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DB8E1200CC for ; Sun, 28 Apr 2019 07:09:42 -0700 (PDT)
Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id E23127F75936A2B7A367; Sun, 28 Apr 2019 15:09:39 +0100 (IST)
Received: from lhreml707-chm.china.huawei.com (10.201.108.56) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 28 Apr 2019 15:09:39 +0100
Received: from lhreml707-chm.china.huawei.com (10.201.108.56) by lhreml707-chm.china.huawei.com (10.201.108.56) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Sun, 28 Apr 2019 15:09:39 +0100
Received: from DGGEMM423-HUB.china.huawei.com (10.1.198.40) by lhreml707-chm.china.huawei.com (10.201.108.56) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Sun, 28 Apr 2019 15:09:38 +0100
Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.138]) by dggemm423-hub.china.huawei.com ([10.1.198.40]) with mapi id 14.03.0415.000; Sun, 28 Apr 2019 22:09:33 +0800
From: "Roni Even (A)" 
To: Christer Holmberg , Paul Kyzivat , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] SDPNEG: How to disable DCEP
Thread-Index: AQHU+njrOtTA5N+Kv0Ox965sWihq+KZLXhAAgAJOQoCAAF5/AIADFOtg///YYoCAAKhswA==
Date: Sun, 28 Apr 2019 14:09:33 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18CDE52D@dggemm526-mbx.china.huawei.com>
References: <8A9AAAC7-FB2D-4884-BAC6-268B98C7A0F0@ericsson.com>  <81169C37-95F2-418A-A221-CCC623392CD2@ericsson.com> <563cf2bd-474a-8fef-ceaf-e2c72ebc6dc4@alum.mit.edu> <6E58094ECC8D8344914996DAD28F1CCD18CDE434@dggemm526-mbx.china.huawei.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.202.62]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP
X-BeenThere: mmusic@ietf.org
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: Sun, 28 Apr 2019 14:09:45 -0000

SW5saW5lDQpSb25pDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDaHJpc3Rl
ciBIb2xtYmVyZyBbbWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbV0gDQpTZW50
OiBTdW5kYXksIEFwcmlsIDI4LCAyMDE5IDI6NTggUE0NClRvOiBSb25pIEV2ZW4gKEEpOyBQYXVs
IEt5eml2YXQ7IG1tdXNpY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtNTVVTSUNdIFNEUE5FRzog
SG93IHRvIGRpc2FibGUgRENFUA0KDQpIaSwNCg0KPiBJIHRoaW5rIHRoYXQgc2VjdGlvbnMgNi4z
IGFuZCA2LjQgdGhhdCBkaXNjdXNzIG9mZmVyL2Fuc3dlciBzYXkgdGhhdCBkY21hcCBpcyB0aGUg
aW5kaWNhdGlvbiBvZiBydWluZyBub24gZGNlcC4NCg0KU2VjdGlvbiA2LjMgYW5kIDYuNCBkZXNj
cmliZSBob3cgdG8gdXNlIGRjbWFwLg0KDQpJIHRoaW5rIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBl
LmcuLCBoYXZlIGFuIEFwcGxpY2FiaWxpdHkgc2VjdGlvbiBpbiB0aGUgYmVnaW5uaW5nIG9mIHRo
ZSBkb2N1bWVudCwgdGhhdCBleHBsaWNpdGx5IGluZGljYXRlcyB0aGF0IHRoZSBwcm9jZWR1cmVz
IGluIHRoZSBkb2N1bWVudCBhcHBseSB3aGVuIGEgZGF0YSBjaGFubmVsIGlzIG5lZ290aWF0ZWQg
dXNpbmcgdGhlIGRjbWFwIGF0dHJpYnV0ZSwgYW5kIHRoYXQgRENFUCBpcyB0aGVuIG5vdCB1c2Vk
Lg0KDQoNClJFOiBzZWN0aW9uIDUgIlRoaXMgc2VjdGlvbiBkZWZpbmVzIHR3byBuZXcgU0RQIG1l
ZGlhLWxldmVsIGF0dHJpYnV0ZXMgdGhhdCBjYW4gYmUNCiAgIHVzZWQgdG9nZXRoZXIgd2l0aCB0
aGUgU0RQIE9mZmVyL0Fuc3dlciBtZWNoYW5pc20gdG8gbmVnb3RpYXRlIGRhdGENCiAgIGNoYW5u
ZWwtc3BlY2lmaWMgYW5kIHN1YnByb3RvY29sLXNwZWNpZmljIHBhcmFtZXRlcnMgd2l0aG91dCB0
aGUNCiAgIHVzYWdlIG9mIERDRVAiLiAgaWYgZGNtYXAgaXMgcmVqZWN0ZWQgaW4gdGhlIGFuc3dl
ciwgdGhlIG9mZmVyZXIgY2FuIHRyeSBkY2VwICggc2VlIG15IGFuc3dlciBiZWxsb3cpDQoNCkJ1
dCwgd2hhdCBpZiBhbiBvZmZlcmVyIHdhbnRzIHRvIG5lZ290aWF0ZSBhIGRhdGEgY2hhbm5lbCwg
YmVmb3JlIGRlY2lkaW5nIHdoYXQgZXhhY3RseSBpdCBpcyBnb2luZyB0byBiZSB1c2VkIGZvciwg
YnV0IHN0aWxsIHdhbnRzIHRvIGluZGljYXRlIHVzYWdlIG9mIFNEUE5FRy4gSW5jbHVkaW5nIGFu
IGVtcHR5IGRjbWFwIGF0dHJpYnV0ZT8NCg0KDQpSRTogSSBkbyBub3Qgc2VlIHdoYXQgaXMgdGhl
IHVzZSBjYXNlLCBpdCBkb2VzIG5vdCBoZWxwIHdpdGggdGhlIGRlY2lzaW9uIGFib3V0IHdoZXRo
ZXIgb3V0IG9mIGJhbmQgY2FzZSBpcyBzdXBwb3J0ZWQgb3Igbm90Lg0KDQoNCg0KPiAgICBUaGUg
ZXhhbXBsZSBpbiBzZWN0aW9uIDcgc2F5IHRoYXQgaWYgZGNtYXAgaXMgcmVqZWN0ZWQgZGNlcCBt
YXkgYmUgbmVnb3RpYXRlZC4NCj4gICAgTWF5YmUgdGhpcyBsaW5lIGZvcm0gc2VjdGlvbiA3IHNo
b3VsZCBiZSBpbiBzZWN0aW9uIDYuND8NCg0KTm9ybWF0aXZlIHRleHQgc2hvdWxkIGRlZmluaXRl
bHkgbm90IGJlIGluIFNlY3Rpb24gNy4NCg0KUkU6IHllcyBtYWtlIHNlbnNlIHRvIGhhdmUgaXQg
aW4gc2VjdGlvbiA2LjUNCg0KSG93ZXZlciwgaWYgdGhlIGFuc3dlcmVyIGRvZXMgbm90IHdhbnQg
dG8gdXNlIFNEUE5FRywgSSB0aGluayBpdCdzIHVwIHRvIHRoZSBvZmZlcmVyIHRvIGRlY2lkZSB3
aGV0aGVyIHRvIGNvbnRpbnVlIHRoZSBzZXNzaW9uIGVzdGFibGlzaG1lbnQsIG9yIGZhbGxiYWNr
IHRvIERDRVAuIA0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KICAgIA0KICAgIC0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgRnJvbTogbW11c2ljIFttYWlsdG86bW11c2ljLWJv
dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYXVsIEt5eml2YXQNCiAgICBTZW50OiBGcmlk
YXksIEFwcmlsIDI2LCAyMDE5IDY6MTYgUE0NCiAgICBUbzogQ2hyaXN0ZXIgSG9sbWJlcmc7IG1t
dXNpY0BpZXRmLm9yZw0KICAgIFN1YmplY3Q6IFJlOiBbTU1VU0lDXSBTRFBORUc6IEhvdyB0byBk
aXNhYmxlIERDRVANCiAgICANCiAgICBPbiA0LzI2LzE5IDU6MzcgQU0sIENocmlzdGVyIEhvbG1i
ZXJnIHdyb3RlOg0KICAgID4gSGkgUGF1bCwNCiAgICA+IA0KICAgID4gU28sIHdoYXQgaXMgeW91
ciBzdWdnZXN0aW9uPyBfXw0KICAgIA0KICAgIEl0IGxvb2tzIHRvIG1lIGxpa2UgdGhlIDJuZCBw
YXJhZ3JhcGggb2YgQXBwZW5kaXggQSBpcyB0aGUgcmlnaHQgcGxhY2UgZm9yIHRoaXM6DQogICAg
DQogICAgICAgIEEgV2ViUlRDIGFwcGxpY2F0aW9uIGNyZWF0ZXMgYSBkYXRhIGNoYW5uZWwgYnkg
cHJvdmlkaW5nIGEgbnVtYmVyIG9mDQogICAgICAgIHNldHVwIHBhcmFtZXRlcnMgKHN1YnByb3Rv
Y29sLCBsYWJlbCwgbWF4aW1hbCBudW1iZXIgb2YNCiAgICAgICAgcmV0cmFuc21pc3Npb25zLCBt
YXhpbWFsIHJldHJhbnNtaXNzaW9uIHRpbWUsIG9yZGVyIG9mIGRlbGl2ZXJ5LA0KICAgICAgICBw
cmlvcml0eSkuICBUaGUgYXBwbGljYXRpb24gYWxzbyBzcGVjaWZpZXMgaWYgaXQgd2FudHMgdG8g
bWFrZSB1c2Ugb2YNCiAgICAgICAgdGhlIG5lZ290aWF0aW9uIHVzaW5nIHRoZSBEQ0VQIFtJLUQu
aWV0Zi1ydGN3ZWItZGF0YS1wcm90b2NvbF0sIG9yIGlmDQogICAgICAgIHRoZSBhcHBsaWNhdGlv
biBpbnRlbmRzIHRvIG5lZ290aWF0ZSBkYXRhIGNoYW5uZWxzIHVzaW5nIHRoZSBTRFANCiAgICAg
ICAgb2ZmZXIvYW5zd2VyIHByb3RvY29sLg0KICAgIA0KICAgIEknbSBpbmNsaW5lZCB0byB0d2Vh
ayB0aGUgYWJvdmUgYXMgZm9sbG93czoNCiAgICANCiAgICAgICAgLi4uDQogICAgICAgIHRoZSBh
cHBsaWNhdGlvbiBpbnRlbmRzIHRvIG5lZ290aWF0ZSBkYXRhIGNoYW5uZWxzIHVzaW5nIHRoZSBT
RFANCiAgICAgICAgb2ZmZXIvYW5zd2VyIHByb3RvY29sLCBvciBib3RoLg0KICAgIA0KICAgIEFu
ZCB0aGVuLCB0aGUgbm90ZSBhdCB0aGUgZW5kIG9mIHRoZSBzZWN0aW9uIGNhbiBiZSBhdWdtZW50
ZWQ6DQogICAgDQogICAgICAgIE5vdGU6IFRoZSBhYm92ZSBTRFAgbWVkaWEgZGVzY3JpcHRpb24g
ZG9lcyBub3QgY29udGFpbiBhbnkgY2hhbm5lbC0NCiAgICAgICAgc3BlY2lmaWMgaW5mb3JtYXRp
b24uIElmIGRhdGEgY2hhbm5lbHMgYXJlIHRvIGJlIG5lZ290aWF0ZWQgdXNpbmcNCiAgICAgICAg
U0RQLCB0aGVuIHRoZSBhYm92ZSB3aWxsIGJlIHN1cHBsZW1lbnRlZCBhcyBzcGVjaWZpZWQgaW4g
U2VjdGlvbnMNCiAgICAgICAgNi4zIGFuZCA2LjQuDQogICAgDQogICAgQnV0IEknbSBub3Qgc3Vy
ZSBhYm91dCAiVGhlIGFwcGxpY2F0aW9uIGFsc28gc3BlY2lmaWVzLi4uIi4gSXMgdGhpcyByZWZl
cnJpbmcgdG8gc29tZXRoaW5nIHNwZWNpZmljIGluIHRoZSB3ZWJydGMgQVBJPyBJZiBzbywgZG9l
cyBpdCBwZXJtaXQgYm90aD8gVGhlIHByZXNlbmNlIG9mIGRjbWFwIGluIHRoZSBTRFAgd2lsbCBp
bmRpY2F0ZSB0aGUgaW50ZW50IHRvIHVzZSBTRFAgbmVnb3RpYXRpb24sIGJ1dCBtdXN0IHRoaXMg
Zmlyc3QgYmUgZW5hYmxlZCBpbiB0aGUgQVBJPw0KICAgIA0KICAgIAlUaGFua3MsDQogICAgCVBh
dWwNCiAgICANCiAgICA+IFJlZ2FyZHMsDQogICAgPiANCiAgICA+IENocmlzdGVyDQogICAgPiAN
CiAgICA+IE9uIDI1LzA0LzIwMTksIDEuMjUsICJtbXVzaWMgb24gYmVoYWxmIG9mIFBhdWwgS3l6
aXZhdCIgPG1tdXNpYy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBwa3l6aXZhdEBhbHVt
Lm1pdC5lZHU+IHdyb3RlOg0KICAgID4gDQogICAgPiAgICAgIFRoZSBkaXN0cmlidXRpb24gb2Yg
c3BlY3MgYWNyb3NzIG11bHRpcGxlIGRvY3VtZW50cyBtYWtlcyBpdCByZWFsbHkNCiAgICA+ICAg
ICAgZnV6enkgd2hhdCBpcyBub3JtYXRpdmUgZm9yIHdoYXQuDQogICAgPiAgICAgIA0KICAgID4g
ICAgICBQZXJoYXBzIHNvbWV0aGluZyBzaG91bGQgYmUgc2FpZCBhYm91dCB0aGUgdmFsaWRpdHkg
b2YgdXNpbmcgYQ0KICAgID4gICAgICB3ZWJydGMtZGF0YWNoYW5uZWwgbWVkaWEgc3RyZWFtIGZv
ciBlc3RhYmxpc2hpbmcgZGF0YSBjaGFubmVscyB2aWEgU0RQDQogICAgPiAgICAgIHdpdGggZGNt
YXAgYW5kL29yIERDRVAuIEkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBzYWlkIGFueXdoZXJlIGVsc2Uu
DQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCiAgICBtbXVzaWMgbWFpbGluZyBsaXN0DQogICAgbW11c2ljQGlldGYub3JnDQogICAgaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCiAgICANCg0K


From nobody Sun Apr 28 08:55:57 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C787120161 for ; Sun, 28 Apr 2019 08:55:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGCSjBSiANVm for ; Sun, 28 Apr 2019 08:55:51 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C61C1200DB for ; Sun, 28 Apr 2019 08:55:50 -0700 (PDT)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x3SFsgpY029966 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 28 Apr 2019 11:54:42 -0400
To: Christer Holmberg , "Roni Even (A)" , "mmusic@ietf.org" 
References: <8A9AAAC7-FB2D-4884-BAC6-268B98C7A0F0@ericsson.com>  <81169C37-95F2-418A-A221-CCC623392CD2@ericsson.com> <563cf2bd-474a-8fef-ceaf-e2c72ebc6dc4@alum.mit.edu> <6E58094ECC8D8344914996DAD28F1CCD18CDE434@dggemm526-mbx.china.huawei.com> 
From: Paul Kyzivat 
Message-ID: <32fb1138-4bc1-6315-0c2f-d660ecfafdcd@alum.mit.edu>
Date: Sun, 28 Apr 2019 11:54:41 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP
X-BeenThere: mmusic@ietf.org
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: Sun, 28 Apr 2019 15:55:54 -0000

Christer,

You seem to be suggesting that using dcmap is mutually exclusive with 
using DCEP to negotiate channels. While I guess it would be possible to 
make such a rule I don't see why it is necessary, or a good thing. Why 
not allow them to be used together? (E.g., use SDP to establish the SCTP 
association and negotiate some initial channels, and later use DCEP to 
negotiate some additional channels.)

	Thanks,
	Paul

On 4/28/19 7:57 AM, Christer Holmberg wrote:
> Hi,
> 
>> I think that sections 6.3 and 6.4 that discuss offer/answer say that dcmap is the indication of ruing non dcep.
> 
> Section 6.3 and 6.4 describe how to use dcmap.
> 
> I think it would be useful to e.g., have an Applicability section in the beginning of the document, that explicitly indicates that the procedures in the document apply when a data channel is negotiated using the dcmap attribute, and that DCEP is then not used.
> 
> But, what if an offerer wants to negotiate a data channel, before deciding what exactly it is going to be used for, but still wants to indicate usage of SDPNEG. Including an empty dcmap attribute?
> 
>>     The example in section 7 say that if dcmap is rejected dcep may be negotiated.
>>     Maybe this line form section 7 should be in section 6.4?
> 
> Normative text should definitely not be in Section 7.
> 
> However, if the answerer does not want to use SDPNEG, I think it's up to the offerer to decide whether to continue the session establishment, or fallback to DCEP.
> 
> Regards,
> 
> Christer
> 
> 
> 
>      
>      -----Original Message-----
>      From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat
>      Sent: Friday, April 26, 2019 6:16 PM
>      To: Christer Holmberg; mmusic@ietf.org
>      Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP
>      
>      On 4/26/19 5:37 AM, Christer Holmberg wrote:
>      > Hi Paul,
>      >
>      > So, what is your suggestion? __
>      
>      It looks to me like the 2nd paragraph of Appendix A is the right place for this:
>      
>          A WebRTC application creates a data channel by providing a number of
>          setup parameters (subprotocol, label, maximal number of
>          retransmissions, maximal retransmission time, order of delivery,
>          priority).  The application also specifies if it wants to make use of
>          the negotiation using the DCEP [I-D.ietf-rtcweb-data-protocol], or if
>          the application intends to negotiate data channels using the SDP
>          offer/answer protocol.
>      
>      I'm inclined to tweak the above as follows:
>      
>          ...
>          the application intends to negotiate data channels using the SDP
>          offer/answer protocol, or both.
>      
>      And then, the note at the end of the section can be augmented:
>      
>          Note: The above SDP media description does not contain any channel-
>          specific information. If data channels are to be negotiated using
>          SDP, then the above will be supplemented as specified in Sections
>          6.3 and 6.4.
>      
>      But I'm not sure about "The application also specifies...". Is this referring to something specific in the webrtc API? If so, does it permit both? The presence of dcmap in the SDP will indicate the intent to use SDP negotiation, but must this first be enabled in the API?
>      
>      	Thanks,
>      	Paul
>      
>      > Regards,
>      >
>      > Christer
>      >
>      > On 25/04/2019, 1.25, "mmusic on behalf of Paul Kyzivat"  wrote:
>      >
>      >      The distribution of specs across multiple documents makes it really
>      >      fuzzy what is normative for what.
>      >
>      >      Perhaps something should be said about the validity of using a
>      >      webrtc-datachannel media stream for establishing data channels via SDP
>      >      with dcmap and/or DCEP. I don't think this is said anywhere else.
>      
>      _______________________________________________
>      mmusic mailing list
>      mmusic@ietf.org
>      https://www.ietf.org/mailman/listinfo/mmusic
>      
> 


From nobody Sun Apr 28 09:43:57 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9494812007A for ; Sun, 28 Apr 2019 09:43:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kc0OEgZgm6fX for ; Sun, 28 Apr 2019 09:43:52 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40061.outbound.protection.outlook.com [40.107.4.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12418120077 for ; Sun, 28 Apr 2019 09:43:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L5O5lq9ewAG/R7nwIZBWl8Sak7wMTBhHnCEm+/RY8xs=; b=D49HLXzk+1+gi3p0H2x1dlIYqXA919DOpNypX2GJ6V+G+RV2PIY91gnIrzbeZ+5dhsvwjgyzxrEdpeSr11A3Sj6WIjAIW0bP+8knua6Wf6fFLk8tobOxDYEcfmvm3aaf3xuWMjl58Hx1X5tyKY4huiwZk6gX2xAs3OkwXV140vU=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4217.eurprd07.prod.outlook.com (20.176.166.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.7; Sun, 28 Apr 2019 16:43:49 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::c999:f848:9abc:d321]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::c999:f848:9abc:d321%6]) with mapi id 15.20.1856.008; Sun, 28 Apr 2019 16:43:49 +0000
From: Christer Holmberg 
To: Paul Kyzivat , "Roni Even (A)" , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] SDPNEG: How to disable DCEP
Thread-Index: AQHU+njrOtTA5N+Kv0Ox965sWihq+KZL5CwAgAKAjYCAACw0AIACj2qAgACQLACAAA/sgIAADWDZ
Date: Sun, 28 Apr 2019 16:43:48 +0000
Message-ID: 
References: <8A9AAAC7-FB2D-4884-BAC6-268B98C7A0F0@ericsson.com>  <81169C37-95F2-418A-A221-CCC623392CD2@ericsson.com> <563cf2bd-474a-8fef-ceaf-e2c72ebc6dc4@alum.mit.edu> <6E58094ECC8D8344914996DAD28F1CCD18CDE434@dggemm526-mbx.china.huawei.com> , <32fb1138-4bc1-6315-0c2f-d660ecfafdcd@alum.mit.edu>
In-Reply-To: <32fb1138-4bc1-6315-0c2f-d660ecfafdcd@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-originating-ip: [176.93.0.86]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1a055be6-8332-4b42-519f-08d6cbf8b05e
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB4217; 
x-ms-traffictypediagnostic: HE1PR07MB4217:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0021920B5A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(396003)(366004)(39860400002)(376002)(189003)(13464003)(51444003)(199004)(26005)(54896002)(110136005)(6506007)(81156014)(1015004)(53546011)(9686003)(81166006)(102836004)(256004)(6306002)(14444005)(53936002)(97736004)(76176011)(55016002)(93886005)(8676002)(478600001)(86362001)(68736007)(8936002)(7696005)(2171002)(966005)(73956011)(66946007)(2501003)(66556008)(229853002)(3846002)(64756008)(66446008)(66476007)(19627405001)(76116006)(6116002)(476003)(5660300002)(186003)(606006)(6246003)(52536014)(74316002)(44832011)(66066001)(486006)(14454004)(236005)(99286004)(71190400001)(2906002)(446003)(33656002)(71200400001)(11346002)(6436002)(25786009)(7736002)(6606003)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4217; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 2Li+XrnIRq/1QP5gTmI1TrUjKuheobAMte3ukKdJOdo62JX2RyGkb2n2WwIUyjte0p1bY/YofV6XE7kXmYvJIxCjTgjfjDwSBxHnl0q1sbTpzGbfhOsPN5qEr0EzkMXXWCxYR8J58Yu9pWQNzcFOqQCm0hLxD5DVlTs/AHpHIfAm9MY7o1RN9UrcMhZXWIZ6uV4LX1abemNgopac+isEWZSc3u3ilew6FUtRCO5H5SbkDDeg1Qexp6/RJdpuTWDTW7ByhgNJy21dMes+xOZllEid7EqMzjbQ600Y62WT45xo19arcRoyEy0UDSnty+7EvdAsyKpO5xq7o8mqF4miaYpis7metUlVHFGbZtgTnq4klKKc8/iPVt9sc8VWbKAIKl5cSuDEsBCmzYS7DMDm5cLJk1p2N8VCqWi2FkcvnDE=
Content-Type: multipart/alternative; boundary="_000_HE1PR07MB3161D0503C6913360B3274B293380HE1PR07MB3161eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1a055be6-8332-4b42-519f-08d6cbf8b05e
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2019 16:43:48.9154 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4217
Archived-At: 
Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP
X-BeenThere: mmusic@ietf.org
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: Sun, 28 Apr 2019 16:43:56 -0000

--_000_HE1PR07MB3161D0503C6913360B3274B293380HE1PR07MB3161eurp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Hi,

>You seem to be suggesting that using dcmap is mutually exclusive with
>using DCEP to negotiate channels. While I guess it would be possible to
>make such a rule I don't see why it is necessary, or a good thing. Why
>not allow them to be used together? (E.g., use SDP to establish the SCTP
>association and negotiate some initial channels, and later use DCEP to
>negotiate some additional channels.)

I agree they can be used together. dcmap is a media-level attribute, so any=
 rule obviously only apply to a given m- line.

Regards,

Christer


On 4/28/19 7:57 AM, Christer Holmberg wrote:
> Hi,
>
>> I think that sections 6.3 and 6.4 that discuss offer/answer say that dcm=
ap is the indication of ruing non dcep.
>
> Section 6.3 and 6.4 describe how to use dcmap.
>
> I think it would be useful to e.g., have an Applicability section in the =
beginning of the document, that explicitly indicates that the procedures in=
 the document apply when a data channel is negotiated using the dcmap attri=
bute, and that DCEP is then not used.
>
> But, what if an offerer wants to negotiate a data channel, before decidin=
g what exactly it is going to be used for, but still wants to indicate usag=
e of SDPNEG. Including an empty dcmap attribute?
>
>>     The example in section 7 say that if dcmap is rejected dcep may be n=
egotiated.
>>     Maybe this line form section 7 should be in section 6.4?
>
> Normative text should definitely not be in Section 7.
>
> However, if the answerer does not want to use SDPNEG, I think it's up to =
the offerer to decide whether to continue the session establishment, or fal=
lback to DCEP.
>
> Regards,
>
> Christer
>
>
>
>
>      -----Original Message-----
>      From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzi=
vat
>      Sent: Friday, April 26, 2019 6:16 PM
>      To: Christer Holmberg; mmusic@ietf.org
>      Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP
>
>      On 4/26/19 5:37 AM, Christer Holmberg wrote:
>      > Hi Paul,
>      >
>      > So, what is your suggestion? __
>
>      It looks to me like the 2nd paragraph of Appendix A is the right pla=
ce for this:
>
>          A WebRTC application creates a data channel by providing a numbe=
r of
>          setup parameters (subprotocol, label, maximal number of
>          retransmissions, maximal retransmission time, order of delivery,
>          priority).  The application also specifies if it wants to make u=
se of
>          the negotiation using the DCEP [I-D.ietf-rtcweb-data-protocol], =
or if
>          the application intends to negotiate data channels using the SDP
>          offer/answer protocol.
>
>      I'm inclined to tweak the above as follows:
>
>          ...
>          the application intends to negotiate data channels using the SDP
>          offer/answer protocol, or both.
>
>      And then, the note at the end of the section can be augmented:
>
>          Note: The above SDP media description does not contain any chann=
el-
>          specific information. If data channels are to be negotiated usin=
g
>          SDP, then the above will be supplemented as specified in Section=
s
>          6.3 and 6.4.
>
>      But I'm not sure about "The application also specifies...". Is this =
referring to something specific in the webrtc API? If so, does it permit bo=
th? The presence of dcmap in the SDP will indicate the intent to use SDP ne=
gotiation, but must this first be enabled in the API?
>
>        Thanks,
>        Paul
>
>      > Regards,
>      >
>      > Christer
>      >
>      > On 25/04/2019, 1.25, "mmusic on behalf of Paul Kyzivat"  wrote:
>      >
>      >      The distribution of specs across multiple documents makes it =
really
>      >      fuzzy what is normative for what.
>      >
>      >      Perhaps something should be said about the validity of using =
a
>      >      webrtc-datachannel media stream for establishing data channel=
s via SDP
>      >      with dcmap and/or DCEP. I don't think this is said anywhere e=
lse.
>
>      _______________________________________________
>      mmusic mailing list
>      mmusic@ietf.org
>      https://www.ietf.org/mailman/listinfo/mmusic
>
>


--_000_HE1PR07MB3161D0503C6913360B3274B293380HE1PR07MB3161eurp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable















Hi,











>You seem to be suggesting that using dcmap is =
mutually exclusive with


>using DCEP to negotiate channels. While I guess it would be possible to=
 

>make such a rule I don't see why it is necessary, or a good thing. Why =


>not allow them to be used together? (E.g., use SDP to establish the SCT=
P 

>association and negotiate some initial channels, and later use DCEP to =


>negotiate some additional channels.)






I agree they can be used together. dcmap is a medi=
a-level attribute, so any rule obviously only apply to a given m- line.






Regards,







Christer












On 4/28/19 7:57 AM, Christer Holmberg wrote:

> Hi,

> 

>> I think that sections 6.3 and 6.4 that discuss offer/answer say th=
at dcmap is the indication of ruing non dcep.

> 

> Section 6.3 and 6.4 describe how to use dcmap.

> 

> I think it would be useful to e.g., have an Applicability section in t=
he beginning of the document, that explicitly indicates that the procedures=
 in the document apply when a data channel is negotiated using the dcmap at=
tribute, and that DCEP is then not
 used.

> 

> But, what if an offerer wants to negotiate a data channel, before deci=
ding what exactly it is going to be used for, but still wants to indicate u=
sage of SDPNEG. Including an empty dcmap attribute?

> 

>>     The example in section 7 say that if dcmap=
 is rejected dcep may be negotiated.

>>     Maybe this line form section 7 should be i=
n section 6.4?

> 

> Normative text should definitely not be in Section 7.

> 

> However, if the answerer does not want to use SDPNEG, I think it's up =
to the offerer to decide whether to continue the session establishment, or =
fallback to DCEP.

> 

> Regards,

> 

> Christer

> 

> 

> 

>      

>      -----Original Message-----

>      From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat

>      Sent: Friday, April 26, 2019 6:16 PM

>      To: Christer Holmberg; mmusic@ietf.org
>      Subject: Re: [MMUSIC] SDPNEG: How to dis=
able DCEP

>      

>      On 4/26/19 5:37 AM, Christer Holmberg wr=
ote:

>      > Hi Paul,

>      >

>      > So, what is your suggestion? __

>      

>      It looks to me like the 2nd paragraph of=
 Appendix A is the right place for this:

>      

>          A WebRTC applica=
tion creates a data channel by providing a number of

>          setup parameters=
 (subprotocol, label, maximal number of

>          retransmissions,=
 maximal retransmission time, order of delivery,

>          priority). =
 The application also specifies if it wants to make use of

>          the negotiation =
using the DCEP [I-D.ietf-rtcweb-data-protocol], or if

>          the application =
intends to negotiate data channels using the SDP

>          offer/answer pro=
tocol.

>      

>      I'm inclined to tweak the above as follo=
ws:

>      

>          ...

>          the application =
intends to negotiate data channels using the SDP

>          offer/answer pro=
tocol, or both.

>      

>      And then, the note at the end of the sec=
tion can be augmented:

>      

>          Note: The above =
SDP media description does not contain any channel-

>          specific informa=
tion. If data channels are to be negotiated using

>          SDP, then the ab=
ove will be supplemented as specified in Sections

>          6.3 and 6.4.

>      

>      But I'm not sure about "The applica=
tion also specifies...". Is this referring to something specific in th=
e webrtc API? If so, does it permit both? The presence of dcmap in the SDP =
will indicate the intent to use SDP negotiation, but must this first be
 enabled in the API?

>      

>        Thanks,

>        Paul

>      

>      > Regards,

>      >

>      > Christer

>      >

>      > On 25/04/2019, 1.25, "mmusic o=
n behalf of Paul Kyzivat" <mmusic-bounces@ietf.org on behalf of pky=
zivat@alum.mit.edu> wrote:

>      >

>      >      The d=
istribution of specs across multiple documents makes it really

>      >      fuzzy=
 what is normative for what.

>      >

>      >      Perha=
ps something should be said about the validity of using a

>      >      webrt=
c-datachannel media stream for establishing data channels via SDP

>      >      with =
dcmap and/or DCEP. I don't think this is said anywhere else.

>      

>      ________________________________________=
_______

>      mmusic mailing list

>      mmusic@ietf.org

>      
https://www.ietf.org/mailman/listinfo/mmusic

>      

> 














--_000_HE1PR07MB3161D0503C6913360B3274B293380HE1PR07MB3161eurp_--


From nobody Sun Apr 28 19:04:01 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3723312017E; Sun, 28 Apr 2019 19:03:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6G5M_M60FNW; Sun, 28 Apr 2019 19:03:48 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D93E6120260; Sun, 28 Apr 2019 19:03:47 -0700 (PDT)
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3T23YLv011553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 28 Apr 2019 22:03:36 -0400
Date: Sun, 28 Apr 2019 21:03:34 -0500
From: Benjamin Kaduk 
To: "Roni Even (A)" 
Cc: The IESG , "draft-ietf-mmusic-data-channel-sdpneg@ietf.org" ,  Bo Burman , "mmusic-chairs@ietf.org" , "mmusic@ietf.org" 
Message-ID: <20190429020308.GG60332@kduck.mit.edu>
References: <155495118561.22741.226184336926630062.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD18CDD817@dggemm526-mbx.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD18CDD817@dggemm526-mbx.china.huawei.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: 
Subject: Re: [MMUSIC] Benjamin Kaduk's No Objection on draft-ietf-mmusic-data-channel-sdpneg-25: (with COMMENT)
X-BeenThere: mmusic@ietf.org
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: Mon, 29 Apr 2019 02:03:52 -0000

On Tue, Apr 23, 2019 at 12:47:10PM +0000, Roni Even (A) wrote:
> Hi,
> Thanks for the review, see inline
> Roni
> 
> -----Original Message-----
> From: Benjamin Kaduk via Datatracker [mailto:noreply@ietf.org] 
> Sent: Thursday, April 11, 2019 5:53 AM
> To: The IESG
> Cc: draft-ietf-mmusic-data-channel-sdpneg@ietf.org; Bo Burman; mmusic-chairs@ietf.org; bo.burman@ericsson.com; mmusic@ietf.org
> Subject: Benjamin Kaduk's No Objection on draft-ietf-mmusic-data-channel-sdpneg-25: (with COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-mmusic-data-channel-sdpneg-25: No Objection
> 
> When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Section 4
> 
>    The mechanism in this document only applies to the Session
>    Description Protocol (SDP) [I-D.ietf-mmusic-rfc4566bis] when used
>    together with the SDP offer/answer mechanism [RFC3264].  Declarative
>    usage of SDP is out of scope of this document, and is thus undefined.
> 
> nit: this text doesn't actually scope itself to "this mechanism" or the RTCWeb data channel, and seems to be saying that all declarative SDP is undefined, globally.
> 
> RE: change to " Declarative  usage of SDP is out of scope for this document, and is thus undefined."
> 
> Section 5.1.7
> 
>                                 The ordered parameter is optional and
>    takes two values: "true" for ordered and "false" for unordered
>    delivery with "true" as the default value.  Any other value is
>    ignored and default "ordered=true" is assumed.  [...]
> 
> This seems to be saying that offers or answers that do not conform to the ABNF will be special-cased as being ignored (instead of rejected) when they appear where ordering-value should appear.  It's not clear to me why we need a special case here, since in Section 8 we explicitly say that peers MUST close the relevant data channel when such error cases occur.
> 
> RE: this statement only applies to the ordered parameter, I am not sure why you think it is for any parameter.

I do not think it is for any parameter.
I'm just not sure why the 'ordered' parameter is so important that we need
to specify the behavior on receipt of ordered="notaboolean", and to some
extent, why the behavior that we do specify for that case is different from
the behavior we would otherwise expect (rejecting the offer, IIUC).  In
short, the text seems superfluous given my understanding at the time  I
read id, and I wanted to understand why it was there.

> Section 5.1.8
> 
> If we chase links to draft-ietf-rtcweb-data-channel we find that larger values indicate higher priority.  Do we want to short-circuit that and say so explicitly here?
> 
> RE: I prefer to keep the link since otherwise any change in the rtcweb document will require a change here.
> 
> Section 5.2
> 
>                                                                    Each
>    of these attributes is represented by one new attribute line, and it
>    includes the contents of a media-level SDP attribute already defined
>    for use with this (sub)protocol in another IETF (Internet Engineering
>    Task Force) document.  [...]
> 
> Do we need to limit the data-channel subprotocols to those specified by the IETF?  Or is it just the media-level SDP attributes that we are trying to maintain change control over?
> 
> RE: it is just the SDP attributes, this is the dcsa section. Sub protocols are specified for dcmap

Okay, thanks for confirming.

>    The detailed offer/answer procedures for the dcsa attribute are
>    dependent on the associated sub-protocol.  If no offer/answer
>    procedures exist for the sub-protocol when used outside of the dcsa
>    attribute, no specification is needed for use with dcsa.  The IANA
>    registration procedures for the WebSocket Subprotocol Name Registry
>    (Section 9.1) do not strictly require a specification of the offer/
>    answer procedures for the sub-protocol when used with dcsa.  If the
>    sub-protocol has defined offer/answer procedures when used outside of
>    dcsa, such a specification is encouraged to ensure interoperability.
>    If the sub-protocol has defined offer/answer procedures when used
>    outside of dcsa, but no specification exists for the offer/answer
>    procedures for the sub-protocol when used with dcsa, implementations
>    SHOULD assume the use of the default values for all otherwise-
>    negotiable and applicable sub-protocol parameters.
> 
> I'm not entirely sure I understand what this paragraph is trying to say.
> The first sentence is clear, but the second sentence seems to be saying that if there are no O/A procedures for a given subprotocol outside the datachannel, it's just a free for all and I can use it in the data channel and make up my own procedures for using the dcsa attribute.
> I understand that IANA doesn't require a specification for the subprotocol when allocating the subprotocol name, but that just means that there may not be a specification available whether or not I want to use it with dcsa -- the IANA registry doesn't care directly about use with dcsa.  If a subprotocol has defined O/A procedures outside of dcsa, doesn't that basically mean there's a specification?  Why do we need to go out of our way to encourage a specification in that case (and is it a specification of the O/A semantics when the subprotocol is used outside dcsa or with dcsa)?  In the last sentence, I think we're talking about using defaults for parameters that are not explicitly negotiated using dcsa, but we don't actually say that.
> 
> RE- Since subprotocols can be registered with IANA on FCFS we cannot assume that there will be a document that will address the offer answer but we would like to encourage it.
> 
> Section 5.2.1
> 
>                                                Note however that not all
>    SDP attributes are suitable as a "a=dcsa:" parameter.  IANA SDP
>    parameters contains the lists of IANA (Internet Assigned Numbers
>    Authority) registered session and media level or media level only SDP
>    attributes.
> 
> Am I supposed to infer that these are the attributes that are suitable for a=dcsa: parameters?
> 
> RE: added the following text to this section:
> 
> " SDP attributes that are only defined for use at the
>    dcsa usage level, SHALL use the dcsa usage level when registering the
>    attribute.  If existing media attributes are used in a datachannel
>    subprotocol specific way, then a new dcsa usage level
>    MUST be defined for the existing media attribute.  Where the SDP
>   attribute is applicable to a particular subprotocol/s this SHALL also
>    be registered by indicating the applicable subprotocol identifiers
>    (see https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-34#section-8.5) along with the dcsa usage level.
> "
> Note that rfc4566bis changes the registration table in IANA
> 
>    As opposed to the data channel "a=dcmap:" attribute parameters, these
>    parameters are subject to offer/answer negotiation following the
>    procedures defined in the subprotocol specific documents.
> 
> I am not sure where we really say that the a=dcmap: parameters are not subject to O/A negotiation.
> 
> RE: see section 6.4 , dcmap is either accepted as is or rejected.
> 
> Section 6.1
> 
>    SCTP stream identifiers associated with data channels that have been
>    negotiated using DCEP MUST NOT be included in SDP offers and answers.
> 
> This sentence appears as a dedicated paragraph and is duplicated at the end of the previous paragraph; presumably we only need one copy thereof...
> 
> RE: yes, thanks
> 
> Section 6.2
> 
>                                          If an SDP answer contains both
>    of these parameters then the offerer MUST treat the associated SDP
>    offer/answer failed.
> 
> nit: "as failed", I think.
> 
> RE: OK
> 
> Section 6.4
> 
> We only mention that the dcmap-stream-id, max-retr, and max-time values need to match the offer, leaving the ordering/subprotocol/label/priority
> to be omitted because they are conveyed at the SCTP layer?  Perhaps we should state explicitly that they need to be absent...
> 
> RE: they can be different in each direction

Ah, thanks.

> Section 6.6
> 
> Do we want to say anything about the appropriate response to receiving changed values for the SDP attributes/attribute values is to close the corresponding data channel?
> 
> RE: Added text in the -26 version about this being application dependent
> 
> Section 6.6.1
> 
> It seems like the second bullet point only makes sense after the first has completed, as the tsvart reviewer noted?  Specifically, the "; or"
> at the end of the first bullet point doesn't seem to make much sense.
> 
> RE: after the data channel is reset you can use a new data channel with a new dcmap value 
> 
> Section 9.3
> 
>                If existing media attributes are used in a datachannel
>    subprotocol specific way (Section 5.2.1), then a new dcsa usage level
>    MUST be defined for the existing media attribute.  [...]
> 
> I'm not entirely sure that I understand what this means, though I'm not really an expert in SDP.
> 
> RE: this section was removed see my comment on section 5.2.1
> 
> Appendix A.1
> 
> I'm not sure that I know what "glare situations" are; is there a reasonable reference to include?
> 
> RE: this is an offer/answer term in RFC3264 and known to anyone who is doing offer/answer (I can add a reference to RFC3264)

(Probably no need to add the reference just for me; my apologies for not
having checked the background material.)

Thanks for all the clarifications,

Ben

>    Which set of stream identifiers is owned by which endpoint is
>    determined by convention or other means.
> 
> (specific to the application?)
> 
>       Note:For data channels negotiated via different protocol from
>       DCEP, no convention is defined by default.
> 
> That seems a bit misleading, since Section 6.1 says that the even/odd split applies to the SDP O/A negotiation case.
> 
> RE: this is true and the note says that for non DCEP you need to specify the convention which is done in section 6.1
> 
> 


From nobody Mon Apr 29 01:25:03 2019
Return-Path: 
X-Original-To: mmusic@ietf.org
Delivered-To: mmusic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8870412015C; Mon, 29 Apr 2019 01:24:55 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: mmusic@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: mmusic@ietf.org
Message-ID: <155652629548.18610.16434322425852509708@ietfa.amsl.com>
Date: Mon, 29 Apr 2019 01:24:55 -0700
Archived-At: 
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-data-channel-sdpneg-27.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Apr 2019 08:24:56 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia Session Control WG of the IETF.

        Title           : SDP-based Data Channel Negotiation
        Authors         : Keith Drage
                          Maridi R. Makaraju (Raju)
                          Richard Ejzak
                          Jerome Marcon
                          Roni Even
	Filename        : draft-ietf-mmusic-data-channel-sdpneg-27.txt
	Pages           : 40
	Date            : 2019-04-29

Abstract:
   Data channel setup can be done using either the in-band Data Channel
   Establishment Protocol (DCEP) or using some out-of-band non-DCEP
   protocol.  This document specifies how the SDP (Session Description
   Protocol) offer/answer exchange can be used to achieve an out-of-band
   non-DCEP negotiation for establishing a data channel.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-27
https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-data-channel-sdpneg-27

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-data-channel-sdpneg-27


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Apr 29 05:54:14 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A1F120343 for ; Mon, 29 Apr 2019 05:54:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdmqGYh0XVh5 for ; Mon, 29 Apr 2019 05:54:08 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70057.outbound.protection.outlook.com [40.107.7.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF4712034C for ; Mon, 29 Apr 2019 05:54:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eZ98UvZRoDjyFzfJN0O86ZWMzq++JhBRz7u1K2Z1nfo=; b=a7vgPR4bVJaYSHK2DgmV0CkMEWnimH9x2z+/0Vgxj/jeR8greqnXOOV2nR1J09d7h7wGqkBGl+h4vc9Kp+JgGCW3xwmhQN9VzOeM9ulGCwYKo9GyvNpP+QoNriR2OgvBlTbgpOV392dSH1Hkz4GluFK2zi0oJMkhMvTcHXVKBTk=
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3258.eurprd07.prod.outlook.com (10.170.246.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.4; Mon, 29 Apr 2019 12:54:04 +0000
Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::c999:f848:9abc:d321]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::c999:f848:9abc:d321%6]) with mapi id 15.20.1856.008; Mon, 29 Apr 2019 12:54:04 +0000
From: Christer Holmberg 
To: Paul Kyzivat , "Roni Even (A)" , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] SDPNEG: How to disable DCEP
Thread-Index: AQHU+njrOtTA5N+Kv0Ox965sWihq+KZL5CwAgAKAjYCAACw0AIACj2qAgACQLACAAA/sgIABXhC/
Date: Mon, 29 Apr 2019 12:54:03 +0000
Message-ID: 
References: <8A9AAAC7-FB2D-4884-BAC6-268B98C7A0F0@ericsson.com>  <81169C37-95F2-418A-A221-CCC623392CD2@ericsson.com> <563cf2bd-474a-8fef-ceaf-e2c72ebc6dc4@alum.mit.edu> <6E58094ECC8D8344914996DAD28F1CCD18CDE434@dggemm526-mbx.china.huawei.com> , <32fb1138-4bc1-6315-0c2f-d660ecfafdcd@alum.mit.edu>
In-Reply-To: <32fb1138-4bc1-6315-0c2f-d660ecfafdcd@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; 
x-originating-ip: [89.166.49.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5935642b-7c18-45f8-a72b-08d6cca1c241
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3258; 
x-ms-traffictypediagnostic: HE1PR07MB3258:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0022134A87
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(376002)(39860400002)(136003)(396003)(51444003)(13464003)(199004)(189003)(44832011)(478600001)(68736007)(66066001)(966005)(5660300002)(102836004)(14454004)(81156014)(76176011)(71200400001)(71190400001)(2906002)(7696005)(99286004)(81166006)(316002)(97736004)(25786009)(1015004)(74316002)(6246003)(6606003)(33656002)(55016002)(8676002)(52536014)(26005)(8936002)(186003)(7736002)(110136005)(9686003)(93886005)(6436002)(486006)(6306002)(53936002)(3846002)(236005)(86362001)(6116002)(446003)(54896002)(66556008)(229853002)(256004)(476003)(14444005)(2501003)(66946007)(73956011)(2171002)(11346002)(606006)(6506007)(19627405001)(66446008)(64756008)(76116006)(53546011)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3258; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: rc1cQoFC9des7SAE8GR+B5xX4o8+perTDKfATfo3UKhrFQz+D2VcK8HeORfHLtdAcEIWVPa5RanchKt9F5Uqp2gBLOLNwTPkQEuskhRuDpMGN1//TwYJqgmjq1D2XVKjmX6pwz5pDUGC8nM4Y/l/87rLDKFXEumeB/3zQWxn11i4GVDYROdEhaEDvef93JQPA/kc39W8spr0Wh1AX28cTpE82Sa2WY0BFv7I+RQk0YnBussfzQRi9+bo8DHs4rjoycvZJpxAXD5B8Mw9Y2JLjBNjSAsl/d9Ix6vXvOVpYn/pSnV8RDJt9Jyc1FpkrXTshslV0mgKo7M7+2MWywQe6bVgWzFvsKkPtzS+hQwr1iehdBnnffSDX3FEkeeFw3Uh0Jgrv6GmF7yFGvUyKJmW3EJ4YYzDl5SUhOamsELwS+w=
Content-Type: multipart/alternative; boundary="_000_HE1PR07MB316176E6552193AB4B39DC6093390HE1PR07MB3161eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5935642b-7c18-45f8-a72b-08d6cca1c241
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2019 12:54:03.8918 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3258
Archived-At: 
Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP
X-BeenThere: mmusic@ietf.org
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: Mon, 29 Apr 2019 12:54:12 -0000

--_000_HE1PR07MB316176E6552193AB4B39DC6093390HE1PR07MB3161eurp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,


>You seem to be suggesting that using dcmap is mutually exclusive with
>using DCEP to negotiate channels. While I guess it would be possible to
>make such a rule I don't see why it is necessary, or a good thing. Why
>not allow them to be used together? (E.g., use SDP to establish the SCTP
>association and negotiate some initial channels, and later use DCEP to
>negotiate some additional channels.)

You are right - one can use both SDPNEG and DCEP for the same SCEP associat=
ion (read: same m- line).

But, if I establish the SCTP association - but do not negotiate some initia=
l channels using SDPNEG - the peer won't know that I support SDPNEG, so I a=
ssume it will always try to use DCEP.

Having explicit support indicators, that are separate from the actual proto=
col indicators, is always good in my opinion.

But, perhaps we should have thought about that earlier. Let's make whatever=
 clarifications are needed and ship the document :)

Regards,

Christer




On 4/28/19 7:57 AM, Christer Holmberg wrote:
> Hi,
>
>> I think that sections 6.3 and 6.4 that discuss offer/answer say that dcm=
ap is the indication of ruing non dcep.
>
> Section 6.3 and 6.4 describe how to use dcmap.
>
> I think it would be useful to e.g., have an Applicability section in the =
beginning of the document, that explicitly indicates that the procedures in=
 the document apply when a data channel is negotiated using the dcmap attri=
bute, and that DCEP is then not used.
>
> But, what if an offerer wants to negotiate a data channel, before decidin=
g what exactly it is going to be used for, but still wants to indicate usag=
e of SDPNEG. Including an empty dcmap attribute?
>
>>     The example in section 7 say that if dcmap is rejected dcep may be n=
egotiated.
>>     Maybe this line form section 7 should be in section 6.4?
>
> Normative text should definitely not be in Section 7.
>
> However, if the answerer does not want to use SDPNEG, I think it's up to =
the offerer to decide whether to continue the session establishment, or fal=
lback to DCEP.
>
> Regards,
>
> Christer
>
>
>
>
>      -----Original Message-----
>      From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzi=
vat
>      Sent: Friday, April 26, 2019 6:16 PM
>      To: Christer Holmberg; mmusic@ietf.org
>      Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP
>
>      On 4/26/19 5:37 AM, Christer Holmberg wrote:
>      > Hi Paul,
>      >
>      > So, what is your suggestion? __
>
>      It looks to me like the 2nd paragraph of Appendix A is the right pla=
ce for this:
>
>          A WebRTC application creates a data channel by providing a numbe=
r of
>          setup parameters (subprotocol, label, maximal number of
>          retransmissions, maximal retransmission time, order of delivery,
>          priority).  The application also specifies if it wants to make u=
se of
>          the negotiation using the DCEP [I-D.ietf-rtcweb-data-protocol], =
or if
>          the application intends to negotiate data channels using the SDP
>          offer/answer protocol.
>
>      I'm inclined to tweak the above as follows:
>
>          ...
>          the application intends to negotiate data channels using the SDP
>          offer/answer protocol, or both.
>
>      And then, the note at the end of the section can be augmented:
>
>          Note: The above SDP media description does not contain any chann=
el-
>          specific information. If data channels are to be negotiated usin=
g
>          SDP, then the above will be supplemented as specified in Section=
s
>          6.3 and 6.4.
>
>      But I'm not sure about "The application also specifies...". Is this =
referring to something specific in the webrtc API? If so, does it permit bo=
th? The presence of dcmap in the SDP will indicate the intent to use SDP ne=
gotiation, but must this first be enabled in the API?
>
>        Thanks,
>        Paul
>
>      > Regards,
>      >
>      > Christer
>      >
>      > On 25/04/2019, 1.25, "mmusic on behalf of Paul Kyzivat"  wrote:
>      >
>      >      The distribution of specs across multiple documents makes it =
really
>      >      fuzzy what is normative for what.
>      >
>      >      Perhaps something should be said about the validity of using =
a
>      >      webrtc-datachannel media stream for establishing data channel=
s via SDP
>      >      with dcmap and/or DCEP. I don't think this is said anywhere e=
lse.
>
>      _______________________________________________
>      mmusic mailing list
>      mmusic@ietf.org
>      https://www.ietf.org/mailman/listinfo/mmusic
>
>


--_000_HE1PR07MB316176E6552193AB4B39DC6093390HE1PR07MB3161eurp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










Hi,











>You seem to be suggesting that using dcmap is =
mutually exclusive with


>using DCEP to negotiate channels. While I guess it would be possible to=
 

>make such a rule I don't see why it is necessary, or a good thing. Why =


>not allow them to be used together? (E.g., use SDP to establish the SCT=
P 

>association and negotiate some initial channels, and later use DCEP to =


>negotiate some additional channels.)



You are right - one can use both SDPNEG and DCEP for the same SCEP associat=
ion (read: same m- line).







But, if I establish the SCTP association - but do =
not negotiate some initial channels using SDPNEG - the peer won't know that=
 I support SDPNEG, so I assume it will always try to use DCEP.







Having explicit support indicators, that are separ=
ate from the actual protocol indicators, is always good in my opinion. =
;







But, perhaps we should have thought about that ear=
lier. Let's make whatever clarifications are needed and ship the document :=
)









Regards,







Christer










On 4/28/19 7:57 AM, Christer Holmberg wrote:

> Hi,

> 

>> I think that sections 6.3 and 6.4 that discuss offer/answer say th=
at dcmap is the indication of ruing non dcep.

> 

> Section 6.3 and 6.4 describe how to use dcmap.

> 

> I think it would be useful to e.g., have an Applicability section in t=
he beginning of the document, that explicitly indicates that the procedures=
 in the document apply when a data channel is negotiated using the dcmap at=
tribute, and that DCEP is then not
 used.

> 

> But, what if an offerer wants to negotiate a data channel, before deci=
ding what exactly it is going to be used for, but still wants to indicate u=
sage of SDPNEG. Including an empty dcmap attribute?

> 

>>     The example in section 7 say that if dcmap=
 is rejected dcep may be negotiated.

>>     Maybe this line form section 7 should be i=
n section 6.4?

> 

> Normative text should definitely not be in Section 7.

> 

> However, if the answerer does not want to use SDPNEG, I think it's up =
to the offerer to decide whether to continue the session establishment, or =
fallback to DCEP.

> 

> Regards,

> 

> Christer

> 

> 

> 

>      

>      -----Original Message-----

>      From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat

>      Sent: Friday, April 26, 2019 6:16 PM

>      To: Christer Holmberg; mmusic@ietf.org
>      Subject: Re: [MMUSIC] SDPNEG: How to dis=
able DCEP

>      

>      On 4/26/19 5:37 AM, Christer Holmberg wr=
ote:

>      > Hi Paul,

>      >

>      > So, what is your suggestion? __

>      

>      It looks to me like the 2nd paragraph of=
 Appendix A is the right place for this:

>      

>          A WebRTC applica=
tion creates a data channel by providing a number of

>          setup parameters=
 (subprotocol, label, maximal number of

>          retransmissions,=
 maximal retransmission time, order of delivery,

>          priority). =
 The application also specifies if it wants to make use of

>          the negotiation =
using the DCEP [I-D.ietf-rtcweb-data-protocol], or if

>          the application =
intends to negotiate data channels using the SDP

>          offer/answer pro=
tocol.

>      

>      I'm inclined to tweak the above as follo=
ws:

>      

>          ...

>          the application =
intends to negotiate data channels using the SDP

>          offer/answer pro=
tocol, or both.

>      

>      And then, the note at the end of the sec=
tion can be augmented:

>      

>          Note: The above =
SDP media description does not contain any channel-

>          specific informa=
tion. If data channels are to be negotiated using

>          SDP, then the ab=
ove will be supplemented as specified in Sections

>          6.3 and 6.4.

>      

>      But I'm not sure about "The applica=
tion also specifies...". Is this referring to something specific in th=
e webrtc API? If so, does it permit both? The presence of dcmap in the SDP =
will indicate the intent to use SDP negotiation, but must this first be
 enabled in the API?

>      

>        Thanks,

>        Paul

>      

>      > Regards,

>      >

>      > Christer

>      >

>      > On 25/04/2019, 1.25, "mmusic o=
n behalf of Paul Kyzivat" <mmusic-bounces@ietf.org on behalf of pky=
zivat@alum.mit.edu> wrote:

>      >

>      >      The d=
istribution of specs across multiple documents makes it really

>      >      fuzzy=
 what is normative for what.

>      >

>      >      Perha=
ps something should be said about the validity of using a

>      >      webrt=
c-datachannel media stream for establishing data channels via SDP

>      >      with =
dcmap and/or DCEP. I don't think this is said anywhere else.

>      

>      ________________________________________=
_______

>      mmusic mailing list

>      mmusic@ietf.org

>      
https://www.ietf.org/mailman/listinfo/mmusic

>      

> 














--_000_HE1PR07MB316176E6552193AB4B39DC6093390HE1PR07MB3161eurp_--


From nobody Mon Apr 29 06:34:23 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180B1120315 for ; Mon, 29 Apr 2019 06:34:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KatDkmVBFhHa for ; Mon, 29 Apr 2019 06:34:20 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FC8A1200C7 for ; Mon, 29 Apr 2019 06:34:19 -0700 (PDT)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x3TDY7wM016346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 29 Apr 2019 09:34:08 -0400
To: Christer Holmberg , "Roni Even (A)" , "mmusic@ietf.org" 
References: <8A9AAAC7-FB2D-4884-BAC6-268B98C7A0F0@ericsson.com>  <81169C37-95F2-418A-A221-CCC623392CD2@ericsson.com> <563cf2bd-474a-8fef-ceaf-e2c72ebc6dc4@alum.mit.edu> <6E58094ECC8D8344914996DAD28F1CCD18CDE434@dggemm526-mbx.china.huawei.com>  <32fb1138-4bc1-6315-0c2f-d660ecfafdcd@alum.mit.edu> 
From: Paul Kyzivat 
Message-ID: <2a06aebe-262b-dbad-4bf8-66c9a5dabf86@alum.mit.edu>
Date: Mon, 29 Apr 2019 09:34:07 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP
X-BeenThere: mmusic@ietf.org
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: Mon, 29 Apr 2019 13:34:22 -0000

On 4/29/19 8:54 AM, Christer Holmberg wrote:
> Hi,
> 
> 
>>You seem to be suggesting that using dcmap is mutually exclusive with
>>using DCEP to negotiate channels. While I guess it would be possible to 
>>make such a rule I don't see why it is necessary, or a good thing. Why 
>>not allow them to be used together? (E.g., use SDP to establish the SCTP 
>>association and negotiate some initial channels, and later use DCEP to 
>>negotiate some additional channels.)
> 
> You are right - one can use both SDPNEG and DCEP for the same SCEP 
> association (read: same m- line).
> 
> But, if I establish the SCTP association - but do not negotiate some 
> initial channels using SDPNEG - the peer won't know that I support 
> SDPNEG, so I assume it will always try to use DCEP.
> 
> Having explicit support indicators, that are separate from the actual 
> protocol indicators, is always good in my opinion.
> 
> But, perhaps we should have thought about that earlier. Let's make 
> whatever clarifications are needed and ship the document :)

Yes, maybe this should have gotten more thinking up front, but that is 
water over the dam.

ISTM that for a particular use an application will likely be coded to 
negotiate a data channel via DCEP or SDPNEG, but not both. But at the 
same time it might be possible that different usages within the 
application *might* work differently in this regard. (E.g., the 
application might call a library that internally needs a data channel 
and negotiates it via DCEP.)

I don't think it is essential to know a priori which are supported. If 
lack of support is discovered via a failure to negotiate then so be it.

But I am interested to hear what others think.

	Thanks,
	Paul


From nobody Mon Apr 29 09:32:28 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78921200F4 for ; Mon, 29 Apr 2019 09:32:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctZRejzKK7iD for ; Mon, 29 Apr 2019 09:32:24 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80112.outbound.protection.outlook.com [40.107.8.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF62E120150 for ; Mon, 29 Apr 2019 09:32:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vUwbcK0PpkOwzpQZXrEvbKi1eOOLwDVfpSaADY5Tqww=; b=TSUQohqqmMfgDa28PFq5mUDFQ2nJIY2iWSNqZv+iLvN87FHNNzhbUnD1fHAK7WcepWA7vHxUkS6Ll9X/KilB8yPL63IWWprqrP5clmMKiJ2kfXBmWm2j4RgJfy1JQBBIZbfNI/BztUE4hGhsJjUdzrTkS3pH61IKaUI7NTnFxEg=
Received: from AM0PR07MB5154.eurprd07.prod.outlook.com (20.178.17.95) by AM0PR07MB3956.eurprd07.prod.outlook.com (52.134.87.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.8; Mon, 29 Apr 2019 16:32:21 +0000
Received: from AM0PR07MB5154.eurprd07.prod.outlook.com ([fe80::407a:b0c2:545e:7815]) by AM0PR07MB5154.eurprd07.prod.outlook.com ([fe80::407a:b0c2:545e:7815%4]) with mapi id 15.20.1856.008; Mon, 29 Apr 2019 16:32:21 +0000
From: "Makaraju, Raju (Nokia - US/Naperville)" 
To: "Roni Even (A)" , Christer Holmberg , Paul Kyzivat , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] SDPNEG: How to disable DCEP
Thread-Index: AQHU+njrOtTA5N+Kv0Ox965sWihq+KZL5CwAgAKAjYCAACw0AIACj2qAgACQLAD///KMgIABtxWw
Date: Mon, 29 Apr 2019 16:31:51 +0000
Deferred-Delivery: Mon, 29 Apr 2019 16:31:00 +0000
Message-ID: 
References: <8A9AAAC7-FB2D-4884-BAC6-268B98C7A0F0@ericsson.com>  <81169C37-95F2-418A-A221-CCC623392CD2@ericsson.com> <563cf2bd-474a-8fef-ceaf-e2c72ebc6dc4@alum.mit.edu> <6E58094ECC8D8344914996DAD28F1CCD18CDE434@dggemm526-mbx.china.huawei.com>  <6E58094ECC8D8344914996DAD28F1CCD18CDE52D@dggemm526-mbx.china.huawei.com>
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD18CDE52D@dggemm526-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=raju.makaraju@nokia.com; 
x-originating-ip: [24.12.12.159]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c246040e-46ef-4ef8-9f7a-08d6ccc040c2
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM0PR07MB3956; 
x-ms-traffictypediagnostic: AM0PR07MB3956:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0022134A87
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(136003)(376002)(366004)(39860400002)(189003)(199004)(51444003)(13464003)(55016002)(86362001)(7696005)(6116002)(76176011)(3846002)(53936002)(6436002)(2906002)(2171002)(71200400001)(6246003)(229853002)(52536014)(9686003)(97736004)(6306002)(71190400001)(99286004)(7736002)(25786009)(68736007)(186003)(14444005)(66066001)(966005)(93886005)(53546011)(33656002)(102836004)(6506007)(478600001)(5660300002)(66946007)(81166006)(81156014)(486006)(8936002)(11346002)(476003)(64756008)(66446008)(110136005)(446003)(73956011)(66556008)(76116006)(6666004)(66476007)(26005)(8676002)(305945005)(74316002)(316002)(2501003)(14454004)(256004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB3956; H:AM0PR07MB5154.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: C5ToPaFwPt0L3Sl77OfV8wCfrNTrB9739DffvVpz7TpqkkMW6w5+8f/2DN1ioLqa0ExCtkg3NRsZy+d17DzNGCuPYi7OM+7j5meAYrLh1cZYrsdBawRYeTU3w7xuiAsCevCCSju+iyYzT6MpFSIuHjNGXD9Q/p+/PXEGPhNuR1t+U2BlqN9E9Q8l1XAnVUBJBXemOn7+EY9/3X7ubogRM+omFjBNpKyTWBSonvBlCK0HsrQ9EjnCwdx6JGf68b1o7eUblrULTo0Rd8dtWFKqxrAvy4UeRI2VrYKCiad4U3O2JzfxZwnMEK0buXtOzMOjD7lWw3k/0B+kpV8MyVn80xCMx+HYCjSl369tcTwxK20WCtjAwTmiTAFToILCqcc/rY5byyYi6ihtjwlZ0HopaOC6ALtmLV3H1EEvT66vvIw=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c246040e-46ef-4ef8-9f7a-08d6ccc040c2
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2019 16:32:21.1277 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB3956
Archived-At: 
Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP
X-BeenThere: mmusic@ietf.org
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: Mon, 29 Apr 2019 16:32:27 -0000

    >      Perhaps something should be said about the validity of using a
    >      webrtc-datachannel media stream for establishing data channels v=
ia SDP
    >      with dcmap and/or DCEP. I don't think this is said anywhere else=
.

[Raju] Appendix A.2.2[1] already indicates streams can be managed by both D=
CEP and non-DCEP, but application has to manage and make sure ids don't ove=
rlap for either use.

> But, what if an offerer wants to negotiate a data channel, before decidin=
g what exactly it is going to be used for, but still wants to indicate usag=
e of SDPNEG. >Including an empty dcmap attribute?

[Raju]
ABF syntax[2]  does already allow a=3Ddcmap without any optional parameters=
 or even subprotocol to be empty quoted string.


[1] A.2.2.  Opening a Data Channel

   In the case of DCEP-less negotiation, the endpoint application has
   the option to fully control the stream identifier assignments.
   However these assignments have to coexist with the assignments
   controlled by the data channel stack for the DCEP negotiated data
   channels (if any).  It is the responsibility of the application to
   ensure consistent assignment of stream identifiers.



[2]
dcmap-value     =3D dcmap-stream-id
                    [ SP dcmap-opt *(";" dcmap-opt) ]
dcmap-opt       =3D ordering-opt / subprotocol-opt / label-opt=20
			....
subprotocol-opt =3D "subprotocol=3D" quoted-string=20
quoted-string   =3D DQUOTE *(quoted-char / escaped-char) DQUOTE

-----Original Message-----
From: mmusic  On Behalf Of Roni Even (A)
Sent: Sunday, April 28, 2019 9:10 AM
To: Christer Holmberg ; Paul Kyzivat ; mmusic@ietf.org
Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP

Inline
Roni

-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20
Sent: Sunday, April 28, 2019 2:58 PM
To: Roni Even (A); Paul Kyzivat; mmusic@ietf.org
Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP

Hi,

> I think that sections 6.3 and 6.4 that discuss offer/answer say that dcma=
p is the indication of ruing non dcep.

Section 6.3 and 6.4 describe how to use dcmap.

I think it would be useful to e.g., have an Applicability section in the be=
ginning of the document, that explicitly indicates that the procedures in t=
he document apply when a data channel is negotiated using the dcmap attribu=
te, and that DCEP is then not used.


RE: section 5 "This section defines two new SDP media-level attributes that=
 can be
   used together with the SDP Offer/Answer mechanism to negotiate data
   channel-specific and subprotocol-specific parameters without the
   usage of DCEP".  if dcmap is rejected in the answer, the offerer can try=
 dcep ( see my answer bellow)

But, what if an offerer wants to negotiate a data channel, before deciding =
what exactly it is going to be used for, but still wants to indicate usage =
of SDPNEG. Including an empty dcmap attribute?


RE: I do not see what is the use case, it does not help with the decision a=
bout whether out of band case is supported or not.



>    The example in section 7 say that if dcmap is rejected dcep may be neg=
otiated.
>    Maybe this line form section 7 should be in section 6.4?

Normative text should definitely not be in Section 7.

RE: yes make sense to have it in section 6.5

However, if the answerer does not want to use SDPNEG, I think it's up to th=
e offerer to decide whether to continue the session establishment, or fallb=
ack to DCEP.=20

Regards,

Christer



   =20
    -----Original Message-----
    From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat
    Sent: Friday, April 26, 2019 6:16 PM
    To: Christer Holmberg; mmusic@ietf.org
    Subject: Re: [MMUSIC] SDPNEG: How to disable DCEP
   =20
    On 4/26/19 5:37 AM, Christer Holmberg wrote:
    > Hi Paul,
    >=20
    > So, what is your suggestion? __
   =20
    It looks to me like the 2nd paragraph of Appendix A is the right place =
for this:
   =20
        A WebRTC application creates a data channel by providing a number o=
f
        setup parameters (subprotocol, label, maximal number of
        retransmissions, maximal retransmission time, order of delivery,
        priority).  The application also specifies if it wants to make use =
of
        the negotiation using the DCEP [I-D.ietf-rtcweb-data-protocol], or =
if
        the application intends to negotiate data channels using the SDP
        offer/answer protocol.
   =20
    I'm inclined to tweak the above as follows:
   =20
        ...
        the application intends to negotiate data channels using the SDP
        offer/answer protocol, or both.
   =20
    And then, the note at the end of the section can be augmented:
   =20
        Note: The above SDP media description does not contain any channel-
        specific information. If data channels are to be negotiated using
        SDP, then the above will be supplemented as specified in Sections
        6.3 and 6.4.
   =20
    But I'm not sure about "The application also specifies...". Is this ref=
erring to something specific in the webrtc API? If so, does it permit both?=
 The presence of dcmap in the SDP will indicate the intent to use SDP negot=
iation, but must this first be enabled in the API?
   =20
    	Thanks,
    	Paul
   =20
    > Regards,
    >=20
    > Christer
    >=20
    > On 25/04/2019, 1.25, "mmusic on behalf of Paul Kyzivat"  wrote:
    >=20
    >      The distribution of specs across multiple documents makes it rea=
lly
    >      fuzzy what is normative for what.
    >     =20
    >      Perhaps something should be said about the validity of using a
    >      webrtc-datachannel media stream for establishing data channels v=
ia SDP
    >      with dcmap and/or DCEP. I don't think this is said anywhere else=
.
   =20
    _______________________________________________
    mmusic mailing list
    mmusic@ietf.org
    https://www.ietf.org/mailman/listinfo/mmusic
   =20

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


From nobody Mon Apr 29 13:45:00 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0680F120766 for ; Mon, 29 Apr 2019 13:44:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level: 
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVm8MDQ79Lff for ; Mon, 29 Apr 2019 13:44:56 -0700 (PDT)
Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C742612076C for ; Mon, 29 Apr 2019 13:44:56 -0700 (PDT)
Received: by mail-pg1-x535.google.com with SMTP id l18so5725462pgj.6 for ; Mon, 29 Apr 2019 13:44:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xuej1h0Dl2eTNddDbtzi+3TnhsDd0HYNnnyrzO5OT/M=; b=WvT8J+7NnQ+jUHkpc2+g3U5XzEjQ1qMQR/n4mhNOZZByvGb6va6/C7CJsRtTdFuSGj V9kH5ypwKYv4qYq1YC/N+Hj23vdsOdmPnhHb95Rk4aLH4xJ4upenoLdHWCnh6HOg6cgc K3RpL9XiOVhOS38ObMcdJnF9nngvMlqMczUsUHGUYr9nIGYa0Vfl402o0qnZ66Is69Mk 6bBoQnkUOIjptj8GllKmbADhsNb3/lZF+LHAkaZgDS2zFoGl6TnMvFQF0ehov87Y++x4 7hXKxkWfuua4UmsJeTLaPVGQKNsDFOCJU+Ph71NJ9eFgnElPNZf5BNvfULFYdUQ6vsPP eTyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Xuej1h0Dl2eTNddDbtzi+3TnhsDd0HYNnnyrzO5OT/M=; b=X3lpYQxwFKYBPayw72WlaUCLKaOmh4AXlkJ6aAx/SlNhDn5iimXS01vKa+cWbVOS+B uabG5yAztkRNcWwV6Okijna6S6+P24tMCotBYcsPFa4tnqMODrcnUKLSHJsHMCGSYD4p WO/X39aE4GIdpbAJj85KfkgsWlmPBIfKBHo75d/LkvE1/gy9tC0eYyXL9Ff9n514V7kP swez4NqS/amMLRA/Ys4P/LagF9jvhUI3hDyiuHJHOIfhj19mK/M5M8MABKxg8aFfQnPO FTLomVekMCVx+ncCaSepfy5Xq5IyyumqRhfk0z1BMu3IIPrVtWaUxS3cCVYw6+W9Z3JB cuww==
X-Gm-Message-State: APjAAAUBEvx/+/xkXie7MxcPY7YNSh5da46tw0cBNWfM3YlOd61gX2sy L0K7v+X8am4YLfc2SykrzXHkW3n7w+c=
X-Google-Smtp-Source: APXvYqwRZ2v6ysB7TG54a2k5r0JGu4idji4Wozf3uKZodBXKAANs1mfmS+B291Z7tZ+XJVaN0Mi0QA==
X-Received: by 2002:a62:424b:: with SMTP id p72mr63838233pfa.167.1556570696146;  Mon, 29 Apr 2019 13:44:56 -0700 (PDT)
Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com. [209.85.215.177]) by smtp.gmail.com with ESMTPSA id 128sm586526pfg.70.2019.04.29.13.44.54 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Apr 2019 13:44:55 -0700 (PDT)
Received: by mail-pg1-f177.google.com with SMTP id d31so5722473pgl.7 for ; Mon, 29 Apr 2019 13:44:54 -0700 (PDT)
X-Received: by 2002:a63:8dc8:: with SMTP id z191mr25835917pgd.9.1556570694673;  Mon, 29 Apr 2019 13:44:54 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Roman Shpount 
Date: Mon, 29 Apr 2019 16:44:43 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Christer Holmberg 
Cc: mmusic WG 
Content-Type: multipart/alternative; boundary="00000000000052edd00587b15b9b"
Archived-At: 
Subject: Re: [MMUSIC] Is ice-mismatch media or session level?
X-BeenThere: mmusic@ietf.org
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: Mon, 29 Apr 2019 20:44:59 -0000

--00000000000052edd00587b15b9b
Content-Type: text/plain; charset="UTF-8"

Hi Christer,

Thank you for reviewing and responding.

On Sat, Apr 27, 2019 at 1:48 PM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Before we just change something back we need to think what the reason for
> the change to media-level was. Could it be related to RTCWEB?
>
>
This is definitely not RTCWEB related, since RTCWEB should never generate
ice-mismatch or use it for any reason.

The ice-mismatch attribute was session only according to RFC 5245 Section
21.1.4 (https://tools.ietf.org/html/rfc5245#section-21.1.4). At the same
time, according to RFC 5245 Section 15.3 (
https://tools.ietf.org/html/rfc5245#section-15.3), ice-mismatch is media
level attribute only. This being said, according to RFC 5245 Section 6.1 (
https://tools.ietf.org/html/rfc5245#section-6.1), ice-mismatch applies to
the whole session, but it is specified per m= line. According to errata
3149 (https://www.rfc-editor.org/errata/eid3149), ice-mismatch should be
media level. So, it is a bit of a mess.

I can change ice-mismatch back to media level, but what we need to clarify
then is the following: If ice-mismatch is present in the m= line, does it
stop ICE processing for the whole session or for this m= line only?

If it stops ICE processing for the whole session then it makes little or no
sense being specified per m= line. If it only stops processing for specific
m= line, then ice-mismatch probably also makes sense at the session level
to stop ICE processing for the whole session.

I am definitely open to input here.
_____________
Roman Shpount

--00000000000052edd00587b15b9b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Christer,

Thank you for r=
eviewing and responding.

On Sat, Apr 27, 2019 at 1:48 PM Christer=
 Holmberg <christer.ho=
lmberg@ericsson.com> wrote:










Before we just change something back we need to think what the reason for=
 the change to media-level was. Could it be related to RTCWEB?=C2=A0=





This is definit=
ely not RTCWEB related, since RTCWEB should never generate ice-mismatch or =
use it for any reason.

The ice-mismatch attribute =
was session only according to RFC 5245 Section 21.1.4 (https://tools.ietf.org/html/rfc5=
245#section-21.1.4). At the same time, according to RFC 5245 Section 15=
.3 (https://to=
ols.ietf.org/html/rfc5245#section-15.3), ice-mismatch is media level at=
tribute only. This being said, according to RFC 5245 Section 6.1 (https://tools.ietf.org=
/html/rfc5245#section-6.1), ice-mismatch applies to the whole session, =
but it is specified per m=3D line. According to errata 3149 (https://www.rfc-editor.org/errata/e=
id3149), ice-mismatch should be media level. So, it is a bit of a mess.=


I can change ice-mismatch back to media level, bu=
t what we need to clarify then is the following: If ice-mismatch is present=
 in the m=3D line, does it stop ICE processing for the whole session or for=
 this m=3D line only?

If it stops ICE processing f=
or the whole session then it makes little or no sense being specified per m=
=3D line. If it only stops processing for specific m=3D line, then ice-mism=
atch probably also makes sense at the session level to stop ICE processing =
for the whole session.

I am definitely open to inp=
ut here.
_____________
Roman Shpount
=C2=A0


--00000000000052edd00587b15b9b--


From nobody Mon Apr 29 14:27:26 2019
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D30120195 for ; Mon, 29 Apr 2019 14:27:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=turbobridge.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8niPVjwd20a7 for ; Mon, 29 Apr 2019 14:27:23 -0700 (PDT)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 282CE1200B1 for ; Mon, 29 Apr 2019 14:27:23 -0700 (PDT)
Received: by mail-pg1-x52f.google.com with SMTP id k19so5789321pgh.0 for ; Mon, 29 Apr 2019 14:27:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=turbobridge.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u2k8+1zR1tGgxVMjvKLnCsm4qjgHNHfP5WH72DRswHg=; b=CbNGcvD34bbns8VYRKeAsBOQ6NmBVd/dvQvHwmSjewne33Gci8MrsJf01+r68y4Ew3 JYsDOXlZYgXp4e4YGgGjbAb4qHHOEKc3nGKDt4G0HEm2FA3uqM8+zQaMO/cXv8CSbWXY 7rnaVS5V4x8Oj1QOBTs9qdPOEFpqdP6XkyRdo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=u2k8+1zR1tGgxVMjvKLnCsm4qjgHNHfP5WH72DRswHg=; b=Ph6N9QOsnr71blH9U7fyY/E0L5X+v23LuT0T2JFNLqB79T/yuIknKqIvZc1LrRFpt7 p3LNB+nlA0zDwSIeUws0lAUIwGSyV8v/z9ikXafhJYL9/CTGWckPYaCzso0WxJtadihF +BRccqpzsYx/RiUK7pqK8uhlORNwShsti8U2gjaUAdO+12RT5H251AU5UtfA8pM/wVKJ mwiXyMGukeuudH2tTY13duk2icD/bhx0FgZJT91faBw5x3M95ItZ2Vs3Z5MgS3pHeVIL j9cHlxHJ1AUDnmZEAhaz/spoEUjypDSA+Kv7M6d4ml/TEM3CyrJPxsMrqioqVfMueb+h NA6w==
X-Gm-Message-State: APjAAAUnVYFdlvlmK1jNb1CGwqNDK4tbfkgI7Xj/l9MiQXHPE51thF9u LlPTGULfHAZBV1PuoKovXkCviVPoptw=
X-Google-Smtp-Source: APXvYqzExMk390ZRXkq0d83gag3Wc1fvLJrlfOe/VyC9K14hdCbwSbEQ24/E3zrHxRg6xATPnCAZrw==
X-Received: by 2002:a63:c54d:: with SMTP id g13mr59222408pgd.376.1556573242365;  Mon, 29 Apr 2019 14:27:22 -0700 (PDT)
Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com. [209.85.214.173]) by smtp.gmail.com with ESMTPSA id t5sm44243068pfh.141.2019.04.29.14.27.21 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Apr 2019 14:27:21 -0700 (PDT)
Received: by mail-pl1-f173.google.com with SMTP id bi2so893802plb.13 for ; Mon, 29 Apr 2019 14:27:21 -0700 (PDT)
X-Received: by 2002:a17:902:5a8f:: with SMTP id r15mr30382894pli.196.1556573241119;  Mon, 29 Apr 2019 14:27:21 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Roman Shpount 
Date: Mon, 29 Apr 2019 17:27:10 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Christer Holmberg 
Cc: mmusic WG 
Content-Type: multipart/alternative; boundary="0000000000001a9c7c0587b1f364"
Archived-At: 
Subject: Re: [MMUSIC] Empty candidate lists in ice-sip-sdp offers and answers
X-BeenThere: mmusic@ietf.org
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: Mon, 29 Apr 2019 21:27:26 -0000

--0000000000001a9c7c0587b1f364
Content-Type: text/plain; charset="UTF-8"

On Sat, Apr 27, 2019 at 2:02 PM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> ...
>
> >NOTE: Since it is possible that no candidates were provided in the
> offer,  or that all candidates in the offer
> >where skipped due to unsupported address type or FQDN name resolution
> failure, ICE nomination process
> >can start with no remote candidates. This,  however, does not indicate an
> immediate ICE nomination failure.
> >See <> for more details.
> >
> >In the Receiving the Initial Answer section I have added the following:
> >
> >NOTE: Since it is possible that no candidates were provided in the
> answer, or that all candidates in the answer
> >where skipped due to unsupported address type or FQDN name resolution
> failure, ICE nomination process can
> >start with no remote candidates. This,  however, does not indicate an
> immediate ICE nomination failure.
> >See <> for more details.
>
> I think the text is confusing, because it starts talking about the ICE
> nomination process. There are other things that happen before, including
> the creation of candidate pairs.
>
> So, I think the text should say that the agent will not be able to create
> candidate pairs, and it will not be able to start sending connectivity
> checks. Instead it will wait for the peer agent to start sending
> connectivity checks, that the agent will then process as peer reflexive
> candidates.
>

I will try to come up with some text that uses the same terminology as RFC
8445.

>I wanted to get the group's opinion regarding:
> >
> >1. Allowing offers and answers with no candidates
>
> I am ok with the principle. There seem to be use-cases for it, so...
>
> >2. Adding a reference to draft-holmberg-ice-pac regarding how such
> session descriptions or session descriptions where all candidates were
> rejected are handled.
>
> The reference in the text above is misleading, because to me it sounds
> like PAC describes how to process offers/answers without candidates. PAC is
> only about a timer.
>
>
Maybe this draft should cover the situation when session description
processing did not generate any candidates. The fact that ICE has some
minimal run timer is not enough. We still need something that explicitly
states that it is acceptable to run ICE nomination process without
candidates since, as far as I know, nothing in RFC 8445 specifies if this
is allowed or not.

Regards,
___________________________________________
Roman Shpount | CTO | Cell: +1(202) 262-8672
4905 Del Ray Ave, Suite 300 | Bethesda, MD 20814
TurboBridge

--0000000000001a9c7c0587b1f364
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Sat, Apr 27, 2019 at 2:02 PM Christer =
Holmberg <christer.hol=
mberg@ericsson.com> wrote:
... 



>NOTE: Since it is possible that no candidates were provided in the offe=
r,=C2=A0 or that all candidates in the offer 

>where skipped due to unsupported address type or FQDN name resolution f=
ailure, ICE nomination process 

>can start with no remote candidates. This,=C2=A0 however, does not indi=
cate an immediate ICE nomination failure. 

>See <<draft-holmberg-ice-pac>> for more details.

> 

>In the=C2=A0Receiving the Initial Answer section I have added the follo=
wing:=C2=A0

>

>NOTE: Since it is possible that no candidates were provided in the answ=
er, or that all candidates in the answer 

>where skipped due to unsupported address type or FQDN name resolution f=
ailure, ICE nomination process can 

>start with no remote candidates. This,=C2=A0 however, does not indicate=
 an immediate ICE nomination failure. 

>See <<draft-holmberg-ice-pac>> for more details. 



I think the text is confusing, because it starts talking about the ICE nomi=
nation process. There are other things that happen before, including the cr=
eation of candidate pairs.



So, I think the text should say that the agent will not be able to create c=
andidate pairs, and it will not be able to start sending connectivity check=
s. Instead it will wait for the peer agent to start sending connectivity ch=
ecks, that the agent will then process as peer reflexive candidates.
=C2=A0
I will try to come up with some text that u=
ses the same terminology as RFC 8445.

>I wanted to get the group's opinio=
n regarding:

>

>1. Allowing offers and answers with no candidates



I am ok with the principle. There seem to be use-cases for it, so...



>2. Adding a reference to draft-holmberg-ice-pac regarding how such sess=
ion descriptions or session descriptions where all candidates were rejected=
 are handled.



The reference in the text above is misleading, because to me it sounds like=
 PAC describes how to process offers/answers without candidates. PAC is onl=
y about a timer.


Maybe this draft s=
hould cover the situation when session description processing did not gener=
ate any candidates. The fact that ICE has some minimal run timer is not eno=
ugh. We still need something that explicitly states that it is acceptable t=
o run ICE nomination process without candidates since, as far as I know, no=
thing in RFC 8445 specifies if this is allowed or not.

=

Regards,
_______________________________________=
____
Roman Shpount | CTO | Cell: +1(202) =
262-8672
4905 Del Ray Ave, Suite 300 | Be=
thesda, MD 20814
TurboBridge
=



<=
div>=C2=A0


--0000000000001a9c7c0587b1f364--