From nobody Sun Jul 2 06:05:18 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CC812EB4B for ; Sun, 2 Jul 2017 06:05:17 -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, FREEMAIL_FROM=0.001, 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=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 saG5ENb2IAzi for ; Sun, 2 Jul 2017 06:05:16 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 BB936129C0B for ; Sun, 2 Jul 2017 06:05:15 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id h22so90080935lfk.3 for ; Sun, 02 Jul 2017 06:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=cSkfvN45np1cEdnsVJOd3CcfDN9/0WHCkjdHFHlAwZE=; b=BN0i2PjgV59uaRPxsj9TyIysZmYjcOHRuRtHunTpNgYG4z2cVecVQRMRKDhGJcMRvA Ih0q8id7d2bfCSB8B4aNP9IWo6w/CnrUMeld26Ch2O9QanrmFaORzDG5n2UyFTnLD5zb VWmc+SiMZRZeqwz4Ei0lMnKHpiPRTch88qL/PeaYKfprQrQTcIbjIs28P6wkodqJR/Vn RFR4dwe5nWM/jCo5U0cmt7WabXTaUBTKQi5SxA6xQW8RYtO0klHFzyw82v5qWKMxj6vo VnnboQrvMi7idvlVtV2S7PQF875aCVVzttAFShtXq5pClITAeJxKGISKN7Bv47Bgxd9K 6kKA== 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=cSkfvN45np1cEdnsVJOd3CcfDN9/0WHCkjdHFHlAwZE=; b=lgmYOjDb0gBTDxAXLQocZEOTApqJXCPSiXx1T4WblEL3KBVLa3nUEPgL71qacyp+Rt p+/20R67WpzVcwEjqTDDlPYW+F0gBRlRJbVJjUwZFbC4MZEPB1oUPxKQ9jbKglecW/g1 Kbz6ZUExwJZmYJQXKCg00YcL2FIogQ88au1Ao8i9xgooF0oOO5H7RjXCn1JHqSkoQnUW 2W1LbSKP3y9RIbQ1IiVeuRyN2XCeb2QRAeJMTKSxZycbQ8BVR4MUWz9j6a5BOYdGf30S NC4gIwHDCCBcdGlqzZxppXjJNC6m1uHu+o6amFjAOFSETBlClmGKl+LBi93Y2/j+Js5w +1xQ== X-Gm-Message-State: AKS2vOxLYa8A2zzF562ix0d1SqG0m2ar/cePZIXWrh/0wz1y/Szo8iCQ 4qhw5fqwfeoFvA632FcZw/u3LTzEo4D4 X-Received: by 10.46.5.10 with SMTP id 10mr7950797ljf.3.1499000714006; Sun, 02 Jul 2017 06:05:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.20.193 with HTTP; Sun, 2 Jul 2017 06:05:13 -0700 (PDT) From: Misha Zaytsev Date: Sun, 2 Jul 2017 16:05:13 +0300 Message-ID: To: dime@ietf.org Content-Type: multipart/alternative; boundary="001a114a881813996e0553554d0b" Archived-At: Subject: [Dime] Question about the changes from RFC3588 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 13:05:17 -0000 --001a114a881813996e0553554d0b Content-Type: text/plain; charset="UTF-8" Hi All, In RFC3588, ch. 2.1: When connecting to a peer and either zero or more transports are specified, SCTP SHOULD be tried first, followed by TCP. In RFC6733, ch. 2.1: When connecting to a peer and either zero or more transports are specified, TLS SHOULD be tried first, followed by DTLS, then by TCP, and finally by SCTP. What was the reason behind to change the order between TCP and SCTP? Could anyone help to sort out this point? Thanks a lot in advance! /Misha --001a114a881813996e0553554d0b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,
=C2=A0
In RFC3588, ch. 2.= 1:
When connecting to a peer and either zero or more trans=
ports are
specified, SCTP SHOULD be tried first, followed by TCP.
<= /span>In RFC6733, ch. 2.1:=C2=A0
When connecting to a peer and e=
ither zero or more transports are
specified, TLS SHOULD be tried first, followed by DTLS, then by TCP,
and finally by SCTP.
What was the reason behind to change the ord= er between TCP and SCTP?
Could anyone help to sort out this point= ?
=C2=A0
Thanks a lot in advance!
=C2=A0
/Misha

=C2=A0

=C2=A0

=C2=A0

=
=C2=A0
--001a114a881813996e0553554d0b-- From nobody Thu Jul 13 07:08:53 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8797131A8F; Thu, 13 Jul 2017 07:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 dpRR7lKAC0ct; Thu, 13 Jul 2017 07:08:51 -0700 (PDT) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61C16131A91; Thu, 13 Jul 2017 07:08:45 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id B91D118066F; Thu, 13 Jul 2017 16:08:43 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 8B8111A00E4; Thu, 13 Jul 2017 16:08:43 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0352.000; Thu, 13 Jul 2017 16:08:43 +0200 From: To: "dime@ietf.org" CC: "dime-chairs@ietf.org" Thread-Topic: IETF 99: Dime Agenda Thread-Index: AdL74RFRCKveB1J7SGWTZ4V0SC85Qw== Date: Thu, 13 Jul 2017 14:08:43 +0000 Message-ID: <11178_1499954923_59677EEB_11178_140_1_6B7134B31289DC4FAF731D844122B36E2D1AF599@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dime] IETF 99: Dime Agenda X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 14:08:53 -0000 Folks, As uploaded in the official IETF agenda, please find hereafter the agenda f= or our session. Please note that at the end, we will discuss the future of the WG. So if yo= u are interested, please be involved in this discussion. regards, Lionel & Jouni. ********************** IETF-99 DIME agenda 1740-1840 July 17, 2017, Monday Afternoon session III=20 meeting room: Karlin III=20=20=20 Jabber room: dime at jabber.ietf.org (Please join) =20=20=20=20=20=20=20=20=20=20 Chairs: Jouni Korhonen Lionel Morand =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20=20=20=20 17:40 - 17:45, Preliminaries, Chairs (5 minutes) ------------------------------------------ Audio/Video & Remote Presentation Debugging=20 Note Well=20 Note Takers/Jabber scribe=20 Agenda bashing =20=20=20=20=20=20=20=20=20=20 17:45 - 17:50, WG Document Status, Chairs (5 minutes) ------------------------------------------ =20=09 *draft-ietf-dime-agent-overload-11 --> RFC Ed Queue=20=09 *draft-ietf-dime-doic-rate-control-06 --> Waiting for Write-Up *draft-ietf-dime-group-signaling-08 --> In WG Last Call=20 *draft-ietf-dime-load-09 --> RFC Ed Queue *draft-ietf-dime-rfc4006bis-03 --> In WG Last Call=20 17:50 - 18:35 Individual draft discussions (45 minutes) ------------------------------------------- 17:50 - 18:10 Diameter Policy Groups and Sets, Lyle (20min) Draft: https://tools.ietf.org/html/draft-bertz-dime-predictunits-02=20=20 Draft: https://tools.ietf.org/html/draft-bertz-dime-policygroups-04=20=20= =20=20 18:10 - 18:35 Diameter Specification Recommendations, Lyle (25min) Draft: https://tools.ietf.org/html/draft-bertz-dime-diamimpr-00=20=20=20 =20=20 18:35 - 18:40 Wrap-up and Next, Chairs/AD (5 minutes) ----------------------------- WG Goals/Milestones status Next steps/Action Points Future of the WG ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri Jul 14 07:59:27 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5957B12F28B for ; Fri, 14 Jul 2017 07:59: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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=definitionnetworks-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 yRdzJGCt7iT6 for ; Fri, 14 Jul 2017 07:59:24 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (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 2D0B412EB43 for ; Fri, 14 Jul 2017 07:59:24 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id j186so46869665pge.2 for ; Fri, 14 Jul 2017 07:59:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=definitionnetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=qELOHRZMrIQwTDXIBFw2dwAiZP0skAmT9C5Opd4MEBY=; b=mLZnhu0LQY9YdSpSxK5ThVoMCBlkMY2XvnUDn7iYzIrZ3OVOjYjkuNu1OGofQUHCuV THJs4YNrsKGvNYVFRqtScA5PK72op0lQIeBeSXU9MuH00+bb3mwkPdJE+nE8fdmR9GaP wm/adNX6wlc/HA8p5dR3dju4af7wo2U6oEMCPkYS5tgCCj1ZQmfcGEZzgFg5ze7LiOpB eNzW/IkeBBaw/d9pH6pFMlHmyHRh1Vpb59XIbXcggYTeykYqKSltYciWqtIw2+dGSktv dkOtBGz4f2hSl/JjQLkfb6gEYCiDKw3www1+7f92VM6IfIUTA8VB1mVWIm0PBn6hQT8k kPew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=qELOHRZMrIQwTDXIBFw2dwAiZP0skAmT9C5Opd4MEBY=; b=GBlHAzYROT2v4RS7EWHggO5nCQ4WIEEphFHv+8NbnvEn38dLOvuJQXPc3YGNd/wABj ZpP5u9dmEPzSuXxTeW/Lx7iB6Zvv3AlAJBGxek5xidFz9BAt/mzr/Toka/1NWnLJmefa 87ppwVUNfwY7pZLJ2ZFNHlgEX/wGFHdjw+7n/4h4mKaTiJ0x+VYYH8QQRpYBgOMMn2zR zMW49BaRvBiI5XvWRyQGNbliHcgSl2+8hE1UCzcbyb/9vFP4CVQe+bfsxkGinh3KLNw5 7XYS61iGlR2Rfj34RsjHBOnFlkMOMViN0b2P396LYaaJ2ScjANLqOuJBWhVC8KPfw+0z 3csw== X-Gm-Message-State: AIVw113aKBSX0ZU5oYhWpwG7sJa5hMIkBUS41MYLz+TMKhpHtIs0kUON PcRKZufcYmWovjjJwmwU3OA9pkbJcd+FkBw= X-Received: by 10.84.176.65 with SMTP id u59mr10370721plb.23.1500044363539; Fri, 14 Jul 2017 07:59:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.153.82 with HTTP; Fri, 14 Jul 2017 07:59:23 -0700 (PDT) In-Reply-To: References: From: Ajinkya Joshi Date: Fri, 14 Jul 2017 20:29:23 +0530 Message-ID: To: dime@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1196546fb8a80554484b9d" Archived-At: Subject: Re: [Dime] Question regarding diameter session X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 14:59:26 -0000 --94eb2c1196546fb8a80554484b9d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I didn't receive the replies on email. Inline question starting with [AJ] Copying the responses from archive for reference. --- Hi, Please see below. Regards, Lionel > -----Message d'origine----- > De : DiME [mailto:dime-bounces at ietf.org] De la part de = Ivan Skytte J=C3=B8rgensen > Envoy=C3=A9 : jeudi 29 juin 2017 11:21 > =C3=80 : dime at ietf.org > Objet : Re: [Dime] Question regarding diameter session > > On Thursday 29 June 2017 13:15:05 Ajinkya Joshi wrote: > > Hello, > > > > >From the RFC 6733, it is clear that diameter session is identified > > >bases on > > session-id, which has to be globally unique. Also in section 2.5 > > (Connections vs Sessions), it's clearly mentioned that one connection > > can be used to multiplex multiple diameter sessions. > > I have following questions related to diameter session - > > > > Is there any implicit correlation between diameter session and origin-h= ost? > > Only what is spelled out in the RFC "The Session-Id MUST begin with the s= ender's > identity [...]" [LM] correct. > > A dubious diameter implementation may decode the session-id extracting wh= at > the origin-host might be. But that would be silly since it is already pre= sent in the > origin-host AVP. Well-behaved diameter implementations treat session-id a= s an > opaque string. > > > Does diameter standard allow different requests for the same session > > to have different origin-host value? > > Yes, eg RAR and ASR requests will have a typically have an origin-host/re= alm > different from where the session-id was created. [LM] if the question was for requests with different origin-host received by the same server for the same session, the answer is NO. Session related data maintained by a server for a given session are bounded to a single Origin-host. As said in the RFC6733, "A session is a logical concept at the application layer that exists between the Diameter client and the Diameter server; it is identified via the Session-Id AVP." There is therefore a 1-to-1 relationship between the server and the client initiating the session. If a server would accept session related messages from different nodes for the same session, it would not possible to ensure a consistent management of the session state, e.g. node A creating the session, node B terminating the session whereas node A is not aware. [AJ] What if there is an implementation where client is distributed and session state is shared by some means between the various client nodes. Each of the client node represents different diameter host. So, how would server behave, if say client node-1 (with diameter host name as "n1", which becomes origin-host) initiates a diameter session, and different client node say node-2 (with diameter host name as "n2", which becomes origin-host) sends some subsequent message for the same session (using same session-id)? > > > /isj > > _______________________________________________ > DiME mailing list > DiME at ietf.org > https://www.ietf.org/mailman/listinfo/dime On Thu, Jun 29, 2017 at 1:15 PM, Ajinkya Joshi < ajoshi@definitionnetworks.com> wrote: > Hello, > > From the RFC 6733, it is clear that diameter session is identified bases > on session-id, which has to be globally unique. Also in section 2.5 > (Connections vs Sessions), it's clearly mentioned that one connection can > be used to multiplex multiple diameter sessions. > I have following questions related to diameter session - > > Is there any implicit correlation between diameter session and > origin-host? > Does diameter standard allow different requests for the same session to > have different origin-host value? > Is there any possible problem if the value of Diameter Identity (part of > recommended format for session-id) is different from those present in the > request (like origin-host/origin-realm)? > > -- > Regards, > Ajinkya Joshi > --=20 Regards, Ajinkya Joshi --94eb2c1196546fb8a80554484b9d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I didn't receive the replies on email.=C2=A0
Inlin= e question starting with [AJ]=C2=A0
Copying the responses from ar= chive for reference. ---
Hi,
Please see below.

Regards,

Lionel

> -----Message d'origine-----
> De=C2=A0: DiME [mailt=
o:dime-bounces at ietf.org] De la part =
de Ivan Skytte J=C3=B8rgensen
> Envoy=C3=A9=C2=A0: jeudi 29 juin 2017 11:21
> =C3=80=C2=A0: dime at ietf.org
> Objet=C2=A0: Re: [Dime] Question regarding diameter session
>=20
> On Thursday 29 June 2017 13:15:05 Ajinkya Joshi wrote:
> > Hello,
> >
> > >From the RFC 6733, it is clear that diameter session is ident=
ified
> > >bases on
> > session-id, which has to be globally unique. Also in section 2.5
> > (Connections vs Sessions), it's clearly mentioned that one co=
nnection
> > can be used to multiplex multiple diameter sessions.
> > I have following questions related to diameter session -
> >
> > Is there any implicit correlation between diameter session and or=
igin-host?
>=20
> Only what is spelled out in the RFC "The Session-Id MUST begin wi=
th the sender's
> identity [...]"

[LM] correct.

>=20
> A dubious diameter implementation may decode the session-id extracting=
 what
> the origin-host might be. But that would be silly since it is already =
present in the
> origin-host AVP. Well-behaved diameter implementations treat session-i=
d as an
> opaque string.
>=20
> > Does diameter standard allow different requests for the same sess=
ion
> > to have different origin-host value?
>=20
> Yes, eg RAR and ASR requests will have a typically have an origin-host=
/realm
> different from where the session-id was created.

[LM] if the question was for requests with different origin-host received b=
y the same server for the same session, the answer is NO.
Session related data maintained by a server for a given session are bounded=
 to a single Origin-host. As said in the RFC6733,=20
  "A session is a
   logical concept at the application layer that exists between the
   Diameter client and the Diameter server; it is identified via the
   Session-Id AVP."
There is therefore a 1-to-1 relationship between the server and the client =
initiating the session. If a server would accept session related messages f=
rom different nodes for the same session, it would not possible to ensure a=
 consistent management of the session state, e.g. node A creating the sessi=
on, node B terminating the session whereas node A is not aware. 
=
[AJ] What if there is an imple=
mentation where client is distributed and session state is shared by some m=
eans between the various client nodes. Each of the client node represents  =
different diameter host. So, how would server behave, if say client node-1 (with diameter host nam=
e as "n1", which becomes origin-host) initiates a diameter sessio=
n, and different client node say node-2 (with diameter host name as "n=
2", which becomes origin-host) sends some subsequent message for the s=
ame session (using same session-id)?

>=20
>=20
> /isj
>=20
> _______________________________________________
> DiME mailing list
> DiME at ietf.org
> https://www.ietf.org/mailman/listinfo/dime

On Thu, Jun 29= , 2017 at 1:15 PM, Ajinkya Joshi <ajoshi@definitionnetworks.co= m> wrote:
= Hello,

From the RFC 6733, it is clear that diameter sess= ion is identified bases on session-id, which has to be globally unique. Als= o in section 2.5 (Connections vs Sessions), it's clearly mentioned that= one connection can be used to multiplex multiple diameter sessions.=C2=A0<= /div>
I have following questions related to diameter session -=C2=A0

Is there any implicit correlation between diameter s= ession and origin-host?=C2=A0
Does diameter standard allow differ= ent requests for the same session to have different origin-host value?
Is there any possible problem if the value of Diameter Identity (part= of recommended format for session-id) is different from those present in t= he request (like origin-host/origin-realm)?

--
Regards,
Ajinkya Joshi



--
Regards,
Ajinkya Joshi=
--94eb2c1196546fb8a80554484b9d-- From nobody Fri Jul 14 08:47:34 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2EF129AF6 for ; Fri, 14 Jul 2017 08:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 gPjql5JpRPiA for ; Fri, 14 Jul 2017 08:47:31 -0700 (PDT) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B864A1242F7 for ; Fri, 14 Jul 2017 08:47:30 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 008D3C03EF; Fri, 14 Jul 2017 17:47:29 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.13]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id C9DC640068; Fri, 14 Jul 2017 17:47:28 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM6D.corporate.adroot.infra.ftgroup ([fe80::54f9:a6c3:c013:cbc7%19]) with mapi id 14.03.0352.000; Fri, 14 Jul 2017 17:47:28 +0200 From: To: Ajinkya Joshi , "dime@ietf.org" Thread-Topic: =?iso-8859-1?Q?RE=A0:_Re:_[Dime]_Question_regarding_diameter_session?= Thread-Index: AQHS/Lh+fvTWiZEAKk6ZSs78BsXH/g== Date: Fri, 14 Jul 2017 15:47:27 +0000 Message-ID: <5135_1500047248_5968E790_5135_80_1_6B7134B31289DC4FAF731D844122B36E2D1B10AC@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: , In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E2D1B10ACOPEXCLILM43corp_" MIME-Version: 1.0 Archived-At: Subject: [Dime] =?iso-8859-1?q?RE=A0=3A_Re=3A__Question_regarding_diameter?= =?iso-8859-1?q?_session?= X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 15:47:33 -0000 --_000_6B7134B31289DC4FAF731D844122B36E2D1B10ACOPEXCLILM43corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, not sure to understand... The use case that you give is exactly the one tha= t I gave to illustrate my answer "No". The server would either reject or ignore sessions related requests coming f= rom another source. Lionel Le 14 juil. 2017 16:59, Ajinkya Joshi a =E9= crit : I didn't receive the replies on email. Inline question starting with [AJ] Copying the responses from archive for reference. --- Hi, Please see below. Regards, Lionel > -----Message d'origine----- > De : DiME [mailto:dime-bounces at ietf.org] De la part d= e Ivan Skytte J=F8rgensen > Envoy=E9 : jeudi 29 juin 2017 11:21 > =C0 : dime at ietf.org > Objet : Re: [Dime] Question regarding diameter session > > On Thursday 29 June 2017 13:15:05 Ajinkya Joshi wrote: > > Hello, > > > > >From the RFC 6733, it is clear that diameter session is identified > > >bases on > > session-id, which has to be globally unique. Also in section 2.5 > > (Connections vs Sessions), it's clearly mentioned that one connection > > can be used to multiplex multiple diameter sessions. > > I have following questions related to diameter session - > > > > Is there any implicit correlation between diameter session and origin-h= ost? > > Only what is spelled out in the RFC "The Session-Id MUST begin with the s= ender's > identity [...]" [LM] correct. > > A dubious diameter implementation may decode the session-id extracting wh= at > the origin-host might be. But that would be silly since it is already pre= sent in the > origin-host AVP. Well-behaved diameter implementations treat session-id a= s an > opaque string. > > > Does diameter standard allow different requests for the same session > > to have different origin-host value? > > Yes, eg RAR and ASR requests will have a typically have an origin-host/re= alm > different from where the session-id was created. [LM] if the question was for requests with different origin-host received b= y the same server for the same session, the answer is NO. Session related data maintained by a server for a given session are bounded= to a single Origin-host. As said in the RFC6733, "A session is a logical concept at the application layer that exists between the Diameter client and the Diameter server; it is identified via the Session-Id AVP." There is therefore a 1-to-1 relationship between the server and the client = initiating the session. If a server would accept session related messages f= rom different nodes for the same session, it would not possible to ensure a= consistent management of the session state, e.g. node A creating the sessi= on, node B terminating the session whereas node A is not aware. [AJ] What if there is an implementation where client is distributed and ses= sion state is shared by some means between the various client nodes. Each o= f the client node represents different diameter host. So, how would server= behave, if say client node-1 (with diameter host name as "n1", which becom= es origin-host) initiates a diameter session, and different client node say= node-2 (with diameter host name as "n2", which becomes origin-host) sends = some subsequent message for the same session (using same session-id)? > > > /isj > > _______________________________________________ > DiME mailing list > DiME at ietf.org > https://www.ietf.org/mailman/listinfo/dime On Thu, Jun 29, 2017 at 1:15 PM, Ajinkya Joshi > wrote: Hello, >From the RFC 6733, it is clear that diameter session is identified bases on= session-id, which has to be globally unique. Also in section 2.5 (Connecti= ons vs Sessions), it's clearly mentioned that one connection can be used to= multiplex multiple diameter sessions. I have following questions related to diameter session - Is there any implicit correlation between diameter session and origin-host? Does diameter standard allow different requests for the same session to hav= e different origin-host value? Is there any possible problem if the value of Diameter Identity (part of re= commended format for session-id) is different from those present in the req= uest (like origin-host/origin-realm)? -- Regards, Ajinkya Joshi -- Regards, Ajinkya Joshi ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E2D1B10ACOPEXCLILM43corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

not sure to understand... The use case that you give is exactly the one tha= t I gave to illustrate my answer "No".
The server would either reject or ignore sessions related requests coming f= rom another source.

Lionel

Le 14 juil. 2017 16:59, Ajinkya Joshi <ajoshi@defin= itionnetworks.com> a =E9crit :
I didn't receive the replies on email. 
Inline question starting with [AJ] 
Copying the responses from archive for reference. --- 
Hi,
Please see below.

Regards,

Lionel

> -----Message d'origine-----
> De : DiME [mailt=
o:dime-bounces at ietf.org] De la part =
de Ivan Skytte J=F8rgensen
> Envoy=E9 : jeudi 29 juin 2017 11:21
> =C0 : dime at ietf.org
> Objet : Re: [Dime] Question regarding diameter session
>=20
> On Thursday 29 June 2017 13:15:05 Ajinkya Joshi wrote:
> > Hello,
> >
> > >From the RFC 6733, it is clear that diameter session is ident=
ified
> > >bases on
> > session-id, which has to be globally unique. Also in section 2.5
> > (Connections vs Sessions), it's clearly mentioned that one connec=
tion
> > can be used to multiplex multiple diameter sessions.
> > I have following questions related to diameter session -
> >
> > Is there any implicit correlation between diameter session and or=
igin-host?
>=20
> Only what is spelled out in the RFC "The Session-Id MUST begin wi=
th the sender's
> identity [...]"

[LM] correct.

>=20
> A dubious diameter implementation may decode the session-id extracting=
 what
> the origin-host might be. But that would be silly since it is already =
present in the
> origin-host AVP. Well-behaved diameter implementations treat session-i=
d as an
> opaque string.
>=20
> > Does diameter standard allow different requests for the same sess=
ion
> > to have different origin-host value?
>=20
> Yes, eg RAR and ASR requests will have a typically have an origin-host=
/realm
> different from where the session-id was created.

[LM] if the question was for requests with different origin-host received b=
y the same server for the same session, the answer is NO.
Session related data maintained by a server for a given session are bounded=
 to a single Origin-host. As said in the RFC6733,=20
  "A session is a
   logical concept at the application layer that exists between the
   Diameter client and the Diameter server; it is identified via the
   Session-Id AVP."
There is therefore a 1-to-1 relationship between the server and the client =
initiating the session. If a server would accept session related messages f=
rom different nodes for the same session, it would not possible to ensure a=
 consistent management of the session state, e.g. node A creating the sessi=
on, node B terminating the session whereas node A is not aware. 
[AJ] What if there is an =
implementation where client is distributed and session state is shared by s=
ome means between the various client nodes. Each of the client node represe=
nts  different diameter host. So, how would server behave, if say client node-1 (with diameter hos=
t name as "n1", which becomes origin-host) initiates a diameter s=
ession, and different client node say node-2 (with diameter host name as &q=
uot;n2", which becomes origin-host) sends some subsequent message for =
the same session (using same session-id)?

>=20
>=20
> /isj
>=20
> _______________________________________________
> DiME mailing list
> DiME at ietf.org
> https://www.ietf.org/mailman/listinfo/dime

On Thu, Jun 29, 2017 at 1:15 PM, Ajinkya Joshi <= span dir=3D"ltr"> <ajos= hi@definitionnetworks.com> wrote:
Hello,

From the RFC 6733, it is clear that diameter session is identified bas= es on session-id, which has to be globally unique. Also in section 2.5 (Con= nections vs Sessions), it's clearly mentioned that one connection can be us= ed to multiplex multiple diameter sessions. 
I have following questions related to diameter session - 

Is there any implicit correlation between diameter session and origin-= host? 
Does diameter standard allow different requests for the same session t= o have different origin-host value?
Is there any possible problem if the value of Diameter Identity (part = of recommended format for session-id) is different from those present in th= e request (like origin-host/origin-realm)?

--
Regards,
Ajinkya Joshi



--
Regards,
Ajinkya Joshi
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E2D1B10ACOPEXCLILM43corp_-- From nobody Fri Jul 14 12:12:55 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3F41316A8 for ; Fri, 14 Jul 2017 12:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 dJ8rUK1BWPLz for ; Fri, 14 Jul 2017 12:12:52 -0700 (PDT) Received: from i1.dk (55e9f507.rev.dansknet.dk [85.233.245.7]) by ietfa.amsl.com (Postfix) with ESMTP id 45F20131690 for ; Fri, 14 Jul 2017 12:12:50 -0700 (PDT) Received: from i1.dk (localhost [127.0.0.1]) by i1.dk (Postfix) with ESMTP id BB10585571 for ; Fri, 14 Jul 2017 19:12:49 +0000 (UTC) Received: from isjsys.localnet (isjsys [10.0.0.2]) by i1.dk (Postfix) with ESMTPA for ; Fri, 14 Jul 2017 19:12:49 +0000 (UTC) From: Ivan Skytte =?ISO-8859-1?Q?J=F8rgensen?= To: dime@ietf.org Date: Fri, 14 Jul 2017 21:12:49 +0200 Message-ID: <2021427.Za52vkRhto@isjsys> User-Agent: KMail/4.11.5 (Linux/3.11.10-29-desktop; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Archived-At: Subject: Re: [Dime] Question regarding diameter session X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 19:12:54 -0000 On Friday 14 July 2017 20:29:23 Ajinkya Joshi wrote: > On Thu, Jun 29, 2017 at 1:15 PM, Ajinkya Joshi wrote: >=20 > > From the RFC 6733, it is clear that diameter session is identified = bases > > on session-id, which has to be globally unique. Also in section 2.5= > > (Connections vs Sessions), it's clearly mentioned that one connecti= on can > > be used to multiplex multiple diameter sessions. > > I have following questions related to diameter session - > > > > Is there any implicit correlation between diameter session and > > origin-host? > > Does diameter standard allow different requests for the same sessio= n to > > have different origin-host value? > > Is there any possible problem if the value of Diameter Identity (pa= rt of > > recommended format for session-id) is different from those present = in the > > request (like origin-host/origin-realm)? > > -----Message d'origine----- > > De : DiME [mailto:dime-bounces at ietf.org] De la pa= rt de Ivan Skytte J=F8rgensen > > Envoy=E9 : jeudi 29 juin 2017 11:21 > > =C0 : dime at ietf.org > > Objet : Re: [Dime] Question regarding diameter session > > > > On Thursday 29 June 2017 13:15:05 Ajinkya Joshi wrote: > > > Hello, > > > > > > >From the RFC 6733, it is clear that diameter session is identifi= ed > > > >bases on > > > session-id, which has to be globally unique. Also in section 2.5 > > > (Connections vs Sessions), it's clearly mentioned that one connec= tion > > > can be used to multiplex multiple diameter sessions. > > > I have following questions related to diameter session - > > > > > > Is there any implicit correlation between diameter session and or= igin-host? > > > > Only what is spelled out in the RFC "The Session-Id MUST begin with= the sender's > > identity [...]" >=20 > [LM] correct. >=20 > > > > A dubious diameter implementation may decode the session-id extract= ing what > > the origin-host might be. But that would be silly since it is alrea= dy present in the > > origin-host AVP. Well-behaved diameter implementations treat sessio= n-id as an > > opaque string. > > > > > Does diameter standard allow different requests for the same sess= ion > > > to have different origin-host value? > > > > Yes, eg RAR and ASR requests will have a typically have an origin-h= ost/realm > > different from where the session-id was created. >=20 > [LM] if the question was for requests with different origin-host > received by the same server for the same session, the answer is NO. > Session related data maintained by a server for a given session are > bounded to a single Origin-host. As said in the RFC6733, > "A session is a > logical concept at the application layer that exists between the > Diameter client and the Diameter server; it is identified via the > Session-Id AVP." > There is therefore a 1-to-1 relationship between the server and the > client initiating the session. If a server would accept session > related messages from different nodes for the same session, it would > not possible to ensure a consistent management of the session state, > e.g. node A creating the session, node B terminating the session > whereas node A is not aware. >=20 > [AJ] What if there is an implementation where client is distributed > and session state is shared by some means between the various client > nodes. Each of the client node represents different diameter host. > So, how would server behave, if say client node-1 (with diameter host= > name as "n1", which becomes origin-host) initiates a diameter session= , > and different client node say node-2 (with diameter host name as "n2"= , > which becomes origin-host) sends some subsequent message for the same= > session (using same session-id)? I have done something similar in the past (a 3gpp reference point if I = remember correctly). The central component "owning" the session was not diameter-capable. Th= e diameter communication was handled by multiple front-ends. The diamet= er session id was unique (the front-ends and the central component coor= dinated and ensured that, as well as the end-to-end-identifier). The fr= ont-ends would then lie that they were proxies even though they technic= ally originated the messages. Eg. the upstream OCS would see messages l= ike: =09session-id : backend.example.com;13459781;7569726735 =09origin-host : backend.example.com =09route-record : frontend1.example.com and the upstream OCS would be none the wiser because it could not tell = if frontend1.example.com was in fact a proxy or if it was lying. It wor= ked. But in order to do something like that you have to ensure three things:= 1: The diameter session-id must be globally eternally unique. And be th= e same for the same session. 2: Origin-host + end-to-end-identifier must be unique for at least 4 mi= nutes. 3: Origin-host must be the same as the diameter-identity in the session= -id. There may be other items that system need to synchronize such as cc-req= uest-number value. So that means you need state synchronization in your distributed system= . The only remaining thing I can think of is that some upstream systems m= ay not like proxied messages at all. I don't know how common that probl= em is nowadays. /isj From nobody Mon Jul 17 03:12:33 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D4712F280 for ; Mon, 17 Jul 2017 03:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, 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 5_ASfB0IN3SA for ; Mon, 17 Jul 2017 03:12:29 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0119.outbound.protection.outlook.com [104.47.41.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 904A112EC13 for ; Mon, 17 Jul 2017 03:12:29 -0700 (PDT) Received: from BY2PR05CA023.namprd05.prod.outlook.com (10.141.250.13) by BLUPR0501MB868.namprd05.prod.outlook.com (10.141.254.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Mon, 17 Jul 2017 10:12:27 +0000 Received: from SN1NAM01FT059.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e40::200) by BY2PR05CA023.outlook.office365.com (2a01:111:e400:2c5f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4 via Frontend Transport; Mon, 17 Jul 2017 10:12:27 +0000 Authentication-Results: spf=pass (sender IP is 144.230.32.80) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.32.80 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.80; helo=preapdm1.corp.sprint.com; Received: from preapdm1.corp.sprint.com (144.230.32.80) by SN1NAM01FT059.mail.protection.outlook.com (10.152.65.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1240.9 via Frontend Transport; Mon, 17 Jul 2017 10:12:26 +0000 Received: from pps.filterd (preapdm1.corp.sprint.com [127.0.0.1]) by preapdm1.corp.sprint.com (8.16.0.17/8.16.0.17) with SMTP id v6HA4miv048548 for ; Mon, 17 Jul 2017 06:12:25 -0400 Received: from plswe13m03.ad.sprint.com (plswe13m03.corp.sprint.com [144.229.214.22]) by preapdm1.corp.sprint.com with ESMTP id 2bqfheqte2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 17 Jul 2017 06:12:25 -0400 Received: from PLSWE13M04.ad.sprint.com (144.229.214.23) by plswe13m03.ad.sprint.com (144.229.214.22) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 17 Jul 2017 05:12:24 -0500 Received: from PLSWE13M04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a]) by plswe13m04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a%24]) with mapi id 15.00.1263.000; Mon, 17 Jul 2017 05:12:24 -0500 From: "Bertz, Lyle T [CTO]" To: "dime@ietf.org list" Thread-Topic: RFC 6733 Commands Thread-Index: AQHS/uUJB8h6U5QREEmZorl9T0AXrg== Date: Mon, 17 Jul 2017 10:12:23 +0000 Message-ID: <1500286334617.86980@sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.229.91.93] Content-Type: multipart/alternative; boundary="_000_150028633461786980sprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.32.80; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39860400002)(39450400003)(39850400002)(39840400002)(39410400002)(2980300002)(438002)(189002)(199003)(9170700003)(2900100001)(5000100001)(8676002)(356003)(2906002)(478600001)(189998001)(14454004)(36756003)(53936002)(7736002)(8936002)(19627405001)(117636001)(106466001)(110136004)(81166006)(5660300001)(38730400002)(54896002)(3846002)(50986999)(54356999)(6916009)(626005)(102836003)(512934002)(6116002)(30436002)(97876018)(5250100002)(86362001)(84326002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB868; H:preapdm1.corp.sprint.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; SN1NAM01FT059; 1:wVXWDPHra2NsrymmJJXSqWn3kSTKHf3K87A90Ow34TftBxJYkn+Z0pALDa3TfWA0JHgINgRRrFsOnj4H3ylmzcQMU3IFBYRZMBPg0kiGJ7Tve3qf/mTIlbf8pYXLtwPm0HOcUxm0iBgkM7fWMtOxe7T/laN+H0x+5FW3E9wBkFKWtIhnmPrsgqm/nUx4ofU13qHBTDER1JE6zeKYIYN5ESFyXsjyKxoided/C4IpScGhb9kVtaKKEd7B/eJa+k2ZK/za1jPwSiX2GgsDf5zpgviTV6fksOxewUnbjl/nfU0GE6wrzEUvWzOT1VW5b2MSELhUH11aGioIA1ehU4JMqoaopc9B9R0DhB6bZzMB0ld7djWe0ZKWGwt5FNEM82j8jmb0SLTS6fNMCd3titdYpeWsdmaWPirsDJaIeZtpYBYNCBJqSotvtD9AL5QrVJgO/RDS95pcBvHs0sQpw4bzT8h4yDrLVFH9cfI2Iy/oL+wqJu/FPHpOSvxQN4GY1BbLAqp/EFrHVDA2GlrAzj5Sg6OQjMtFTWgH+JniEfyniyktn4OiBDkH9EwYWtqSlsPkuj2K0+j4GKsyeCW3CcusS5EsASeTMfwaPif6AVmVyPiy/E4QMU2GSiJPRIJytnDLpsF4QCUIV8WVKnYw6MH1bT9loWOYObxa1GQXbR/1JrQ+1aVPsWjExxrLhygy+vpeETi+TQktiCDc/Y+XcQYquldyQN9w0l3V/x9mjLAdyrHcE9Tw7wglceJ1sBncTmsJ/eXwRSyfq25jdDsCiMbBHvM21mku+xPTatyvio+kinV9IJrY9ONzdkOz5jo45XlyVTgFg34QpmLF1VbukgeHufBd4m4LMY8JW9tVzzg/ZyEShsZ9HHIjLwwSzsSdFcc1 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1d64aca8-e4f0-4229-000b-08d4ccfc5324 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(8251501002)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR0501MB868; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB868; 3:jh4vh83yQwbQfTnUSrsGecxNt6T3FvMcZqAeAvWw05reVbkLKrYdUv/iM9ezUd6k1gRmR6NX46wc0dqRJSZpfNyc9JZx7yY9sLg1CWQg3YhGDt37aoFqXEZVcX9jehvNaTK+JioiBbDJXDhY7ZqKsVmmt4FwIpp8nmBFpREM8PK7Qg09L41316IsSN5X990lN+x7UXgEAci9zqyVJZ+EV8epaAn71tDM2NbZbyk7WPK2A6ppt4NG1gVEkZAQtUTcqIaqbLr9Gl27npI8mOfEMqv/sr0UuLBeYA5GD5z3H1dh+GpsPpVWh8rjgATa4DtSlGFnOThOniWtI5GasJ8DlJXSMXO3vR48808wL005+Ln6ePxTterOY/0GE4ekMOu6yb573cPki1vxNiblMhXJdPhZfyr0HvxG+cV/UC7JICbry9EJ1/trfQyMwDPPWeJ9HKQlvqvE9mbFedDBFYol8nWXk5VjkXOW141U0TD9bPe8Cex2jyH6z8U92+Xf1dZdIHE41/21xNVYJaeKiR55c5Kjg0zUN+66blP4+1LHTmIOj30MaqhuSaSmZCuc8XjJXJ+3hU+CrwJ175hnSIPnEshXXwMRziSWKPLvywAngX52pGgr4j9AJUtvPlc22pk1asgRzeSS+pjmtSt1QLMJJELIi1jqFQg3rpY/AO6xTn/rWhXWTYt59fC8cIo7X5GhBh1k1lVnSpsjgYW4KfcDzynSksYwB3KpiUxulMJEGqbtBZVmcgX2LvZ8XPxzfvD5Ts/lTgnzFzJkhCWZyB0Kbq7M1wzsGNmUoBM1Cb6gsKxBbytyb9uglto+GTINjXBxfo/Bz+jSGDSmgYuyMpB4L9KcPQo/rOhmGHmJUUEnDbRlbIEPa79fn2uoDvyd5pg0MNYZY+eOdB7176BPGKVMDTEXNKGiSiKjpTlu31X6CPI= X-MS-TrafficTypeDiagnostic: BLUPR0501MB868: X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB868; 25:kUHI8di9I31CRnTy+WDhnb3fnRhoV3SJ7PvMsT4C8cfhIu2jKt2u6bypolw3v/eFtKjlGyJ5RUYB2nHhIBhwpVxI9aeMIQCfXetk/vi0Ya7/3kT/zh/SHTUVsHDbhgX4/zxQOptJAbiGmCSabnnm9M8Xz55LU6HFN0tS2cGv2XXFdC924btPzMPprtutOayFhCfNYUxg3OB0rA3BA5CaBbaPk8DK7dDiCTbN5EazLzMwK4e487P91rbnnr+IHl8hbWLTevQOY3Y7ga3P70n4IQwqKaF4b4LGvloA6RaQ+GPO2kbd2UN4S44vLg+0sKeTyPqaOPYJj485SaG0ZaDZlt8bKdVZgPIBJqxLgjWhcQfts2wpWstQwAkm/gzAECPcZ4aR4dSfcO8M8MNhROY0bi0yKYO1cykKrB9/NTou9yqnOwqTkXK/VEJ5KdotmcZR4IphjIUI5gC0Har0SKQ3+0hPmTJ06Z5xtWGcVGMl08VGIh/SPKoDV2dsAlseo2tbvDDtAMkICDY1GW/+d0Nr2qtP8UZJZh71L6dQtTDIoexvbHbevmYnZJ1TvESEt+lVpOP2m3vNv6tczVD5yICAgusGcR1so8u4yOhZnVoBPfjbgCXju7Yv0VE/bA97czwrqR5DW6KDb5UYT0Ts7fYj8WAHVkcEzRohlSFz5wESk3rwKaVpRQUM/PqQucZOpHcTkgLognloZvs8VNxWoTLR/jCe9ZiN5MoYy6BLn4ziudjjvBqTe5mgDpsZ/wzoIyxy9G5ZrH5g8Q/dGfQEtt9dQzkPDMT3RBYr3O6RXIR/z06z0Py1Jl6y72SAvcbY7qOmYqQdpHPqZR76k5XalXHA60zu5/F4XpIlf4Ltdsxi4Ed0H8emR+Ol56YNDPgNPJVdbBlKhyclDaZ7L0+Scu+eDlaasgK5KmbPpNX+ez+Cr5Y= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB868; 31:lIWhyeW6ApGThayzaeDCQISKl9n1R8spsOXKx4KgXUMtXJMr7YhCUWRR8pbCxiKvYX5TB5r5mDVB1z04VG0R18SXOfkqf1io7Uj0xYrM9OeDs4QU/n4RU5aAoVTtIo0+Kcs8MKOah6FMCpO4gVmhBuxskcr1lidVLVHJOuyffZImZc94AJJfx0cJMtlINMs311AUsjICQr4Q2KS0yKYER/K3Qu9S9pKq1dzS/cIwu5AZggpNeCRmLK9N0qR51vBBijOU7INQaQgL+h6NJhu/ErwHBzVeogF/+dlvko9rvDhBqytzUrdw07ISgMFZPN1X965MsYSuQJH6iCyqKzrlYtaiIuL4m1c3+p0Zl8aIfiozQZglC/dRq2k9cOUrB2nwTgNn4AN7GOhEYFSZr7O81kb6lsMeV+i3YzQ1Aw6D75ftk2rUXc+cjs2xS1Ej/IbFfJ3OcZtNOapqq/qJUgZZDh6nb4K0MX0gPa4Xn/BMU3upgoyao3pwUAlpaPVnfcT8T3OuqMNTzJOAoDtRuQ8QkLjtfwdubZpDIVubNRGKcv8Y96dTkK7Hs76cgdo7oIcqhz4SWdb/41ibRDN9WnxLpD2/m6tP0P7jc3zLum9Wxk/+xFAlXoiaQJUy9BNvLAQSkMNnfupwN2Odeyvxw0cBFYn9AMIfLaHjdDS4jeNngjbZY1G6e5hn/ZP6g+3bPzQIYJUPQwztfdhk88DDQUjJSg== X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB868; 20:ISaGax9C8A3ELaEarulgeiCrK2ADqkr7wga/xgyvz41Ady2aUZmfRApjfDFrGl6Z+2/iVi4kR0Z8PC/6F7NntpP28m5xOIlYJ6ulN1tdsYGvXZn4APyDsiDKECB2L932pLWVuTk2Nheyi1pTK0wnohaZ8K69uJZWJOsn45DKAv27TteudIdeKyla2/G55uJVVEgB5TLZnC+vTE7WQUB5HqNnu2AnWQVIch16UsEjsgm4lLJbOX0x0+QkAiKT1vgZxoZgGMh0VeITj40I+qcBvCcm5Nabr0EYYDgivz2lvfZ8cI2GGnQn0Lg0MKQHOUaURavw48Z637C1qAd/BlufsKRXWm9CLIZzNwLsgpMl/zFeVgQoYbVea50KsdERskrvwqHkQ9elksNTilxdpjKxE27THWSPkplQP/BYtPa4CbCH9At7vb5hA4ZXPN6MdzFcBAcW4ku9oZKxS1aLGEBzlIUT++ghlqo4ls55YP5oCeaPJp5CpekIKN4xGmvRRjmE X-Exchange-Antispam-Report-Test: UriScan:(236129657087228); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(13018025)(2017060910075)(5005006)(13016025)(8121501046)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93004095)(6055026)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR0501MB868; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR0501MB868; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0501MB868; 4:uEGCuv+1YZBRWjOErtIZUBhRMxQ+c0y4Gq67eee4V?= =?us-ascii?Q?M55jWNpKSkxMzJTKsxBU7I3eGLjguHiNRWegM51ZMV72xe3MKSsUK+S/S6e5?= =?us-ascii?Q?eaPgcMUniaiOmqJuHebXnGgfXTCh63h9itBeLgN7qhdkLsO2zm53MRIXIGz3?= =?us-ascii?Q?bnEmbgS9G1oDAhxtynE7RmU/fjXGLqNpymk2/yxN0AUawZV97b2+LnTncMFg?= =?us-ascii?Q?6K3xtbJ8h5jZmH7EuPC1NoSxoNr03z0Q5eLgzKjHn2w00PoaNnDV0VFyC/q1?= =?us-ascii?Q?6ZeYbn/k+cysCCqPCtff5nKqhH8YXHLw3NBKBLwQqp8KmXayurjCV8krDT4n?= =?us-ascii?Q?XYfrZISE1tpx2+E+Z+6zGP2x4HGNOAefINbrHn+PXjEGYQSV9EJyYa9TY+fd?= =?us-ascii?Q?+SQEqPdpofZYkOeL3Dkpg/y5AVT/BuwH2xV2NZuqLNUo80CEzIBoAQUpU4xu?= =?us-ascii?Q?I6ulDZO9cERDtT0Fwu22dUnquQ1dwciRSEl0iCVa8LJrIRZwluOzfh9S39Bp?= =?us-ascii?Q?yirH51I3JEzjwGbaXMxGzc6Hrq4OUOtZidkIvmtsxtu/9HSVwlYL4pQbJHGN?= =?us-ascii?Q?AtEUHNAs9Jl3VdRCbvfQNj8HlvZgBHajta8z1TGGItViNMdBABHqxM6T/syz?= =?us-ascii?Q?QPy5j8oay6d4OPENSnOmg0doqHC0f7H23EACSklkW1xhMl0BCjXZr2C/uSvm?= =?us-ascii?Q?Iqgb8MsJkKCNHzubEZ65Un79836/xIXdj9JuYyDp9SaGHyjiquRmplF++lPM?= =?us-ascii?Q?g7WVB63WcEhiYv5l9842Nnm3hpT81q4xmRmASzZ4FylgGIW8qwqzhyK/QizT?= =?us-ascii?Q?ciBr5eGOvQT3EYI0nxx4ESCjw+JqNuO+XgujAeBvDBQFzEIbqKv/dKM/Xkcs?= =?us-ascii?Q?bn6o8gRY/diPPJdb2kr5p2s+poreWImjsT5kRECddaOLRfwS/54Q4E2sGreR?= =?us-ascii?Q?IxChe/nkrMNrlIOqEMfMmYMzRuiRCYuJ6JXeGynWKv3k3kXpmB1atCh3nB3l?= =?us-ascii?Q?ibOrTdGCXaeEIIHUVtOxXN5gK/ddIqfEGLJmI9BZW+nP9weoUsln+5BcUDYA?= =?us-ascii?Q?XB4jW7NKPtNKIJt/ZAXEvQZZvd44DleTTnDwwi9N7t2i4HoQxLR3cswITzVw?= =?us-ascii?Q?I7Jt7akgiSexkXDlBz0WzAdYUzTKOY3no8u7a5sP3ld46xPaDKS9enBVBBbX?= =?us-ascii?Q?J7rPSUrQowqJmbF49wN0eusv/DR/IVNUeeQZPvpPwMkZwVLsAlkriUxo6FEf?= =?us-ascii?Q?RiLoMZ7L1voP593X+5csMBhqDQrZAPLFoxaCJTF?= X-Forefront-PRVS: 0371762FE7 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0501MB868; 23:z52VcAD/YZ+enCDqfeDlgkTap/WGdpCjax6429LY?= =?us-ascii?Q?gkD4U2ZEmO9GowugnJdjRiMZPw2foTsfxy7y5AkeHAY9fK8W7G22YMEY3KIy?= =?us-ascii?Q?qKzSFo9vvzDFBOS7bdkqSqArSPRqJ0Px3jvZQvgpcBkHN4BJubCtrW6KOrR4?= =?us-ascii?Q?917mnJSqxaPe8Yk+5H9GmbktTgbRN63aWWCTVvTKxhjbdlkylJT0hcYVrUBE?= =?us-ascii?Q?GbZGQzjuREL9dWXCgf9DizoFbd+cl0OcHz+cx/ODG1K60XAOrldRJNELha0Z?= =?us-ascii?Q?pOMr2fBc0UzeJdQcmOAhlRTsI7eX22mtwiK/XDDnCvdAtXnc7FOZFdYn1iR3?= =?us-ascii?Q?85ptVuCtShXCuiq9KF3xuUj6+sLvV+YtYgsK/8xGX6G0oa+ni4YcQSFaPmtE?= =?us-ascii?Q?7kwA1ar2lOXE+mNuHK4mPqEwYdsQdc87/VEXcabIXAtnb5Rr3BeHEh7AI5+s?= =?us-ascii?Q?1U2I9zKdtt9du9oGw7B8rAoPOhhM31XIU/BceX+19Afc+MFN6Z/flt8BxzM8?= =?us-ascii?Q?a2Ur6kz85d8M6O7KPgzvN+9vmoEwVDff/QhyKrcJ7iTYK07XVZQN51fPUGlb?= =?us-ascii?Q?B4mFX/6DMOhcu7/9viPG5ST5p13WbwbDA436tucapvyhDzCZJ2D44EHP9MSQ?= =?us-ascii?Q?K0HfgQBGWK4zSYszAv0b2P3+f3UH6h+Bl6CZTPmAndN8YdiDvT2b2Dm/BADR?= =?us-ascii?Q?Qf2BKvbiKHm4EmXccU3edfFL28nqQK9wrcv4kUPowzkYIasSsVFAzPw1x3Z+?= =?us-ascii?Q?UBwuJjK6TRC0RWr5oHwfqCYl07ffWhdo0Ruli1ChK6BitAeS68YokP1NJ54I?= =?us-ascii?Q?UFBl4O9yahdcYZF9cWSRpGwP2UjSVuuO3eU5jaFuBl2ltyY86mjidBrGRJud?= =?us-ascii?Q?Hv0CzuHg8hUpBswr/1O4iLFZugLnPaTavDxNYoLMTVj0rF4WhJntQaYhO8eO?= =?us-ascii?Q?Po0evIE0HOCbSO/EHiKU/3SSbWUEA2R0L5EUH1INTftIx8s3dgic1gjKnDDJ?= =?us-ascii?Q?G0PR0ZtV+wxTxMaTd5u58GTjkqG6w3qYKFz1L5uMG8cPfniXbpRhcCldYhHr?= =?us-ascii?Q?iSJr15s1nw6hC93vwMH8r1v+rN1zzO42W+g2I5o5HSXezbAht1RuxJM46j1R?= =?us-ascii?Q?ggYDkuonZIM=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0501MB868; 6:4RZ6af7srz96+xe9tYdShr5D9CoY1mlrjR5DrPLrY?= =?us-ascii?Q?ymzhPd5FVHIModY2nJHi6Qw5HcZQeuZuzxa4yoKPIBc+Hxm1hzjfAWinB1cs?= =?us-ascii?Q?S58PnpqgnlU1QbC6bFUc7CGYL1ktio4rcSRG4de4+MmWe6exSgV2FkE7FVb+?= =?us-ascii?Q?ZRu3RZgXwiUuUsPxQZVYL12chCHz4OLE+6hbtFExa8eUg+Y1T9jqYeo5mkV1?= =?us-ascii?Q?jImASIEN2n7lU+bNFNlfh1pQMetOMOX4DssmlNqvBBfveskS3A40gB2015JX?= =?us-ascii?Q?2o6vKBWAsYkb6pjNWMU10DYrqbgl+ygrwS5Bowd3rdSQ4MmarzM2696K5vCK?= =?us-ascii?Q?oWuj6hnRQZaJZtxh3mBy2vzEnVtHLEMHMorbc0HEjpF19zVN2svctFGwUgg/?= =?us-ascii?Q?wA8XSwK7wmwhX63CV4imfhdMX+x/bJhNCaUAMkfDzi7jxgqBNptTUQllahaR?= =?us-ascii?Q?Cf3h3gaa4HFlG/b0H3kX1W7BYfwvZQ/rLJYwsvykm4mAO3wXcTg2XBhVhYv+?= =?us-ascii?Q?mbSnukF6uOMDwm3bY7ktmJV/UztNOe20EpqNybM/myqEx4/iL7fo3ioqgH+D?= =?us-ascii?Q?5f8flrfdgVaQJ8a3Pb0eS4fxHptrOr0s+lpnihjpfczMFOb8oMZq233LzOzb?= =?us-ascii?Q?PPZ68i+PvCoQr2JSGAKKvuFToQjBg6N++CcPlzT3SmF0IDxHcLYfgU/2EECb?= =?us-ascii?Q?7qKZEPGE4yH67rM0HLCgUzu5CuRV3ypp/eo470fuKPIr0lM7E4lGoLBlxqXy?= =?us-ascii?Q?Xip7cR0poz4uQAIKwBjaOjtj2fpGswWhw5tSaeRmCkj1u+PyUDwO5xCxO5jf?= =?us-ascii?Q?BabI7nZ4Eda8kGAjPiXidJTd1NIRHKtTduS8LvumbxfeCS1mH5DeYFgq7QbD?= =?us-ascii?Q?4OWuADBMVSbi+55Anzw/3CaKoEsGHvj3jtOgorjmub+XPEr4cCfLjewJioi4?= =?us-ascii?Q?yEkIbM43Ypor0GVbewzxyMHmRMiSB3nBGJLOmmrZ6B2Uu20MjTrWlnMAc1Tm?= =?us-ascii?Q?edVQh/tX4G0QWamQlUePI9Y?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB868; 5:PbTyIeioWlnfP8mfCx0gKk0T/zwCRh/AqLM5cmzaaugipyyjbNEVNj0eOVSYCPmV0dXHkVRX2wH1/en5nU7QceRIeEHLGWGhLRfUaZ486R7EdX7dLP7yzRqHWCU1wcH2vdU8eCoUjRSCQnfszGec1fYVDk4L2lhc6iiHsgn1uG25Ldf1gGzxwvRfdwxPUaZF3ad8mltNAYTSkC/brSzt2XB/r0WOF3t6CXApMkqOCka7ZPIf58bqseVwKriyNUl8/TxRD+WOo4A1tmsfFJ0CYPJ4xdZxt7p6mb9EbA8HQN9EJAubBNKUehRnvCW4d9odBj7eqOr9DE4Kc8O7N8pz8RmYUeZ25DJpLeSr2+93Ji3pjADarcPyEVuCIfGc7UNldFG7yUSrz0LR05RFI0LL8DfVdikZ5F0NcGilQEkhEmZP/sCAnFzXCftPNKugDAX1wQbHyBVAHxF6tbBZdK9lgHXdk52uC6+hpu2hD9Vv9zCXr56AbqFT5uoUUUk+rCew; 24:u03tq192BnSHw7XXCoGFZ2j/JMd3yakEMcCOCib6AB/V1KLxkOZhwsESHpWKhqrTGRRaktaxzSg+kEIgChsHVkCqehcCLVvIZNTyc3iRiys= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB868; 7:Czv0XIlFvd2iQwxUNzSLQgkoG1RtDMehgCKZcgVACIebBVz3OsoaM1wnwtyEKCE2vCJ87hcGGr1+NVHoYD21vF10AUg1jpvlV2B9vSY2kTVDTtHSTJIji+R33eASZVzEjsmTAgNXqdHKlv0KizVIamF40ztcVYYb6jgkbX125U3gKGb1ji3JV7KIRkhrQ67mcRxcXRfLFYmr8uME467jHgJXSYKSQFT8qmyu8QpRqlgteDWgIz2l8KC7CVR0dtiSwrUOrcxSeHCHKUItrB4oN4A5eOCPreXyGBKvsFp8sANkpyCS37bBLFhiITjxDUhl0xFNgmP10Ay9PA5a9uJ5btIo2hfCsGfhOm2O4/mFx2f9TwbTHyXc+ymuXXBlNPq+tzJlRW+o23oFyqq/xw4olYQJVSHx/+qMautkFnIQRiNkYQM/fOtVsfqRCPWSfLpLbsPE2FIrnqWHYtfJxKIoZXMXsPBA/kO2sxBI587YUYSZYXC2lLHBQnMwGL3KT5F1t8VxRZFSQYLIt2XLkKqX2rGdRShG57WKNoGKqmIHXFKSoFN8gfDqJwvrRWcFYXpyPMRa+u9UsGS84YCH88Hnl1BMRixR173Z2+uQ3WPhEdenmjZHzl7BEQQ7YPqMCT7iFtudZLS5mfMv5nPuHj02vJSxukR1ltIDwu0B7iiwiGpQqLvG+f5ZV9wTi1FCyQ3F5J7I40pe0OZ4efDFl38CfEliL0/9SXJTVvf/J20B0Kh5FwlbrqeLB1RHyhtynit4/qHPsF+ErQfgugBJut9GzU6Qyea2HSJPfEr0iyAyndE= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2017 10:12:26.2744 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.80]; Helo=[preapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB868 Archived-At: Subject: [Dime] RFC 6733 Commands X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 10:12:32 -0000 --_000_150028633461786980sprintcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In the spec was there a particular reason why we did not specify the applic= ation Identifier in the header for each of the command codes, e.g. ACR/ACA = assigned to application ID 3? Lyle ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_150028633461786980sprintcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

In the spec was there a particular reason why we did not specify the app= lication Identifier in the header for each of the command codes, e.g. = ACR/ACA assigned to application ID 3?


Lyle



This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
 --_000_150028633461786980sprintcom_-- From nobody Mon Jul 17 07:33:03 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2938D131C01 for ; Mon, 17 Jul 2017 07:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 AHh5Pp6dYn2w for ; Mon, 17 Jul 2017 07:33:00 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F8DE131BF3 for ; Mon, 17 Jul 2017 07:33:00 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id E77DC12110B; Mon, 17 Jul 2017 16:32:58 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id C501D180087; Mon, 17 Jul 2017 16:32:58 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0352.000; Mon, 17 Jul 2017 16:32:58 +0200 From: To: "Bertz, Lyle T [CTO]" , "dime@ietf.org list" Thread-Topic: RFC 6733 Commands Thread-Index: AQHS/uUJB8h6U5QREEmZorl9T0AXrqJYEfmA Date: Mon, 17 Jul 2017 14:32:57 +0000 Message-ID: <8331_1500301978_596CCA9A_8331_333_1_6B7134B31289DC4FAF731D844122B36E2D1B5E23@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <1500286334617.86980@sprint.com> In-Reply-To: <1500286334617.86980@sprint.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E2D1B5E23OPEXCLILM43corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] RFC 6733 Commands X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 14:33:02 -0000 --_000_6B7134B31289DC4FAF731D844122B36E2D1B5E23OPEXCLILM43corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Lyle, I think that there is no specific reason. By definition, the command is ind= ependent of any application. So when describing the command code, it may or= may not be contained in the command code header. It is consistent with the= CCF specification: header =3D "" The CCF is mainly used to identify the set of AVP that can be present in th= e command. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Bertz, Lyle T [CTO] Envoy=E9 : lundi 17 juillet 2017 12:12 =C0 : dime@ietf.org list Objet : [Dime] RFC 6733 Commands In the spec was there a particular reason why we did not specify the applic= ation Identifier in the header for each of the command codes, e.g. ACR/ACA = assigned to application ID 3? Lyle ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E2D1B5E23OPEXCLILM43corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Lyle,

 

I think that t= here is no specific reason. By definition, the command is independent of an= y application. So when describing the command code, it may or may not be contained in the command code header. It is consistent with = the CCF specification:

 

   header    =        =3D "<Diameter-Header:" c= ommand-id

       &= nbsp;           &nbs= p;     [r-bit] [p-bit] [e-bit] [application-id]"&g= t;"

 

The CCF is mai= nly used to identify the set of AVP that can be present in the command.

 

Regards,<= /o:p>

 

Lionel

 

De : DiME [mailto:dime-bounces@ietf.org] De la part de Bertz, Ly= le T [CTO]
Envoy=E9 : lundi 17 juillet 2017 12:12
=C0 : dime@ietf.org list
Objet : [Dime] RFC 6733 Commands

 

In the spec was there a particular reason why we did not specify= the application Identifier in the header for each of the command code= s, e.g. ACR/ACA assigned to application ID 3?

 

Lyle

 


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E2D1B5E23OPEXCLILM43corp_-- From nobody Mon Jul 17 07:53:10 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC276131C3C for ; Mon, 17 Jul 2017 07:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 hFwwDdsO3jEI for ; Mon, 17 Jul 2017 07:53:07 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AD6E131C41 for ; Mon, 17 Jul 2017 07:52:56 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 88FF0C0D18; Mon, 17 Jul 2017 16:52:54 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 549B0120082; Mon, 17 Jul 2017 16:52:54 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0352.000; Mon, 17 Jul 2017 16:52:54 +0200 From: To: Misha Zaytsev , "dime@ietf.org" Thread-Topic: [Dime] Question about the changes from RFC3588 Thread-Index: AQHS8zPdwgvtijx8lE6LLznwVivKtqJYL4sg Date: Mon, 17 Jul 2017 14:52:53 +0000 Message-ID: <29366_1500303174_596CCF46_29366_111_1_6B7134B31289DC4FAF731D844122B36E2D1B5ECB@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E2D1B5ECBOPEXCLILM43corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] Question about the changes from RFC3588 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 14:53:09 -0000 --_000_6B7134B31289DC4FAF731D844122B36E2D1B5ECBOPEXCLILM43corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgd2FzIG5vdCBhYmxlIHRvIHBvaW50IHRvIGEgc3BlY2lmaWMgZW1haWwgZXhjaGFu Z2Ugb3IgZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGljLiBCdXQgSSB0aGluayB0aGUgY2hhbmdlIG9m IG9yZGVyIGJldHdlZW4gVENQIGFuZCBTQ1RQIGlzIG9ubHkgZHVlIHRvIHRoZSBjb250ZXh0IG9m IHB1YmxpY2F0aW9uLg0KDQpBdCB0aGUgdGltZSBvZiBSRkMzNTg4LCBpdCB3YXMgYXNzdW1lZCB0 aGF0IFNDVFAgd291bGQgYmUgbGFyZ2VseSBkZXBsb3llZCBhbmQgYXZhaWxhYmxlLg0KV29ya2lu ZyBvbiB0aGUgUkZDNjczMyAoUkZDMzU4OC1iaXMpLCBpZiB5b3Ugd2FudCB0byBkZXBsb3kgRGlh bWV0ZXIgaW4gYSBzZWN1cmUgd2F5LCAoVExTLylUQ1AgYmFzZWQgaW1wbGVtZW50YXRpb25zIHdl cmUgc3RpbGwgbXVjaCBtb3JlIGF2YWlsYWJsZSB0aGFuIChEVExTLylTQ1RQLiBTbyBpZiBhbnkg cmVjb21tZW5kYXRpb24gd2FzIHVzZWZ1bCBhdCB0aGlzIHRpbWUsIGl0IHdhcyBuYXR1cmFsIHRv IHByb3Bvc2UgdG8gc3RhcnQgd2l0aCBUQ1AgZmlyc3QgYW5kIHRoZW4gU0NUUC4NCg0KUmVnYXJk cywNCg0KTGlvbmVsDQoNCkRlIDogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10g RGUgbGEgcGFydCBkZSBNaXNoYSBaYXl0c2V2DQpFbnZvecOpIDogZGltYW5jaGUgMiBqdWlsbGV0 IDIwMTcgMTU6MDUNCsOAIDogZGltZUBpZXRmLm9yZw0KT2JqZXQgOiBbRGltZV0gUXVlc3Rpb24g YWJvdXQgdGhlIGNoYW5nZXMgZnJvbSBSRkMzNTg4DQoNCkhpIEFsbCwNCg0KSW4gUkZDMzU4OCwg Y2guIDIuMToNCg0KV2hlbiBjb25uZWN0aW5nIHRvIGEgcGVlciBhbmQgZWl0aGVyIHplcm8gb3Ig bW9yZSB0cmFuc3BvcnRzIGFyZQ0KDQpzcGVjaWZpZWQsIFNDVFAgU0hPVUxEIGJlIHRyaWVkIGZp cnN0LCBmb2xsb3dlZCBieSBUQ1AuDQpJbiBSRkM2NzMzLCBjaC4gMi4xOg0KDQpXaGVuIGNvbm5l Y3RpbmcgdG8gYSBwZWVyIGFuZCBlaXRoZXIgemVybyBvciBtb3JlIHRyYW5zcG9ydHMgYXJlDQoN CnNwZWNpZmllZCwgVExTIFNIT1VMRCBiZSB0cmllZCBmaXJzdCwgZm9sbG93ZWQgYnkgRFRMUywg dGhlbiBieSBUQ1AsDQoNCmFuZCBmaW5hbGx5IGJ5IFNDVFAuDQpXaGF0IHdhcyB0aGUgcmVhc29u IGJlaGluZCB0byBjaGFuZ2UgdGhlIG9yZGVyIGJldHdlZW4gVENQIGFuZCBTQ1RQPw0KQ291bGQg YW55b25lIGhlbHAgdG8gc29ydCBvdXQgdGhpcyBwb2ludD8NCg0KVGhhbmtzIGEgbG90IGluIGFk dmFuY2UhDQoNCi9NaXNoYQ0KDQoNCg0KDQoNCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2Vz IHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRl bnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZm dXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6 IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhw ZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMg bWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApP cmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFs dGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1h dGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlz dHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBt YXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2 ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK --_000_6B7134B31289DC4FAF731D844122B36E2D1B5ECBOPEXCLILM43corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLD qWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bh bi5QcmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0 w6kgSFRNTCI7DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIiwic2VyaWYiOw0KCW1zby1mYXJlYXN0 LWxhbmd1YWdlOkZSO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJs YWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3 MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SGks PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JIHdhcyBub3QgYWJsZSB0byBwb2ludCB0byBh IHNwZWNpZmljIGVtYWlsIGV4Y2hhbmdlIG9yIGRpc2N1c3Npb24gb24gdGhpcyB0b3BpYy4gQnV0 IEkgdGhpbmsgdGhlIGNoYW5nZSBvZiBvcmRlciBiZXR3ZWVuIFRDUCBhbmQgU0NUUCBpcyBvbmx5 IGR1ZQ0KIHRvIHRoZSBjb250ZXh0IG9mIHB1YmxpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+QXQgdGhlIHRpbWUgb2YgUkZDMzU4OCwgaXQgd2FzIGFzc3VtZWQgdGhhdCBTQ1RQ IHdvdWxkIGJlIGxhcmdlbHkgZGVwbG95ZWQgYW5kIGF2YWlsYWJsZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+V29ya2luZyBvbiB0aGUgUkZDNjczMyAoUkZDMzU4OC1i aXMpLCBpZiB5b3Ugd2FudCB0byBkZXBsb3kgRGlhbWV0ZXIgaW4gYSBzZWN1cmUgd2F5LCAoVExT LylUQ1AgYmFzZWQgaW1wbGVtZW50YXRpb25zIHdlcmUgc3RpbGwgbXVjaCBtb3JlIGF2YWlsYWJs ZQ0KIHRoYW4gKERUTFMvKVNDVFAuIFNvIGlmIGFueSByZWNvbW1lbmRhdGlvbiB3YXMgdXNlZnVs IGF0IHRoaXMgdGltZSwgaXQgd2FzIG5hdHVyYWwgdG8gcHJvcG9zZSB0byBzdGFydCB3aXRoIFRD UCBmaXJzdCBhbmQgdGhlbiBTQ1RQLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UmVnYXJk cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkxpb25lbDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gRGlNRSBbbWFpbHRvOmRpbWUt Ym91bmNlc0BpZXRmLm9yZ10NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IE1pc2hhIFpheXRzZXY8YnI+ DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gZGltYW5jaGUgMiBqdWlsbGV0IDIwMTcgMTU6MDU8YnI+ DQo8Yj7DgCZuYnNwOzo8L2I+IGRpbWVAaWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+ IFtEaW1lXSBRdWVzdGlvbiBhYm91dCB0aGUgY2hhbmdlcyBmcm9tIFJGQzM1ODg8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEFs bCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SW4gUkZDMzU4OCwgY2guIDIuMTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+ V2hlbiBjb25uZWN0aW5nIHRvIGEgcGVlciBhbmQgZWl0aGVyIHplcm8gb3IgbW9yZSB0cmFuc3Bv cnRzIGFyZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnNwZWNpZmllZCwgU0NUUCBTSE9VTEQgYmUg dHJpZWQgZmlyc3QsIGZvbGxvd2VkIGJ5IFRDUC48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SW4gUkZDNjczMywgY2guIDIuMTombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHByZT5XaGVuIGNvbm5lY3RpbmcgdG8gYSBwZWVyIGFuZCBlaXRoZXIgemVybyBvciBt b3JlIHRyYW5zcG9ydHMgYXJlPG86cD48L286cD48L3ByZT4NCjxwcmU+c3BlY2lmaWVkLCBUTFMg U0hPVUxEIGJlIHRyaWVkIGZpcnN0LCBmb2xsb3dlZCBieSBEVExTLCB0aGVuIGJ5IFRDUCw8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5hbmQgZmluYWxseSBieSBTQ1RQLjxvOnA+PC9vOnA+PC9wcmU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCB3YXMgdGhlIHJlYXNvbiBiZWhpbmQg dG8gY2hhbmdlIHRoZSBvcmRlciBiZXR3ZWVuIFRDUCBhbmQgU0NUUD88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvdWxkIGFueW9uZSBoZWxwIHRv IHNvcnQgb3V0IHRoaXMgcG9pbnQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBhIGxvdCBpbiBhZHZhbmNlITxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4vTWlzaGE8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8UFJFPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1l c3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0 aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpw YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh bHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmls ZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3Vs ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlv bi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMu CkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3Nh Z2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsg eW91Lgo8L1BSRT48L2JvZHk+DQo8L2h0bWw+DQo= --_000_6B7134B31289DC4FAF731D844122B36E2D1B5ECBOPEXCLILM43corp_-- From nobody Mon Jul 17 08:04:00 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC02E131C34 for ; Mon, 17 Jul 2017 08:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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 psx2CsNkhhJL for ; Mon, 17 Jul 2017 08:03:55 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0112.outbound.protection.outlook.com [104.47.40.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 F30F5130019 for ; Mon, 17 Jul 2017 08:03:54 -0700 (PDT) Received: from BY2PR05CA036.namprd05.prod.outlook.com (10.141.250.26) by BLUPR0501MB865.namprd05.prod.outlook.com (10.141.254.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Mon, 17 Jul 2017 15:03:52 +0000 Received: from SN1NAM01FT026.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e40::200) by BY2PR05CA036.outlook.office365.com (2a01:111:e400:2c5f::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4 via Frontend Transport; Mon, 17 Jul 2017 15:03:52 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.38) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.38 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.38; helo=plsapdm2.corp.sprint.com; Received: from plsapdm2.corp.sprint.com (144.230.172.38) by SN1NAM01FT026.mail.protection.outlook.com (10.152.65.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1240.9 via Frontend Transport; Mon, 17 Jul 2017 15:03:51 +0000 Received: from pps.filterd (plsapdm2.corp.sprint.com [127.0.0.1]) by plsapdm2.corp.sprint.com (8.16.0.17/8.16.0.17) with SMTP id v6HEPZ8e029857; Mon, 17 Jul 2017 10:03:51 -0500 Received: from prewe13m04.ad.sprint.com (prewe13m04.corp.sprint.com [144.226.128.23]) by plsapdm2.corp.sprint.com with ESMTP id 2bqgu5rsar-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 17 Jul 2017 10:03:51 -0500 Received: from PLSWE13M04.ad.sprint.com (2002:90e5:d617::90e5:d617) by PREWE13M04.ad.sprint.com (2002:90e2:8017::90e2:8017) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 17 Jul 2017 11:03:49 -0400 Received: from PLSWE13M04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a]) by plswe13m04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a%24]) with mapi id 15.00.1263.000; Mon, 17 Jul 2017 10:03:49 -0500 From: "Bertz, Lyle T [CTO]" To: "lionel.morand@orange.com" , "dime@ietf.org list" Thread-Topic: RFC 6733 Commands Thread-Index: AQHS/uUJB8h6U5QREEmZorl9T0AXrqJYEfmAgAAL0Ho= Date: Mon, 17 Jul 2017 15:03:48 +0000 Message-ID: <1500303827591.97405@sprint.com> References: <1500286334617.86980@sprint.com>, <8331_1500301978_596CCA9A_8331_333_1_6B7134B31289DC4FAF731D844122B36E2D1B5E23@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: <8331_1500301978_596CCA9A_8331_333_1_6B7134B31289DC4FAF731D844122B36E2D1B5E23@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.229.91.93] Content-Type: multipart/alternative; boundary="_000_150030382759197405sprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.172.38; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39450400003)(39400400002)(39840400002)(39410400002)(39860400002)(2980300002)(438002)(51444003)(189002)(199003)(377454003)(9170700003)(53546010)(626005)(86362001)(36756003)(14454004)(117636001)(76176999)(106466001)(54356999)(50986999)(5660300001)(84326002)(512934002)(189998001)(19627405001)(97876018)(356003)(229853002)(7736002)(30436002)(5250100002)(2501003)(6116002)(102836003)(3846002)(8676002)(478600001)(5890100001)(8936002)(81166006)(6246003)(38730400002)(53936002)(54896002)(2900100001)(2906002)(2950100002)(19627315001)(19607625011); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB865; H:plsapdm2.corp.sprint.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; SN1NAM01FT026; 1:odQHwbtkGiCPdXr9dFqphceU7fWIIUn4WR9M87CgPYkjOwvITUAx4t8664GDgEocyRiss76nFtU5acPYGLAVkSD1qYF/AJUpFbAjp2KHJgxLT+6f9jb38XQIYrbt6X+A9uDFRiF6W/dnDLS+qqpao3E++IUY9gvFxkijd6AdQ77qZRV4z8QR7ZKplOK5G6BkwZKcOWOFc/UubJXqCmmskPxAOLWuZP7VutFP+Bfa8bOb5pzZUuJPpMn/qzfUks8VT/7H8BDYJSN5hKgfNc6tx/KBD3dTlOcKPnUCZfd7vedIFtnbD3435tyTCQ9JwzQoOMdzCJuYMDKoaEQ8mOctFevVv/DLIKWBoPxOyTeSIyjtPzPkoo5Sxy7pYJZTisE/6pupeuRreDX1anBEXL592TwLyZ89JLVF8ylnJ6MH4OUElZf9/1hmh9012keBbXUE+IvtvMJGKvMQlWUUIB37zI5yv3YNP+szG3tgND9rj1QvzpNZDmFs0sklLcgweW/x0YE4/CpzBHIWnnELB1D/7dVIqwtT4JUovPXQatAU8eePFhUf6Oy/nSRx0dnjCgOFh4FkVuJTc4BIUm327mCKpwk98+V3j0i/9pX+K9R+32E9mEd8KxwtYPqPZWAsWTazGu5ksWJEp7RIBmPOyaWg3tMlTtOFrXKlxNfas+buUkliIP5/S60Qbjnu4ki7BLXWLpS8d/YDJaBgvkLX8LBLacePYe89I8qj0c2GDgarXEL/F0hsB9bLHsxrt9cmdIl4nRB4C0rGwIThHeQOtGVpkFDAvYE041Ww8Rdugi+K9RQhxY8ObnVMDFPWKpgWep5Rw0/RQx2XF2joBZmJ+sW7txTcKyTg465pnqMWbDyXddpWhlA5e9zRsyMTB5v2nXo6fDwPNeTsbWOXC7xkBHqqB9HlKEiJgdkDd+4iPi7crn0= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ddfd1783-1c37-4f2a-da58-08d4cd250957 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(8251501002)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR0501MB865; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0501MB865; 3:s95qIFoyErNu4Fo/taaS3tCZbu+uOWu/jsumBW3KX?= =?us-ascii?Q?J5rcTDLzN9+Dm+yC3U7uHHyRtY/9MfYtM+RXFs6t70+gbn1pckQJw9GLK5pT?= =?us-ascii?Q?1lzzY8/H5YQdz4whdHfhvjiI3CwhSBkxtjj0PDGYUo2uhh4+57STJ0RYt5eE?= =?us-ascii?Q?sDamFcdRiJhe0rxyxGKSXwcZaVSfSIFqhwbozpTGDkl48+G5p0EUkxglf8z5?= =?us-ascii?Q?cQb8NDM/kP3m7+rW9q1aDD9dTRYqu5oGFXaV7g/qUWjBKdu5u/esXQMIvVVm?= =?us-ascii?Q?zD4rzBeFh/hBKkXb6E3c1ffPq5BYbBWyIa7E9mnkiVdSQVBrrWWCSa+2BOIh?= =?us-ascii?Q?5PlJhhk1VuiWwYG4VespRvbFZ4MyV33JvZ4QK1sB/1bzFlK7rfmnJeRRYNHG?= =?us-ascii?Q?h7YL4HRbhTM3UI3121RmXKGA44l+bL8tI+b30zFsxMsc6EPma/xQqg5IXTMg?= =?us-ascii?Q?5XwmfLWkBNjb6VHgBfzgM5cXZWtYT3BlH/X+tdM5B/9YUrX/0Hl30cYSL26N?= =?us-ascii?Q?aHUy+20XXS9dbi5wGBndh1z8nRGumKjdfLZs3m0sJ55xPd8gSOiaCMCVwFJm?= =?us-ascii?Q?ftmAaYLTFJAqExyOp4SVZZQe2IRQLTasU0jHnrPlN6QDPVodAG66r9dTGhpI?= =?us-ascii?Q?1OgMv/idJ/dBv8WCqPWqYigsCLZjJVGcAdHZD2cSPWb5mTb49tkz9oAL+jSp?= =?us-ascii?Q?AJDtPFPcwu8o3qv7cXrtfb9crSWb0oPgSwTaeXSPge29U8UyoRhj2Hj+CB4T?= =?us-ascii?Q?sRiuwiirNNdpKY+E91lN+83KW22MjPR1Os4l2v46ByGfaxAYtB+S4lM3LiUW?= =?us-ascii?Q?tjyHud4/EPukWTxZ8H9u9e+X9xMhtxdFAueI89sFUoD7AQK60ed6XYf1BZDZ?= =?us-ascii?Q?scIqUqkS1LCpcBlsT8HrQ1VoKzSZ4eorS6yZtmXgoKQ479Pq//RgF5PuzCLB?= =?us-ascii?Q?Jbcs8kWpSYgUr6DMAz/UcaxM/IUKPWhXhxTYVII3A=3D=3D?= X-MS-TrafficTypeDiagnostic: BLUPR0501MB865: X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB865; 25:vTK6z77T2jc7oTV1VcTM20814ptoeJ/vJl+7M/PS3ELNLkdm8068SostHyhES2gUoOgZrqQEkj8bdAFk4lURtSdjOJxyuZRlxDd01PBON8K5HBtWrb2m7paZVA3I/XWlybIU1ZdWq7wa1KjPs4GdbEFPB3OAUcgt/c6m87P10jv5jqiYQBgrufDkMHH705ZRkjm24hmUq/lk+huqIdDkmcn2tbkYuAMiOHpdWlX8Ugey0Gsuv6QBfRYbLpTQGiROA2316qx9CmynRPjPxKTdWiRuVVsJyEeQeLycs2McYRkd2oxnCeIfcJbVcV/Ti32gydRmia/kPtOD76e4p/ZB8PqM96O+87HlxQSO8pyBusZXEhU4j6ZDrVF0nRX93mTtWbWVcvVXc+a03tPqI7dKA3zhlZOymoR0jvYyQvi8xyFzUBQqanOAxZsc+avEn0vCer7Hfn312X1/EptFzak4D315AWW22vzoPzP7nvnhp67YP4mVB5gB/xrAkest/2unrLkxChRdmMakBWlj+EmnGDkbRKMa11dQ3eoYL4SWonpRKZMdMfDK95Xc/dYjJBiq85sfO6bZIFbCCnpR3MLOn04fi3svuYDsLIjR7JYhPUhCFTKyawQxWOdelqaGiweB5sMZjcoGxe85jACQ0opN8Bk5vXIhXRCGvKCev9HJadDvix1Dbk/S209nJ0Skz7d48YLnmFEt2mv4zCiwzIbBofsBvVfKCsgi+KJ0DvGbaUq7wf5Efi0fI2fmhAg2w/k35OnRWivDpIZa7BfPduJVhr3S39A6VKiuHy8QiRgDSVLNtj1+QR17euvhlgO1hG1uWCu6yRpTEFNI27JAxbUK0ErYcZv4xREYDjb4sdFYa1ARqE/wJvYxm7i/H809YYg6X4u6YLMNbdiuf8mDgTcJywXfOTQIM0+S8Rf6BqT4GYI= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB865; 31:lq/X8BdVP6DdNsuKPSatovpksziQa3U1bpm8JMssr3ywAHrllXUEpVQKuQJWvFst2xArJm+8nT3S820RqpOi4GftC8heJd0kKsHkzOjJYsk5lh/1qKrZ050etbBh395mX0663Mx0jrC0MVR1itIPSGFi3HkG+F0J0GUi7C2kqMq1+K6/7nGq2rmdtskVtTl8SSkMkviCzdUp4DfxdB++vBl2qHyspgYcVbUkU+glG0EV2LDH4ZpKOV2MpzDyB9u5TAuqg2PJtW10tOjvLoMZzcHP807OuJZNW6KioZ1uv+WZNpMCTyUrP5UA1jMA9XFkNJARhwxKxhUCji1l0ckuQxVebaBcYlzZpN/6MXEE6RF5phA5mmSViLANzVYi63F93m23EneQB44Z87/zEd7Poembacdvw+7UwZaftq0ZSokGUQ73EpRLAIEISApeSwG9kAMSC8899+wXtS3hKLez99r4xiUB1VYMvkkrjcz2u2zm70v87EAuDrZcG//1Kzgx4rtVL0pVop8TRmDzhnS2qrXZQg/S3IGqVP+ZIvy+Gd5xYcsiI/ApaKgGQuI0PDAMR2C4WfocmCduR2CPA8xSn4d8jK1xGVy1MeXJ1QetbPrISNvrcuMiAMkAFnbS1gd6gvFEgw4ikNleV6bQ7tjLN8dF8jEvxdRaNaQ0riNhEAMBqIgFzxE+vHovmNxS/lszIdKLRQyYlI0aCyYWlMv62I07W4M7LmWsoa5u/Dfr85A= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB865; 20:Lo2z8IwrkgJ0Dh4/pYyngm1DOZTvkHDMuNNx7neLTEBN8rOGNwQc4TF0E7wNke/ANPHQXNUJjCcUtem4wlXmRxVLXAS0IPjlbX+gYkJo5HFhbQCpMFjFir+VQ9VWde49AkW7FoQeeDscDvEFA6Fw44+a70t1GS8tO2iNSkTIPVqpYFVeL5LGkzb7I+PYXrr+/eYSSiWFjIXw4NBcrbNiZ0oBrK6AMWvisgp5gziVlOMY7Tc2qgdm/7Hgvw5EmUwEskCD15yqWtmfATRkqG0xVtqGb+x9oGu21z5sqL3P/QjB9+NIGrnt3JcqohxU0D+noE9BdGkBAVxdCwzGlojpr90QS76gBjAZqlIjp822N3OJYQL5Z7+AQhy6zbfWBqATzf98obARYISTjSXBuuvmhYsG0njQWE8K1VWXajkZP+nwnJ1r+bslPUgLZYZ7YEUerIbIC4PqSsVh4tLzXCzbB4divK58ADDtTRyxqIBAYZjYwhkeFDxHeg19H4J3mfTb X-Exchange-Antispam-Report-Test: UriScan:(236129657087228)(148574349560750)(18271650672692)(209349559609743); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(13016025)(2017060910075)(13018025)(8121501046)(93006095)(93004095)(3002001)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR0501MB865; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR0501MB865; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0501MB865; 4:ZpO7108RrHGpHACfn9hRa7B4Ioc8mWtHNscweTFM3?= =?us-ascii?Q?vy9CmMoafhgL9B/xdzn9WzTPfD7ol86qIEAARQDasobsrUk8gYhtLwwnW4rD?= =?us-ascii?Q?PE3Re89FX+Cc0dfvMNDnwVSwFCEU1KtmGfipSIo70myVhOzHUurU/RwikQsm?= =?us-ascii?Q?vEoqeMmUj6z294A8UiAi8VpL8U8DQ20E9zeFq20YYUG0VRa1n6sRIFu4c1YF?= =?us-ascii?Q?zPwcS0VAHnLxiJ02JAf4V1N/0bzRVX0muA+2OYSt5Z7x2cL4wtA7gvhfyoBz?= =?us-ascii?Q?aHwy1a2iJVk6VcoIJbF11j6i3p2L/opagcFXMCgOoNWj9Fnu5rzTbRVchFGH?= =?us-ascii?Q?ySwi2T8gajFUZA7GCBP35hBFR1giRd55hVYJJQ07a69AGdwFmvPONPclkVas?= =?us-ascii?Q?IiFgCsHFKgaedUrtDm/FBLPxu3xAjpe4TsOe1WNBZ9BhF8V8sILlUO55EZBN?= =?us-ascii?Q?GfDI9hWLRYfxRMGzawNrXfixDqmsqVHZDZ14cGGLaRbBufa5b8J5yYjhI7k1?= =?us-ascii?Q?/uq5K7N8u2ZGBYmf0IZrJMyDc06jNLqy47Ku8r6HvV98CsO1Wle8iuIqwh6E?= =?us-ascii?Q?YX5nl0dFt3Om9JG4Sr6cYT0LE/qRsMdDwto4mfDmF/rGZeZcnXh7us3fEo37?= =?us-ascii?Q?UG7FOcm9nLS+ks+N9OwgfqGiBpTTi+751jFmCuF/KqEaAuljBqoT5iYXb2OX?= =?us-ascii?Q?Nxd3kVBLVTOgpo8O2SqPx05fv1e1t+6S9Y68YMbiFJhnar88gb866uil1IGL?= =?us-ascii?Q?7Yz0QwcTd+XAj4C8jPOyZeUxIckzMd9ezZjSCL+wOjb8pxg8KoZY9FXHN8T6?= =?us-ascii?Q?Izzu+fFXRgupRe8mlTJr8mE5Jq8heP5wLzVg7LWh/0txpBhBjy2w7GdGoB6W?= =?us-ascii?Q?bevNHyk2HFuC+fGUFPMydgI0SajTudAUW7LxNX3w8tFzywh/Mis4MAsgZHx6?= =?us-ascii?Q?2KKAMlcY5HafB144z1joJIHBuLXqULFTgrDH7iiwBuHfFXeChPsAeHByUwXF?= =?us-ascii?Q?T1ERqp5MwimAvdsAA8psf1zvtzwgiJpmiyhxHqd5JKLxJy+giQqSiWO//w74?= =?us-ascii?Q?ksKP/aqFWVzroryUsuEKvCoUfVSkVFq+/YG6uJarCcVdbgC9/xQ2Ynskc3V8?= =?us-ascii?Q?evKs0DgYL6oQnYTb3ftTbfFjDj9gTu9bk6QvEIt06qCVXiQdrramoRlWZ7Ta?= =?us-ascii?Q?oijWv0AAXfnynyDf1PqfEeKJNq3bV7aPRwlIaQeSA5n+g36NCEVDjOQ1dNtQ?= =?us-ascii?Q?ONHRJaN/Zcq+03i7Fb3EbpMrkcucPGg1TR+gZkf04fcEqyJL20zRUuDSVYdH?= =?us-ascii?Q?Z/mUbNTJO5eU6hNkMG9Dgcw02b0EZDWMyApqEe7veEXvRiWpucJzaB9MI2cO?= =?us-ascii?Q?U3geGchgjKJw5jvCEaL8HyqfpI=3D?= X-Forefront-PRVS: 0371762FE7 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0501MB865; 23:vbglxO/c6Mfg3vsBTYj8q853v+fIME0cuyZq51Mr?= =?us-ascii?Q?BpRxoC988511RgwZXesUlONEexN6kn6P4+zbGJ5LB9MA5uMV/TsE3nm9w0DA?= =?us-ascii?Q?5CWsaYN3qzLuSL7lCw+odxZ2xu0Cg1UBO9x+q1N5kCXszEcknYI2rNFAWIJa?= =?us-ascii?Q?p3sGOAiQFsFszoVDRpfU5BCM0QLAExgqKIGfBMbYpN79JnoJTSFR5F3XyjoK?= =?us-ascii?Q?UgIxQTNpL+G5ddiZGM+/70kDFDvlF8YEjzocWa3qIT8EJ6rDBD6YtoTfoZX3?= =?us-ascii?Q?GqJ4TNWe+v/o5ZOHuR7/Hg25Rt9+E3TTnSQv3MkqxFSa+C9V77yaB+xTUjIS?= =?us-ascii?Q?/9M71Ir61BiZHPtzfu9OLCYvhAcJWM6sSuPcZjLs3w9diiospOboYAZUDrX4?= =?us-ascii?Q?E3whbOEOoczk/U9S+LmuW2qGZ5WN5tm3awSLzBl5LIOoiGyaFhW4PMVBAW4J?= =?us-ascii?Q?j7W4jZxX00a8Mtxbcd7gPlOTmN1eBDj3I/BnMwicFGyzPCpyOTfuC/6VM73y?= =?us-ascii?Q?MinWoE65Mtn2HlKP0VIVOTHKZGBdwKpxtsKx6N5NUKOVqiPOGRHwc51OWEwa?= =?us-ascii?Q?BG1Lm9oH4cfCIuxfpIQQqH2Gtlas8zNTrngHxob2DMZGujqMGsA/d6dTBmXW?= =?us-ascii?Q?NHAlLvyySdnTYBC9gOSi6VGx0JWTqtm8+tvwCNQvbaAmXPYqe2FB+PILhtPd?= =?us-ascii?Q?Tx3muzUydb+eCL1buTZAeRzKM3hkVZ/C0bpnQRxYNXXCGZ281v5FuCqCbC2h?= =?us-ascii?Q?n7s32Fw3JiC2kBfNulKAgfkDB9+rifOKnx4tbgJCSBCujKdKUz1KzRHK8dnk?= =?us-ascii?Q?8K9xMTAA8DkovnJ/0PudQ3cCPhVIsFkqxE1PxUnJho/Oy82pMzXoBVcDjVtG?= =?us-ascii?Q?nFpoWZTFF+tYkEWgfs5Mp31T/DXRNDsApCSg7vQaJT0UwGsNUrxv0DsHpD3G?= =?us-ascii?Q?xCHidcNNfjzDFFCeHUl/h3JnZcUSCARGsn447OoCv8wpkV4+xYagyhKjqYSt?= =?us-ascii?Q?fFXWDfHkqF4EmoMbufnnkcSKxiv7CT8mOCWiYn/sb3TkcZskCqjC5MwhN/EU?= =?us-ascii?Q?J5ly6Om/kW1iWPU/s0dcts+fDp9x7A+1J88KqctgNNmbejlQqjqkxyh3+GXT?= =?us-ascii?Q?LCXXRk5whi8fikI1JR9ylej8mtnoR9ao6OtLGTrTG95X+aGZxrCuxIar0DW5?= =?us-ascii?Q?65jjqfKgquO0FYy1XkH+V6g2MTwfHVdiBk9vNnKBvp5dVhuIc1l3HNTNCUCh?= =?us-ascii?Q?/9mPKhEKc4S2ci/bGonhf9b4SUsFzstKMV+MIlGRBF9AuG+0S2tPa+4qCQHK?= =?us-ascii?Q?n2LM+6DFMGmbiVLYC638qns=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0501MB865; 6:p5o/VxhbY4yuJ+Oe/5WPWjeh9LtuEHj2az5ByAtW1?= =?us-ascii?Q?Lx6EjyGFHl4bhflByfd92pp0Bqfkc+7VJqgXKbCGcme5SGdpTu45A42svbSs?= =?us-ascii?Q?GJjN4zH6JfiKPKNX8u03FBUQp33dAty/BuBpatWCd8Ucd1XPfU94gTZ+86UG?= =?us-ascii?Q?CMHAzB5IIDYL7zhPm3iTjtINBduT8mgdhSqxeSPOxgTp3iZFxzv3iQt71VlL?= =?us-ascii?Q?D0TaD7hrkYCGjwkH3fWxwuvNRBrlNMIyWpdDVxOCIG5vwJud65ESWyIyWdao?= =?us-ascii?Q?d/XEycv9OSD9MUYOQCiVPt/mzgr+AqcPWMT5g9ycUu+0aKTb99zJRDjmKNDT?= =?us-ascii?Q?hyB0vGQKuux7Y50A5Pr3SogYN/m7Rg3dtUD7CeiejkTy3GG2q70jFUQXtKXz?= =?us-ascii?Q?ktmB99V4IdUIBI5BvYt6NvSOlV/fxkFbwEkrZoHTNti/RVjoZVnp/0m0cR37?= =?us-ascii?Q?m38n6peMg2Ax+wgojRHG8TPdyoS3BrpbQyoUaUyG8ITOP3uanOct2ytzmOAT?= =?us-ascii?Q?wYyx/m5q7wR/YCKhyGfePoOjYA1LWfkPsGxs/Db434mBAWAXCB629/5RYG7c?= =?us-ascii?Q?o09v4errBRp4hhBkP9l5YUpTuZoEcQiu4hQnpM4Zkwx+OU9X535nbCQi3gNb?= =?us-ascii?Q?XYj2qbS3QdgY1LbFtRJbJYQBTholugkDiSbBKVoFEeHlqxdNhEwcvVO+2l7A?= =?us-ascii?Q?A8f43f7b4A5bDH3iVkdF4c02pWn4SFuTtTRz4J1pzE3LB8R3pn7Xyo7Bb+RY?= =?us-ascii?Q?0tVWj/wut9QI4HUNyiMqnpR+e6qBBSl4OUhxQ098CajvdA7EgiWfc7h6zaGT?= =?us-ascii?Q?kVGjw2dqihxjBVBsklPM/9aGctNfCj11ey0GvE1MFyvozXYBC6HIqsAfvoF0?= =?us-ascii?Q?wXP/Huw0db7RpcNM7Lm3NhVmDO1JO868cyrr9JAUgiOVL1SST5fTx+Pryvxb?= =?us-ascii?Q?sxdD2wiiN9ViyD/paxDXy5z3+jf7XKiFRXmcc3dPPV2wKPA4FvvNdmRPH48n?= =?us-ascii?Q?UthtfS3TQrjPdPEkMvP8oNC?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB865; 5:ScsxHGAkI+QUFxC8+X1wAMggGeECAsdxx5o2/f4m1ZojPscxaaf9iL6eX2dVIdWUs990VN9WFu4w/PjdZHz5F76gw0cGbJ4r0d+psZxk5gCOM7Tgsj9UX8roMr2Czh/jO/nLNT10KnC6Ii5FLtCfLv1WQ0Vm/vzfx5Yswg5jTOpqHY3EVIibOa4+BmelH8Or7C0yDgfg63LTKIdSuarUOlhvJxtnvvt+NDPwNtJzWXR+uG+Q/iuLDrRROmL58hs2OK227oy3568BveCwm+yfCb/PFMH8/VM4sxGXP+nTw+w9Jc7hPgWvApB1K1D3d+Yf1rR9B50gc79HOjY/t3A862XZGciDH/Ogtxci3iCZWvUHdtB270wnJ4FUGpKBLZ7xRo68eF3bb+C8n0JO03XFb/inmEiNUHFrgYpK6mxRuRlJFrXcBfz4f83VQWu8LFxs8/qSkNX4W1Bpm3O3rQIKM4fTc2puBlYMG/8g/4qJOgQob4y5BrHj/7OxE9CPYgye; 24:52FRIBaskJELPegkXuE1hpwXhi0ySmSTGfCmCzrUuVlaQcXacVj9MNJhtcGwCMxaUjNqXvMxUjfP3PfQUtM1apc22OpNNW0BxcNFNmOYyS8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB865; 7:oximecp5K79z0KRvWVrh5MOSdCX0suLOcLYmbk4g64a+HCaBE4vp11mEi4ddlbF9tS6qt62krOCFi59nWUlDXGxPPxYsYe/Jx8zlMK0QZUuwb8fwOneOVJsPzfYcqoLhMBPStzRsqbwZ6tzSKwdF9CNZCwI9kp2ocBULZOEhXruNb4t0L4vHn3b4SWKgWqZvTF4Tr+lxZkecNJmJ76gNDyO+9de4ae0DgCMFBfUVt7lMAHQWjSsghom7qga18cJuwQP5xZD+9OQK/POsJnfxB/ICSQG7myZb4pDmoGRep9kuASPT5pY4l/VKw/Z8zU1b5lPzISrAviLdiMl9kpXU8XJmGvotDQ9PjvOucX4K494i+UzwyVRmCZEwXciLqboATrbvU7lIPVUvDFcDKAwZ/BQPTSR9fVS81qsUsR69JO1Go0yD5Ks9GlbKIngSgJBaI8CvQB64lydjdacdBw3o24g8LO0d31CbxP1/9qp/2RQkiORtAsyP3+paPDxOBjJXa3Iyyfc0uKjx8e1D74MC0Icwy8m8H8VkXyqAUyHrs1FdTfptmKKHHMiSh8o0h4uePhGXJFHmY7M49MtpTNb8Vj9zVTuJDjp+eZOt/ACCG4RnCxb9dGsuP4pGgwpWGLsGaAUyBIlyN48+2y492LDjROByL0vkQVVagtN7HPwOYzcPtXkjneT/fIU7nrHzEkCl1tPhXdDD+3VkGMwvW+KuusmplvnHlL47ux/gdwIqhTXzrPmhW/0fRgLKQRp9snXZrM/8sAA6anEhUmSO/EGX0TztVid/ryF+W8Z84/yv/Go= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2017 15:03:51.8287 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.38]; Helo=[plsapdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB865 Archived-At: Subject: Re: [Dime] RFC 6733 Commands X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 15:03:58 -0000 --_000_150030382759197405sprintcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable agreed, we have encountered some folks tying the ACR/ACA to app id 0 in ope= n source. ________________________________ From: lionel.morand@orange.com Sent: Monday, July 17, 2017 9:32 AM To: Bertz, Lyle T [CTO]; dime@ietf.org list Subject: RE: RFC 6733 Commands Hi Lyle, I think that there is no specific reason. By definition, the command is ind= ependent of any application. So when describing the command code, it may or= may not be contained in the command code header. It is consistent with the= CCF specification: header =3D "" The CCF is mainly used to identify the set of AVP that can be present in th= e command. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Bertz, Lyle T [CTO] Envoy=E9 : lundi 17 juillet 2017 12:12 =C0 : dime@ietf.org list Objet : [Dime] RFC 6733 Commands In the spec was there a particular reason why we did not specify the applic= ation Identifier in the header for each of the command codes, e.g. ACR/ACA = assigned to application ID 3? Lyle ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_150030382759197405sprintcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

agreed, we have encountered some folks tying the ACR/ACA to app id 0 in = open source.



From: lionel.morand@orange.= com <lionel.morand@orange.com>
Sent: Monday, July 17, 2017 9:32 AM
To: Bertz, Lyle T [CTO]; dime@ietf.org list
Subject: RE: RFC 6733 Commands
 

Hi Lyle,

 

I think that= there is no specific reason. By definition, the command is independent of = any application. So when describing the command code, it may or may not be contained in the command code header. It is consistent with = the CCF specification:

 

   header    = ;       =3D "<Diameter-Header:" = command-id

       =             &nb= sp;     [r-bit] [p-bit] [e-bit] [application-id]"&= gt;"

 

The CCF is m= ainly used to identify the set of AVP that can be present in the command.

 

Regards,

 

Lionel

 

De :<= span lang=3D"EN-US" style=3D"font-size:10.0pt; font-family:"Tahoma&quo= t;,"sans-serif""> DiME [mailto:dime-bounces@ietf.org] De la part de Bertz, = Lyle T [CTO]
Envoy=E9 : lundi 17 juillet 2017 12:12
=C0 : dime@ietf.org list
Objet : [Dime] RFC 6733 Commands

 

In the spec was there a particular reason why we did not specif= y the application Identifier in the header for each of the command cod= es, e.g. ACR/ACA assigned to application ID 3?

 

Lyle

 


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

______________________________________________________________________=
___________________________________________________=0A=
=0A=
Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc=0A=
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler=0A=
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,=0A=
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.=0A=
=0A=
This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;=0A=
they should not be distributed, used or copied without authorisation.=0A=
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.=0A=
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.=0A=
Thank you.=0A=
--_000_150030382759197405sprintcom_-- From nobody Mon Jul 17 08:29:21 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138F2131C65; Mon, 17 Jul 2017 08:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.398 X-Spam-Level: X-Spam-Status: No, score=-5.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 IwTWVfE6VLZx; Mon, 17 Jul 2017 08:29:16 -0700 (PDT) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1257C131C62; Mon, 17 Jul 2017 08:29:10 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id DB83DA052D; Mon, 17 Jul 2017 17:29:08 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 85C1B1A00A6; Mon, 17 Jul 2017 17:29:08 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0352.000; Mon, 17 Jul 2017 17:29:08 +0200 From: To: Dave Dolson , "Gardella, Maryse (Nokia - FR/Nozay)" , Alan DeKok CC: "dime@ietf.org list" , "draft-ietf-dime-rfc4006bis@ietf.org" Thread-Topic: M-bit setting in draft-ietf-dime-rfc4006bis-02 Thread-Index: AdL/Dc/OHV8jIku1TbW+ki3uYtdcWQ== Date: Mon, 17 Jul 2017 15:29:07 +0000 Message-ID: <13800_1500305348_596CD7C4_13800_63_1_6B7134B31289DC4FAF731D844122B36E2D1B6048@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E2D1B6048OPEXCLILM43corp_" MIME-Version: 1.0 Archived-At: Subject: [Dime] M-bit setting in draft-ietf-dime-rfc4006bis-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 15:29:19 -0000 --_000_6B7134B31289DC4FAF731D844122B36E2D1B6048OPEXCLILM43corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Sorry for this late comment. As stated in RFC6733, It is the decision of the protocol designer when to develop a new Diameter application rather than extending Diameter in other ways. However, a new Diameter application MUST be created when one or more of the following criteria are met: M-bit Setting An AVP with the M-bit in the MUST column of the AVP flag table is added to an existing Command/Application. An AVP with the M-bit in the MAY column of the AVP flag table is added to an existing Command/Application. Therefore, if it is proposed to keep the existing DCC application-id, the n= ewly defined AVPs must be defined with the M-bit put in the MUST NOT column: +---------------+ |AVP Flag rules | |----+-----+----| AVP Section | | |MUST| Attribute Name Code Defined Data Type |MUST| MAY |NOT | -----------------------------------------|----+-----+----| QoS-Final-Unit- TBD17 8.68 Grouped | | M | V | Indication | | | | Redirect-Server TBD13 8.64 Grouped | | M | V | -Extension | | | | Redirect-Address TBD14 8.65 Address | | M | V | -IPAddress | | | | Redirect-Address TBD15 8.66 UTF8String | | M | V | -URL | | | | Redirect-Address TBD16 8.67 UTF8String | | M | V | -SIP-URI | | | | Subscription-Id TBD7 8.58 Grouped | | M | V | -Extension | | | | Subscription-Id TBD8 8.59 UTF8String | | M | V | -E164 | | | | Subscription-Id TBD9 8.60 UTF8String | | M | V | -IMSI | | | | Subscription-Id TBD10 8.61 UTF8String | | M | V | -SIP-URI | | | | Subscription-Id TBD11 8.62 UTF8String | | M | V | -NAI | | | | Subscription-Id TBD12 8.63 UTF8String | | M | V | -Private | | | | User-Equipment TBD1 8.52 Grouped | | M | V | -Info-Extension | | | | User-Equipment TBD2 8.53 OctetString| | M | V | -Info-IMEISV | | | | User-Equipment TBD3 8.54 OctetString| | M | V | -Info-MAC | | | | User-Equipment TBD4 8.55 OctetString| | M | V | -Info-EUI64 | | | | User-Equipment TBD5 8.56 OctetString| | M | V | -Info-ModifiedEUI64 | | | | User-Equipment TBD6 8.57 OctetString| | M | V | Now, regarding existing AVPs with the M-bit put in the MAY column (listed b= elow), I would recommend not to use the MAY column but to specific in which= DCC commands the M-bit setting may change for some AVP, as indicated in RF= C6733 and RFC7423. >From RFC6733: Note: The M-bit setting for a given AVP is relevant to an Application and each command within that application that includes the AVP. That is, if an AVP appears in two commands for application Foo and the M-bit settings are different in each command, then there should be two AVP flag tables describing when to set the M-bit. For AVPs for which there is no clear use case for change of the M-bit setti= ng in the DCC app, the M-bit should be put in the MUST column. It may be th= e case for all the AVPs listed below (I've not checked). Other applications= using DCC commands can decide to set or clear the M-bit of the related DCC= commands' AVPs without any constraint. +---------------+ |AVP Flag rules | |----+-----+----| AVP Section | | |MUST| Attribute Name Code Defined Data Type |MUST| MAY |NOT | -----------------------------------------|----+-----+----| CC-Correlation-Id 411 8.1 OctetString| | M | V | Service-Parameter 440 8.43 Grouped | | M | V | -Info | | | | Service- 441 8.44 Unsigned32 | | M | V | Parameter-Type | | | | Service- 442 8.45 OctetString| | M | V | Parameter-Value | | | | User-Equipment 458 8.49 Grouped | | M | V | -Info | | | | User-Equipment 459 8.50 Enumerated | | M | V | -Info-Type | | | | User-Equipment 460 8.51 OctetString| | M | V | -Info-Value | | | | User-Equipment TBD1 8.52 Grouped | | M | V | -Info-Extension | | | | User-Equipment TBD2 8.53 OctetString| | M | V | -Info-IMEISV | | | | User-Equipment TBD3 8.54 OctetString| | M | V | -Info-MAC | | | | User-Equipment TBD4 8.55 OctetString| | M | V | -Info-EUI64 | | | | User-Equipment TBD5 8.56 OctetString| | M | V | -Info-ModifiedEUI64 | | | | User-Equipment TBD6 8.57 OctetString| | M | V | -Info-IMEI | | | | Regards, Lionel De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : jeudi 11 mai 2017 17:03 =C0 : Gardella, Maryse (Nokia - FR/Nozay); MORAND Lionel IMT/OLN; Alan DeKok Cc : dime@ietf.org list; draft-ietf-dime-rfc4006bis@ietf.org Objet : RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 I have uploaded version -03 with the agreed changes to simply replace the r= eference with RFC7542. https://tools.ietf.org/html/draft-ietf-dime-rfc4006bis-03 From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com] Sent: Saturday, May 6, 2017 3:00 AM To: Dave Dolson; lionel.morand@orange.com;= Alan DeKok Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ie= tf.org Subject: RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Hi all, Therefore it makes sense to do so. Thanks Maryse From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: vendredi 5 mai 2017 21:57 To: lionel.morand@orange.com; Gardella, Ma= ryse (Nokia - FR/Nozay) >; Alan DeKok > Cc: dime@ietf.org list >; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Lionel, OK, thanks. I'll make the changes. -Dave From: lionel.morand@orange.com [mailto:lio= nel.morand@orange.com] Sent: Friday, May 5, 2017 3:42 PM To: Dave Dolson; Gardella, Maryse (Nokia - FR/Nozay); Alan DeKok Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ie= tf.org Subject: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Hi, RFC 6733 was published before RFC 7542, obsoleting RFC 4282. It is why RFC = 4282 was still used as reference in RFC 6733. Using IETF rules, RFC 7242 should be used anyway for any Diameter implement= ation based on RFC 6733 and using NAI. Therefore, when updating RFC 4006, RFC 7242 should be used as reference. Regards, Lionel Le 5 mai 2017 20:05, Dave Dolson > a =E9crit : Maryse, Thanks for doing some research and pointing this out. In RFC 6733, RFC4282 is used for two things: 1. to define "Network Access Identifier", for use as realm names, which are= "piggybacked on the administration of the DNS namespace" - so DNS restrictions would have to apply here. 2. Defining User-Name AVP, which is a NAI, but specifically "of type UTF8St= ring ... in a format consistent with the NAI specification [RFC4282]" - (see section 8.14 of RFC6733) - so User-Name is defined to be the UTF8 subset of RFC4282. So I claim that although RFC4282 is mentioned, RFC6733 intends that user na= mes in Diameter be limited to UTF-8, hence compatible with RFC7542. -Dave -----Original Message----- From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com] Sent: Wednesday, May 3, 2017 10:37 AM To: Dave Dolson; Alan DeKok Cc: Yuval Lifshitz; jouni korhonen; dime@ietf.org lis= t; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 My mistake, it should be RFC 6733 Maryse -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: mercredi 3 mai 2017 16:19 To: Gardella, Maryse (Nokia - FR/Nozay) >; Alan DeKok > Cc: Yuval Lifshitz >;= jouni korhonen >; di= me@ietf.org list = >; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 RFC4282 is also obsolete, and RFC7542 explains the problems with it. I don't think we should introduce RFC4282 at this point. (And sorry, I don't see RFC 6377 referring to 4282) -----Original Message----- From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com] Sent: Wednesday, May 3, 2017 9:21 AM To: Alan DeKok; Dave Dolson Cc: Yuval Lifshitz; jouni korhonen; dime@ietf.org lis= t; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Hello all, For the new AVP, no question: RFC 7542 should be used. I have not the full overview of 3GPP specs used for reference to NAI, and b= ased on: - assuming the TS 23.003 (Numbering, addressing and identification) is an i= mportant spec to consider, the RFC 4282 is used - RFC 6377 DBP also referring to RFC 4282 I would tend to agree on at least using RFC 4282 as the reference for the E= ND_USER_NAI in Subscription-Id-Type for RFC4006bis. Whether to directly refer to RFC7542, I cannot confirm whether this is acce= ptable or not. BR Maryse -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: mercredi 3 mai 2017 00:47 To: Dave Dolson > Cc: Yuval Lifshitz >;= Gardella, Maryse (Nokia - FR/Nozay) >; jouni korhonen >; dime@ietf.org list >; draft-ietf-dime-rfc4006bis@ietf.org Subject: Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 On May 2, 2017, at 5:51 PM, Dave Dolson > wrote: > > Thanks Alan. > Do I correctly hear you saying we should replace all references to RFC 24= 86 with RFC 7542? Yes. It's 2017. Independent of RFC 7542, *inter-operable* implementations jus= t have no business using non-UTF8 identifiers. Alan DeKok. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E2D1B6048OPEXCLILM43corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

Sorry for this late comment.

 

As stated in RFC6733,

 

   It is the decision of the prot= ocol designer when to develop a new

   Diameter application rather th= an extending Diameter in other ways.

   However, a new Diameter applic= ation MUST be created when one or more

   of the following criteria are = met:

 

   M-bit Setting

 

      An AVP with = the M-bit in the MUST column of the AVP flag table is

      added to an = existing Command/Application.  An AVP with the M-bit=

      in the MAY c= olumn of the AVP flag table is added to an existing

      Command/Appl= ication.

 

Therefore, if it is proposed to keep the ex= isting DCC application-id, the newly defined AVPs must be defined with the = M-bit put in the MUST NOT column:

 

       &= nbsp;           &nbs= p;            &= nbsp;           +----= -----------+

       &= nbsp;           &nbs= p;            &= nbsp;           |AVP Flag= rules |

       &= nbsp;           &nbs= p;            &= nbsp;           |----+= ;-----+----|

       &= nbsp;           &nbs= p; AVP  Section         &= nbsp; |    |     |MUST|

   Attribute Name  &nbs= p; Code Defined Data Type |MUST| MAY |NOT |

   ------------------------------= -----------|----+-----+----|

   QoS-Final-Unit-  TBD17 8.= 68   Grouped    |    |  M = ; |  V |

     Indication &n= bsp;            = ;            &n= bsp;  |    |     |   &nbs= p;|

   Redirect-Server  TBD13 8.= 64   Grouped    |    |  M = ; |  V |

     -Extension &n= bsp;            = ;            &n= bsp;  |    |     |   = ; |

   Redirect-Address TBD14 8.65&nb= sp;  Address    |    |  M  |&n= bsp; V |

     -IPAddress &n= bsp;            = ;            &n= bsp;  |    |     |   = ; |

   Redirect-Address TBD15 8.66&nb= sp;  UTF8String |    |  M  |  V |

     -URL  &n= bsp;            = ;            &n= bsp;       |    |  &= nbsp;  |    |

   Redirect-Address TBD16 8.67&nb= sp;  UTF8String |    |  M  |  V |

     -SIP-URI &nbs= p;            &= nbsp;           &nbs= p;    |    |     | &= nbsp;  |

   Subscription-Id  TBD7&nbs= p; 8.58   Grouped    |    |  M=   |  V |

     -Extension &n= bsp;            = ;            &n= bsp;  |    |     |   = ; |

   Subscription-Id  TBD8&nbs= p; 8.59   UTF8String |    |  M  |  = V |

     -E164  &= nbsp;           &nbs= p;            &= nbsp;      |    |   =   |    |

   Subscription-Id  TBD9&nbs= p; 8.60   UTF8String |    |  M  |  = V |

     -IMSI   =             &nb= sp;            =       |    |   =   |    |

   Subscription-Id  TBD10 8.= 61   UTF8String |    |  M  |  V |

     -SIP-URI &nbs= p;            &= nbsp;           &nbs= p;    |    |     | &= nbsp;  |

   Subscription-Id  TBD11 8.= 62   UTF8String |    |  M  |  V |

     -NAI  &n= bsp;            &nbs= p;            &= nbsp;      |    |  &= nbsp;  |    |

   Subscription-Id  TBD12 8.= 63   UTF8String |    |  M  |  V |

     -Private &nbs= p;            &= nbsp;           &nbs= p;    |    |     | &= nbsp;  |

   User-Equipment   TBD= 1  8.52   Grouped    |    |&nb= sp; M  |  V |

     -Info-Extension          = ;            &n= bsp; |    |     |    |

   User-Equipment   TBD= 2  8.53   OctetString|    |  M  |&n= bsp; V |

     -Info-IMEISV =             &nb= sp;            = |    |     |    |

   User-Equipment   TBD= 3  8.54   OctetString|    |  M  |&n= bsp; V |

     -Info-MAC &nb= sp;            =             &nb= sp;   |    |     |  =   |

   User-Equipment   TBD= 4  8.55   OctetString|    |  M  |&n= bsp; V |

     -Info-EUI64 &= nbsp;           &nbs= p;            &= nbsp; |    |     |    |

   User-Equipment   TBD= 5  8.56   OctetString|    |  M  |&n= bsp; V |

     -Info-ModifiedEUI6= 4            &n= bsp;       |    |  &= nbsp;  |    |

   User-Equipment   TBD= 6  8.57   OctetString|    |  M  |&n= bsp; V |

 

Now, regarding existing AVPs with the M-bit= put in the MAY column (listed below), I would recommend not to use the MAY= column but to specific in which DCC commands the M-bit setting may change for some AVP, as indicated in RFC6733 and RFC7423= .

 

From RFC6733:

 

      Note: The M-= bit setting for a given AVP is relevant to an

      Application = and each command within that application that includes

      the AVP.&nbs= p; That is, if an AVP appears in two commands for

      application = Foo and the M-bit settings are different in each

      command, the= n there should be two AVP flag tables describing when

      to set the M= -bit.

 

For AVPs for which there is no clear use ca= se for change of the M-bit setting in the DCC app, the M-bit should be put = in the MUST column. It may be the case for all the AVPs listed below (I've not checked). Other applications using DCC command= s can decide to set or clear the M-bit of the related DCC commands' AVPs wi= thout any constraint.

 

       &= nbsp;           &nbs= p;            &= nbsp;           +----= -----------+

       &= nbsp;           &nbs= p;            &= nbsp;           |AVP Flag= rules |

       &= nbsp;           &nbs= p;            &= nbsp;           |----+= ;-----+----|

       &= nbsp;            &nb= sp;AVP  Section         &= nbsp; |    |     |MUST|

   Attribute Name  &nbs= p; Code Defined Data Type |MUST| MAY |NOT |

   ------------------------------= -----------|----+-----+----|

   CC-Correlation-Id 411  8.= 1    OctetString|    |  M  |  = V |

   Service-Parameter 440  8.= 43   Grouped    |    |  M = ; |  V |

     -Info  &= nbsp;           &nbs= p;            &= nbsp;      |    |   =   |    |

   Service-   &nbs= p;      441  8.44   Unsigned32 |&nb= sp;   |  M  |  V |

     Parameter-Type&nbs= p;            &= nbsp;           | &n= bsp;  |     |    |

   Service-   &nbs= p;      442  8.45   OctetString|&nb= sp;   |  M  |  V |

     Parameter-Value&nb= sp;            =            |  &= nbsp; |     |    |

   User-Equipment  &nbs= p; 458  8.49   Grouped    |   = |  M  |  V |

     -Info  &= nbsp;           &nbs= p;            &= nbsp;      |    |   =   |    |

   User-Equipment  &nbs= p; 459  8.50   Enumerated |    |  M = ; |  V |

     -Info-Type &n= bsp;            = ;            &n= bsp;  |    |     |   = ; |

   User-Equipment  &nbs= p; 460  8.51   OctetString|    |  M = ; |  V |

     -Info-Value &= nbsp;           &nbs= p;            &= nbsp; |    |     |    |

   User-Equipment   TBD= 1  8.52   Grouped    |    |&nb= sp; M  |  V |

     -Info-Extension&nb= sp;            =            |  &= nbsp; |     |    |

   User-Equipment   TBD= 2  8.53   OctetString|    |  M  |&n= bsp; V |

     -Info-IMEISV =             &nb= sp;            = |    |     |    |

   User-Equipment   TBD= 3  8.54   OctetString|    |  M  |&n= bsp; V |

     -Info-MAC &nb= sp;            =             &nb= sp;   |    |     |  =   |

   User-Equipment   TBD= 4  8.55   OctetString|    |  M  |&n= bsp; V |

     -Info-EUI64 &= nbsp;           &nbs= p;            &= nbsp; |    |     |    |

   User-Equipment   TBD= 5  8.56   OctetString|    |  M  |&n= bsp; V |

     -Info-ModifiedEUI6= 4            &n= bsp;       |    |  &= nbsp;  |    |

   User-Equipment   TBD= 6  8.57   OctetString|    |  M  |&n= bsp; V |

     -Info-IMEI &n= bsp;            = ;            &n= bsp;  |    |     |   = ; |

 

 

Regards,

 

Lionel

 

 

De : Dave= Dolson [mailto:ddolson@sandvine.com]
Envoy=E9 : jeudi 11 mai 2017 17:03
=C0 : Gardella, Maryse (Nokia - FR/Nozay); MORAND Lionel IMT/OL= N; Alan DeKok
Cc : dime@ietf.org list; draft-ietf-dime-rfc4006bis@ietf.org
Objet : RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-d= ime-rfc4006bis-02

 

I have upl= oaded version -03 with the agreed changes to simply replace the reference w= ith RFC7542.

https://tools.i= etf.org/html/draft-ietf-dime-rfc4006bis-03

 = ;

 = ;

From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com]
Sent: Saturday, May 6, 2017 3:00 AM
To: Dave Dolson; lionel.= morand@orange.com; Alan DeKok
Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ietf.org
Subject: RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-= rfc4006bis-02

 

Hi all,

 

Therefore it makes sense= to do so.

 

Thanks

Maryse

 

From: Dave Dolson [mailto:ddolson@sandvine.com]
Sent: vendredi 5 mai 2017 21:57
To: lionel.morand@orange= .com; Gardella, Maryse (Nokia - FR/Nozay) <maryse.gardella@nokia.com>; Alan DeKok <aland@deployingradius.com> Cc: dime@ietf.org list <dime@ietf.org>; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-= rfc4006bis-02

 

Lionel,

OK, thanks= . I’ll make the changes.

 

-Dave

 

 

From: lionel.morand@orange.com [<= a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<= /a>]
Sent: Friday, May 5, 2017 3:42 PM
To: Dave Dolson; Gardella, Maryse (Nokia - FR/Nozay); Alan DeKok
Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ietf.org
Subject: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4= 006bis-02

 

Hi,

RFC 6733 was published before RFC 7542, obsoleting RFC 4282. It is why RFC = 4282 was still used as reference in RFC 6733.
Using IETF rules, RFC 7242 should be used anyway for any Diameter implement= ation based on RFC 6733 and using NAI.
Therefore, when updating RFC 4006, RFC 7242 should be used as reference.
Regards,

Lionel

Le 5 mai 2017 20:05, Dave Dolso= n <ddolson@sandvine.com> = a =E9crit :

Mary= se,
Thanks for doing some research and pointing this out.

In RFC 6733, RFC4282 is used for two things:
1. to define "Network Access Identifier", for use as realm names,= which are "piggybacked on the administration of the DNS namespace&quo= t;
- so DNS restrictions would have to apply here.

2. Defining User-Name AVP, which is a NAI, but specifically "of type U= TF8String ... in a format consistent with the NAI specification [RFC4282]&q= uot;
- (see section 8.14 of RFC6733)
- so User-Name is defined to be the UTF8 subset of RFC4282.

So I claim that although RFC4282 is mentioned, RFC6733 intends that user na= mes in Diameter be limited to UTF-8, hence compatible with RFC7542.


-Dave


-----Original Message-----
From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com]
Sent: Wednesday, May 3, 2017 10:37 AM
To: Dave Dolson; Alan DeKok
Cc: Yuval Lifshitz; jouni korhonen; dime@i= etf.org list; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

My mistake, it should be RFC 6733
Maryse

-----Original Message-----
From: Dave Dolson [mailto:ddolson@s= andvine.com]
Sent: mercredi 3 mai 2017 16:19
To: Gardella, Maryse (Nokia - FR/Nozay) <maryse.gardella@nokia.com>; Alan DeKok <aland@deployingradius.com>
Cc: Yuval Lifshitz <ylifshitz@= sandvine.com>; jouni korhonen <jouni.nospam@gmail.com>; dime@ietf.org list <dime@ietf.org>; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

RFC4282 is also obsolete, and RFC7542 explains the problems with it.
I don't think we should introduce RFC4282 at this point.

(And sorry, I don't see RFC 6377 referring to 4282)


-----Original Message-----
From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com]
Sent: Wednesday, May 3, 2017 9:21 AM
To: Alan DeKok; Dave Dolson
Cc: Yuval Lifshitz; jouni korhonen; dime@i= etf.org list; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

Hello all,

For the new AVP, no question: RFC 7542 should be used.
I have not the full overview of 3GPP specs used for reference to NAI, and b= ased on:
- assuming the TS 23.003 (Numbering, addressing and identification) is an i= mportant spec to consider, the RFC 4282 is used
- RFC 6377 DBP also referring to RFC 4282
 
I would tend to agree on at least using RFC 4282 as the reference for the E= ND_USER_NAI in Subscription-Id-Type for RFC4006bis.
Whether to directly refer to RFC7542, I cannot confirm whether this is acce= ptable or not. 

BR
Maryse

-----Original Message-----
From: Alan DeKok [mailto:aland= @deployingradius.com]
Sent: mercredi 3 mai 2017 00:47
To: Dave Dolson <ddolson@sandvin= e.com>
Cc: Yuval Lifshitz <ylifshitz@= sandvine.com>; Gardella, Maryse (Nokia - FR/Nozay) <maryse.gardella@nokia.com>; jouni ko= rhonen <jouni.nospam@gmail.com= >; dime@ietf.org list <dime@ietf.org>; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

On May 2, 2017, at 5:51 PM, Dave Dolson <ddolson@sandvine.com> wrote:
>
> Thanks Alan.
> Do I correctly hear you saying we should replace all references to RFC= 2486 with RFC 7542?

  Yes.

  It's 2017.  Independent of RFC 7542, *inter-operable* implement= ations just have no business using non-UTF8 identifiers.

  Alan DeKok.

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org= /mailman/listinfo/dime

_________________________________________________=
________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=

a l'expediteur et le detruire ainsi que les piece=
s jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message=
 a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.=

Thank you.
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E2D1B6048OPEXCLILM43corp_-- From nobody Mon Jul 17 09:05:55 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4C412711E; Mon, 17 Jul 2017 09:05:53 -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, RP_MATCHES_RCVD=-0.001, 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 cP8UtkZbRV7r; Mon, 17 Jul 2017 09:05:45 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AB81131C91; Mon, 17 Jul 2017 09:05:45 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-3.sandvine.com (192.168.196.177) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 17 Jul 2017 12:05:44 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Mon, 17 Jul 2017 12:05:44 -0400 From: Dave Dolson To: "lionel.morand@orange.com" , "Gardella, Maryse (Nokia - FR/Nozay)" , Alan DeKok CC: "dime@ietf.org list" , "draft-ietf-dime-rfc4006bis@ietf.org" Thread-Topic: M-bit setting in draft-ietf-dime-rfc4006bis-02 Thread-Index: AdL/Dc/OHV8jIku1TbW+ki3uYtdcWQACO2sw Date: Mon, 17 Jul 2017 16:05:42 +0000 Message-ID: References: <13800_1500305348_596CD7C4_13800_63_1_6B7134B31289DC4FAF731D844122B36E2D1B6048@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: <13800_1500305348_596CD7C4_13800_63_1_6B7134B31289DC4FAF731D844122B36E2D1B6048@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.142.50] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E98A906566Awtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] M-bit setting in draft-ietf-dime-rfc4006bis-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 16:05:53 -0000 --_000_E8355113905631478EFF04F5AA706E98A906566Awtlexchp2sandvi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lionel, Do you consider those to be errata against RFC4006 ? From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] Sent: Monday, July 17, 2017 5:29 PM To: Dave Dolson; Gardella, Maryse (Nokia - FR/Nozay); Alan DeKok Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ietf.org Subject: M-bit setting in draft-ietf-dime-rfc4006bis-02 Hi, Sorry for this late comment. As stated in RFC6733, It is the decision of the protocol designer when to develop a new Diameter application rather than extending Diameter in other ways. However, a new Diameter application MUST be created when one or more of the following criteria are met: M-bit Setting An AVP with the M-bit in the MUST column of the AVP flag table is added to an existing Command/Application. An AVP with the M-bit in the MAY column of the AVP flag table is added to an existing Command/Application. Therefore, if it is proposed to keep the existing DCC application-id, the n= ewly defined AVPs must be defined with the M-bit put in the MUST NOT column= : +---------------+ |AVP Flag rules | |----+-----+----| AVP Section | | |MUST| Attribute Name Code Defined Data Type |MUST| MAY |NOT | -----------------------------------------|----+-----+----| QoS-Final-Unit- TBD17 8.68 Grouped | | M | V | Indication | | | | Redirect-Server TBD13 8.64 Grouped | | M | V | -Extension | | | | Redirect-Address TBD14 8.65 Address | | M | V | -IPAddress | | | | Redirect-Address TBD15 8.66 UTF8String | | M | V | -URL | | | | Redirect-Address TBD16 8.67 UTF8String | | M | V | -SIP-URI | | | | Subscription-Id TBD7 8.58 Grouped | | M | V | -Extension | | | | Subscription-Id TBD8 8.59 UTF8String | | M | V | -E164 | | | | Subscription-Id TBD9 8.60 UTF8String | | M | V | -IMSI | | | | Subscription-Id TBD10 8.61 UTF8String | | M | V | -SIP-URI | | | | Subscription-Id TBD11 8.62 UTF8String | | M | V | -NAI | | | | Subscription-Id TBD12 8.63 UTF8String | | M | V | -Private | | | | User-Equipment TBD1 8.52 Grouped | | M | V | -Info-Extension | | | | User-Equipment TBD2 8.53 OctetString| | M | V | -Info-IMEISV | | | | User-Equipment TBD3 8.54 OctetString| | M | V | -Info-MAC | | | | User-Equipment TBD4 8.55 OctetString| | M | V | -Info-EUI64 | | | | User-Equipment TBD5 8.56 OctetString| | M | V | -Info-ModifiedEUI64 | | | | User-Equipment TBD6 8.57 OctetString| | M | V | Now, regarding existing AVPs with the M-bit put in the MAY column (listed b= elow), I would recommend not to use the MAY column but to specific in which= DCC commands the M-bit setting may change for some AVP, as indicated in RF= C6733 and RFC7423. >From RFC6733: Note: The M-bit setting for a given AVP is relevant to an Application and each command within that application that includes the AVP. That is, if an AVP appears in two commands for application Foo and the M-bit settings are different in each command, then there should be two AVP flag tables describing when to set the M-bit. For AVPs for which there is no clear use case for change of the M-bit setti= ng in the DCC app, the M-bit should be put in the MUST column. It may be th= e case for all the AVPs listed below (I've not checked). Other applications= using DCC commands can decide to set or clear the M-bit of the related DCC= commands' AVPs without any constraint. +---------------+ |AVP Flag rules | |----+-----+----| AVP Section | | |MUST| Attribute Name Code Defined Data Type |MUST| MAY |NOT | -----------------------------------------|----+-----+----| CC-Correlation-Id 411 8.1 OctetString| | M | V | Service-Parameter 440 8.43 Grouped | | M | V | -Info | | | | Service- 441 8.44 Unsigned32 | | M | V | Parameter-Type | | | | Service- 442 8.45 OctetString| | M | V | Parameter-Value | | | | User-Equipment 458 8.49 Grouped | | M | V | -Info | | | | User-Equipment 459 8.50 Enumerated | | M | V | -Info-Type | | | | User-Equipment 460 8.51 OctetString| | M | V | -Info-Value | | | | User-Equipment TBD1 8.52 Grouped | | M | V | -Info-Extension | | | | User-Equipment TBD2 8.53 OctetString| | M | V | -Info-IMEISV | | | | User-Equipment TBD3 8.54 OctetString| | M | V | -Info-MAC | | | | User-Equipment TBD4 8.55 OctetString| | M | V | -Info-EUI64 | | | | User-Equipment TBD5 8.56 OctetString| | M | V | -Info-ModifiedEUI64 | | | | User-Equipment TBD6 8.57 OctetString| | M | V | -Info-IMEI | | | | Regards, Lionel De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : jeudi 11 mai 2017 17:03 =C0 : Gardella, Maryse (Nokia - FR/Nozay); MORAND Lionel IMT/OLN; Alan DeKo= k Cc : dime@ietf.org list; draft-ietf-dime-rfc4006bis@i= etf.org Objet : RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 I have uploaded version -03 with the agreed changes to simply replace the r= eference with RFC7542. https://tools.ietf.org/html/draft-ietf-dime-rfc4006bis-03 From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com= ] Sent: Saturday, May 6, 2017 3:00 AM To: Dave Dolson; lionel.morand@orange.com;= Alan DeKok Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ie= tf.org Subject: RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-0= 2 Hi all, Therefore it makes sense to do so. Thanks Maryse From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: vendredi 5 mai 2017 21:57 To: lionel.morand@orange.com; Gardella, Ma= ryse (Nokia - FR/Nozay) >; Alan DeKok > Cc: dime@ietf.org list >; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-0= 2 Lionel, OK, thanks. I'll make the changes. -Dave From: lionel.morand@orange.com [mailto:lio= nel.morand@orange.com] Sent: Friday, May 5, 2017 3:42 PM To: Dave Dolson; Gardella, Maryse (Nokia - FR/Nozay); Alan DeKok Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ie= tf.org Subject: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Hi, RFC 6733 was published before RFC 7542, obsoleting RFC 4282. It is why RFC = 4282 was still used as reference in RFC 6733. Using IETF rules, RFC 7242 should be used anyway for any Diameter implement= ation based on RFC 6733 and using NAI. Therefore, when updating RFC 4006, RFC 7242 should be used as reference. Regards, Lionel Le 5 mai 2017 20:05, Dave Dolson > a =E9crit : Maryse, Thanks for doing some research and pointing this out. In RFC 6733, RFC4282 is used for two things: 1. to define "Network Access Identifier", for use as realm names, which are= "piggybacked on the administration of the DNS namespace" - so DNS restrictions would have to apply here. 2. Defining User-Name AVP, which is a NAI, but specifically "of type UTF8St= ring ... in a format consistent with the NAI specification [RFC4282]" - (see section 8.14 of RFC6733) - so User-Name is defined to be the UTF8 subset of RFC4282. So I claim that although RFC4282 is mentioned, RFC6733 intends that user na= mes in Diameter be limited to UTF-8, hence compatible with RFC7542. -Dave -----Original Message----- From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com= ] Sent: Wednesday, May 3, 2017 10:37 AM To: Dave Dolson; Alan DeKok Cc: Yuval Lifshitz; jouni korhonen; dime@ietf.org lis= t; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 My mistake, it should be RFC 6733 Maryse -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: mercredi 3 mai 2017 16:19 To: Gardella, Maryse (Nokia - FR/Nozay) >; Alan DeKok > Cc: Yuval Lifshitz >;= jouni korhonen >; di= me@ietf.org list = >; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 RFC4282 is also obsolete, and RFC7542 explains the problems with it. I don't think we should introduce RFC4282 at this point. (And sorry, I don't see RFC 6377 referring to 4282) -----Original Message----- From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com= ] Sent: Wednesday, May 3, 2017 9:21 AM To: Alan DeKok; Dave Dolson Cc: Yuval Lifshitz; jouni korhonen; dime@ietf.org lis= t; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Hello all, For the new AVP, no question: RFC 7542 should be used. I have not the full overview of 3GPP specs used for reference to NAI, and b= ased on: - assuming the TS 23.003 (Numbering, addressing and identification) is an i= mportant spec to consider, the RFC 4282 is used - RFC 6377 DBP also referring to RFC 4282 I would tend to agree on at least using RFC 4282 as the reference for the E= ND_USER_NAI in Subscription-Id-Type for RFC4006bis. Whether to directly refer to RFC7542, I cannot confirm whether this is acce= ptable or not. BR Maryse -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: mercredi 3 mai 2017 00:47 To: Dave Dolson > Cc: Yuval Lifshitz >;= Gardella, Maryse (Nokia - FR/Nozay) >; jouni korhonen >; dime@ietf.org list >; draft-ietf-dime-rfc4006bis@ietf.org Subject: Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 On May 2, 2017, at 5:51 PM, Dave Dolson > wrote: > > Thanks Alan. > Do I correctly hear you saying we should replace all references to RFC 24= 86 with RFC 7542? Yes. It's 2017. Independent of RFC 7542, *inter-operable* implementations jus= t have no business using non-UTF8 identifiers. Alan DeKok. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_E8355113905631478EFF04F5AA706E98A906566Awtlexchp2sandvi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Lionel,=

Do you consider those to = be errata against RFC4006 ?

 <= /p>

 <= /p>

From: lionel.m= orand@orange.com [mailto:lionel.morand@orange.com]
Sent: Monday, July 17, 2017 5:29 PM
To: Dave Dolson; Gardella, Maryse (Nokia - FR/Nozay); Alan DeKok
Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ietf.org
Subject: M-bit setting in draft-ietf-dime-rfc4006bis-02

 

Hi,

 

Sorry for this late comment.

 

As stated in RFC6733,

 

   It is the decision of the protocol designer w= hen to develop a new

   Diameter application rather than extending Di= ameter in other ways.

   However, a new Diameter application MUST be c= reated when one or more

   of the following criteria are met:=

 

   M-bit Setting

 

      An AVP with the M-bit in th= e MUST column of the AVP flag table is

      added to an existing Comman= d/Application.  An AVP with the M-bit

      in the MAY column of the AV= P flag table is added to an existing

      Command/Application.

 

Therefore, if it is proposed to keep the existing DCC appl= ication-id, the newly defined AVPs must be defined with the M-bit put in th= e MUST NOT column:

 

         &nbs= p;            &= nbsp;           &nbs= p;         +---------------+= ;

         &nbs= p;            &= nbsp;           &nbs= p;         |AVP Flag rules |

         &nbs= p;            &= nbsp;           &nbs= p;         |----+-----+----= |

         &nbs= p;           AVP  Se= ction           | &n= bsp;  |     |MUST|

   Attribute Name    Code Defined= Data Type |MUST| MAY |NOT |

   -----------------------------------------|---= -+-----+----|

   QoS-Final-Unit-  TBD17 8.68   = Grouped    |    |  M  |  V |

     Indication    = ;            &n= bsp;            |&nb= sp;   |     |    |<= /span>

   Redirect-Server  TBD13 8.64   = Grouped    |    |  M  |  V |

     -Extension    = ;            &n= bsp;            |&nb= sp;   |     |    |<= /span>

   Redirect-Address TBD14 8.65   Addre= ss    |    |  M  |  V |

     -IPAddress    = ;            &n= bsp;            |&nb= sp;   |     |    |<= /span>

   Redirect-Address TBD15 8.66   UTF8S= tring |    |  M  |  V |

     -URL     = ;            &n= bsp;            = ;     |    |     |&n= bsp;   |

   Redirect-Address TBD16 8.67   UTF8S= tring |    |  M  |  V |

     -SIP-URI    &= nbsp;           &nbs= p;            &= nbsp; |    |     |    |

   Subscription-Id  TBD7  8.58 &n= bsp; Grouped    |    |  M  |  = V |

     -Extension    = ;            &n= bsp;            |&nb= sp;   |     |    |<= /span>

   Subscription-Id  TBD8  8.59 &n= bsp; UTF8String |    |  M  |  V |<= /span>

     -E164    &nbs= p;            &= nbsp;           &nbs= p;    |    |     | &= nbsp;  |

   Subscription-Id  TBD9  8.60 &n= bsp; UTF8String |    |  M  |  V |<= /span>

     -IMSI     &nb= sp;            =             &nb= sp;   |    |     | &= nbsp;  |

   Subscription-Id  TBD10 8.61   = UTF8String |    |  M  |  V |

     -SIP-URI    &= nbsp;           &nbs= p;            &= nbsp; |    |     |    |

   Subscription-Id  TBD11 8.62   = UTF8String |    |  M  |  V |

     -NAI     = ;             &= nbsp;           &nbs= p;    |    |     |&n= bsp;   |

   Subscription-Id  TBD12 8.63   = UTF8String |    |  M  |  V |

     -Private    &= nbsp;           &nbs= p;            &= nbsp; |    |     |    |

   User-Equipment   TBD1  8.52&nb= sp;  Grouped    |    |  M  |&n= bsp; V |

     -Info-Extension        = ;            &n= bsp;   |    |     |  = ;  |

   User-Equipment   TBD2  8.53&nb= sp;  OctetString|    |  M  |  V |

     -Info-IMEISV   &nb= sp;            =            |  &= nbsp; |     |    |

   User-Equipment   TBD3  8.54&nb= sp;  OctetString|    |  M  |  V |

     -Info-MAC    =             &nb= sp;            = |    |     |    |

   User-Equipment   TBD4  8.55&nb= sp;  OctetString|    |  M  |  V |

     -Info-EUI64   &nbs= p;            &= nbsp;           | &n= bsp;  |     |    |

   User-Equipment   TBD5  8.56&nb= sp;  OctetString|    |  M  |  V |

     -Info-ModifiedEUI64  &n= bsp;            = ;     |    |     |&n= bsp;   |

   User-Equipment   TBD6  8.57&nb= sp;  OctetString|    |  M  |  V |

 

Now, regarding existing AVPs with the M-bit put in the MAY= column (listed below), I would recommend not to use the MAY column but to = specific in which DCC commands the M-bit setting may change for some AVP, as indicated in RFC6733 and RFC7423. <= /span>

 

From RFC6733:

 

      Note: The M-bit setting for= a given AVP is relevant to an

      Application and each comman= d within that application that includes

      the AVP.  That is, if = an AVP appears in two commands for

      application Foo and the M-b= it settings are different in each

      command, then there should = be two AVP flag tables describing when

      to set the M-bit.

 

For AVPs for which there is no clear use case for change o= f the M-bit setting in the DCC app, the M-bit should be put in the MUST col= umn. It may be the case for all the AVPs listed below (I've not checked). Other applications using DCC commands can decide= to set or clear the M-bit of the related DCC commands' AVPs without any co= nstraint.

 

         &nbs= p;            &= nbsp;           &nbs= p;         +---------------+= ;

         &nbs= p;            &= nbsp;           &nbs= p;         |AVP Flag rules |

         &nbs= p;            &= nbsp;           &nbs= p;         |----+-----+----= |

         &nbs= p;           AVP  Se= ction           | &n= bsp;  |     |MUST|

   Attribute Name    Code Defined= Data Type |MUST| MAY |NOT |

   -----------------------------------------|---= -+-----+----|

   CC-Correlation-Id 411  8.1  &n= bsp; OctetString|    |  M  |  V |<= /span>

   Service-Parameter 440  8.43   = Grouped    |    |  M  |  V |

     -Info    &nbs= p;            &= nbsp;           &nbs= p;    |    |     | &= nbsp;  |

   Service-      &= nbsp;   441  8.44   Unsigned32 |   = |  M  |  V |

     Parameter-Type   &= nbsp;           &nbs= p;         |    |&nb= sp;    |    |

   Service-      &= nbsp;   442  8.45   OctetString|   = |  M  |  V |

     Parameter-Value   =             &nb= sp;        |    | &n= bsp;   |    |

   User-Equipment    458  8.= 49   Grouped    |    |  M = ; |  V |

     -Info    &nbs= p;            &= nbsp;           &nbs= p;    |    |     | &= nbsp;  |

   User-Equipment    459  8.= 50   Enumerated |    |  M  |  V |

     -Info-Type    = ;            &n= bsp;            |&nb= sp;   |     |    |<= /span>

   User-Equipment    460  8.= 51   OctetString|    |  M  |  V |

     -Info-Value   &nbs= p;            &= nbsp;           | &n= bsp;  |     |    |

   User-Equipment   TBD1  8.52&nb= sp;  Grouped    |    |  M  |&n= bsp; V |

     -Info-Extension   =             &nb= sp;        |    | &n= bsp;   |    |

   User-Equipment   TBD2  8.53&nb= sp;  OctetString|    |  M  |  V |

     -Info-IMEISV   &nb= sp;            =            |  &= nbsp; |     |    |

   User-Equipment   TBD3  8.54&nb= sp;  OctetString|    |  M  |  V |

     -Info-MAC    =             &nb= sp;            = |    |     |    |

   User-Equipment   TBD4  8.55&nb= sp;  OctetString|    |  M  |  V |

     -Info-EUI64   &nbs= p;            &= nbsp;           | &n= bsp;  |     |    |

   User-Equipment   TBD5  8.56&nb= sp;  OctetString|    |  M  |  V |

     -Info-ModifiedEUI64  &n= bsp;            = ;     |    |     |&n= bsp;   |

   User-Equipment   TBD6  8.57&nb= sp;  OctetString|    |  M  |  V |

     -Info-IMEI    = ;            &n= bsp;            |&nb= sp;   |     |    |<= /span>

 

 

Regards,

 

Lionel

 

 

De : Dave Dolson [ma= ilto:ddolson@sandvine.com]
Envoy=E9 : jeudi 11 mai 2017 17:03
=C0 : Gardella, Maryse (Nokia - FR/Nozay); MORAND Lionel IMT/OL= N; Alan DeKok
Cc : dime@ietf.org list; <= a href=3D"mailto:draft-ietf-dime-rfc4006bis@ietf.org"> draft-ietf-dime-rfc4006bis@ietf.org
Objet : RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-d= ime-rfc4006bis-02

 

I have uploaded version -= 03 with the agreed changes to simply replace the reference with RFC7542.

https://tools.ietf.org/html/dr= aft-ietf-dime-rfc4006bis-03

 <= /p>

 <= /p>

From: Gardella= , Maryse (Nokia - FR/Nozay) [m= ailto:maryse.gardella@nokia.com]
Sent: Saturday, May 6, 2017 3:00 AM
To: Dave Dolson; lionel.= morand@orange.com; Alan DeKok
Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ietf.org
Subject: RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-= rfc4006bis-02

 

Hi all,

 

Therefore it makes sense to do so.

 

Thanks

Maryse

 

From: Dave D= olson [mailto:ddolson@sandvine.com<= /a>]
Sent: vendredi 5 mai 2017 21:57
To: lionel.morand@orange= .com; Gardella, Maryse (Nokia - FR/Nozay) <maryse.gardella@nokia.com>; Alan DeKok <aland@deployingradius.com> Cc: dime@ietf.org list <dime@ietf.org>; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-= rfc4006bis-02

 

Lionel,=

OK, thanks. I’ll ma= ke the changes.

 <= /p>

-Dave

 <= /p>

 <= /p>

From: lionel.morand@orange.com [<= a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<= /a>]
Sent: Friday, May 5, 2017 3:42 PM
To: Dave Dolson; Gardella, Maryse (Nokia - FR/Nozay); Alan DeKok
Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ietf.org
Subject: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4= 006bis-02

 

Hi,

RFC 6733 was published before RFC 7542, obsoleting RFC 4282. It is why RFC = 4282 was still used as reference in RFC 6733.
Using IETF rules, RFC 7242 should be used anyway for any Diameter implement= ation based on RFC 6733 and using NAI.
Therefore, when updating RFC 4006, RFC 7242 should be used as reference.
Regards,

Lionel

Le 5 mai 2017 20:05, Dave Dolson <ddolson@sandvine.com> a =E9crit :

Maryse,
Thanks for doing some research and pointing this out.

In RFC 6733, RFC4282 is used for two things:
1. to define "Network Access Identifier", for use as realm names,= which are "piggybacked on the administration of the DNS namespace&quo= t;
- so DNS restrictions would have to apply here.

2. Defining User-Name AVP, which is a NAI, but specifically "of type U= TF8String ... in a format consistent with the NAI specification [RFC4282]&q= uot;
- (see section 8.14 of RFC6733)
- so User-Name is defined to be the UTF8 subset of RFC4282.

So I claim that although RFC4282 is mentioned, RFC6733 intends that user na= mes in Diameter be limited to UTF-8, hence compatible with RFC7542.


-Dave


-----Original Message-----
From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com]
Sent: Wednesday, May 3, 2017 10:37 AM
To: Dave Dolson; Alan DeKok
Cc: Yuval Lifshitz; jouni korhonen; dime@i= etf.org list; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

My mistake, it should be RFC 6733
Maryse

-----Original Message-----
From: Dave Dolson [mailto:ddolson@s= andvine.com]
Sent: mercredi 3 mai 2017 16:19
To: Gardella, Maryse (Nokia - FR/Nozay) <maryse.gardella@nokia.com>; Alan DeKok <aland@deployingradius.com>
Cc: Yuval Lifshitz <ylifshitz@= sandvine.com>; jouni korhonen <jouni.nospam@gmail.com>; dime@ietf.org list <dime@ietf.org>; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

RFC4282 is also obsolete, and RFC7542 explains the problems with it.
I don't think we should introduce RFC4282 at this point.

(And sorry, I don't see RFC 6377 referring to 4282)


-----Original Message-----
From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com]
Sent: Wednesday, May 3, 2017 9:21 AM
To: Alan DeKok; Dave Dolson
Cc: Yuval Lifshitz; jouni korhonen; dime@i= etf.org list; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

Hello all,

For the new AVP, no question: RFC 7542 should be used.
I have not the full overview of 3GPP specs used for reference to NAI, and b= ased on:
- assuming the TS 23.003 (Numbering, addressing and identification) is an i= mportant spec to consider, the RFC 4282 is used
- RFC 6377 DBP also referring to RFC 4282
 
I would tend to agree on at least using RFC 4282 as the reference for the E= ND_USER_NAI in Subscription-Id-Type for RFC4006bis.
Whether to directly refer to RFC7542, I cannot confirm whether this is acce= ptable or not. 

BR
Maryse

-----Original Message-----
From: Alan DeKok [mailto:aland= @deployingradius.com]
Sent: mercredi 3 mai 2017 00:47
To: Dave Dolson <ddolson@sandvin= e.com>
Cc: Yuval Lifshitz <ylifshitz@= sandvine.com>; Gardella, Maryse (Nokia - FR/Nozay) <maryse.gardella@nokia.com>; jouni ko= rhonen <jouni.nospam@gmail.com= >; dime@ietf.org list <dime@ietf.org>; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

On May 2, 2017, at 5:51 PM, Dave Dolson <ddolson@sandvine.com> wrote:
>
> Thanks Alan.
> Do I correctly hear you saying we should replace all references to RFC= 2486 with RFC 7542?

  Yes.

  It's 2017.  Independent of RFC 7542, *inter-operable* implement= ations just have no business using non-UTF8 identifiers.

  Alan DeKok.

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org= /mailman/listinfo/dime

_=
___________________________________________________________________________=
_____________________________________________
&=
nbsp;
C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc
p=
as etre diffuses, exploites ou copies sans autorisation. Si vous avez recu =
ce message par erreur, veuillez le signaler
a=
 l'expediteur et le detruire ainsi que les pieces jointes. Les messages ele=
ctroniques etant susceptibles d'alteration,
O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. Merci.
&=
nbsp;
T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;
t=
hey should not be distributed, used or copied without authorisation.
I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.
A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.
T=
hank you.
________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.


 


This message and its attachments may contain confidential or pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that=
 have been modified, changed or falsified.


Thank you.
--_000_E8355113905631478EFF04F5AA706E98A906566Awtlexchp2sandvi_-- From nobody Mon Jul 17 14:47:09 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFE8128BA2; Mon, 17 Jul 2017 14:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 WDJ7OgVDbSBI; Mon, 17 Jul 2017 14:47:05 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2A14126CC7; Mon, 17 Jul 2017 14:47:04 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 85AE42056F; Mon, 17 Jul 2017 23:47:03 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.72]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 39B751C006F; Mon, 17 Jul 2017 23:47:03 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0352.000; Mon, 17 Jul 2017 23:47:03 +0200 From: To: Dave Dolson , "Gardella, Maryse (Nokia - FR/Nozay)" , Alan DeKok CC: "dime@ietf.org list" , "draft-ietf-dime-rfc4006bis@ietf.org" Thread-Topic: =?Windows-1252?Q?RE=A0:_RE:_M-bit_setting_in_draft-ietf-dime-rfc4006bis-0?= =?Windows-1252?Q?2?= Thread-Index: AQHS/0Y5aJJaUsU+AkWDYMLzgtR+Ng== Date: Mon, 17 Jul 2017 21:47:01 +0000 Message-ID: <20138_1500328023_596D3057_20138_295_1_6B7134B31289DC4FAF731D844122B36E2D1B6758@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <13800_1500305348_596CD7C4_13800_63_1_6B7134B31289DC4FAF731D844122B36E2D1B6048@OPEXCLILM43.corporate.adroot.infra.ftgroup>, In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E2D1B6758OPEXCLILM43corp_" MIME-Version: 1.0 Archived-At: Subject: [Dime] =?windows-1252?q?RE=A0=3A_RE=3A_M-bit_setting_in_draft-iet?= =?windows-1252?q?f-dime-rfc4006bis-02?= X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 21:47:08 -0000 --_000_6B7134B31289DC4FAF731D844122B36E2D1B6758OPEXCLILM43corp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Dave, Speaking about the existing AVPs, I don't think that we need a specific err= ata report on RFC4006 if it is what you meant. I consider it more as a clarification on the M-bit setting included while r= evising the specification, based on requirements/guidelines provided after = the publication of the RFC4006. As it is, the MAY column is not wrong. It is just useless and it is why its= use was deprecated. Lionel Le 17 juil. 2017 18:05, Dave Dolson a =E9crit : Lionel, Do you consider those to be errata against RFC4006 ? From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] Sent: Monday, July 17, 2017 5:29 PM To: Dave Dolson; Gardella, Maryse (Nokia - FR/Nozay); Alan DeKok Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ietf.org Subject: M-bit setting in draft-ietf-dime-rfc4006bis-02 Hi, Sorry for this late comment. As stated in RFC6733, It is the decision of the protocol designer when to develop a new Diameter application rather than extending Diameter in other ways. However, a new Diameter application MUST be created when one or more of the following criteria are met: M-bit Setting An AVP with the M-bit in the MUST column of the AVP flag table is added to an existing Command/Application. An AVP with the M-bit in the MAY column of the AVP flag table is added to an existing Command/Application. Therefore, if it is proposed to keep the existing DCC application-id, the n= ewly defined AVPs must be defined with the M-bit put in the MUST NOT column: +---------------+ |AVP Flag rules | |----+-----+----| AVP Section | | |MUST| Attribute Name Code Defined Data Type |MUST| MAY |NOT | -----------------------------------------|----+-----+----| QoS-Final-Unit- TBD17 8.68 Grouped | | M | V | Indication | | | | Redirect-Server TBD13 8.64 Grouped | | M | V | -Extension | | | | Redirect-Address TBD14 8.65 Address | | M | V | -IPAddress | | | | Redirect-Address TBD15 8.66 UTF8String | | M | V | -URL | | | | Redirect-Address TBD16 8.67 UTF8String | | M | V | -SIP-URI | | | | Subscription-Id TBD7 8.58 Grouped | | M | V | -Extension | | | | Subscription-Id TBD8 8.59 UTF8String | | M | V | -E164 | | | | Subscription-Id TBD9 8.60 UTF8String | | M | V | -IMSI | | | | Subscription-Id TBD10 8.61 UTF8String | | M | V | -SIP-URI | | | | Subscription-Id TBD11 8.62 UTF8String | | M | V | -NAI | | | | Subscription-Id TBD12 8.63 UTF8String | | M | V | -Private | | | | User-Equipment TBD1 8.52 Grouped | | M | V | -Info-Extension | | | | User-Equipment TBD2 8.53 OctetString| | M | V | -Info-IMEISV | | | | User-Equipment TBD3 8.54 OctetString| | M | V | -Info-MAC | | | | User-Equipment TBD4 8.55 OctetString| | M | V | -Info-EUI64 | | | | User-Equipment TBD5 8.56 OctetString| | M | V | -Info-ModifiedEUI64 | | | | User-Equipment TBD6 8.57 OctetString| | M | V | Now, regarding existing AVPs with the M-bit put in the MAY column (listed b= elow), I would recommend not to use the MAY column but to specific in which= DCC commands the M-bit setting may change for some AVP, as indicated in RF= C6733 and RFC7423. >From RFC6733: Note: The M-bit setting for a given AVP is relevant to an Application and each command within that application that includes the AVP. That is, if an AVP appears in two commands for application Foo and the M-bit settings are different in each command, then there should be two AVP flag tables describing when to set the M-bit. For AVPs for which there is no clear use case for change of the M-bit setti= ng in the DCC app, the M-bit should be put in the MUST column. It may be th= e case for all the AVPs listed below (I've not checked). Other applications= using DCC commands can decide to set or clear the M-bit of the related DCC= commands' AVPs without any constraint. +---------------+ |AVP Flag rules | |----+-----+----| AVP Section | | |MUST| Attribute Name Code Defined Data Type |MUST| MAY |NOT | -----------------------------------------|----+-----+----| CC-Correlation-Id 411 8.1 OctetString| | M | V | Service-Parameter 440 8.43 Grouped | | M | V | -Info | | | | Service- 441 8.44 Unsigned32 | | M | V | Parameter-Type | | | | Service- 442 8.45 OctetString| | M | V | Parameter-Value | | | | User-Equipment 458 8.49 Grouped | | M | V | -Info | | | | User-Equipment 459 8.50 Enumerated | | M | V | -Info-Type | | | | User-Equipment 460 8.51 OctetString| | M | V | -Info-Value | | | | User-Equipment TBD1 8.52 Grouped | | M | V | -Info-Extension | | | | User-Equipment TBD2 8.53 OctetString| | M | V | -Info-IMEISV | | | | User-Equipment TBD3 8.54 OctetString| | M | V | -Info-MAC | | | | User-Equipment TBD4 8.55 OctetString| | M | V | -Info-EUI64 | | | | User-Equipment TBD5 8.56 OctetString| | M | V | -Info-ModifiedEUI64 | | | | User-Equipment TBD6 8.57 OctetString| | M | V | -Info-IMEI | | | | Regards, Lionel De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : jeudi 11 mai 2017 17:03 =C0 : Gardella, Maryse (Nokia - FR/Nozay); MORAND Lionel IMT/OLN; Alan DeKok Cc : dime@ietf.org list; draft-ietf-dime-rfc4006bis@i= etf.org Objet : RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 I have uploaded version -03 with the agreed changes to simply replace the r= eference with RFC7542. https://tools.ietf.org/html/draft-ietf-dime-rfc4006bis-03 From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com] Sent: Saturday, May 6, 2017 3:00 AM To: Dave Dolson; lionel.morand@orange.com;= Alan DeKok Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ie= tf.org Subject: RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Hi all, Therefore it makes sense to do so. Thanks Maryse From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: vendredi 5 mai 2017 21:57 To: lionel.morand@orange.com; Gardella, Ma= ryse (Nokia - FR/Nozay) >; Alan DeKok > Cc: dime@ietf.org list >; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Lionel, OK, thanks. I=92ll make the changes. -Dave From: lionel.morand@orange.com [mailto:lio= nel.morand@orange.com] Sent: Friday, May 5, 2017 3:42 PM To: Dave Dolson; Gardella, Maryse (Nokia - FR/Nozay); Alan DeKok Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ie= tf.org Subject: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Hi, RFC 6733 was published before RFC 7542, obsoleting RFC 4282. It is why RFC = 4282 was still used as reference in RFC 6733. Using IETF rules, RFC 7242 should be used anyway for any Diameter implement= ation based on RFC 6733 and using NAI. Therefore, when updating RFC 4006, RFC 7242 should be used as reference. Regards, Lionel Le 5 mai 2017 20:05, Dave Dolson > a =E9crit : Maryse, Thanks for doing some research and pointing this out. In RFC 6733, RFC4282 is used for two things: 1. to define "Network Access Identifier", for use as realm names, which are= "piggybacked on the administration of the DNS namespace" - so DNS restrictions would have to apply here. 2. Defining User-Name AVP, which is a NAI, but specifically "of type UTF8St= ring ... in a format consistent with the NAI specification [RFC4282]" - (see section 8.14 of RFC6733) - so User-Name is defined to be the UTF8 subset of RFC4282. So I claim that although RFC4282 is mentioned, RFC6733 intends that user na= mes in Diameter be limited to UTF-8, hence compatible with RFC7542. -Dave -----Original Message----- From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com] Sent: Wednesday, May 3, 2017 10:37 AM To: Dave Dolson; Alan DeKok Cc: Yuval Lifshitz; jouni korhonen; dime@ietf.org lis= t; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 My mistake, it should be RFC 6733 Maryse -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: mercredi 3 mai 2017 16:19 To: Gardella, Maryse (Nokia - FR/Nozay) >; Alan DeKok > Cc: Yuval Lifshitz >;= jouni korhonen >; di= me@ietf.org list = >; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 RFC4282 is also obsolete, and RFC7542 explains the problems with it. I don't think we should introduce RFC4282 at this point. (And sorry, I don't see RFC 6377 referring to 4282) -----Original Message----- From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com] Sent: Wednesday, May 3, 2017 9:21 AM To: Alan DeKok; Dave Dolson Cc: Yuval Lifshitz; jouni korhonen; dime@ietf.org lis= t; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Hello all, For the new AVP, no question: RFC 7542 should be used. I have not the full overview of 3GPP specs used for reference to NAI, and b= ased on: - assuming the TS 23.003 (Numbering, addressing and identification) is an i= mportant spec to consider, the RFC 4282 is used - RFC 6377 DBP also referring to RFC 4282 I would tend to agree on at least using RFC 4282 as the reference for the E= ND_USER_NAI in Subscription-Id-Type for RFC4006bis. Whether to directly refer to RFC7542, I cannot confirm whether this is acce= ptable or not. BR Maryse -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: mercredi 3 mai 2017 00:47 To: Dave Dolson > Cc: Yuval Lifshitz >;= Gardella, Maryse (Nokia - FR/Nozay) >; jouni korhonen >; dime@ietf.org list >; draft-ietf-dime-rfc4006bis@ietf.org Subject: Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 On May 2, 2017, at 5:51 PM, Dave Dolson > wrote: > > Thanks Alan. > Do I correctly hear you saying we should replace all references to RFC 24= 86 with RFC 7542? Yes. It's 2017. Independent of RFC 7542, *inter-operable* implementations jus= t have no business using non-UTF8 identifiers. Alan DeKok. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E2D1B6758OPEXCLILM43corp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Dave,

Speaking about the existing AVPs, I don't think that we need a specific err= ata report on RFC4006 if it is what you meant.
I consider it more as a clarification on the M-bit setting included while r= evising the specification, based on requirements/guidelines provided after = the publication of the RFC4006.
As it is, the MAY column is not wrong. It is just useless and it is why its= use was deprecated.

Lionel

Le 17 juil. 2017 18:05, Dave Dolson <ddolson@sandvi= ne.com> a =E9crit :

Lionel,

Do you consider those t= o be errata against RFC4006 ?

 

 

From: lionel= .morand@orange.com [mailto:lionel.morand@orange.com]
Sent: Monday, July 17, 2017 5:29 PM
To: Dave Dolson; Gardella, Maryse (Nokia - FR/Nozay); Alan DeKok
Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ietf.org
Subject: M-bit setting in draft-ietf-dime-rfc4006bis-02

 

Hi,

 

Sorry for this late comment.

 

As stated in RFC6733,

 

   It is the decision of the protocol designer = when to develop a new

   Diameter application rather than extending D= iameter in other ways.

   However, a new Diameter application MUST be = created when one or more

   of the following criteria are met:

 

   M-bit Setting

 

      An AVP with the M-bit in t= he MUST column of the AVP flag table is

      added to an existing Comma= nd/Application.  An AVP with the M-bit

      in the MAY column of the A= VP flag table is added to an existing

      Command/Application.

 

Therefore, if it is proposed to keep the existing DCC app= lication-id, the newly defined AVPs must be defined with the M-bit put in t= he MUST NOT column:

 

         &nb= sp;            =             &nb= sp;         +---------------= 3;

         &nb= sp;            =             &nb= sp;         |AVP Flag rules |

         &nb= sp;            =             &nb= sp;         |----+-----+---= -|

         &nb= sp;           AVP  S= ection           | &= nbsp;  |     |MUST|

   Attribute Name    Code Define= d Data Type |MUST| MAY |NOT |

   -----------------------------------------|--= --+-----+----|

   QoS-Final-Unit-  TBD17 8.68  = Grouped    |    |  M  |  V |<= /span>

     Indication   &nbs= p;            &= nbsp;            |&n= bsp;   |     |    |

   Redirect-Server  TBD13 8.64  = Grouped    |    |  M  |  V |<= /span>

     -Extension   &nbs= p;            &= nbsp;            |&n= bsp;   |     |    |

   Redirect-Address TBD14 8.65   Addr= ess    |    |  M  |  V |

     -IPAddress   &nbs= p;            &= nbsp;            |&n= bsp;   |     |    |

   Redirect-Address TBD15 8.66   UTF8= String |    |  M  |  V |

     -URL    &nbs= p;            &= nbsp;           &nbs= p;     |    |     |&= nbsp;   |

   Redirect-Address TBD16 8.67   UTF8= String |    |  M  |  V |

     -SIP-URI    =             &nb= sp;            =   |    |     |    |<= /span>

   Subscription-Id  TBD7  8.58 &= nbsp; Grouped    |    |  M  | = V |

     -Extension   &nbs= p;            &= nbsp;            |&n= bsp;   |     |    |

   Subscription-Id  TBD8  8.59 &= nbsp; UTF8String |    |  M  |  V |

     -E164    &nb= sp;            =             &nb= sp;    |    |     | =    |

   Subscription-Id  TBD9  8.60 &= nbsp; UTF8String |    |  M  |  V |

     -IMSI     &n= bsp;            = ;            &n= bsp;   |    |     | =    |

   Subscription-Id  TBD10 8.61  = UTF8String |    |  M  |  V |

     -SIP-URI    =             &nb= sp;            =   |    |     |    |<= /span>

   Subscription-Id  TBD11 8.62  = UTF8String |    |  M  |  V |

     -NAI    &nbs= p;             =             &nb= sp;    |    |     |&= nbsp;   |

   Subscription-Id  TBD12 8.63  = UTF8String |    |  M  |  V |

     -Private    =             &nb= sp;            =   |    |     |    |<= /span>

   User-Equipment   TBD1  8.52&n= bsp;  Grouped    |    |  M  |&= nbsp; V |

     -Info-Extension       &nbs= p;            &= nbsp;   |    |     | &nbs= p;  |

   User-Equipment   TBD2  8.53&n= bsp;  OctetString|    |  M  |  V |

     -Info-IMEISV   &n= bsp;            = ;           |  =   |     |    |

   User-Equipment   TBD3  8.54&n= bsp;  OctetString|    |  M  |  V |

     -Info-MAC    = ;            &n= bsp;            = ; |    |     |    |

   User-Equipment   TBD4  8.55&n= bsp;  OctetString|    |  M  |  V |

     -Info-EUI64   &nb= sp;            =             | &= nbsp;  |     |    |

   User-Equipment   TBD5  8.56&n= bsp;  OctetString|    |  M  |  V |

     -Info-ModifiedEUI64  &= nbsp;           &nbs= p;     |    |     |&= nbsp;   |

   User-Equipment   TBD6  8.57&n= bsp;  OctetString|    |  M  |  V |

 

Now, regarding existing AVPs with the M-bit put in the MA= Y column (listed below), I would recommend not to use the MAY column but to= specific in which DCC commands the M-bit setting may change for some AVP, as indicated in RFC6733 and RFC7423.

 

From RFC6733:

 

      Note: The M-bit setting fo= r a given AVP is relevant to an

      Application and each comma= nd within that application that includes

      the AVP.  That is, if= an AVP appears in two commands for

      application Foo and the M-= bit settings are different in each

      command, then there should= be two AVP flag tables describing when

      to set the M-bit.

 

For AVPs for which there is no clear use case for change = of the M-bit setting in the DCC app, the M-bit should be put in the MUST co= lumn. It may be the case for all the AVPs listed below (I've not checked). Other applications using DCC commands can decide= to set or clear the M-bit of the related DCC commands' AVPs without any co= nstraint.

 

         &nb= sp;            =             &nb= sp;         +---------------= 3;

         &nb= sp;            =             &nb= sp;         |AVP Flag rules |

         &nb= sp;            =             &nb= sp;         |----+-----+---= -|

         &nb= sp;           AVP  S= ection           | &= nbsp;  |     |MUST|

   Attribute Name    Code Define= d Data Type |MUST| MAY |NOT |

   -----------------------------------------|--= --+-----+----|

   CC-Correlation-Id 411  8.1  &= nbsp; OctetString|    |  M  |  V |

   Service-Parameter 440  8.43  = Grouped    |    |  M  |  V |<= /span>

     -Info    &nb= sp;            =             &nb= sp;    |    |     | =    |

   Service-      =     441  8.44   Unsigned32 |   = ; |  M  |  V |

     Parameter-Type   =             &nb= sp;         |    |&n= bsp;    |    |

   Service-      =     442  8.45   OctetString|   = ; |  M  |  V |

     Parameter-Value   = ;            &n= bsp;        |    | &= nbsp;   |    |

   User-Equipment    458  8= .49   Grouped    |    |  M&nbs= p; |  V |

     -Info    &nb= sp;            =             &nb= sp;    |    |     | =    |

   User-Equipment    459  8= .50   Enumerated |    |  M  |  V |<= /span>

     -Info-Type   &nbs= p;            &= nbsp;            |&n= bsp;   |     |    |

   User-Equipment    460  8= .51   OctetString|    |  M  |  V |<= /span>

     -Info-Value   &nb= sp;            =             | &= nbsp;  |     |    |

   User-Equipment   TBD1  8.52&n= bsp;  Grouped    |    |  M  |&= nbsp; V |

     -Info-Extension   = ;            &n= bsp;        |    | &= nbsp;   |    |

   User-Equipment   TBD2  8.53&n= bsp;  OctetString|    |  M  |  V |

     -Info-IMEISV   &n= bsp;            = ;           |  =   |     |    |

   User-Equipment   TBD3  8.54&n= bsp;  OctetString|    |  M  |  V |

     -Info-MAC    = ;            &n= bsp;            = ; |    |     |    |

   User-Equipment   TBD4  8.55&n= bsp;  OctetString|    |  M  |  V |

     -Info-EUI64   &nb= sp;            =             | &= nbsp;  |     |    |

   User-Equipment   TBD5  8.56&n= bsp;  OctetString|    |  M  |  V |

     -Info-ModifiedEUI64  &= nbsp;           &nbs= p;     |    |     |&= nbsp;   |

   User-Equipment   TBD6  8.57&n= bsp;  OctetString|    |  M  |  V |

     -Info-IMEI   &nbs= p;            &= nbsp;            |&n= bsp;   |     |    |

 

 

Regards,

 

Lionel

 

 

De : Dave Dolson [= mailto:ddolson@sandvine.com]
Envoy=E9 : jeudi 11 mai 2017 17:03
=C0 : Gardella, Maryse (Nokia - FR/Nozay); MORAND Lionel IMT/OL= N; Alan DeKok
Cc : dime@ietf.org list; <= a href=3D"mailto:draft-ietf-dime-rfc4006bis@ietf.org"> draft-ietf-dime-rfc4006bis@ietf.org
Objet : RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-d= ime-rfc4006bis-02

 

I have uploaded version= -03 with the agreed changes to simply replace the reference with RFC7542.<= /span>

https://tools.ietf.org/html/= draft-ietf-dime-rfc4006bis-03

 

 

From: Gardel= la, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com]
Sent: Saturday, May 6, 2017 3:00 AM
To: Dave Dolson; lionel.= morand@orange.com; Alan DeKok
Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ietf.org
Subject: RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-= rfc4006bis-02

 

Hi all,

 

Therefore it makes sense to do so.

 

Thanks

Maryse

 

From: Dave= Dolson [mailto:ddolson@sandvine.co= m]
Sent: vendredi 5 mai 2017 21:57
To: lionel.morand@orange= .com; Gardella, Maryse (Nokia - FR/Nozay) <maryse.gardella@nokia.com>; Alan DeKok <aland@deployingradius.com> Cc: dime@ietf.org list <dime@ietf.org>; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-= rfc4006bis-02

 

Lionel,

OK, thanks. I=92ll make= the changes.

 

-Dave

 

 

From: lionel.morand@orange.com [<= a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<= /a>]
Sent: Friday, May 5, 2017 3:42 PM
To: Dave Dolson; Gardella, Maryse (Nokia - FR/Nozay); Alan DeKok
Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ietf.org
Subject: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4= 006bis-02

 

Hi,

RFC 6733 was published before RFC 7542, obsoleting RFC 4282. It is why RFC = 4282 was still used as reference in RFC 6733.
Using IETF rules, RFC 7242 should be used anyway for any Diameter implement= ation based on RFC 6733 and using NAI.
Therefore, when updating RFC 4006, RFC 7242 should be used as reference.
Regards,

Lionel

Le 5 mai 2017 20:05, Dave Dolson <ddolson@sandvine.com> a =E9crit :

Maryse,
Thanks for doing some research and pointing this out.

In RFC 6733, RFC4282 is used for two things:
1. to define "Network Access Identifier", for use as realm names,= which are "piggybacked on the administration of the DNS namespace&quo= t;
- so DNS restrictions would have to apply here.

2. Defining User-Name AVP, which is a NAI, but specifically "of type U= TF8String ... in a format consistent with the NAI specification [RFC4282]&q= uot;
- (see section 8.14 of RFC6733)
- so User-Name is defined to be the UTF8 subset of RFC4282.

So I claim that although RFC4282 is mentioned, RFC6733 intends that user na= mes in Diameter be limited to UTF-8, hence compatible with RFC7542.


-Dave


-----Original Message-----
From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com]
Sent: Wednesday, May 3, 2017 10:37 AM
To: Dave Dolson; Alan DeKok
Cc: Yuval Lifshitz; jouni korhonen; dime@i= etf.org list; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

My mistake, it should be RFC 6733
Maryse

-----Original Message-----
From: Dave Dolson [mailto:ddolson@s= andvine.com]
Sent: mercredi 3 mai 2017 16:19
To: Gardella, Maryse (Nokia - FR/Nozay) <maryse.gardella@nokia.com>; Alan DeKok <aland@deployingradius.com>
Cc: Yuval Lifshitz <ylifshitz@= sandvine.com>; jouni korhonen <jouni.nospam@gmail.com>; dime@ietf.org list <dime@ietf.org>; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

RFC4282 is also obsolete, and RFC7542 explains the problems with it.
I don't think we should introduce RFC4282 at this point.

(And sorry, I don't see RFC 6377 referring to 4282)


-----Original Message-----
From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com]
Sent: Wednesday, May 3, 2017 9:21 AM
To: Alan DeKok; Dave Dolson
Cc: Yuval Lifshitz; jouni korhonen; dime@i= etf.org list; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

Hello all,

For the new AVP, no question: RFC 7542 should be used.
I have not the full overview of 3GPP specs used for reference to NAI, and b= ased on:
- assuming the TS 23.003 (Numbering, addressing and identification) is an i= mportant spec to consider, the RFC 4282 is used
- RFC 6377 DBP also referring to RFC 4282
 
I would tend to agree on at least using RFC 4282 as the reference for the E= ND_USER_NAI in Subscription-Id-Type for RFC4006bis.
Whether to directly refer to RFC7542, I cannot confirm whether this is acce= ptable or not. 

BR
Maryse

-----Original Message-----
From: Alan DeKok [mailto:aland= @deployingradius.com]
Sent: mercredi 3 mai 2017 00:47
To: Dave Dolson <ddolson@sandvin= e.com>
Cc: Yuval Lifshitz <ylifshitz@= sandvine.com>; Gardella, Maryse (Nokia - FR/Nozay) <maryse.gardella@nokia.com>; jouni ko= rhonen <jouni.nospam@gmail.com= >; dime@ietf.org list <dime@ietf.org>; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

On May 2, 2017, at 5:51 PM, Dave Dolson <ddolson@sandvine.com> wrote:
>
> Thanks Alan.
> Do I correctly hear you saying we should replace all references to RFC= 2486 with RFC 7542?

  Yes.

  It's 2017.  Independent of RFC 7542, *inter-operable* implement= ations just have no business using non-UTF8 identifiers.

  Alan DeKok.

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org= /mailman/listinfo/dime

=
___________________________________________________________________________=
______________________________________________
=
 
=
Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
=
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
=
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
=
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.
=
 
=
This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
=
they should not be distributed, used or copied without authorisation.
=
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
=
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
=
Thank you.
_______________________________________________________________=
__________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informati=
ons confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vo=
us avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les=
 messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere,=
 deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or pr=
ivileged information that may be protected by law;
they should not be distributed, used or copied without authoris=
ation.
If you have received this email in error, please notify the sen=
der and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages tha=
t have been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E2D1B6758OPEXCLILM43corp_-- From nobody Tue Jul 18 06:41:55 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5BE131B01 for ; Tue, 18 Jul 2017 06:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 SGtHTH_NrqRX for ; Tue, 18 Jul 2017 06:41: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 3EB0D131B41 for ; Tue, 18 Jul 2017 06:41:52 -0700 (PDT) Received: from dhcp-8888.meeting.ietf.org ([IPv6:2001:67c:370:128:751c:2554:5681:6acc]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v6IDfnCF024143 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 18 Jul 2017 08:41:50 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [IPv6:2001:67c:370:128:751c:2554:5681:6acc] claimed to be dhcp-8888.meeting.ietf.org To: "dime@ietf.org" From: "A. Jean Mahoney" Message-ID: <9ec38b25-41d4-a751-aa97-d8af0f9022c5@nostrum.com> Date: Tue, 18 Jul 2017 15:41:48 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Dime] 99 IETF DIME session notes X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 13:41:54 -0000 Hi all, Below are my notes from the session yesterday. Thanks! Jean ------------------------------------------------------------------------------------------- IETF-99 DIME 1740-1840 July 17, 2017, Monday Afternoon session III meeting room: Karlin III Jabber room: dime at jabber.ietf.org (Please join) Chairs:Jouni Korhonen, Lionel Morand AD: Ben Campbell 17:40 - 17:45, Preliminaries, Chairs (5 minutes) ------------------------------------------ Presentation: https://www.ietf.org/proceedings/99/slides/slides-99-dime-agenda-wg-status-00.pdf slide 1: Title Lionel Morand: Jouni is not able to make it to the meeting. slide 2: Note Well slide 3: Agenda Note taker/Jabber scribe: Jean Mahoney Martin Dolly: when will Diameter security discussion happen? Lionel: end of the session. 17:45 - 17:50, WG Document Status, Chairs (5 minutes) ------------------------------------------ *draft-ietf-dime-agent-overload-11 --> RFC Ed Queue *draft-ietf-dime-doic-rate-control-06 --> Waiting for Write-Up *draft-ietf-dime-group-signaling-08 --> In WG Last Call *draft-ietf-dime-load-09 --> RFC Ed Queue *draft-ietf-dime-rfc4006bis-03 --> In WG Last Call slide 4: WG Status Update Lionel: Both overload and load are in the RFC editor queue due to a MISREF. I'll take care of it after this meeting. Steve Donovan: Just a nit on the slide - I'm the editor on load information, I'm not the editor for 4006bis. Lionel: Group signaling - the author's think it's ready. We need more reviews. Marco? Marco Liebsch: we've updated it before Chicago. We've covered all comments. Is ready for expert review. Lionel: we've received a good technical review from Steve. Needs another before WGLC. Rate control is missing its writeup. Steve: Has it finished WGLC? Lionel: Yes, needs writeup. Rate-control didn't receive a deep technical review. Need further review. From SA5 guys in 3GPP, since they are the main users. slide 5: WG Status update (2/2) Lionel: AVP level security (e2e) draft has expired - Jouni is not able to support the workload alone. I will go to the SAAG meeting and will ask for support from security experts. Solution doesn't have to be Diameter specific. Ben Campbell: I would personally like to see this completed. Who will deploy it? Martin Dolly: next round of FCC sys req, they just finished looking at SS7 security vulnerabilities, next 2 years they'll look at Diameter. SA3 coming up in 3 weeks. I'll give them discussion paper, a status update of work here. It gets friendly talk there. It's been discussed with regard to 5G and security system. It's now or never, forever-hold-your-peace time. Lionel: GSMA would like a recommendation. If it's easy to implement, we have ongoing deployment. Ben: They are welcome to come here and help. Eric Guttman: for mission-critical deployments, there are 2 security domains - operator domain and mission-critical operator domain. We've looked at securing at a message or component to a SIP message level. The message has to be e2e secure between client and host at the mission-critical ISP. Are there AAA requirements where you can't expose certain AVPs to the operator? Need to check. Lionel: From the requirements POV, both should be available with the solution. Normally you would only be able to secure signaling between gateways for instance. You may have e2e secure exchange between any Diameter client and any Diameter server. Martin: I don't think that's a case. 401 specifies that equipment manufacturers must support IPsec for communication within the EPC, but says it optional to deploy. No one has deployed. For 5G, the European operators are fighting pulling the security into the EPC not at the ENodeB. Some of those statements aren't true. Lionel: Ben, you see there is some interest. We would like to see this work done in IETF. Ben: I observe an interest in using the work. I need to observe interest in doing the work. Maybe SAAG will help. Lionel: It's more a security discussion than a Diameter discussion. Need help from security area. Eric: There was a mechanism for using an SMIME encapsulation. That became historic? Lionel: deprecated. A new mechanism will be defined outside the base protocol. All new drafts are based on this. 17:50 - 18:35 Individual draft discussions (45 minutes) ------------------------------------------- 17:50 - 18:10 Diameter Policy Groups and Sets, Lyle (20min) Draft: https://tools.ietf.org/html/draft-bertz-dime-predictunits-02 Draft: https://tools.ietf.org/html/draft-bertz-dime-policygroups-04 Presentation: https://www.ietf.org/proceedings/99/slides/slides-99-dime-predicted-units-policy-groups-00.pdf slide 1: Title slide 2: Predicted Units v02 - Motivation Lyle: It takes 3-4 minutes to spin up a VM. slide 3: Predicted Units v02 - Update Lyle: Have not received any new updates. I would like to ask for adoption. Lionel: Who has read? I wasn't in the last meeting what was the feeling in the room? Ben: Besides the chair and the AD? Jean: About 7 people total. Lionel: I've read it and understood the mechanism, which is good. Check on the ML if there is support for adoption. There's not much to do on this doc. slide 4: Intermission slide 5: Purpose slide 6: Policy Groups - Update slide 7: Relationship Model slide 8: Policy Groups Example 1, Overlap Deduplication at Enforcement Point - Adding Membership Assignment to Filters Lyle: SDN switches have limitations of tables (13 tables in OpenFlow). Can concatenate tables. The rules no longer overlap. How to use your metadata field and tie it back to a customer? slide 9: Policy Groups Example 2, Application at the Decision Point Process Lyle: We don't change the user's relationship to their services mid-session. Usually reauthorize them before doing that. slide 10: Applications slide 11: Next Steps Lyle: Would like to hear more from the group before asking for adoption. Lionel: who has read? Lionel: Go back to the Purpose slide. Lyle: didn't want to confuse people but wanted a similar aggregation concept with backwards compatibility. It's similar to ... It's a membership domain. Lionel: I need to review it again. It would be useful to have more review. Lyle: I'm not happy with the examples, I'd like them to be consistent through the doc. Lionel: the draft needs to clearly identify why you can't do this with existing mechanisms. Lyle: all of our filters are based on time and what's in the packets. When the time is the same and the rule is a default rule, that's the most overlap in the system. Lionel: It's not that clear from the creation of AVP, be good to describe it. 18:10 - 18:35 Diameter Specification Recommendations, Lyle (25min) Draft: https://tools.ietf.org/html/draft-bertz-dime-diamimpr-00 Pres: https://www.ietf.org/proceedings/99/slides/slides-99-dime-diameter-specification-recommendations-00.pdf slide 1: Title slide 2: Motivation Lyle: 85% of the time, errors due to ambiguity. slide 3: Findings Eric Guttman: send this to SA5 charging if you have a delegate. Lyle: we don't, but wanted to get it out. slide 4: Methodology slide 5: Unexpected Use Cases slide 6: We are not immune slide 7: Enumerations slide 8: Recommendations slide 9: Defined AVP Recommendations slide 10: Defined AVPs Recommended Formats slide 11: Imported AVP Recommendations slide 12: Grouped AVP / Command Refinement slide 13: Example Refinement slide 14: Command Recommendations slide 15: Enumeration Recommendations slide 16: GAPs for Automated Validation slide 17: Example to Close Gaps slide 18: Enumeration Example Format slide 19: Open Questions slide 20: Summary slide 21: Next steps Lionel: who has read? (Three people raised hands) Lyle: Dave Dolson and Jouni read it. Lionel: in 3GPP it's not really refinement, because in 3GPP just highlight the AVPs they use. We you take a specification and not reading anything - Lyle: they want to just write the code and be done. Lionel: For new drafts, it should be taken into consideration. For existing RFCs, these are documentation errors. When it's clarification, it needs to go through the errata process. For the 3GPP specs, CRs need to be opened. Lyle: This has a lot of errors documented. Would this be informational? How would it progress? Lionel: It can be informational, and can be referenced by other docs. No guideline here. Just highlight what could go wrong. Lyle: I would change the style. Make it more of a report. Lionel: It's not unusual for the IETF to explain issues with implementations. 18:35 - 18:40 Wrap-up and Next, Chairs/AD (5 minutes) ----------------------------- WG Goals/Milestones status - skipped Next steps/Action Points - Future of the WG Lionel: We have 3 remaining documents. Ben: And two that you are thinking of adopting. Lionel: few people in room, not much activity on the list. I won't be able to continue with the chair position - too much work in the 3GPP. Same with Jouni - he changed companies, won't be able to continue. What is the next step except closing the group? Ben: The existing documents are post or near WGLC. Those can be in the hands of the ADs before long. What's you're time frame for needing to step down? Lionel: I need to know when to stop adopting new documents. Even for Jouni. Ben: Of the 2 drafts for the adoption - the predictive units can be AD sponsored. The group one is on the border, a little more complex. I don't have to be the AD that sponsors it. Lionel: For the group one, I need to see more interest. Ben: even if I AD sponsor, I want someone to review them. Lionel: E2E security needs to be done. If we get volunteers from SAAG. Ben: lets see what happens in SAAG. If there's interest - maybe we can spin up some mini-group. Or just speculating here - recharter dime with new chairs to just do that. Lionel: If it is only to go with existing drafts, I think it can be done in short timeframe. Need to confirm with Jouni. Defining new charter with new chairs may not be useful. Ben: E2E security may go into the security area. Lionel: Are there any other comments? (none from the room). To summarize - existing WG documents will be pushed forward. For predictive units, confirm on ML that it's a WG doc, for the group one, we'll check. After those documents, we'll close the WG. Ben: Those 2 new drafts - predictive definitely and maybe group - can be AD sponsored. They can still change to AD sponsorship if we need to close the working group sooner. I'm skeptical of bringing new work into the group, unless we see interest. Lionel: Thank you. ACTION: Chairs to push existing WG documents forward. ACTION: Lionel to bring the e2e security draft to the SAAG session this week to ask for support in finishing it. ACTION: Confirm interest on mailing list for adopting draft-bertz-dime-predictunits. ACTION: Confirm interest on mailing list for adopting draft-bertz-dime-policygroups. ACTION: Ben to look more closely at draft-bertz-dime-policygroups as a candidate for AD sponsorship. From nobody Tue Jul 18 07:53:31 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDE31317BE for ; Tue, 18 Jul 2017 07:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 D-GDYJ1GaJIv for ; Tue, 18 Jul 2017 07:53:18 -0700 (PDT) Received: from mailport7.csra.com (mailport7.csra.com [131.131.83.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A29B131B5D for ; Tue, 18 Jul 2017 07:53:17 -0700 (PDT) Received: from csrrdu1exm025.corp.csra.com (HELO mail.csra.com) ([10.176.90.35]) by mailport7.csra.com with ESMTP/TLS/AES256-SHA; 18 Jul 2017 10:53:16 -0400 Received: from CSRRDU1EXM025.corp.csra.com (10.176.90.35) by CSRRDU1EXM024.corp.csra.com (10.176.90.34) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 18 Jul 2017 10:53:15 -0400 Received: from CSRRDU1EXM025.corp.csra.com ([10.176.90.35]) by CSRRDU1EXM025.corp.csra.com ([10.176.90.35]) with mapi id 15.00.1210.000; Tue, 18 Jul 2017 10:53:15 -0400 From: "Gunn, Janet P" To: "A. Jean Mahoney" , "dime@ietf.org" Thread-Topic: [Dime] 99 IETF DIME session notes Thread-Index: AQHS/8umRKiz/plCiUaSjwu1tWWtVaJZqsmA Date: Tue, 18 Jul 2017 14:53:15 +0000 Message-ID: <7278718efbb946b8adb89c7306cced30@CSRRDU1EXM025.corp.csra.com> References: <9ec38b25-41d4-a751-aa97-d8af0f9022c5@nostrum.com> In-Reply-To: <9ec38b25-41d4-a751-aa97-d8af0f9022c5@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.76.253.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] 99 IETF DIME session notes X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 14:53:21 -0000 Nit In Martin's statement, I think "FCC sys rec" should be "FCC CSRIC" https://www.fcc.gov/about-fcc/advisory-committees/communications-security-r= eliability-and-interoperability-1 Janet -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of A. Jean Mahoney Sent: Tuesday, July 18, 2017 9:42 AM To: dime@ietf.org Subject: [Dime] 99 IETF DIME session notes Hi all, Below are my notes from the session yesterday. Thanks! Jean ---------------------------------------------------------------------------= ---------------- IETF-99 DIME 1740-1840 July 17, 2017, Monday Afternoon session III meeting room: Karlin= III Jabber room: dime at jabber.ietf.org (Please join) Chairs:Jouni Korhonen, Lionel Morand AD: Ben Campbell 17:40 - 17:45, Preliminaries, Chairs (5 minutes) ------------------------------------------ Presentation: https://www.ietf.org/proceedings/99/slides/slides-99-dime-agenda-wg-status-= 00.pdf slide 1: Title Lionel Morand: Jouni is not able to make it to the meeting. slide 2: Note Well slide 3: Agenda Note taker/Jabber scribe: Jean Mahoney Martin Dolly: when will Diameter security discussion happen? Lionel: end of the session. 17:45 - 17:50, WG Document Status, Chairs (5 minutes) ------------------------------------------ *draft-ietf-dime-agent-overload-11 --> RFC Ed Queue *draft-ietf-dime-doic-rate-control-06 --> Waiting for Write-Up *draft-ietf-dime-group-signaling-08 --> In WG Last Call *draft-ietf-dime-load-09 --> RFC Ed Queue *draft-ietf-dime-rfc4006bis-03 --> In WG Last Call slide 4: WG Status Update Lionel: Both overload and load are in the RFC editor queue due to a MISREF.= I'll take care of it after this meeting. Steve Donovan: Just a nit on the slide - I'm the editor on load information= , I'm not the editor for 4006bis. Lionel: Group signaling - the author's think it's ready. We need more revie= ws. Marco? Marco Liebsch: we've updated it before Chicago. We've covered all comments.= Is ready for expert review. Lionel: we've received a good technical review from Steve. Needs another be= fore WGLC. Rate control is missing its writeup. Steve: Has it finished WGLC? Lionel: Yes, needs writeup. Rate-control didn't receive a deep technical re= view. Need further review. From SA5 guys in 3GPP, since they are the main u= sers. slide 5: WG Status update (2/2) Lionel: AVP level security (e2e) draft has expired - Jouni is not able to s= upport the workload alone. I will go to the SAAG meeting and will ask for s= upport from security experts. Solution doesn't have to be Diameter specific= . Ben Campbell: I would personally like to see this completed. Who will deplo= y it? Martin Dolly: next round of FCC sys req, they just finished looking at SS7 security vulnerabilities, next 2 years they'll look at Diameter. SA3 co= ming up in 3 weeks. I'll give them discussion paper, a status update of wor= k here. It gets friendly talk there. It's been discussed with regard to 5G = and security system. It's now or never, forever-hold-your-peace time. Lionel: GSMA would like a recommendation. If it's easy to implement, we hav= e ongoing deployment. Ben: They are welcome to come here and help. Eric Guttman: for mission-critical deployments, there are 2 security domain= s - operator domain and mission-critical operator domain. We've looked at s= ecuring at a message or component to a SIP message level. The message has t= o be e2e secure between client and host at the mission-critical ISP. Are th= ere AAA requirements where you can't expose certain AVPs to the operator? N= eed to check. Lionel: From the requirements POV, both should be available with the soluti= on. Normally you would only be able to secure signaling between gateways fo= r instance. You may have e2e secure exchange between any Diameter client an= d any Diameter server. Martin: I don't think that's a case. 401 specifies that equipment manufactu= rers must support IPsec for communication within the EPC, but says it optio= nal to deploy. No one has deployed. For 5G, the European operators are figh= ting pulling the security into the EPC not at the ENodeB. Some of those sta= tements aren't true. Lionel: Ben, you see there is some interest. We would like to see this work= done in IETF. Ben: I observe an interest in using the work. I need to observe interest in= doing the work. Maybe SAAG will help. Lionel: It's more a security discussion than a Diameter discussion. Need he= lp from security area. Eric: There was a mechanism for using an SMIME encapsulation. That became h= istoric? Lionel: deprecated. A new mechanism will be defined outside the base protoc= ol. All new drafts are based on this. 17:50 - 18:35 Individual draft discussions (45 minutes) ------------------------------------------- 17:50 - 18:10 Diameter Policy Groups and Sets, Lyle (20min) Draft: https://tools.ietf.org/html/draft-bertz-dime-predictunits-02 Draft: https://tools.ietf.org/html/draft-bertz-dime-policygroups-04 Presentation: https://www.ietf.org/proceedings/99/slides/slides-99-dime-predicted-units-p= olicy-groups-00.pdf slide 1: Title slide 2: Predicted Units v02 - Motivation Lyle: It takes 3-4 minutes to spin up a VM. slide 3: Predicted Units v02 - Update Lyle: Have not received any new updates. I would like to ask for adoption. Lionel: Who has read? I wasn't in the last meeting what was the feeling in the room? Ben: Besides the chair and the AD? Jean: About 7 people total. Lionel: I've read it and understood the mechanism, which is good. Check on the ML if there is support for adoption. There's not much to do on this doc. slide 4: Intermission slide 5: Purpose slide 6: Policy Groups - Update slide 7: Relationship Model slide 8: Policy Groups Example 1, Overlap Deduplication at Enforcement Point - Adding Membership Assignment to Filters Lyle: SDN switches have limitations of tables (13 tables in OpenFlow). Can concatenate tables. The rules no longer overlap. How to use your metadata field and tie it back to a customer? slide 9: Policy Groups Example 2, Application at the Decision Point Process Lyle: We don't change the user's relationship to their services mid-session. Usually reauthorize them before doing that. slide 10: Applications slide 11: Next Steps Lyle: Would like to hear more from the group before asking for adoption. Lionel: who has read? Lionel: Go back to the Purpose slide. Lyle: didn't want to confuse people but wanted a similar aggregation concept with backwards compatibility. It's similar to ... It's a membership domain. Lionel: I need to review it again. It would be useful to have more review. Lyle: I'm not happy with the examples, I'd like them to be consistent through the doc. Lionel: the draft needs to clearly identify why you can't do this with existing mechanisms. Lyle: all of our filters are based on time and what's in the packets. When the time is the same and the rule is a default rule, that's the most overlap in the system. Lionel: It's not that clear from the creation of AVP, be good to describe it. 18:10 - 18:35 Diameter Specification Recommendations, Lyle (25min) Draft: https://tools.ietf.org/html/draft-bertz-dime-diamimpr-00 Pres: https://www.ietf.org/proceedings/99/slides/slides-99-dime-diameter-specific= ation-recommendations-00.pdf slide 1: Title slide 2: Motivation Lyle: 85% of the time, errors due to ambiguity. slide 3: Findings Eric Guttman: send this to SA5 charging if you have a delegate. Lyle: we don't, but wanted to get it out. slide 4: Methodology slide 5: Unexpected Use Cases slide 6: We are not immune slide 7: Enumerations slide 8: Recommendations slide 9: Defined AVP Recommendations slide 10: Defined AVPs Recommended Formats slide 11: Imported AVP Recommendations slide 12: Grouped AVP / Command Refinement slide 13: Example Refinement slide 14: Command Recommendations slide 15: Enumeration Recommendations slide 16: GAPs for Automated Validation slide 17: Example to Close Gaps slide 18: Enumeration Example Format slide 19: Open Questions slide 20: Summary slide 21: Next steps Lionel: who has read? (Three people raised hands) Lyle: Dave Dolson and Jouni read it. Lionel: in 3GPP it's not really refinement, because in 3GPP just highlight the AVPs they use. We you take a specification and not reading anything - Lyle: they want to just write the code and be done. Lionel: For new drafts, it should be taken into consideration. For existing RFCs, these are documentation errors. When it's clarification, it needs to go through the errata process. For the 3GPP specs, CRs need to be opened. Lyle: This has a lot of errors documented. Would this be informational? How would it progress? Lionel: It can be informational, and can be referenced by other docs. No guideline here. Just highlight what could go wrong. Lyle: I would change the style. Make it more of a report. Lionel: It's not unusual for the IETF to explain issues with implementations. 18:35 - 18:40 Wrap-up and Next, Chairs/AD (5 minutes) ----------------------------- WG Goals/Milestones status - skipped Next steps/Action Points - Future of the WG Lionel: We have 3 remaining documents. Ben: And two that you are thinking of adopting. Lionel: few people in room, not much activity on the list. I won't be able to continue with the chair position - too much work in the 3GPP. Same with Jouni - he changed companies, won't be able to continue. What is the next step except closing the group? Ben: The existing documents are post or near WGLC. Those can be in the hands of the ADs before long. What's you're time frame for needing to step down? Lionel: I need to know when to stop adopting new documents. Even for Jouni. Ben: Of the 2 drafts for the adoption - the predictive units can be AD sponsored. The group one is on the border, a little more complex. I don't have to be the AD that sponsors it. Lionel: For the group one, I need to see more interest. Ben: even if I AD sponsor, I want someone to review them. Lionel: E2E security needs to be done. If we get volunteers from SAAG. Ben: lets see what happens in SAAG. If there's interest - maybe we can spin up some mini-group. Or just speculating here - recharter dime with new chairs to just do that. Lionel: If it is only to go with existing drafts, I think it can be done in short timeframe. Need to confirm with Jouni. Defining new charter with new chairs may not be useful. Ben: E2E security may go into the security area. Lionel: Are there any other comments? (none from the room). To summarize - existing WG documents will be pushed forward. For predictive units, confirm on ML that it's a WG doc, for the group one, we'll check. After those documents, we'll close the WG. Ben: Those 2 new drafts - predictive definitely and maybe group - can be AD sponsored. They can still change to AD sponsorship if we need to close the working group sooner. I'm skeptical of bringing new work into the group, unless we see interest. Lionel: Thank you. ACTION: Chairs to push existing WG documents forward. ACTION: Lionel to bring the e2e security draft to the SAAG session this week to ask for support in finishing it. ACTION: Confirm interest on mailing list for adopting draft-bertz-dime-predictunits. ACTION: Confirm interest on mailing list for adopting draft-bertz-dime-policygroups. ACTION: Ben to look more closely at draft-bertz-dime-policygroups as a candidate for AD sponsorship. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime This electronic message transmission contains information from CSRA that ma= y be attorney-client privileged, proprietary or confidential. The informati= on in this message is intended only for use by the individual(s) to whom it= is addressed. If you believe you have received this message in error, plea= se contact me immediately and be aware that any use, disclosure, copying or= distribution of the contents of this message is strictly prohibited. NOTE:= Regardless of content, this email shall not operate to bind CSRA to any or= der or other contract unless pursuant to explicit written agreement or gove= rnment initiative expressly permitting the use of email for such purpose. From nobody Tue Jul 18 07:58:29 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFF11204DA for ; Tue, 18 Jul 2017 07:58:27 -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, FREEMAIL_FROM=0.001, 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=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 7CZkG5oddtG9 for ; Tue, 18 Jul 2017 07:58:23 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 0B2D512ECBC for ; Tue, 18 Jul 2017 07:58:23 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id d78so12085441lfg.3 for ; Tue, 18 Jul 2017 07:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZsRzxflDDEmlPzfDnN70IcZSRWn6tygNtTVXD+0Y804=; b=OBYsteXS0+bXw74cTN2o51F2scKFoqMHDVsPAHojGN1VhQcouRiPtkDX7c7+GeOyDH vVfwYPxs/IEVcWtoGuqYcIZ2B+mf4AK4YFD/HECvPvVBpzx8tWEFcnvxAeOkB4Kzb5wc RkNUqg4dBEyHOsFLaJVimxeSRx5cxP4+V62i8p4eohU7FNC8k1dmIfpbnMwS0PyZIdWT Sp+ZZSJPXGKv+hfU5OCCDfxL1wyYpZDPjEa7bXczn2rtg52VInSLBbAZbbfVzdXm+27l c9Msv7kyw2nPATwSL2gBP6+6rZeBhDqrj6MeR09ut4gg64a/0WqL9WZ61kDLEybNtYCg NkgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZsRzxflDDEmlPzfDnN70IcZSRWn6tygNtTVXD+0Y804=; b=Rfdzo6jf3i0pH5RGNPl/sm995YzVedoMU7GwhzLMZt9+T1z749CClIuVH7mY7mFWc6 pJT4/SrppPGteJrnsOoXdQbUZlnQ+1IojHnpcpggBNlAQuZ2uzbtnZK76llostJqsL2Z 8t/DroktGQpM7FU504aGOHooOFkgyF04u0xyJ+zHvpNVGEK7xhYbAKRyXPoNGg/tcynH K/lcJvzYINuCgA7m2Y8mR/fJIs+xnI/oQeX5rDcwflfWDXE1E8KxA5OdyWTpUTQBdAXW M8sqtqnYfYA8yyCvA0fWCT9326UUf4S2KdpXlztOr238bO/mw8QJDlc64EeQRiiow/Bj Fhow== X-Gm-Message-State: AIVw110dJCGHigiTUlDU8KU91Ae0GGoFcSy7bH1VOkKo33jBh6rMrQUb 2cw7bvH85gxFE02VQyYcrRAk4vuxFg== X-Received: by 10.25.103.19 with SMTP id b19mr925036lfc.80.1500389901270; Tue, 18 Jul 2017 07:58:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.20.193 with HTTP; Tue, 18 Jul 2017 07:58:20 -0700 (PDT) In-Reply-To: <7278718efbb946b8adb89c7306cced30@CSRRDU1EXM025.corp.csra.com> References: <9ec38b25-41d4-a751-aa97-d8af0f9022c5@nostrum.com> <7278718efbb946b8adb89c7306cced30@CSRRDU1EXM025.corp.csra.com> From: Misha Zaytsev Date: Tue, 18 Jul 2017 17:58:20 +0300 Message-ID: To: "Gunn, Janet P" Cc: "A. Jean Mahoney" , "dime@ietf.org" Content-Type: multipart/alternative; boundary="f403045e92541704ac055498bf6d" Archived-At: Subject: Re: [Dime] 99 IETF DIME session notes X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 14:58:27 -0000 --f403045e92541704ac055498bf6d Content-Type: text/plain; charset="UTF-8" Hi All, May I wonder about e2e security draft mentioned in the MoM? Where can I find it? Thanks in advance! /Misha 2017-07-18 17:53 GMT+03:00 Gunn, Janet P : > Nit > In Martin's statement, I think "FCC sys rec" should be "FCC CSRIC" > https://www.fcc.gov/about-fcc/advisory-committees/communications-security- > reliability-and-interoperability-1 > > Janet > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of A. Jean Mahoney > Sent: Tuesday, July 18, 2017 9:42 AM > To: dime@ietf.org > Subject: [Dime] 99 IETF DIME session notes > > Hi all, > > Below are my notes from the session yesterday. > > Thanks! > > Jean > > > ------------------------------------------------------------ > ------------------------------- > > IETF-99 DIME > > 1740-1840 July 17, 2017, Monday Afternoon session III meeting room: > Karlin III Jabber room: dime at jabber.ietf.org (Please join) > > Chairs:Jouni Korhonen, Lionel Morand > AD: Ben Campbell > > 17:40 - 17:45, Preliminaries, Chairs (5 minutes) > ------------------------------------------ > Presentation: > https://www.ietf.org/proceedings/99/slides/slides- > 99-dime-agenda-wg-status-00.pdf > > slide 1: Title > > Lionel Morand: Jouni is not able to make it to the meeting. > > slide 2: Note Well > > slide 3: Agenda > > Note taker/Jabber scribe: Jean Mahoney > > Martin Dolly: when will Diameter security discussion happen? > > Lionel: end of the session. > > > 17:45 - 17:50, WG Document Status, Chairs (5 minutes) > ------------------------------------------ > > *draft-ietf-dime-agent-overload-11 --> RFC Ed Queue > *draft-ietf-dime-doic-rate-control-06 --> Waiting for Write-Up > *draft-ietf-dime-group-signaling-08 --> In WG Last Call > *draft-ietf-dime-load-09 --> RFC Ed Queue > *draft-ietf-dime-rfc4006bis-03 --> In WG Last Call > > slide 4: WG Status Update > > Lionel: Both overload and load are in the RFC editor queue due to a > MISREF. I'll take care of it after this meeting. > > Steve Donovan: Just a nit on the slide - I'm the editor on load > information, I'm not the editor for 4006bis. > > Lionel: Group signaling - the author's think it's ready. We need more > reviews. Marco? > > Marco Liebsch: we've updated it before Chicago. We've covered all > comments. Is ready for expert review. > > Lionel: we've received a good technical review from Steve. Needs another > before WGLC. Rate control is missing its writeup. > > Steve: Has it finished WGLC? > > Lionel: Yes, needs writeup. Rate-control didn't receive a deep technical > review. Need further review. From SA5 guys in 3GPP, since they are the main > users. > > slide 5: WG Status update (2/2) > > Lionel: AVP level security (e2e) draft has expired - Jouni is not able to > support the workload alone. I will go to the SAAG meeting and will ask for > support from security experts. Solution doesn't have to be Diameter > specific. > > Ben Campbell: I would personally like to see this completed. Who will > deploy it? > > Martin Dolly: next round of FCC sys req, they just finished looking at > SS7 security vulnerabilities, next 2 years they'll look at Diameter. SA3 > coming up in 3 weeks. I'll give them discussion paper, a status update of > work here. It gets friendly talk there. It's been discussed with regard to > 5G and security system. It's now or never, forever-hold-your-peace time. > > Lionel: GSMA would like a recommendation. If it's easy to implement, we > have ongoing deployment. > > Ben: They are welcome to come here and help. > > Eric Guttman: for mission-critical deployments, there are 2 security > domains - operator domain and mission-critical operator domain. We've > looked at securing at a message or component to a SIP message level. The > message has to be e2e secure between client and host at the > mission-critical ISP. Are there AAA requirements where you can't expose > certain AVPs to the operator? Need to check. > > Lionel: From the requirements POV, both should be available with the > solution. Normally you would only be able to secure signaling between > gateways for instance. You may have e2e secure exchange between any > Diameter client and any Diameter server. > > Martin: I don't think that's a case. 401 specifies that equipment > manufacturers must support IPsec for communication within the EPC, but says > it optional to deploy. No one has deployed. For 5G, the European operators > are fighting pulling the security into the EPC not at the ENodeB. Some of > those statements aren't true. > > Lionel: Ben, you see there is some interest. We would like to see this > work done in IETF. > > Ben: I observe an interest in using the work. I need to observe interest > in doing the work. Maybe SAAG will help. > > Lionel: It's more a security discussion than a Diameter discussion. Need > help from security area. > > Eric: There was a mechanism for using an SMIME encapsulation. That became > historic? > > Lionel: deprecated. A new mechanism will be defined outside the base > protocol. All new drafts are based on this. > > > > 17:50 - 18:35 Individual draft discussions (45 minutes) > ------------------------------------------- > > 17:50 - 18:10 Diameter Policy Groups and Sets, Lyle (20min) > Draft: https://tools.ietf.org/html/draft-bertz-dime-predictunits-02 > Draft: https://tools.ietf.org/html/draft-bertz-dime-policygroups-04 > Presentation: > https://www.ietf.org/proceedings/99/slides/slides-99-dime-predicted-units- > policy-groups-00.pdf > > > slide 1: Title > > slide 2: Predicted Units v02 - Motivation > > Lyle: It takes 3-4 minutes to spin up a VM. > > slide 3: Predicted Units v02 - Update > > Lyle: Have not received any new updates. I would like to ask for adoption. > > Lionel: Who has read? I wasn't in the last meeting what was the feeling > in the room? > > Ben: Besides the chair and the AD? > > Jean: About 7 people total. > > Lionel: I've read it and understood the mechanism, which is good. Check > on the ML if there is support for adoption. There's not much to do on > this doc. > > slide 4: Intermission > > slide 5: Purpose > > slide 6: Policy Groups - Update > > slide 7: Relationship Model > > slide 8: Policy Groups Example 1, Overlap Deduplication at Enforcement > Point - Adding Membership Assignment to Filters > > Lyle: SDN switches have limitations of tables (13 tables in OpenFlow). > Can concatenate tables. The rules no longer overlap. How to use your > metadata field and tie it back to a customer? > > slide 9: Policy Groups Example 2, Application at the Decision Point Process > > Lyle: We don't change the user's relationship to their services > mid-session. Usually reauthorize them before doing that. > > slide 10: Applications > > slide 11: Next Steps > > Lyle: Would like to hear more from the group before asking for adoption. > > Lionel: who has read? > > Lionel: Go back to the Purpose slide. > > Lyle: didn't want to confuse people but wanted a similar aggregation > concept with backwards compatibility. It's similar to ... It's a > membership domain. > > Lionel: I need to review it again. It would be useful to have more review. > > Lyle: I'm not happy with the examples, I'd like them to be consistent > through the doc. > > Lionel: the draft needs to clearly identify why you can't do this with > existing mechanisms. > > Lyle: all of our filters are based on time and what's in the packets. > When the time is the same and the rule is a default rule, that's the > most overlap in the system. > > Lionel: It's not that clear from the creation of AVP, be good to > describe it. > > > 18:10 - 18:35 Diameter Specification Recommendations, Lyle (25min) > Draft: https://tools.ietf.org/html/draft-bertz-dime-diamimpr-00 > Pres: > https://www.ietf.org/proceedings/99/slides/slides-99-dime-diameter- > specification-recommendations-00.pdf > > slide 1: Title > > slide 2: Motivation > > Lyle: 85% of the time, errors due to ambiguity. > > slide 3: Findings > > Eric Guttman: send this to SA5 charging if you have a delegate. > > Lyle: we don't, but wanted to get it out. > > slide 4: Methodology > > slide 5: Unexpected Use Cases > > slide 6: We are not immune > > slide 7: Enumerations > > slide 8: Recommendations > > slide 9: Defined AVP Recommendations > > slide 10: Defined AVPs Recommended Formats > > slide 11: Imported AVP Recommendations > > slide 12: Grouped AVP / Command Refinement > > slide 13: Example Refinement > > slide 14: Command Recommendations > > slide 15: Enumeration Recommendations > > slide 16: GAPs for Automated Validation > > slide 17: Example to Close Gaps > > slide 18: Enumeration Example Format > > slide 19: Open Questions > > slide 20: Summary > > slide 21: Next steps > > Lionel: who has read? (Three people raised hands) > > Lyle: Dave Dolson and Jouni read it. > > Lionel: in 3GPP it's not really refinement, because in 3GPP just > highlight the AVPs they use. We you take a specification and not reading > anything - > > Lyle: they want to just write the code and be done. > > Lionel: For new drafts, it should be taken into consideration. For > existing RFCs, these are documentation errors. When it's clarification, > it needs to go through the errata process. For the 3GPP specs, CRs need > to be opened. > > Lyle: This has a lot of errors documented. Would this be informational? > How would it progress? > > Lionel: It can be informational, and can be referenced by other docs. No > guideline here. Just highlight what could go wrong. > > Lyle: I would change the style. Make it more of a report. > > Lionel: It's not unusual for the IETF to explain issues with > implementations. > > > 18:35 - 18:40 Wrap-up and Next, Chairs/AD (5 minutes) > ----------------------------- > > WG Goals/Milestones status - skipped > > Next steps/Action Points - Future of the WG > > Lionel: We have 3 remaining documents. > > Ben: And two that you are thinking of adopting. > > Lionel: few people in room, not much activity on the list. I won't be > able to continue with the chair position - too much work in the 3GPP. > Same with Jouni - he changed companies, won't be able to continue. What > is the next step except closing the group? > > Ben: The existing documents are post or near WGLC. Those can be in the > hands of the ADs before long. What's you're time frame for needing to > step down? > > Lionel: I need to know when to stop adopting new documents. Even for Jouni. > > Ben: Of the 2 drafts for the adoption - the predictive units can be AD > sponsored. The group one is on the border, a little more complex. I > don't have to be the AD that sponsors it. > > Lionel: For the group one, I need to see more interest. > > Ben: even if I AD sponsor, I want someone to review them. > > Lionel: E2E security needs to be done. If we get volunteers from SAAG. > > Ben: lets see what happens in SAAG. If there's interest - maybe we can > spin up some mini-group. Or just speculating here - recharter dime with > new chairs to just do that. > > Lionel: If it is only to go with existing drafts, I think it can be done > in short timeframe. Need to confirm with Jouni. Defining new charter > with new chairs may not be useful. > > Ben: E2E security may go into the security area. > > Lionel: Are there any other comments? (none from the room). To summarize > - existing WG documents will be pushed forward. For predictive units, > confirm on ML that it's a WG doc, for the group one, we'll check. After > those documents, we'll close the WG. > > Ben: Those 2 new drafts - predictive definitely and maybe group - can be > AD sponsored. They can still change to AD sponsorship if we need to > close the working group sooner. I'm skeptical of bringing new work into > the group, unless we see interest. > > Lionel: Thank you. > > ACTION: Chairs to push existing WG documents forward. > > ACTION: Lionel to bring the e2e security draft to the SAAG session this > week to ask for support in finishing it. > > ACTION: Confirm interest on mailing list for adopting > draft-bertz-dime-predictunits. > > ACTION: Confirm interest on mailing list for adopting > draft-bertz-dime-policygroups. > > ACTION: Ben to look more closely at draft-bertz-dime-policygroups as a > candidate for AD sponsorship. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > This electronic message transmission contains information from CSRA that > may be attorney-client privileged, proprietary or confidential. The > information in this message is intended only for use by the individual(s) > to whom it is addressed. If you believe you have received this message in > error, please contact me immediately and be aware that any use, disclosure, > copying or distribution of the contents of this message is strictly > prohibited. NOTE: Regardless of content, this email shall not operate to > bind CSRA to any order or other contract unless pursuant to explicit > written agreement or government initiative expressly permitting the use of > email for such purpose. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --f403045e92541704ac055498bf6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

May I wonder abou= t e2e security draft mentioned in the MoM? Where can I find it?
Thanks in advance!

/Misha


2017-07-18 17:53 GMT+03:00 Gunn,= Janet P <Janet.Gunn@csra.com>:
Nit
In Martin's statement, I think=C2=A0 "FCC sys rec" should be = "FCC CSRIC"
https://www.fcc.gov/about-fcc/advisory-committees/communi= cations-security-reliability-and-interoperability-1

Janet


-----Original Message-----
From: DiME [mailto:dime-bounces@ie= tf.org] On Behalf Of A. Jean Mahoney
Sent: Tuesday, July 18, 2017 9:42 AM
To: dime@ietf.org
Subject: [Dime] 99 IETF DIME session notes

Hi all,

Below are my notes from the session yesterday.

Thanks!

Jean


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

IETF-99 DIME

1740-1840=C2=A0 July 17, 2017, Monday Afternoon session III meeting room: K= arlin III Jabber room: dime at jabber.ietf.org (Please join)

Chairs:Jouni Korhonen, Lionel Morand
AD: Ben Campbell

17:40 - 17:45, Preliminaries, Chairs (5 minutes)
------------------------------------------
Presentation:
https://www.ietf.or= g/proceedings/99/slides/slides-99-dime-agenda-wg-status-00.p= df

slide 1: Title

Lionel Morand: Jouni is not able to make it to the meeting.

slide 2: Note Well

slide 3: Agenda

Note taker/Jabber scribe: Jean Mahoney

Martin Dolly: when will Diameter security discussion happen?

Lionel: end of the session.


17:45 - 17:50, WG Document Status, Chairs (5 minutes)
------------------------------------------

*draft-ietf-dime-agent-overload-11=C2=A0 =C2=A0 --> RFC Ed Queue *draft-ietf-dime-doic-rate-control-06 --> Waiting for Write-Up
*draft-ietf-dime-group-signaling-08=C2=A0 =C2=A0--> In WG Last Call=
*draft-ietf-dime-load-09=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --= > RFC Ed Queue
*draft-ietf-dime-rfc4006bis-03=C2=A0 =C2=A0 =C2=A0 =C2=A0 --> In WG Last= Call

slide 4: WG Status Update

Lionel: Both overload and load are in the RFC editor queue due to a MISREF.= I'll take care of it after this meeting.

Steve Donovan: Just a nit on the slide - I'm the editor on load informa= tion, I'm not the editor for 4006bis.

Lionel: Group signaling - the author's think it's ready. We need mo= re reviews. Marco?

Marco Liebsch: we've updated it before Chicago. We've covered all c= omments. Is ready for expert review.

Lionel: we've received a good technical review from Steve. Needs anothe= r before WGLC. Rate control is missing its writeup.

Steve: Has it finished WGLC?

Lionel: Yes, needs writeup. Rate-control didn't receive a deep technica= l review. Need further review. From SA5 guys in 3GPP, since they are the ma= in users.

slide 5: WG Status update (2/2)

Lionel: AVP level security (e2e) draft has expired - Jouni is not able to s= upport the workload alone. I will go to the SAAG meeting and will ask for s= upport from security experts. Solution doesn't have to be Diameter spec= ific.

Ben Campbell: I would personally like to see this completed. Who will deplo= y it?

Martin Dolly: next round of FCC sys req, they just finished looking at
SS7 security vulnerabilities, next 2 years they'll look at Diameter. SA= 3 coming up in 3 weeks. I'll give them discussion paper, a status updat= e of work here. It gets friendly talk there. It's been discussed with r= egard to 5G and security system. It's now or never, forever-hold-your-p= eace time.

Lionel: GSMA would like a recommendation. If it's easy to implement, we= have ongoing deployment.

Ben: They are welcome to come here and help.

Eric Guttman: for mission-critical deployments, there are 2 security domain= s - operator domain and mission-critical operator domain. We've looked = at securing at a message or component to a SIP message level. The message h= as to be e2e secure between client and host at the mission-critical ISP. Ar= e there AAA requirements where you can't expose certain AVPs to the ope= rator? Need to check.

Lionel: From the requirements POV, both should be available with the soluti= on. Normally you would only be able to secure signaling between gateways fo= r instance. You may have e2e secure exchange between any Diameter client an= d any Diameter server.

Martin: I don't think that's a case. 401 specifies that equipment m= anufacturers must support IPsec for communication within the EPC, but says = it optional to deploy. No one has deployed. For 5G, the European operators = are fighting pulling the security into the EPC not at the ENodeB. Some of t= hose statements aren't true.

Lionel: Ben, you see there is some interest. We would like to see this work= done in IETF.

Ben: I observe an interest in using the work. I need to observe interest in= doing the work. Maybe SAAG will help.

Lionel: It's more a security discussion than a Diameter discussion. Nee= d help from security area.

Eric: There was a mechanism for using an SMIME encapsulation. That became h= istoric?

Lionel: deprecated. A new mechanism will be defined outside the base protoc= ol. All new drafts are based on this.



17:50 - 18:35 Individual draft discussions (45 minutes)
-------------------------------------------

17:50 - 18:10 Diameter Policy Groups and Sets, Lyle (20min)
=C2=A0 =C2=A0Draft: https://tools.ietf.o= rg/html/draft-bertz-dime-predictunits-02
=C2=A0 =C2=A0Draft: https://tools.ietf.o= rg/html/draft-bertz-dime-policygroups-04
=C2=A0 =C2=A0Presentation:
https:= //www.ietf.org/proceedings/99/slides/slides-99-dime-predicted-uni= ts-policy-groups-00.pdf


slide 1: Title

slide 2: Predicted Units v02 - Motivation

Lyle: It takes 3-4 minutes to spin up a VM.

slide 3: Predicted Units v02 - Update

Lyle: Have not received any new updates. I would like to ask for adoption.<= br>
Lionel: Who has read? I wasn't in the last meeting what was the feeling=
in the room?

Ben: Besides the chair and the AD?

Jean: About 7 people total.

Lionel: I've read it and understood the mechanism, which is good. Check=
on the ML if there is support for adoption. There's not much to do on this doc.

slide 4: Intermission

slide 5: Purpose

slide 6: Policy Groups - Update

slide 7: Relationship Model

slide 8: Policy Groups Example 1, Overlap Deduplication at Enforcement
Point - Adding Membership Assignment to Filters

Lyle: SDN switches have limitations of tables (13 tables in OpenFlow).
Can concatenate tables. The rules no longer overlap. How to use your
metadata field and tie it back to a customer?

slide 9: Policy Groups Example 2, Application at the Decision Point Process=

Lyle: We don't change the user's relationship to their services
mid-session. Usually reauthorize them before doing that.

slide 10: Applications

slide 11: Next Steps

Lyle: Would like to hear more from the group before asking for adoption.
Lionel: who has read?

Lionel: Go back to the Purpose slide.

Lyle: didn't want to confuse people but wanted a similar aggregation concept with backwards compatibility. It's similar to ... It's a membership domain.

Lionel: I need to review it again. It would be useful to have more review.<= br>
Lyle: I'm not happy with the examples, I'd like them to be consiste= nt
through the doc.

Lionel: the draft needs to clearly identify why you can't do this with<= br> existing mechanisms.

Lyle: all of our filters are based on time and what's in the packets. When the time is the same and the rule is a default rule, that's the most overlap in the system.

Lionel: It's not that clear from the creation of AVP, be good to
describe it.


18:10 - 18:35 Diameter Specification Recommendations, Lyle (25min)
=C2=A0 =C2=A0Draft: https://tools.ietf.org/h= tml/draft-bertz-dime-diamimpr-00
=C2=A0 =C2=A0Pres:
https://www.ietf.org/proceedings/99/slides/slides-99-dime-diam= eter-specification-recommendations-00.pdf

slide 1: Title

slide 2: Motivation

Lyle: 85% of the time, errors due to ambiguity.

slide 3: Findings

Eric Guttman: send this to SA5 charging if you have a delegate.

Lyle: we don't, but wanted to get it out.

slide 4: Methodology

slide 5: Unexpected Use Cases

slide 6: We are not immune

slide 7: Enumerations

slide 8: Recommendations

slide 9: Defined AVP Recommendations

slide 10: Defined AVPs Recommended Formats

slide 11: Imported AVP Recommendations

slide 12: Grouped AVP / Command Refinement

slide 13: Example Refinement

slide 14: Command Recommendations

slide 15: Enumeration Recommendations

slide 16: GAPs for Automated Validation

slide 17: Example to Close Gaps

slide 18: Enumeration Example Format

slide 19: Open Questions

slide 20: Summary

slide 21:=C2=A0 Next steps

Lionel: who has read? (Three people raised hands)

Lyle: Dave Dolson and Jouni read it.

Lionel: in 3GPP it's not really refinement, because in 3GPP just
highlight the AVPs they use. We you take a specification and not reading anything -

Lyle: they want to just write the code and be done.

Lionel: For new drafts, it should be taken into consideration. For
existing RFCs, these are documentation errors. When it's clarification,=
it needs to go through the errata process. For the 3GPP specs, CRs need
to be opened.

Lyle: This has a lot of errors documented. Would this be informational?
How would it progress?

Lionel: It can be informational, and can be referenced by other docs. No guideline here. Just highlight what could go wrong.

Lyle: I would change the style. Make it more of a report.

Lionel: It's not unusual for the IETF to explain issues with
implementations.


18:35 - 18:40 Wrap-up and Next, Chairs/AD (5 minutes)
-----------------------------

WG Goals/Milestones status - skipped

Next steps/Action Points - Future of the WG

Lionel: We have 3 remaining documents.

Ben: And two that you are thinking of adopting.

Lionel: few people in room, not much activity on the list. I won't be able to continue with the chair position - too much work in the 3GPP.
Same with Jouni - he changed companies, won't be able to continue. What=
is the next step except closing the group?

Ben: The existing documents are post or near WGLC. Those can be in the
hands of the ADs before long. What's you're time frame for needing = to
step down?

Lionel: I need to know when to stop adopting new documents. Even for Jouni.=

Ben: Of the 2 drafts for the adoption - the predictive units can be AD
sponsored. The group one is on the border, a little more complex. I
don't have to be the AD that sponsors it.

Lionel: For the group one, I need to see more interest.

Ben: even if I AD sponsor, I want someone to review them.

Lionel: E2E security needs to be done. If we get volunteers from SAAG.

Ben: lets see what happens in SAAG. If there's interest - maybe we can<= br> spin up some mini-group. Or just speculating here - recharter dime with
new chairs to just do that.

Lionel: If it is only to go with existing drafts, I think it can be done in short timeframe. Need to confirm with Jouni. Defining new charter
with new chairs may not be useful.

Ben: E2E security may go into the security area.

Lionel: Are there any other comments? (none from the room). To summarize - existing WG documents will be pushed forward. For predictive units,
confirm on ML that it's a WG doc, for the group one, we'll check. A= fter
those documents, we'll close the WG.

Ben: Those 2 new drafts - predictive definitely and maybe group - can be AD sponsored. They can still change to AD sponsorship if we need to
close the working group sooner. I'm skeptical of bringing new work into=
the group, unless we see interest.

Lionel: Thank you.

ACTION: Chairs to push existing WG documents forward.

ACTION: Lionel to bring the e2e security draft to the SAAG session this
week to ask for support in finishing it.

ACTION: Confirm interest on mailing list for adopting
draft-bertz-dime-predictunits.

ACTION: Confirm interest on mailing list for adopting
draft-bertz-dime-policygroups.

ACTION: Ben to look more closely at draft-bertz-dime-policygroups as a
candidate for AD sponsorship.

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

This electronic message transmission contains information from = CSRA that may be attorney-client privileged, proprietary or confidential. T= he information in this message is intended only for use by the individual(s= ) to whom it is addressed. If you believe you have received this message in= error, please contact me immediately and be aware that any use, disclosure= , copying or distribution of the contents of this message is strictly prohi= bited. NOTE: Regardless of content, this email shall not operate to bind CS= RA to any order or other contract unless pursuant to explicit written agree= ment or government initiative expressly permitting the use of email for suc= h purpose.

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

--f403045e92541704ac055498bf6d-- From nobody Tue Jul 18 08:42:38 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32EC131B46 for ; Tue, 18 Jul 2017 08:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 BgsAmERlv6t2 for ; Tue, 18 Jul 2017 08:42:33 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75DAB131A7E for ; Tue, 18 Jul 2017 08:42:33 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 28F72180655; Tue, 18 Jul 2017 17:42:32 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id E88B81A00B3; Tue, 18 Jul 2017 17:42:31 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0352.000; Tue, 18 Jul 2017 17:42:31 +0200 From: To: Misha Zaytsev , "Gunn, Janet P" CC: "dime@ietf.org" Thread-Topic: =?iso-8859-1?Q?RE=A0:_Re:_[Dime]_99_IETF_DIME_session_notes?= Thread-Index: AQHS/9x3x5bv7ftmsE+GPXQIxiy6Rw== Date: Tue, 18 Jul 2017 15:42:30 +0000 Message-ID: <10505_1500392552_596E2C68_10505_41_1_6B7134B31289DC4FAF731D844122B36E2D1B82FB@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <9ec38b25-41d4-a751-aa97-d8af0f9022c5@nostrum.com> <7278718efbb946b8adb89c7306cced30@CSRRDU1EXM025.corp.csra.com>, In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E2D1B82FBOPEXCLILM43corp_" MIME-Version: 1.0 Archived-At: Subject: [Dime] =?iso-8859-1?q?RE=A0=3A_Re=3A__99_IETF_DIME_session_notes?= X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 15:42:37 -0000 --_000_6B7134B31289DC4FAF731D844122B36E2D1B82FBOPEXCLILM43corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The draft has expired but is still available: https://tools.ietf.org/html/draft-korhonen-dime-e2e-security-03 Regards, Lionel Envoy=E9 de mon Orange Nura 2 Le 18 juil. 2017 16:58, Misha Zaytsev a =E9cr= it : Hi All, May I wonder about e2e security draft mentioned in the MoM? Where can I fin= d it? Thanks in advance! /Misha 2017-07-18 17:53 GMT+03:00 Gunn, Janet P >: Nit In Martin's statement, I think "FCC sys rec" should be "FCC CSRIC" https://www.fcc.gov/about-fcc/advisory-committees/communications-security-r= eliability-and-interoperability-1 Janet -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On = Behalf Of A. Jean Mahoney Sent: Tuesday, July 18, 2017 9:42 AM To: dime@ietf.org Subject: [Dime] 99 IETF DIME session notes Hi all, Below are my notes from the session yesterday. Thanks! Jean ---------------------------------------------------------------------------= ---------------- IETF-99 DIME 1740-1840 July 17, 2017, Monday Afternoon session III meeting room: Karlin= III Jabber room: dime at jabber.ietf.org (Please j= oin) Chairs:Jouni Korhonen, Lionel Morand AD: Ben Campbell 17:40 - 17:45, Preliminaries, Chairs (5 minutes) ------------------------------------------ Presentation: https://www.ietf.org/proceedings/99/slides/slides-99-dime-agenda-wg-status-= 00.pdf slide 1: Title Lionel Morand: Jouni is not able to make it to the meeting. slide 2: Note Well slide 3: Agenda Note taker/Jabber scribe: Jean Mahoney Martin Dolly: when will Diameter security discussion happen? Lionel: end of the session. 17:45 - 17:50, WG Document Status, Chairs (5 minutes) ------------------------------------------ *draft-ietf-dime-agent-overload-11 --> RFC Ed Queue *draft-ietf-dime-doic-rate-control-06 --> Waiting for Write-Up *draft-ietf-dime-group-signaling-08 --> In WG Last Call *draft-ietf-dime-load-09 --> RFC Ed Queue *draft-ietf-dime-rfc4006bis-03 --> In WG Last Call slide 4: WG Status Update Lionel: Both overload and load are in the RFC editor queue due to a MISREF.= I'll take care of it after this meeting. Steve Donovan: Just a nit on the slide - I'm the editor on load information= , I'm not the editor for 4006bis. Lionel: Group signaling - the author's think it's ready. We need more revie= ws. Marco? Marco Liebsch: we've updated it before Chicago. We've covered all comments.= Is ready for expert review. Lionel: we've received a good technical review from Steve. Needs another be= fore WGLC. Rate control is missing its writeup. Steve: Has it finished WGLC? Lionel: Yes, needs writeup. Rate-control didn't receive a deep technical re= view. Need further review. From SA5 guys in 3GPP, since they are the main u= sers. slide 5: WG Status update (2/2) Lionel: AVP level security (e2e) draft has expired - Jouni is not able to s= upport the workload alone. I will go to the SAAG meeting and will ask for s= upport from security experts. Solution doesn't have to be Diameter specific. Ben Campbell: I would personally like to see this completed. Who will deplo= y it? Martin Dolly: next round of FCC sys req, they just finished looking at SS7 security vulnerabilities, next 2 years they'll look at Diameter. SA3 co= ming up in 3 weeks. I'll give them discussion paper, a status update of wor= k here. It gets friendly talk there. It's been discussed with regard to 5G = and security system. It's now or never, forever-hold-your-peace time. Lionel: GSMA would like a recommendation. If it's easy to implement, we hav= e ongoing deployment. Ben: They are welcome to come here and help. Eric Guttman: for mission-critical deployments, there are 2 security domain= s - operator domain and mission-critical operator domain. We've looked at s= ecuring at a message or component to a SIP message level. The message has t= o be e2e secure between client and host at the mission-critical ISP. Are th= ere AAA requirements where you can't expose certain AVPs to the operator? N= eed to check. Lionel: From the requirements POV, both should be available with the soluti= on. Normally you would only be able to secure signaling between gateways fo= r instance. You may have e2e secure exchange between any Diameter client an= d any Diameter server. Martin: I don't think that's a case. 401 specifies that equipment manufactu= rers must support IPsec for communication within the EPC, but says it optio= nal to deploy. No one has deployed. For 5G, the European operators are figh= ting pulling the security into the EPC not at the ENodeB. Some of those sta= tements aren't true. Lionel: Ben, you see there is some interest. We would like to see this work= done in IETF. Ben: I observe an interest in using the work. I need to observe interest in= doing the work. Maybe SAAG will help. Lionel: It's more a security discussion than a Diameter discussion. Need he= lp from security area. Eric: There was a mechanism for using an SMIME encapsulation. That became h= istoric? Lionel: deprecated. A new mechanism will be defined outside the base protoc= ol. All new drafts are based on this. 17:50 - 18:35 Individual draft discussions (45 minutes) ------------------------------------------- 17:50 - 18:10 Diameter Policy Groups and Sets, Lyle (20min) Draft: https://tools.ietf.org/html/draft-bertz-dime-predictunits-02 Draft: https://tools.ietf.org/html/draft-bertz-dime-policygroups-04 Presentation: https://www.ietf.org/proceedings/99/slides/slides-99-dime-predicted-units-p= olicy-groups-00.pdf slide 1: Title slide 2: Predicted Units v02 - Motivation Lyle: It takes 3-4 minutes to spin up a VM. slide 3: Predicted Units v02 - Update Lyle: Have not received any new updates. I would like to ask for adoption. Lionel: Who has read? I wasn't in the last meeting what was the feeling in the room? Ben: Besides the chair and the AD? Jean: About 7 people total. Lionel: I've read it and understood the mechanism, which is good. Check on the ML if there is support for adoption. There's not much to do on this doc. slide 4: Intermission slide 5: Purpose slide 6: Policy Groups - Update slide 7: Relationship Model slide 8: Policy Groups Example 1, Overlap Deduplication at Enforcement Point - Adding Membership Assignment to Filters Lyle: SDN switches have limitations of tables (13 tables in OpenFlow). Can concatenate tables. The rules no longer overlap. How to use your metadata field and tie it back to a customer? slide 9: Policy Groups Example 2, Application at the Decision Point Process Lyle: We don't change the user's relationship to their services mid-session. Usually reauthorize them before doing that. slide 10: Applications slide 11: Next Steps Lyle: Would like to hear more from the group before asking for adoption. Lionel: who has read? Lionel: Go back to the Purpose slide. Lyle: didn't want to confuse people but wanted a similar aggregation concept with backwards compatibility. It's similar to ... It's a membership domain. Lionel: I need to review it again. It would be useful to have more review. Lyle: I'm not happy with the examples, I'd like them to be consistent through the doc. Lionel: the draft needs to clearly identify why you can't do this with existing mechanisms. Lyle: all of our filters are based on time and what's in the packets. When the time is the same and the rule is a default rule, that's the most overlap in the system. Lionel: It's not that clear from the creation of AVP, be good to describe it. 18:10 - 18:35 Diameter Specification Recommendations, Lyle (25min) Draft: https://tools.ietf.org/html/draft-bertz-dime-diamimpr-00 Pres: https://www.ietf.org/proceedings/99/slides/slides-99-dime-diameter-specific= ation-recommendations-00.pdf slide 1: Title slide 2: Motivation Lyle: 85% of the time, errors due to ambiguity. slide 3: Findings Eric Guttman: send this to SA5 charging if you have a delegate. Lyle: we don't, but wanted to get it out. slide 4: Methodology slide 5: Unexpected Use Cases slide 6: We are not immune slide 7: Enumerations slide 8: Recommendations slide 9: Defined AVP Recommendations slide 10: Defined AVPs Recommended Formats slide 11: Imported AVP Recommendations slide 12: Grouped AVP / Command Refinement slide 13: Example Refinement slide 14: Command Recommendations slide 15: Enumeration Recommendations slide 16: GAPs for Automated Validation slide 17: Example to Close Gaps slide 18: Enumeration Example Format slide 19: Open Questions slide 20: Summary slide 21: Next steps Lionel: who has read? (Three people raised hands) Lyle: Dave Dolson and Jouni read it. Lionel: in 3GPP it's not really refinement, because in 3GPP just highlight the AVPs they use. We you take a specification and not reading anything - Lyle: they want to just write the code and be done. Lionel: For new drafts, it should be taken into consideration. For existing RFCs, these are documentation errors. When it's clarification, it needs to go through the errata process. For the 3GPP specs, CRs need to be opened. Lyle: This has a lot of errors documented. Would this be informational? How would it progress? Lionel: It can be informational, and can be referenced by other docs. No guideline here. Just highlight what could go wrong. Lyle: I would change the style. Make it more of a report. Lionel: It's not unusual for the IETF to explain issues with implementations. 18:35 - 18:40 Wrap-up and Next, Chairs/AD (5 minutes) ----------------------------- WG Goals/Milestones status - skipped Next steps/Action Points - Future of the WG Lionel: We have 3 remaining documents. Ben: And two that you are thinking of adopting. Lionel: few people in room, not much activity on the list. I won't be able to continue with the chair position - too much work in the 3GPP. Same with Jouni - he changed companies, won't be able to continue. What is the next step except closing the group? Ben: The existing documents are post or near WGLC. Those can be in the hands of the ADs before long. What's you're time frame for needing to step down? Lionel: I need to know when to stop adopting new documents. Even for Jouni. Ben: Of the 2 drafts for the adoption - the predictive units can be AD sponsored. The group one is on the border, a little more complex. I don't have to be the AD that sponsors it. Lionel: For the group one, I need to see more interest. Ben: even if I AD sponsor, I want someone to review them. Lionel: E2E security needs to be done. If we get volunteers from SAAG. Ben: lets see what happens in SAAG. If there's interest - maybe we can spin up some mini-group. Or just speculating here - recharter dime with new chairs to just do that. Lionel: If it is only to go with existing drafts, I think it can be done in short timeframe. Need to confirm with Jouni. Defining new charter with new chairs may not be useful. Ben: E2E security may go into the security area. Lionel: Are there any other comments? (none from the room). To summarize - existing WG documents will be pushed forward. For predictive units, confirm on ML that it's a WG doc, for the group one, we'll check. After those documents, we'll close the WG. Ben: Those 2 new drafts - predictive definitely and maybe group - can be AD sponsored. They can still change to AD sponsorship if we need to close the working group sooner. I'm skeptical of bringing new work into the group, unless we see interest. Lionel: Thank you. ACTION: Chairs to push existing WG documents forward. ACTION: Lionel to bring the e2e security draft to the SAAG session this week to ask for support in finishing it. ACTION: Confirm interest on mailing list for adopting draft-bertz-dime-predictunits. ACTION: Confirm interest on mailing list for adopting draft-bertz-dime-policygroups. ACTION: Ben to look more closely at draft-bertz-dime-policygroups as a candidate for AD sponsorship. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime This electronic message transmission contains information from CSRA that ma= y be attorney-client privileged, proprietary or confidential. The informati= on in this message is intended only for use by the individual(s) to whom it= is addressed. If you believe you have received this message in error, plea= se contact me immediately and be aware that any use, disclosure, copying or= distribution of the contents of this message is strictly prohibited. NOTE:= Regardless of content, this email shall not operate to bind CSRA to any or= der or other contract unless pursuant to explicit written agreement or gove= rnment initiative expressly permitting the use of email for such purpose. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E2D1B82FBOPEXCLILM43corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The draft has expired but is still available:

https://tools.ietf.org/html/draft-korhonen-dime-e2e-security-03

Regards,

Lionel

Envoy=E9 de mon Orange Nura 2

Le 18 juil. 2017 16:58, Misha Zaytsev <misha.zaytse= v.rus@gmail.com> a =E9crit :
Hi All,

May I wonder about e2e security draft mentioned in the MoM? Where can I fin= d it?

Thanks in advance!

/Misha


2017-07-18 17:53 GMT+03:00 Gunn, Janet P <Janet.Gunn@csr= a.com>:
Nit
In Martin's statement, I think  "FCC sys rec" should be &quo= t;FCC CSRIC"
https://www.fcc.gov/about-fcc/advisory-committees/communi= cations-security-reliability-and-interoperability-1

Janet


-----Original Message-----
From: DiME [mailto:dime-bounces@ie= tf.org] On Behalf Of A. Jean Mahoney
Sent: Tuesday, July 18, 2017 9:42 AM
To: dime@ietf.org
Subject: [Dime] 99 IETF DIME session notes

Hi all,

Below are my notes from the session yesterday.

Thanks!

Jean


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

IETF-99 DIME

1740-1840  July 17, 2017, Monday Afternoon session III meeting room: K= arlin III Jabber room: dime at jab= ber.ietf.org (Please join)

Chairs:Jouni Korhonen, Lionel Morand
AD: Ben Campbell

17:40 - 17:45, Preliminaries, Chairs (5 minutes)
------------------------------------------
Presentation:
https://www.ietf.or= g/proceedings/99/slides/slides-99-dime-agenda-wg-status-00.p= df

slide 1: Title

Lionel Morand: Jouni is not able to make it to the meeting.

slide 2: Note Well

slide 3: Agenda

Note taker/Jabber scribe: Jean Mahoney

Martin Dolly: when will Diameter security discussion happen?

Lionel: end of the session.


17:45 - 17:50, WG Document Status, Chairs (5 minutes)
------------------------------------------

*draft-ietf-dime-agent-overload-11    --> RFC Ed Queue
*draft-ietf-dime-doic-rate-control-06 --> Waiting for Write-Up
*draft-ietf-dime-group-signaling-08   --> In WG Last Call=
*draft-ietf-dime-load-09              --= > RFC Ed Queue
*draft-ietf-dime-rfc4006bis-03        --> In WG Last= Call

slide 4: WG Status Update

Lionel: Both overload and load are in the RFC editor queue due to a MISREF.= I'll take care of it after this meeting.

Steve Donovan: Just a nit on the slide - I'm the editor on load information= , I'm not the editor for 4006bis.

Lionel: Group signaling - the author's think it's ready. We need more revie= ws. Marco?

Marco Liebsch: we've updated it before Chicago. We've covered all comments.= Is ready for expert review.

Lionel: we've received a good technical review from Steve. Needs another be= fore WGLC. Rate control is missing its writeup.

Steve: Has it finished WGLC?

Lionel: Yes, needs writeup. Rate-control didn't receive a deep technical re= view. Need further review. From SA5 guys in 3GPP, since they are the main u= sers.

slide 5: WG Status update (2/2)

Lionel: AVP level security (e2e) draft has expired - Jouni is not able to s= upport the workload alone. I will go to the SAAG meeting and will ask for s= upport from security experts. Solution doesn't have to be Diameter specific= .

Ben Campbell: I would personally like to see this completed. Who will deplo= y it?

Martin Dolly: next round of FCC sys req, they just finished looking at
SS7 security vulnerabilities, next 2 years they'll look at Diameter. SA3 co= ming up in 3 weeks. I'll give them discussion paper, a status update of wor= k here. It gets friendly talk there. It's been discussed with regard to 5G = and security system. It's now or never, forever-hold-your-peace time.

Lionel: GSMA would like a recommendation. If it's easy to implement, we hav= e ongoing deployment.

Ben: They are welcome to come here and help.

Eric Guttman: for mission-critical deployments, there are 2 security domain= s - operator domain and mission-critical operator domain. We've looked at s= ecuring at a message or component to a SIP message level. The message has t= o be e2e secure between client and host at the mission-critical ISP. Are there AAA requirements where you can= 't expose certain AVPs to the operator? Need to check.

Lionel: From the requirements POV, both should be available with the soluti= on. Normally you would only be able to secure signaling between gateways fo= r instance. You may have e2e secure exchange between any Diameter client an= d any Diameter server.

Martin: I don't think that's a case. 401 specifies that equipment manufactu= rers must support IPsec for communication within the EPC, but says it optio= nal to deploy. No one has deployed. For 5G, the European operators are figh= ting pulling the security into the EPC not at the ENodeB. Some of those statements aren't true.

Lionel: Ben, you see there is some interest. We would like to see this work= done in IETF.

Ben: I observe an interest in using the work. I need to observe interest in= doing the work. Maybe SAAG will help.

Lionel: It's more a security discussion than a Diameter discussion. Need he= lp from security area.

Eric: There was a mechanism for using an SMIME encapsulation. That became h= istoric?

Lionel: deprecated. A new mechanism will be defined outside the base protoc= ol. All new drafts are based on this.



17:50 - 18:35 Individual draft discussions (45 minutes)
-------------------------------------------

17:50 - 18:10 Diameter Policy Groups and Sets, Lyle (20min)
   Draft: https://tools.ietf.org/html/draft-bertz-dime-predictunits-02<= br>    Draft: https://tools.ietf.org/html/draft-bertz-dime-policygroups-04<= br>    Presentation:
https:= //www.ietf.org/proceedings/99/slides/slides-99-dime-predicted-uni= ts-policy-groups-00.pdf


slide 1: Title

slide 2: Predicted Units v02 - Motivation

Lyle: It takes 3-4 minutes to spin up a VM.

slide 3: Predicted Units v02 - Update

Lyle: Have not received any new updates. I would like to ask for adoption.<= br>
Lionel: Who has read? I wasn't in the last meeting what was the feeling
in the room?

Ben: Besides the chair and the AD?

Jean: About 7 people total.

Lionel: I've read it and understood the mechanism, which is good. Check
on the ML if there is support for adoption. There's not much to do on
this doc.

slide 4: Intermission

slide 5: Purpose

slide 6: Policy Groups - Update

slide 7: Relationship Model

slide 8: Policy Groups Example 1, Overlap Deduplication at Enforcement
Point - Adding Membership Assignment to Filters

Lyle: SDN switches have limitations of tables (13 tables in OpenFlow).
Can concatenate tables. The rules no longer overlap. How to use your
metadata field and tie it back to a customer?

slide 9: Policy Groups Example 2, Application at the Decision Point Process=

Lyle: We don't change the user's relationship to their services
mid-session. Usually reauthorize them before doing that.

slide 10: Applications

slide 11: Next Steps

Lyle: Would like to hear more from the group before asking for adoption.

Lionel: who has read?

Lionel: Go back to the Purpose slide.

Lyle: didn't want to confuse people but wanted a similar aggregation
concept with backwards compatibility. It's similar to ... It's a
membership domain.

Lionel: I need to review it again. It would be useful to have more review.<= br>
Lyle: I'm not happy with the examples, I'd like them to be consistent
through the doc.

Lionel: the draft needs to clearly identify why you can't do this with
existing mechanisms.

Lyle: all of our filters are based on time and what's in the packets.
When the time is the same and the rule is a default rule, that's the
most overlap in the system.

Lionel: It's not that clear from the creation of AVP, be good to
describe it.


18:10 - 18:35 Diameter Specification Recommendations, Lyle (25min)
   Draft: https://tools.ietf.org/html/draft-bertz-dime-diamimpr-00
   Pres:
https://www.ietf.org/proceedings/99/slides/slides-99-dime-diam= eter-specification-recommendations-00.pdf

slide 1: Title

slide 2: Motivation

Lyle: 85% of the time, errors due to ambiguity.

slide 3: Findings

Eric Guttman: send this to SA5 charging if you have a delegate.

Lyle: we don't, but wanted to get it out.

slide 4: Methodology

slide 5: Unexpected Use Cases

slide 6: We are not immune

slide 7: Enumerations

slide 8: Recommendations

slide 9: Defined AVP Recommendations

slide 10: Defined AVPs Recommended Formats

slide 11: Imported AVP Recommendations

slide 12: Grouped AVP / Command Refinement

slide 13: Example Refinement

slide 14: Command Recommendations

slide 15: Enumeration Recommendations

slide 16: GAPs for Automated Validation

slide 17: Example to Close Gaps

slide 18: Enumeration Example Format

slide 19: Open Questions

slide 20: Summary

slide 21:  Next steps

Lionel: who has read? (Three people raised hands)

Lyle: Dave Dolson and Jouni read it.

Lionel: in 3GPP it's not really refinement, because in 3GPP just
highlight the AVPs they use. We you take a specification and not reading
anything -

Lyle: they want to just write the code and be done.

Lionel: For new drafts, it should be taken into consideration. For
existing RFCs, these are documentation errors. When it's clarification,
it needs to go through the errata process. For the 3GPP specs, CRs need
to be opened.

Lyle: This has a lot of errors documented. Would this be informational?
How would it progress?

Lionel: It can be informational, and can be referenced by other docs. No
guideline here. Just highlight what could go wrong.

Lyle: I would change the style. Make it more of a report.

Lionel: It's not unusual for the IETF to explain issues with
implementations.


18:35 - 18:40 Wrap-up and Next, Chairs/AD (5 minutes)
-----------------------------

WG Goals/Milestones status - skipped

Next steps/Action Points - Future of the WG

Lionel: We have 3 remaining documents.

Ben: And two that you are thinking of adopting.

Lionel: few people in room, not much activity on the list. I won't be
able to continue with the chair position - too much work in the 3GPP.
Same with Jouni - he changed companies, won't be able to continue. What
is the next step except closing the group?

Ben: The existing documents are post or near WGLC. Those can be in the
hands of the ADs before long. What's you're time frame for needing to
step down?

Lionel: I need to know when to stop adopting new documents. Even for Jouni.=

Ben: Of the 2 drafts for the adoption - the predictive units can be AD
sponsored. The group one is on the border, a little more complex. I
don't have to be the AD that sponsors it.

Lionel: For the group one, I need to see more interest.

Ben: even if I AD sponsor, I want someone to review them.

Lionel: E2E security needs to be done. If we get volunteers from SAAG.

Ben: lets see what happens in SAAG. If there's interest - maybe we can
spin up some mini-group. Or just speculating here - recharter dime with
new chairs to just do that.

Lionel: If it is only to go with existing drafts, I think it can be done
in short timeframe. Need to confirm with Jouni. Defining new charter
with new chairs may not be useful.

Ben: E2E security may go into the security area.

Lionel: Are there any other comments? (none from the room). To summarize
- existing WG documents will be pushed forward. For predictive units,
confirm on ML that it's a WG doc, for the group one, we'll check. After
those documents, we'll close the WG.

Ben: Those 2 new drafts - predictive definitely and maybe group - can be
AD sponsored. They can still change to AD sponsorship if we need to
close the working group sooner. I'm skeptical of bringing new work into
the group, unless we see interest.

Lionel: Thank you.

ACTION: Chairs to push existing WG documents forward.

ACTION: Lionel to bring the e2e security draft to the SAAG session this
week to ask for support in finishing it.

ACTION: Confirm interest on mailing list for adopting
draft-bertz-dime-predictunits.

ACTION: Confirm interest on mailing list for adopting
draft-bertz-dime-policygroups.

ACTION: Ben to look more closely at draft-bertz-dime-policygroups as a
candidate for AD sponsorship.

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

This electronic message transmission contains information from CSRA that ma= y be attorney-client privileged, proprietary or confidential. The informati= on in this message is intended only for use by the individual(s) to whom it= is addressed. If you believe you have received this message in error, please contact me immediately and be = aware that any use, disclosure, copying or distribution of the contents of = this message is strictly prohibited. NOTE: Regardless of content, this emai= l shall not operate to bind CSRA to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of email for such = purpose.

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

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E2D1B82FBOPEXCLILM43corp_-- From nobody Wed Jul 19 02:32:23 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91018131C60 for ; Wed, 19 Jul 2017 02:32:22 -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, RP_MATCHES_RCVD=-0.001, 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 5RtsmVpUzKCi for ; Wed, 19 Jul 2017 02:32:20 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2626C131C5F for ; Wed, 19 Jul 2017 02:32:20 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0319.002; Wed, 19 Jul 2017 05:32:18 -0400 From: Yuval Lifshitz To: "Bertz, Lyle T [CTO]" , "lionel.morand@orange.com" , "dime@ietf.org list" Thread-Topic: RFC 6733 Commands Thread-Index: AQHS/uUJB8h6U5QREEmZorl9T0AXrqJYEfmAgAAL0HqAAscIwA== Date: Wed, 19 Jul 2017 09:32:18 +0000 Message-ID: References: <1500286334617.86980@sprint.com>, <8331_1500301978_596CCA9A_8331_333_1_6B7134B31289DC4FAF731D844122B36E2D1B5E23@OPEXCLILM43.corporate.adroot.infra.ftgroup> <1500303827591.97405@sprint.com> In-Reply-To: <1500303827591.97405@sprint.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.142.10] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_C43C255C7106314F8D13D03FA20CFE49A8AB7250wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] RFC 6733 Commands X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 09:32:23 -0000 --_000_C43C255C7106314F8D13D03FA20CFE49A8AB7250wtlexchp2sandvi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Actually, we may have an issue there. The spec says that zero must be used = for base protocol messages (page 23): Diameter messages pertaining to peer connection establishment and maintenance such as CER/CEA, DWR/DWA, and DPR/DPA MUST carry an Application Id of zero (0). But does not say that it must not be used for anything else (or at least I = failed to find such text). Do you think such text should be added? Note that there is such text regarding vendor-id. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Bertz, Lyle T [CTO] Sent: Monday, July 17, 2017 6:04 PM To: lionel.morand@orange.com; dime@ietf.org list Subject: Re: [Dime] RFC 6733 Commands agreed, we have encountered some folks tying the ACR/ACA to app id 0 in ope= n source. ________________________________ From: lionel.morand@orange.com > Sent: Monday, July 17, 2017 9:32 AM To: Bertz, Lyle T [CTO]; dime@ietf.org list Subject: RE: RFC 6733 Commands Hi Lyle, I think that there is no specific reason. By definition, the command is ind= ependent of any application. So when describing the command code, it may or= may not be contained in the command code header. It is consistent with the= CCF specification: header =3D "" The CCF is mainly used to identify the set of AVP that can be present in th= e command. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Bertz, Lyle T [CTO] Envoy=E9 : lundi 17 juillet 2017 12:12 =C0 : dime@ietf.org list Objet : [Dime] RFC 6733 Commands In the spec was there a particular reason why we did not specify the applic= ation Identifier in the header for each of the command codes, e.g. ACR/ACA = assigned to application ID 3? Lyle ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_C43C255C7106314F8D13D03FA20CFE49A8AB7250wtlexchp2sandvi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Actually, we may have an = issue there. The spec says that zero must be used for base protocol message= s (page 23):

 <= /p>

Diameter messages pertaining to peer connectio= n

   establishment and maintenance suc= h as CER/CEA, DWR/DWA, and DPR/DPA

   MUST carry an Application Id of z= ero (0).

 <= /p>

But does not say that it = must not be used for anything else (or at least I failed to find such text)= . Do you think such text should be added?

Note that there is such t= ext regarding vendor-id.

 <= /p>

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of Bertz, Lyle T [CTO]
Sent: Monday, July 17, 2017 6:04 PM
To: lionel.morand@orange.com; dime@ietf.org list
Subject: Re: [Dime] RFC 6733 Commands

 

agreed, we have encountered some folks tying the ACR/ACA to app = id 0 in open source.

 

 

From: lionel.morand@orange.com &l= t;lionel.morand@orange.com&= gt;
Sent: Monday, July 17, 2017 9:32 AM
To: Bertz, Lyle T [CTO]; dime@ietf.= org list
Subject: RE: RFC 6733 Commands

 

Hi Lyle,

 

I think that there is no spec= ific reason. By definition, the command is independent of any application. = So when describing the command code, it may or may not be contained in the command code header. It is consistent with the CCF specif= ication:

 

   header    &= nbsp;      =3D "<Diameter-Header:" co= mmand-id

       &n= bsp;            = ;     [r-bit] [p-bit] [e-bit] [application-id]">= ;"

 

The CCF is mainly used to ide= ntify the set of AVP that can be present in the command.

 

Regards,

 

Lionel

 

De : DiME [mail= to:dime-bounces@ietf.org] De la part de Bertz, Lyle T [CTO]
Envoy=E9 : lundi 17 juillet 2017 12:12
=C0 : dime@ietf.org list Objet : [Dime] RFC 6733 Commands

 

In the spec was there a particular reason why we did not specify= the application Identifier in the header for each of the command code= s, e.g. ACR/ACA assigned to application ID 3?

 

Lyle

 <= o:p>


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

________________________________________=
___________________________________________________________________________=
______
 
Ce message et ses pieces jointes peuvent=
 contenir des informations confidentielles ou privilegiees et ne doivent do=
nc
pas etre diffuses, exploites ou copies s=
ans autorisation. Si vous avez recu ce message par erreur, veuillez le sign=
aler
a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles d'alterat=
ion,
Orange decline toute responsabilite si c=
e message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may con=
tain confidential or privileged information that may be protected by law;
they should not be distributed, used or =
copied without authorisation.
If you have received this email in error=
, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not =
liable for messages that have been modified, changed or falsified.
Thank you.
--_000_C43C255C7106314F8D13D03FA20CFE49A8AB7250wtlexchp2sandvi_-- From nobody Wed Jul 19 03:00:25 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393C0131C77 for ; Wed, 19 Jul 2017 03:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 rxI__lnX9KKO for ; Wed, 19 Jul 2017 03:00:21 -0700 (PDT) Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::241]) (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 1131812F24E for ; Wed, 19 Jul 2017 03:00:21 -0700 (PDT) Received: by mail-lf0-x241.google.com with SMTP id z78so4006526lff.2 for ; Wed, 19 Jul 2017 03:00:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-language:thread-index; bh=90SA1TP39rakV9b8XVpS0XSisyJFfhMzihPr0fhv0/o=; b=tK+HgftROTl4m85xksgUQl7buzwd2Jwrw9fVvELWD6ujA1bFHKYRtfOeJXEY7Z3t2x 5psCoIbIFBC/EyLX49+5Y/aN+5VulrdKtC1u2aooLFYql5ZvbfGNQlGJHsF6XaB65kzx kSZzn8RVpFT1jwLRgo1zO8HvWdu/xh5hGNDvbHnnC+E1E3PV3MPlu1iO6xUs0MDQBGue C4imbonUTDebz4Kdj71foIZLD7PeHqcQB7J8q5BZF1zkQG2OiSPjnV74CMcYeZIFCj2b KzOtfdtJb+nzlRbPj86Pi94vm/RxWJ8JTGJiSeAQ/V/8AUoBXLRbK8/6TyxvXdoXcuwh KN8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-language:thread-index; bh=90SA1TP39rakV9b8XVpS0XSisyJFfhMzihPr0fhv0/o=; b=eOTwSbwYTL6+FxtEymZ12++GTIpAjt/PwAv0hb1jHFRvhA5/EKflM02HKUFreb6RYe OQaY6npLwr9QuzKcadbNdrATcYPblBmr5yc3PhK3QhXQKdvFsc/srwNRe3jiMUyLuCmQ MawFaBdrmTLOCvYYBz/w+iUhuO2r0ow6vFBLct5toi2KyrqZk9UyyOzhk8CIBpwKxsi1 uBYny/DCHRLa51CjIapL4Ropwz+QJ7HSC7RcxF9OXltWpEBqS50ymQozLGlw2k4upFjv sY7WtYftFAbq9b4Vjx3w0I9b5mtjziGWwIqwJTfEn9vTPY4pTKmZ164RXXPjVXw+wnlF +JhQ== X-Gm-Message-State: AIVw110FmjSMBEIhFfDkWJYo2VLXZ55OWmnhvQwZub5jd4J4K6Oa73If 0qsOg0XTAGGalURB X-Received: by 10.46.83.7 with SMTP id h7mr2178258ljb.22.1500458419157; Wed, 19 Jul 2017 03:00:19 -0700 (PDT) Received: from JOKO ([83.150.126.201]) by smtp.gmail.com with ESMTPSA id s20sm1202377ljd.65.2017.07.19.03.00.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 03:00:18 -0700 (PDT) From: "Jouni" To: "'Yuval Lifshitz'" , "'Bertz, Lyle T [CTO]'" , , References: <1500286334617.86980@sprint.com>, <8331_1500301978_596CCA9A_8331_333_1_6B7134B31289DC4FAF731D844122B36E2D1B5E23@OPEXCLILM43.corporate.adroot.infra.ftgroup> <1500303827591.97405@sprint.com> In-Reply-To: Date: Wed, 19 Jul 2017 13:00:17 +0300 Message-ID: <559e01d30075$d36b13e0$7a413ba0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_559F_01D3008E.F8BF50C0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQJ4SKXtVleed+r8bygyRJbzSNgxvwI0ElhcAq0/UBgBqfvIxKDb/TTA Archived-At: Subject: Re: [Dime] RFC 6733 Commands X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 10:00:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_559F_01D3008E.F8BF50C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Unless you extend and existing application within the rules in Section = 1.3.4 you always get a new application. And if you wish to extend the existing base protocol application with new commands that most likely would = require a new protocol version. I think we are good here with the current text. =20 - Jouni=20 =20 From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Yuval Lifshitz Sent: Wednesday, July 19, 2017 12:32 PM To: Bertz, Lyle T [CTO] ; = lionel.morand@orange.com; dime@ietf.org list Subject: Re: [Dime] RFC 6733 Commands =20 Actually, we may have an issue there. The spec says that zero must be = used for base protocol messages (page 23): =20 Diameter messages pertaining to peer connection establishment and maintenance such as CER/CEA, DWR/DWA, and DPR/DPA MUST carry an Application Id of zero (0). =20 But does not say that it must not be used for anything else (or at least = I failed to find such text). Do you think such text should be added? Note that there is such text regarding vendor-id. =20 From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Bertz, Lyle T = [CTO] Sent: Monday, July 17, 2017 6:04 PM To: lionel.morand@orange.com ; dime@ietf.org list Subject: Re: [Dime] RFC 6733 Commands =20 agreed, we have encountered some folks tying the ACR/ACA to app id 0 in = open source. =20 =20 _____ =20 From: lionel.morand@orange.com > Sent: Monday, July 17, 2017 9:32 AM To: Bertz, Lyle T [CTO]; dime@ietf.org list Subject: RE: RFC 6733 Commands=20 =20 Hi Lyle, =20 I think that there is no specific reason. By definition, the command is independent of any application. So when describing the command code, it = may or may not be contained in the command code header. It is consistent = with the CCF specification: =20 header =3D "" =20 The CCF is mainly used to identify the set of AVP that can be present in = the command. =20 Regards, =20 Lionel=20 =20 De : DiME [mailto:dime-bounces@ietf.org] De la part de Bertz, Lyle T = [CTO] Envoy=E9 : lundi 17 juillet 2017 12:12 =C0 : dime@ietf.org list Objet : [Dime] RFC 6733 Commands =20 In the spec was there a particular reason why we did not specify the application Identifier in the header for each of the command codes, e.g. ACR/ACA assigned to application ID 3? =20 Lyle =20 _____ =20 This e-mail may contain Sprint proprietary information intended for the = sole use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. _________________________________________________________________________= ___ _____________________________________________ =20 Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. =20 This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. Thank you. ------=_NextPart_000_559F_01D3008E.F8BF50C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Unless you extend and existing application within the rules in Section = 1.3.4 you always get a new application. And if you wish to extend the = existing base protocol application with new commands that most likely = would require a new protocol version. I think we are good here with the = current text.

 

-        = Jouni

 

From:<= /b> = DiME [mailto:dime-bounces@ietf.org] On Behalf Of Yuval = Lifshitz
Sent: Wednesday, July 19, 2017 12:32 PM
To: = Bertz, Lyle T [CTO] <Lyle.T.Bertz@sprint.com>; = lionel.morand@orange.com; dime@ietf.org list = <dime@ietf.org>
Subject: Re: [Dime] RFC 6733 = Commands

 

Actually, we may have an issue there. The spec says that zero must be = used for base protocol messages (page 23):

 

Diameter messages pertaining to peer = connection

   establishment and maintenance such as = CER/CEA, DWR/DWA, and DPR/DPA

   MUST carry an Application Id of zero = (0).

 

But does not say that it must not be used for anything else (or at = least I failed to find such text). Do you think such text should be = added?

Note that there is such text regarding = vendor-id.

 

From: DiME = [mailto:dime-bounces@ietf.org] = On Behalf Of Bertz, Lyle T [CTO]
Sent: Monday, July 17, = 2017 6:04 PM
To: lionel.morand@orange.com; = dime@ietf.org = list
Subject: Re: [Dime] RFC 6733 = Commands

 

agreed, we have = encountered some folks tying the ACR/ACA to app id 0 in open = source.

 <= /span>

 <= /span>

F= rom: = lionel.morand@orange.com = <lionel.morand@orange.com>=
Sent: Monday, July 17, 2017 9:32 AM
To: Bertz, Lyle = T [CTO]; dime@ietf.org = list
Subject: RE: RFC 6733 Commands =

 

Hi = Lyle,

&nb= sp;

I = think that there is no specific reason. By definition, the command is = independent of any application. So when describing the command code, it = may or may not be contained in the command code header. It is consistent = with the CCF specification:

&nb= sp;

   = header           =3D = "<Diameter-Header:" command-id

         = ;            =     [r-bit] [p-bit] [e-bit] = [application-id]">"

&nb= sp;

The= CCF is mainly used to identify the set of AVP that can be present in = the command.

&nb= sp;

Reg= ards,

&nb= sp;

Lio= nel

&nb= sp;

= De := DiME [mailto:dime-bounces@ietf.org] = De la part de Bertz, Lyle T [CTO]
Envoy=E9 : lundi = 17 juillet 2017 12:12
=C0 : dime@ietf.org = list
Objet : [Dime] RFC 6733 Commands

 

In the spec was = there a particular reason why we did not specify the application = Identifier in the header for each of the command codes, e.g. = ACR/ACA assigned to application ID 3?

 

Lyle

 


T= his e-mail may contain Sprint proprietary information intended for the = sole use of the recipient(s). Any use by others is prohibited. If you = are not the intended recipient, please contact the sender and delete all = copies of the message.

_________________________________________________=
________________________________________________________________________<=
o:p>
 
Ce message et ses pieces jointes peuvent =
contenir des informations confidentielles ou privilegiees et ne doivent =
donc
pas etre =
diffuses, exploites ou copies sans autorisation. Si vous avez recu ce =
message par erreur, veuillez le =
signaler
a =
l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles =
d'alteration,
Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. =
Merci.
 
This message and its attachments may contain =
confidential or privileged information that may be protected by =
law;
they =
should not be distributed, used or copied without =
authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its =
attachments.
As emails may be altered, Orange is not liable =
for messages that have been modified, changed or =
falsified.
Thank =
you.
------=_NextPart_000_559F_01D3008E.F8BF50C0-- From nobody Wed Jul 19 03:12:12 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2560131C60; Wed, 19 Jul 2017 03:12:11 -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, RP_MATCHES_RCVD=-0.001, 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 sEUvy9dMmPV6; Wed, 19 Jul 2017 03:12:08 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92635131A78; Wed, 19 Jul 2017 03:12:07 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-3.sandvine.com (192.168.196.177) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 19 Jul 2017 06:12:06 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Wed, 19 Jul 2017 06:12:05 -0400 From: Yuval Lifshitz To: "lionel.morand@orange.com" , Dave Dolson , "Gardella, Maryse (Nokia - FR/Nozay)" , Alan DeKok CC: "dime@ietf.org list" , "draft-ietf-dime-rfc4006bis@ietf.org" , Yuval Lifshitz Thread-Topic: =?iso-8859-1?Q?RE=A0:_RE:_M-bit_setting_in_draft-ietf-dime-rfc4006bis-02?= Thread-Index: AdL/Dc/OHV8jIku1TbW+ki3uYtdcWQACO2swABRAjoAAQ2kQsA== Date: Wed, 19 Jul 2017 10:12:05 +0000 Message-ID: References: <13800_1500305348_596CD7C4_13800_63_1_6B7134B31289DC4FAF731D844122B36E2D1B6048@OPEXCLILM43.corporate.adroot.infra.ftgroup>, <20138_1500328023_596D3057_20138_295_1_6B7134B31289DC4FAF731D844122B36E2D1B6758@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: <20138_1500328023_596D3057_20138_295_1_6B7134B31289DC4FAF731D844122B36E2D1B6758@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.142.10] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_C43C255C7106314F8D13D03FA20CFE49A8AB727Fwtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] =?iso-8859-1?q?RE=A0=3A_RE=3A_M-bit_setting_in_draft-ietf?= =?iso-8859-1?q?-dime-rfc4006bis-02?= X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 10:12:12 -0000 --_000_C43C255C7106314F8D13D03FA20CFE49A8AB727Fwtlexchp2sandvi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lionel, The AVPs newly added to RFC4006bis were not added to the MAY column because= they are mandatory in some messages and not in other - reason was specific= ally to "workaround" the RFC6733 directive :-) =B7 If an equipment that support RFC4006bis, works in a mixed envir= onment, where RFC4006 also exist, it should not set the M-bit on the new AV= Ps, so that legacy equipment can just ignore them =B7 While, if working in pure RFC4006bis environment, it can set th= e M-bit for the AVPs that replace existing AVPs that has the M-bit set for = them If this approach is not acceptable, we would have other 2 options: 1. Say that the M-bit must be set - this would define a new protocol = in RFC4006bis, which would, IMO, decrease the probability of adoption to ze= ro :-( 2. Say that the M-bit must not be set - this makes the new AVPs "weak= er" as they may be ignored even if they carry critical information So, if we have to change, I would go for (2). Yuval From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] Sent: Tuesday, July 18, 2017 12:47 AM To: Dave Dolson; Gardella, Maryse (Nokia - FR/Nozay); Alan DeKok Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE : RE: M-bit setting in draft-ietf-dime-rfc4006bis-02 Hi Dave, Speaking about the existing AVPs, I don't think that we need a specific err= ata report on RFC4006 if it is what you meant. I consider it more as a clarification on the M-bit setting included while r= evising the specification, based on requirements/guidelines provided after = the publication of the RFC4006. As it is, the MAY column is not wrong. It is just useless and it is why its= use was deprecated. Lionel Le 17 juil. 2017 18:05, Dave Dolson > a =E9crit : Lionel, Do you consider those to be errata against RFC4006 ? From: lionel.morand@orange.com [mailto:lio= nel.morand@orange.com] Sent: Monday, July 17, 2017 5:29 PM To: Dave Dolson; Gardella, Maryse (Nokia - FR/Nozay); Alan DeKok Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ie= tf.org Subject: M-bit setting in draft-ietf-dime-rfc4006bis-02 Hi, Sorry for this late comment. As stated in RFC6733, It is the decision of the protocol designer when to develop a new Diameter application rather than extending Diameter in other ways. However, a new Diameter application MUST be created when one or more of the following criteria are met: M-bit Setting An AVP with the M-bit in the MUST column of the AVP flag table is added to an existing Command/Application. An AVP with the M-bit in the MAY column of the AVP flag table is added to an existing Command/Application. Therefore, if it is proposed to keep the existing DCC application-id, the n= ewly defined AVPs must be defined with the M-bit put in the MUST NOT column= : +---------------+ |AVP Flag rules | |----+-----+----| AVP Section | | |MUST| Attribute Name Code Defined Data Type |MUST| MAY |NOT | -----------------------------------------|----+-----+----| QoS-Final-Unit- TBD17 8.68 Grouped | | M | V | Indication | | | | Redirect-Server TBD13 8.64 Grouped | | M | V | -Extension | | | | Redirect-Address TBD14 8.65 Address | | M | V | -IPAddress | | | | Redirect-Address TBD15 8.66 UTF8String | | M | V | -URL | | | | Redirect-Address TBD16 8.67 UTF8String | | M | V | -SIP-URI | | | | Subscription-Id TBD7 8.58 Grouped | | M | V | -Extension | | | | Subscription-Id TBD8 8.59 UTF8String | | M | V | -E164 | | | | Subscription-Id TBD9 8.60 UTF8String | | M | V | -IMSI | | | | Subscription-Id TBD10 8.61 UTF8String | | M | V | -SIP-URI | | | | Subscription-Id TBD11 8.62 UTF8String | | M | V | -NAI | | | | Subscription-Id TBD12 8.63 UTF8String | | M | V | -Private | | | | User-Equipment TBD1 8.52 Grouped | | M | V | -Info-Extension | | | | User-Equipment TBD2 8.53 OctetString| | M | V | -Info-IMEISV | | | | User-Equipment TBD3 8.54 OctetString| | M | V | -Info-MAC | | | | User-Equipment TBD4 8.55 OctetString| | M | V | -Info-EUI64 | | | | User-Equipment TBD5 8.56 OctetString| | M | V | -Info-ModifiedEUI64 | | | | User-Equipment TBD6 8.57 OctetString| | M | V | Now, regarding existing AVPs with the M-bit put in the MAY column (listed b= elow), I would recommend not to use the MAY column but to specific in which= DCC commands the M-bit setting may change for some AVP, as indicated in RF= C6733 and RFC7423. >From RFC6733: Note: The M-bit setting for a given AVP is relevant to an Application and each command within that application that includes the AVP. That is, if an AVP appears in two commands for application Foo and the M-bit settings are different in each command, then there should be two AVP flag tables describing when to set the M-bit. For AVPs for which there is no clear use case for change of the M-bit setti= ng in the DCC app, the M-bit should be put in the MUST column. It may be th= e case for all the AVPs listed below (I've not checked). Other applications= using DCC commands can decide to set or clear the M-bit of the related DCC= commands' AVPs without any constraint. +---------------+ |AVP Flag rules | |----+-----+----| AVP Section | | |MUST| Attribute Name Code Defined Data Type |MUST| MAY |NOT | -----------------------------------------|----+-----+----| CC-Correlation-Id 411 8.1 OctetString| | M | V | Service-Parameter 440 8.43 Grouped | | M | V | -Info | | | | Service- 441 8.44 Unsigned32 | | M | V | Parameter-Type | | | | Service- 442 8.45 OctetString| | M | V | Parameter-Value | | | | User-Equipment 458 8.49 Grouped | | M | V | -Info | | | | User-Equipment 459 8.50 Enumerated | | M | V | -Info-Type | | | | User-Equipment 460 8.51 OctetString| | M | V | -Info-Value | | | | User-Equipment TBD1 8.52 Grouped | | M | V | -Info-Extension | | | | User-Equipment TBD2 8.53 OctetString| | M | V | -Info-IMEISV | | | | User-Equipment TBD3 8.54 OctetString| | M | V | -Info-MAC | | | | User-Equipment TBD4 8.55 OctetString| | M | V | -Info-EUI64 | | | | User-Equipment TBD5 8.56 OctetString| | M | V | -Info-ModifiedEUI64 | | | | User-Equipment TBD6 8.57 OctetString| | M | V | -Info-IMEI | | | | Regards, Lionel De : Dave Dolson [mailto:ddolson@sandvine.com] Envoy=E9 : jeudi 11 mai 2017 17:03 =C0 : Gardella, Maryse (Nokia - FR/Nozay); MORAND Lionel IMT/OLN; Alan DeKo= k Cc : dime@ietf.org list; draft-ietf-dime-rfc4006bis@i= etf.org Objet : RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 I have uploaded version -03 with the agreed changes to simply replace the r= eference with RFC7542. https://tools.ietf.org/html/draft-ietf-dime-rfc4006bis-03 From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com= ] Sent: Saturday, May 6, 2017 3:00 AM To: Dave Dolson; lionel.morand@orange.com;= Alan DeKok Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ie= tf.org Subject: RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-0= 2 Hi all, Therefore it makes sense to do so. Thanks Maryse From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: vendredi 5 mai 2017 21:57 To: lionel.morand@orange.com; Gardella, Ma= ryse (Nokia - FR/Nozay) >; Alan DeKok > Cc: dime@ietf.org list >; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-0= 2 Lionel, OK, thanks. I'll make the changes. -Dave From: lionel.morand@orange.com [mailto:lio= nel.morand@orange.com] Sent: Friday, May 5, 2017 3:42 PM To: Dave Dolson; Gardella, Maryse (Nokia - FR/Nozay); Alan DeKok Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ie= tf.org Subject: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Hi, RFC 6733 was published before RFC 7542, obsoleting RFC 4282. It is why RFC = 4282 was still used as reference in RFC 6733. Using IETF rules, RFC 7242 should be used anyway for any Diameter implement= ation based on RFC 6733 and using NAI. Therefore, when updating RFC 4006, RFC 7242 should be used as reference. Regards, Lionel Le 5 mai 2017 20:05, Dave Dolson > a =E9crit : Maryse, Thanks for doing some research and pointing this out. In RFC 6733, RFC4282 is used for two things: 1. to define "Network Access Identifier", for use as realm names, which are= "piggybacked on the administration of the DNS namespace" - so DNS restrictions would have to apply here. 2. Defining User-Name AVP, which is a NAI, but specifically "of type UTF8St= ring ... in a format consistent with the NAI specification [RFC4282]" - (see section 8.14 of RFC6733) - so User-Name is defined to be the UTF8 subset of RFC4282. So I claim that although RFC4282 is mentioned, RFC6733 intends that user na= mes in Diameter be limited to UTF-8, hence compatible with RFC7542. -Dave -----Original Message----- From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com= ] Sent: Wednesday, May 3, 2017 10:37 AM To: Dave Dolson; Alan DeKok Cc: Yuval Lifshitz; jouni korhonen; dime@ietf.org lis= t; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 My mistake, it should be RFC 6733 Maryse -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: mercredi 3 mai 2017 16:19 To: Gardella, Maryse (Nokia - FR/Nozay) >; Alan DeKok > Cc: Yuval Lifshitz >;= jouni korhonen >; di= me@ietf.org list = >; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 RFC4282 is also obsolete, and RFC7542 explains the problems with it. I don't think we should introduce RFC4282 at this point. (And sorry, I don't see RFC 6377 referring to 4282) -----Original Message----- From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com= ] Sent: Wednesday, May 3, 2017 9:21 AM To: Alan DeKok; Dave Dolson Cc: Yuval Lifshitz; jouni korhonen; dime@ietf.org lis= t; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Hello all, For the new AVP, no question: RFC 7542 should be used. I have not the full overview of 3GPP specs used for reference to NAI, and b= ased on: - assuming the TS 23.003 (Numbering, addressing and identification) is an i= mportant spec to consider, the RFC 4282 is used - RFC 6377 DBP also referring to RFC 4282 I would tend to agree on at least using RFC 4282 as the reference for the E= ND_USER_NAI in Subscription-Id-Type for RFC4006bis. Whether to directly refer to RFC7542, I cannot confirm whether this is acce= ptable or not. BR Maryse -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: mercredi 3 mai 2017 00:47 To: Dave Dolson > Cc: Yuval Lifshitz >;= Gardella, Maryse (Nokia - FR/Nozay) >; jouni korhonen >; dime@ietf.org list >; draft-ietf-dime-rfc4006bis@ietf.org Subject: Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 On May 2, 2017, at 5:51 PM, Dave Dolson > wrote: > > Thanks Alan. > Do I correctly hear you saying we should replace all references to RFC 24= 86 with RFC 7542? Yes. It's 2017. Independent of RFC 7542, *inter-operable* implementations jus= t have no business using non-UTF8 identifiers. Alan DeKok. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_C43C255C7106314F8D13D03FA20CFE49A8AB727Fwtlexchp2sandvi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Lionel,=

The AVPs newly added to R= FC4006bis were not added to the MAY column because they are mandatory in so= me messages and not in other - reason was specifically to “workaround” the RFC6733 directive :-)

=B7      &nbs= p;  If an equipment that support RFC4006bis, works in a mixed environme= nt, where RFC4006 also exist, it should not set the M-bit on the new AVPs, so that legacy equipment can just ignore them<= /span>

=B7      &nbs= p;  While, if working in pure RFC4006bis environment, it can set the M-= bit for the AVPs that replace existing AVPs that has the M-bit set for them

 <= /p>

If this approach is no= t acceptable, we would have other 2 o= ptions:

1. = ;      Say that the M-bit must be set – this would define a new prot= ocol in RFC4006bis, which would, IMO, decrease the probability of adoption to zero :-(

2. = ;      Say that the M-bit must not be set – this makes the new AVPs = “weaker” as they may be ignored even if they carry critical inf= ormation

So, if we have to change,= I would go for (2).

 <= /p>

Yuval

 <= /p>

From: lionel.m= orand@orange.com [mailto:lionel.morand@orange.com]
Sent: Tuesday, July 18, 2017 12:47 AM
To: Dave Dolson; Gardella, Maryse (Nokia - FR/Nozay); Alan DeKok
Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ietf.org
Subject: RE : RE: M-bit setting in draft-ietf-dime-rfc4006bis-0= 2

 

Hi Dave,

Speaking about the existing AVPs, I don't think that we need a specific err= ata report on RFC4006 if it is what you meant.
I consider it more as a clarification on the M-bit setting included while r= evising the specification, based on requirements/guidelines provided after = the publication of the RFC4006.
As it is, the MAY column is not wrong. It is just useless and it is why its= use was deprecated.

Lionel

Le 17 juil. 2017 18:05, Dave Dolson <ddolson@sandvine.com> a =E9crit :

Lionel,=

Do you consider those to = be errata against RFC4006 ?

 <= /p>

 <= /p>

From: lionel.morand@orange.com [<= a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<= /a>]
Sent: Monday, July 17, 2017 5:29 PM
To: Dave Dolson; Gardella, Maryse (Nokia - FR/Nozay); Alan DeKok
Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ietf.org
Subject: M-bit setting in draft-ietf-dime-rfc4006bis-02<= /o:p>

 

Hi,

 

Sorry for this late comment.

 

As stated in RFC6733,

 

   It is the decision of the protocol designer w= hen to develop a new

   Diameter application rather than extending Di= ameter in other ways.

   However, a new Diameter application MUST be c= reated when one or more

   of the following criteria are met:

 

   M-bit Setting

 

      An AVP with the M-bit in th= e MUST column of the AVP flag table is

      added to an existing Comman= d/Application.  An AVP with the M-bit

      in the MAY column of the AV= P flag table is added to an existing

      Command/Application.=

 

Therefore, if it is proposed to keep the existing DCC appl= ication-id, the newly defined AVPs must be defined with the M-bit put in th= e MUST NOT column:

 

         &nbs= p;            &= nbsp;           &nbs= p;         +---------------+= ;

         &nbs= p;            &= nbsp;           &nbs= p;         |AVP Flag rules |=

         &nbs= p;            &= nbsp;           &nbs= p;         |----+-----+----= |

         &nbs= p;           AVP  Se= ction           | &n= bsp;  |     |MUST|

   Attribute Name    Code Defined= Data Type |MUST| MAY |NOT |

   -----------------------------------------|---= -+-----+----|

   QoS-Final-Unit-  TBD17 8.68   = Grouped    |    |  M  |  V |

     Indication    = ;            &n= bsp;            |&nb= sp;   |     |    |=

   Redirect-Server  TBD13 8.64   = Grouped    |    |  M  |  V |

     -Extension    = ;            &n= bsp;            |&nb= sp;   |     |    |=

   Redirect-Address TBD14 8.65   Addre= ss    |    |  M  |  V |=

     -IPAddress    = ;            &n= bsp;            |&nb= sp;   |     |    |=

   Redirect-Address TBD15 8.66   UTF8S= tring |    |  M  |  V |

     -URL     = ;            &n= bsp;            = ;     |    |     |&n= bsp;   |

   Redirect-Address TBD16 8.67   UTF8S= tring |    |  M  |  V |

     -SIP-URI    &= nbsp;           &nbs= p;            &= nbsp; |    |     |    |

   Subscription-Id  TBD7  8.58 &n= bsp; Grouped    |    |  M  |  = V |

     -Extension    = ;            &n= bsp;            |&nb= sp;   |     |    |=

   Subscription-Id  TBD8  8.59 &n= bsp; UTF8String |    |  M  |  V |=

     -E164    &nbs= p;            &= nbsp;           &nbs= p;    |    |     | &= nbsp;  |

   Subscription-Id  TBD9  8.60 &n= bsp; UTF8String |    |  M  |  V |=

     -IMSI     &nb= sp;            =             &nb= sp;   |    |     | &= nbsp;  |

   Subscription-Id  TBD10 8.61   = UTF8String |    |  M  |  V |

     -SIP-URI    &= nbsp;           &nbs= p;            &= nbsp; |    |     |    |

   Subscription-Id  TBD11 8.62   = UTF8String |    |  M  |  V |

     -NAI     = ;             &= nbsp;           &nbs= p;    |    |     |&n= bsp;   |

   Subscription-Id  TBD12 8.63   = UTF8String |    |  M  |  V |

     -Private    &= nbsp;           &nbs= p;            &= nbsp; |    |     |    |

   User-Equipment   TBD1  8.52&nb= sp;  Grouped    |    |  M  |&n= bsp; V |

     -Info-Extension        = ;            &n= bsp;   |    |     |  = ;  |

   User-Equipment   TBD2  8.53&nb= sp;  OctetString|    |  M  |  V |=

     -Info-IMEISV   &nb= sp;            =            |  &= nbsp; |     |    |

   User-Equipment   TBD3  8.54&nb= sp;  OctetString|    |  M  |  V |=

     -Info-MAC    =             &nb= sp;            = |    |     |    |=

   User-Equipment   TBD4  8.55&nb= sp;  OctetString|    |  M  |  V |=

     -Info-EUI64   &nbs= p;            &= nbsp;           | &n= bsp;  |     |    |

   User-Equipment   TBD5  8.56&nb= sp;  OctetString|    |  M  |  V |=

     -Info-ModifiedEUI64  &n= bsp;            = ;     |    |     |&n= bsp;   |

   User-Equipment   TBD6  8.57&nb= sp;  OctetString|    |  M  |  V |=

 

Now, regarding existing AVPs with the M-bit put in the MAY= column (listed below), I would recommend not to use the MAY column but to = specific in which DCC commands the M-bit setting may change for some AVP, as indicated in RFC6733 and RFC7423. =

 

From RFC6733:

 

      Note: The M-bit setting for= a given AVP is relevant to an

      Application and each comman= d within that application that includes

      the AVP.  That is, if = an AVP appears in two commands for

      application Foo and the M-b= it settings are different in each

      command, then there should = be two AVP flag tables describing when

      to set the M-bit.

 

For AVPs for which there is no clear use case for change o= f the M-bit setting in the DCC app, the M-bit should be put in the MUST col= umn. It may be the case for all the AVPs listed below (I've not checked). Other applications using DCC commands can decide= to set or clear the M-bit of the related DCC commands' AVPs without any co= nstraint.

 

         &nbs= p;            &= nbsp;           &nbs= p;         +---------------+= ;

         &nbs= p;            &= nbsp;           &nbs= p;         |AVP Flag rules |=

         &nbs= p;            &= nbsp;           &nbs= p;         |----+-----+----= |

         &nbs= p;           AVP  Se= ction           | &n= bsp;  |     |MUST|

   Attribute Name    Code Defined= Data Type |MUST| MAY |NOT |

   -----------------------------------------|---= -+-----+----|

   CC-Correlation-Id 411  8.1  &n= bsp; OctetString|    |  M  |  V |=

   Service-Parameter 440  8.43   = Grouped    |    |  M  |  V |

     -Info    &nbs= p;            &= nbsp;           &nbs= p;    |    |     | &= nbsp;  |

   Service-      &= nbsp;   441  8.44   Unsigned32 |   = |  M  |  V |

     Parameter-Type   &= nbsp;           &nbs= p;         |    |&nb= sp;    |    |

   Service-      &= nbsp;   442  8.45   OctetString|   = |  M  |  V |

     Parameter-Value   =             &nb= sp;        |    | &n= bsp;   |    |

   User-Equipment    458  8.= 49   Grouped    |    |  M = ; |  V |

     -Info    &nbs= p;            &= nbsp;           &nbs= p;    |    |     | &= nbsp;  |

   User-Equipment    459  8.= 50   Enumerated |    |  M  |  V |

     -Info-Type    = ;            &n= bsp;            |&nb= sp;   |     |    |=

   User-Equipment    460  8.= 51   OctetString|    |  M  |  V |

     -Info-Value   &nbs= p;            &= nbsp;           | &n= bsp;  |     |    |

   User-Equipment   TBD1  8.52&nb= sp;  Grouped    |    |  M  |&n= bsp; V |

     -Info-Extension   =             &nb= sp;        |    | &n= bsp;   |    |

   User-Equipment   TBD2  8.53&nb= sp;  OctetString|    |  M  |  V |=

     -Info-IMEISV   &nb= sp;            =            |  &= nbsp; |     |    |

   User-Equipment   TBD3  8.54&nb= sp;  OctetString|    |  M  |  V |=

     -Info-MAC    =             &nb= sp;            = |    |     |    |=

   User-Equipment   TBD4  8.55&nb= sp;  OctetString|    |  M  |  V |=

     -Info-EUI64   &nbs= p;            &= nbsp;           | &n= bsp;  |     |    |

   User-Equipment   TBD5  8.56&nb= sp;  OctetString|    |  M  |  V |=

     -Info-ModifiedEUI64  &n= bsp;            = ;     |    |     |&n= bsp;   |

   User-Equipment   TBD6  8.57&nb= sp;  OctetString|    |  M  |  V |=

     -Info-IMEI    = ;            &n= bsp;            |&nb= sp;   |     |    |=

 

 

Regards,

 

Lionel

 

 

De : Dave Dolson [ma= ilto:ddolson@sandvine.com]
Envoy=E9 : jeudi 11 mai 2017 17:03
=C0 : Gardella, Maryse (Nokia - FR/Nozay); MORAND Lionel IMT/OL= N; Alan DeKok
Cc : dime@ietf.org list; <= a href=3D"mailto:draft-ietf-dime-rfc4006bis@ietf.org"> draft-ietf-dime-rfc4006bis@ietf.org
Objet : RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-d= ime-rfc4006bis-02

 

I have uploaded version -= 03 with the agreed changes to simply replace the reference with RFC7542.

https://tools.ietf.org/html/dr= aft-ietf-dime-rfc4006bis-03

 <= /p>

 <= /p>

From: Gardella= , Maryse (Nokia - FR/Nozay) [m= ailto:maryse.gardella@nokia.com]
Sent: Saturday, May 6, 2017 3:00 AM
To: Dave Dolson; lionel.= morand@orange.com; Alan DeKok
Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ietf.org
Subject: RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-= rfc4006bis-02

 

Hi all,

 

Therefore it makes sense to do so.

 

Thanks

Maryse

 

From: Dave D= olson [mailto:ddolson@sandvine.com<= /a>]
Sent: vendredi 5 mai 2017 21:57
To: lionel.morand@orange= .com; Gardella, Maryse (Nokia - FR/Nozay) <maryse.gardella@nokia.com>; Alan DeKok <aland@deployingradius.com> Cc: dime@ietf.org list <dime@ietf.org>; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-= rfc4006bis-02

 

Lionel,=

OK, thanks. I’ll ma= ke the changes.

 <= /p>

-Dave

 <= /p>

 <= /p>

From: lionel.morand@orange.com [<= a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<= /a>]
Sent: Friday, May 5, 2017 3:42 PM
To: Dave Dolson; Gardella, Maryse (Nokia - FR/Nozay); Alan DeKok
Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ietf.org
Subject: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4= 006bis-02

 

Hi,

RFC 6733 was published before RFC 7542, obsoleting RFC 4282. It is why RFC = 4282 was still used as reference in RFC 6733.
Using IETF rules, RFC 7242 should be used anyway for any Diameter implement= ation based on RFC 6733 and using NAI.
Therefore, when updating RFC 4006, RFC 7242 should be used as reference.
Regards,

Lionel

Le 5 mai 2017 20:05, Dave Dolson <ddolson@sandvine.com> a =E9crit :

Maryse,
Thanks for doing some research and pointing this out.

In RFC 6733, RFC4282 is used for two things:
1. to define "Network Access Identifier", for use as realm names,= which are "piggybacked on the administration of the DNS namespace&quo= t;
- so DNS restrictions would have to apply here.

2. Defining User-Name AVP, which is a NAI, but specifically "of type U= TF8String ... in a format consistent with the NAI specification [RFC4282]&q= uot;
- (see section 8.14 of RFC6733)
- so User-Name is defined to be the UTF8 subset of RFC4282.

So I claim that although RFC4282 is mentioned, RFC6733 intends that user na= mes in Diameter be limited to UTF-8, hence compatible with RFC7542.


-Dave


-----Original Message-----
From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com]
Sent: Wednesday, May 3, 2017 10:37 AM
To: Dave Dolson; Alan DeKok
Cc: Yuval Lifshitz; jouni korhonen; dime@i= etf.org list; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

My mistake, it should be RFC 6733
Maryse

-----Original Message-----
From: Dave Dolson [mailto:ddolson@s= andvine.com]
Sent: mercredi 3 mai 2017 16:19
To: Gardella, Maryse (Nokia - FR/Nozay) <maryse.gardella@nokia.com>; Alan DeKok <aland@deployingradius.com>
Cc: Yuval Lifshitz <ylifshitz@= sandvine.com>; jouni korhonen <jouni.nospam@gmail.com>; dime@ietf.org list <dime@ietf.org>; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

RFC4282 is also obsolete, and RFC7542 explains the problems with it.
I don't think we should introduce RFC4282 at this point.

(And sorry, I don't see RFC 6377 referring to 4282)


-----Original Message-----
From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com]
Sent: Wednesday, May 3, 2017 9:21 AM
To: Alan DeKok; Dave Dolson
Cc: Yuval Lifshitz; jouni korhonen; dime@i= etf.org list; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

Hello all,

For the new AVP, no question: RFC 7542 should be used.
I have not the full overview of 3GPP specs used for reference to NAI, and b= ased on:
- assuming the TS 23.003 (Numbering, addressing and identification) is an i= mportant spec to consider, the RFC 4282 is used
- RFC 6377 DBP also referring to RFC 4282
 
I would tend to agree on at least using RFC 4282 as the reference for the E= ND_USER_NAI in Subscription-Id-Type for RFC4006bis.
Whether to directly refer to RFC7542, I cannot confirm whether this is acce= ptable or not. 

BR
Maryse

-----Original Message-----
From: Alan DeKok [mailto:aland= @deployingradius.com]
Sent: mercredi 3 mai 2017 00:47
To: Dave Dolson <ddolson@sandvin= e.com>
Cc: Yuval Lifshitz <ylifshitz@= sandvine.com>; Gardella, Maryse (Nokia - FR/Nozay) <maryse.gardella@nokia.com>; jouni ko= rhonen <jouni.nospam@gmail.com= >; dime@ietf.org list <dime@ietf.org>; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

On May 2, 2017, at 5:51 PM, Dave Dolson <ddolson@sandvine.com> wrote:
>
> Thanks Alan.
> Do I correctly hear you saying we should replace all references to RFC= 2486 with RFC 7542?

  Yes.

  It's 2017.  Independent of RFC 7542, *inter-operable* implement= ations just have no business using non-UTF8 identifiers.

  Alan DeKok.

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org= /mailman/listinfo/dime

_=
___________________________________________________________________________=
_____________________________________________
&=
nbsp;
C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc
p=
as etre diffuses, exploites ou copies sans autorisation. Si vous avez recu =
ce message par erreur, veuillez le signaler
a=
 l'expediteur et le detruire ainsi que les pieces jointes. Les messages ele=
ctroniques etant susceptibles d'alteration,
O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. Merci.
&=
nbsp;
T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;
t=
hey should not be distributed, used or copied without authorisation.=

I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.
A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.
T=
hank you.
________________________________________________________________=
_________________________________________________________=

 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.


 


This message and its attachments may contain confidential or pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that=
 have been modified, changed or falsified.


Thank you.


______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
--_000_C43C255C7106314F8D13D03FA20CFE49A8AB727Fwtlexchp2sandvi_-- From nobody Wed Jul 19 03:19:40 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434A5131A8C for ; Wed, 19 Jul 2017 03:19:40 -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, RP_MATCHES_RCVD=-0.001, 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 6QcUaBcjSEpK for ; Wed, 19 Jul 2017 03:19:37 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEC2F131C63 for ; Wed, 19 Jul 2017 03:19:36 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-2.sandvine.com (192.168.194.177) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 19 Jul 2017 06:19:35 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Wed, 19 Jul 2017 06:19:34 -0400 From: Yuval Lifshitz To: Jouni , "'Bertz, Lyle T [CTO]'" , "lionel.morand@orange.com" , "dime@ietf.org" Thread-Topic: [Dime] RFC 6733 Commands Thread-Index: AQHS/uUJB8h6U5QREEmZorl9T0AXrqJYEfmAgAAL0HqAAscIwIAATBiA///BYQA= Date: Wed, 19 Jul 2017 10:19:33 +0000 Message-ID: References: <1500286334617.86980@sprint.com>, <8331_1500301978_596CCA9A_8331_333_1_6B7134B31289DC4FAF731D844122B36E2D1B5E23@OPEXCLILM43.corporate.adroot.infra.ftgroup> <1500303827591.97405@sprint.com> <559e01d30075$d36b13e0$7a413ba0$@gmail.com> In-Reply-To: <559e01d30075$d36b13e0$7a413ba0$@gmail.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.142.10] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_C43C255C7106314F8D13D03FA20CFE49A8AB729Dwtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] RFC 6733 Commands X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 10:19:40 -0000 --_000_C43C255C7106314F8D13D03FA20CFE49A8AB729Dwtlexchp2sandvi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You mean, that if someone implement a new protocol but does not change defi= nitions from base, not add any new stuff which is mandatory, they are allow= ed to use application-id zero for commands other than (CERA, DPR/A, DWR/A)? Shouldn't we block that? Would imagine there are implementations where they= assume zero is only for peer level messages? From: Jouni [mailto:jouni.nospam@gmail.com] Sent: Wednesday, July 19, 2017 1:00 PM To: Yuval Lifshitz; 'Bertz, Lyle T [CTO]'; lionel.morand@orange.com; dime@i= etf.org Subject: RE: [Dime] RFC 6733 Commands Unless you extend and existing application within the rules in Section 1.3.= 4 you always get a new application. And if you wish to extend the existing = base protocol application with new commands that most likely would require = a new protocol version. I think we are good here with the current text. - Jouni From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Yuval Lifshitz Sent: Wednesday, July 19, 2017 12:32 PM To: Bertz, Lyle T [CTO] >; lionel.morand@orange.com; dime@iet= f.org list > Subject: Re: [Dime] RFC 6733 Commands Actually, we may have an issue there. The spec says that zero must be used = for base protocol messages (page 23): Diameter messages pertaining to peer connection establishment and maintenance such as CER/CEA, DWR/DWA, and DPR/DPA MUST carry an Application Id of zero (0). But does not say that it must not be used for anything else (or at least I = failed to find such text). Do you think such text should be added? Note that there is such text regarding vendor-id. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Bertz, Lyle T [CTO] Sent: Monday, July 17, 2017 6:04 PM To: lionel.morand@orange.com; dime@ietf.or= g list Subject: Re: [Dime] RFC 6733 Commands agreed, we have encountered some folks tying the ACR/ACA to app id 0 in ope= n source. ________________________________ From: lionel.morand@orange.com > Sent: Monday, July 17, 2017 9:32 AM To: Bertz, Lyle T [CTO]; dime@ietf.org list Subject: RE: RFC 6733 Commands Hi Lyle, I think that there is no specific reason. By definition, the command is ind= ependent of any application. So when describing the command code, it may or= may not be contained in the command code header. It is consistent with the= CCF specification: header =3D "" The CCF is mainly used to identify the set of AVP that can be present in th= e command. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Bertz, Lyle T [CTO] Envoy=E9 : lundi 17 juillet 2017 12:12 =C0 : dime@ietf.org list Objet : [Dime] RFC 6733 Commands In the spec was there a particular reason why we did not specify the applic= ation Identifier in the header for each of the command codes, e.g. ACR/ACA = assigned to application ID 3? Lyle ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_C43C255C7106314F8D13D03FA20CFE49A8AB729Dwtlexchp2sandvi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

You mean, that if someone= implement a new protocol but does not change definitions from base, not ad= d any new stuff which is mandatory, they are allowed to use application-id zero for commands other than (CERA, DPR/A, DWR/A)?=

Shouldn’t we block = that? Would imagine there are implementations where they assume zero is onl= y for peer level messages?

 <= /p>

From: Jouni [m= ailto:jouni.nospam@gmail.com]
Sent: Wednesday, July 19, 2017 1:00 PM
To: Yuval Lifshitz; 'Bertz, Lyle T [CTO]'; lionel.morand@orange.com;= dime@ietf.org
Subject: RE: [Dime] RFC 6733 Commands

 

Unless you extend and exi= sting application within the rules in Section 1.3.4 you always get a new ap= plication. And if you wish to extend the existing base protocol application with new commands that most likely would require a new protoco= l version. I think we are good here with the current text.

 <= /p>

- &nbs= p;      Jouni

 <= /p>

From: DiME [= mailto:dime-bounces@ietf.org] On Behalf Of Yuval Lifshitz
Sent: Wednesday, July 19, 2017 12:32 PM
To: Bertz, Lyle T [CTO] <Lyle.T.Bertz@sprint.com>; lionel.morand@orange.com; <= a href=3D"mailto:dime@ietf.org"> dime@ietf.org list <dime@ietf.org>
Subject: Re: [Dime] RFC 6733 Commands

 

Actually, we may have an = issue there. The spec says that zero must be used for base protocol message= s (page 23):

 <= /p>

Diameter messages pertaining to peer connectio= n

   establishment and maintenance suc= h as CER/CEA, DWR/DWA, and DPR/DPA

   MUST carry an Application Id of z= ero (0).

 <= /p>

But does not say that it = must not be used for anything else (or at least I failed to find such text)= . Do you think such text should be added?

Note that there is such t= ext regarding vendor-id.

 <= /p>

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Bertz, Lyle T [CTO]
Sent: Monday, July 17, 2017 6:04 PM
To: lionel.morand@orange= .com; dime@ietf.org list
Subject: Re: [Dime] RFC 6733 Commands

 

agreed, we have encountered some folks tying the ACR/ACA to app = id 0 in open source.

 

 

From: lionel.morand@orange.com &l= t;lionel.morand@orange.com&= gt;
Sent: Monday, July 17, 2017 9:32 AM
To: Bertz, Lyle T [CTO]; dime@ietf.= org list
Subject: RE: RFC 6733 Commands

 

Hi Lyle,

 

I think that there is no spec= ific reason. By definition, the command is independent of any application. = So when describing the command code, it may or may not be contained in the command code header. It is consistent with the CCF specif= ication:

 

   header    &= nbsp;      =3D "<Diameter-Header:" co= mmand-id

       &n= bsp;            = ;     [r-bit] [p-bit] [e-bit] [application-id]">= ;"

 

The CCF is mainly used to ide= ntify the set of AVP that can be present in the command.

 

Regards,

 

Lionel

 

De : DiME [mail= to:dime-bounces@ietf.org] De la part de Bertz, Lyle T [CTO]
Envoy=E9 : lundi 17 juillet 2017 12:12
=C0 : dime@ietf.org list Objet : [Dime] RFC 6733 Commands

 

In the spec was there a particular reason why we did not specify= the application Identifier in the header for each of the command code= s, e.g. ACR/ACA assigned to application ID 3?

 

Lyle

 <= o:p>


This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.

________________________________________=
___________________________________________________________________________=
______
 
Ce message et ses pieces jointes peuvent=
 contenir des informations confidentielles ou privilegiees et ne doivent do=
nc
pas etre diffuses, exploites ou copies s=
ans autorisation. Si vous avez recu ce message par erreur, veuillez le sign=
aler
a l'expediteur et le detruire ainsi que =
les pieces jointes. Les messages electroniques etant susceptibles d'alterat=
ion,
Orange decline toute responsabilite si c=
e message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may con=
tain confidential or privileged information that may be protected by law;
they should not be distributed, used or =
copied without authorisation.
If you have received this email in error=
, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not =
liable for messages that have been modified, changed or falsified.
Thank you.
--_000_C43C255C7106314F8D13D03FA20CFE49A8AB729Dwtlexchp2sandvi_-- From nobody Wed Jul 19 04:04:10 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB802131CA8 for ; Wed, 19 Jul 2017 04:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_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=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 6hZb0iQn_zpe for ; Wed, 19 Jul 2017 04:04:03 -0700 (PDT) Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::241]) (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 298B5131CA4 for ; Wed, 19 Jul 2017 04:04:03 -0700 (PDT) Received: by mail-lf0-x241.google.com with SMTP id l125so88937lfg.5 for ; Wed, 19 Jul 2017 04:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-language:thread-index; bh=rDHZxAKHR0Bv4fSp5gBDu6+Gsvi3xckl5LLTIlKqpJk=; b=QxY8rsX9ZF3P1oCU2hEVKu5D9NW5CzlDqs9EQw0sQgEAHPpIzvRQ+8I6JI0rc5Vk1E UkJ1Z7mgYp9+xAnCfEKSeaDEYhxadr10YWNly1dyEG8RTIwsUlMFoQYtMCJzxLyvUdVW RRq6je/3eWyqhCYMFYS7Ndpn5GSEOsoFEOVGmoa2QA0bE/3wW+rxJ97hZERPmTO0+jvd QyDbvtoOwmxMoePfi8nws5VBLvxZDukr9x1SPDPWzCA0KTmaBv5xTjPoBHyqUJqV+bfl kZO++tm5yS8SQ+5ovFvJCRgzjs9bjjBQ6N/EVZgw2a8NW7TwlV4s6IQq8TiwqVhkS58k inXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-language:thread-index; bh=rDHZxAKHR0Bv4fSp5gBDu6+Gsvi3xckl5LLTIlKqpJk=; b=P2LnkmInm3+CcsF/+D35LqHV9SCjmAN6ZtNZcEO1eaTvHSFKyA2O4ds9vC6yKx1stS 7r5534Nu/m7w4W2d24TmMV81CNDITB5U8+ASFzY7h0FMEnyWaaGCH+UKjAfrckOazPue /CAzj2rf7TzVuvysogxo2M7Ae4V8BE3eEc8qSDG4l/YVL1euVEufiqhhoi8ZdXnogrOJ ySjNHmeRU/SvkuiUcsuMSYpcwWl/4JDFHX2No2k4g36le/7icAKQiKy1lV8bgeYQFaMQ Q12ugPqH2uMfEdc01TZvsZNopbD3i/qwVpcaTo/c1n5QQyTDIp7p9uBZO6haAA3fcYNm tAvg== X-Gm-Message-State: AIVw1106W42ZtKLR/qs8JrHwoOwawMTg3k0rTKtImEIyJt5ycsjIM/yq 9/wLTHYpZRUM2qhG X-Received: by 10.25.233.15 with SMTP id g15mr1908717lfh.161.1500462241247; Wed, 19 Jul 2017 04:04:01 -0700 (PDT) Received: from JOKO ([83.150.126.201]) by smtp.gmail.com with ESMTPSA id g1sm17959ljd.91.2017.07.19.04.03.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 04:04:00 -0700 (PDT) From: "Jouni" To: "'Yuval Lifshitz'" , "'Bertz, Lyle T [CTO]'" , , References: <1500286334617.86980@sprint.com>, <8331_1500301978_596CCA9A_8331_333_1_6B7134B31289DC4FAF731D844122B36E2D1B5E23@OPEXCLILM43.corporate.adroot.infra.ftgroup> <1500303827591.97405@sprint.com> <559e01d30075$d36b13e0$7a413ba0$@gmail.com> In-Reply-To: Date: Wed, 19 Jul 2017 14:03:59 +0300 Message-ID: <561801d3007e$b95bd940$2c138bc0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_5619_01D30097.DEACE1D0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQJ4SKXtVleed+r8bygyRJbzSNgxvwI0ElhcAq0/UBgBqfvIxAIor9D3AXCTSNigv0RKQA== Archived-At: Subject: Re: [Dime] RFC 6733 Commands X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 11:04:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_5619_01D30097.DEACE1D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you go for new protocol version that opens a door for a lot of = things. Generally adding commands to base protocol using app-id 0 is not = possible without a new protocol version. I do not see a reason for any extra clarifications. I would be reluctant to assume app-id 0 is forever for = peer level commands. We have other ways to impose that restriction at the AVP level where such things actually belong (see Section 6.1). =20 - JOuni =20 From: Yuval Lifshitz [mailto:ylifshitz@sandvine.com]=20 Sent: Wednesday, July 19, 2017 13:20 PM To: Jouni ; 'Bertz, Lyle T [CTO]' ; lionel.morand@orange.com; dime@ietf.org Cc: Yuval Lifshitz Subject: RE: [Dime] RFC 6733 Commands =20 You mean, that if someone implement a new protocol but does not change definitions from base, not add any new stuff which is mandatory, they = are allowed to use application-id zero for commands other than (CERA, DPR/A, DWR/A)? Shouldn=92t we block that? Would imagine there are implementations where = they assume zero is only for peer level messages? =20 From: Jouni [mailto:jouni.nospam@gmail.com]=20 Sent: Wednesday, July 19, 2017 1:00 PM To: Yuval Lifshitz; 'Bertz, Lyle T [CTO]'; lionel.morand@orange.com ; dime@ietf.org = Subject: RE: [Dime] RFC 6733 Commands =20 Unless you extend and existing application within the rules in Section = 1.3.4 you always get a new application. And if you wish to extend the existing base protocol application with new commands that most likely would = require a new protocol version. I think we are good here with the current text. =20 - Jouni=20 =20 From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Yuval Lifshitz Sent: Wednesday, July 19, 2017 12:32 PM To: Bertz, Lyle T [CTO] >; lionel.morand@orange.com ; dime@ietf.org list > Subject: Re: [Dime] RFC 6733 Commands =20 Actually, we may have an issue there. The spec says that zero must be = used for base protocol messages (page 23): =20 Diameter messages pertaining to peer connection establishment and maintenance such as CER/CEA, DWR/DWA, and DPR/DPA MUST carry an Application Id of zero (0). =20 But does not say that it must not be used for anything else (or at least = I failed to find such text). Do you think such text should be added? Note that there is such text regarding vendor-id. =20 From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Bertz, Lyle T = [CTO] Sent: Monday, July 17, 2017 6:04 PM To: lionel.morand@orange.com ; dime@ietf.org list Subject: Re: [Dime] RFC 6733 Commands =20 agreed, we have encountered some folks tying the ACR/ACA to app id 0 in = open source. =20 =20 _____ =20 From: lionel.morand@orange.com > Sent: Monday, July 17, 2017 9:32 AM To: Bertz, Lyle T [CTO]; dime@ietf.org list Subject: RE: RFC 6733 Commands=20 =20 Hi Lyle, =20 I think that there is no specific reason. By definition, the command is independent of any application. So when describing the command code, it = may or may not be contained in the command code header. It is consistent = with the CCF specification: =20 header =3D "" =20 The CCF is mainly used to identify the set of AVP that can be present in = the command. =20 Regards, =20 Lionel=20 =20 De : DiME [mailto:dime-bounces@ietf.org] De la part de Bertz, Lyle T = [CTO] Envoy=E9 : lundi 17 juillet 2017 12:12 =C0 : dime@ietf.org list Objet : [Dime] RFC 6733 Commands =20 In the spec was there a particular reason why we did not specify the application Identifier in the header for each of the command codes, e.g. ACR/ACA assigned to application ID 3? =20 Lyle =20 _____ =20 This e-mail may contain Sprint proprietary information intended for the = sole use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. _________________________________________________________________________= ___ _____________________________________________ =20 Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. =20 This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. Thank you. ------=_NextPart_000_5619_01D30097.DEACE1D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

If you go for new protocol version that opens a door for a lot of = things. Generally adding commands to base protocol using app-id 0 is not = possible without a new protocol version. I do not see a reason for any = extra clarifications. I would be reluctant to assume app-id 0 is forever = for peer level commands. We have other ways to impose that restriction = at the AVP level where such things actually belong (see Section = 6.1).

 

-        = JOuni

 

From:<= /b> = Yuval Lifshitz [mailto:ylifshitz@sandvine.com]
Sent: = Wednesday, July 19, 2017 13:20 PM
To: Jouni = <jouni.nospam@gmail.com>; 'Bertz, Lyle T [CTO]' = <Lyle.T.Bertz@sprint.com>; lionel.morand@orange.com; = dime@ietf.org
Cc: Yuval Lifshitz = <ylifshitz@sandvine.com>
Subject: RE: [Dime] RFC 6733 = Commands

 

You mean, that if someone implement a new protocol but does not change = definitions from base, not add any new stuff which is mandatory, they = are allowed to use application-id zero for commands other than (CERA, = DPR/A, DWR/A)?

Shouldn’t we block that? Would imagine there are implementations = where they assume zero is only for peer level = messages?

 

From: = Jouni [mailto:jouni.nospam@gmail.com]=
Sent: Wednesday, July 19, 2017 1:00 PM
To: Yuval = Lifshitz; 'Bertz, Lyle T [CTO]'; lionel.morand@orange.com; = dime@ietf.org
Subject: = RE: [Dime] RFC 6733 Commands

 

Unless you extend and existing application within the rules in Section = 1.3.4 you always get a new application. And if you wish to extend the = existing base protocol application with new commands that most likely = would require a new protocol version. I think we are good here with the = current text.

 

-     &nb= sp;  Jouni

 

From:<= /b> = DiME [mailto:dime-bounces@ietf.org] = On Behalf Of Yuval Lifshitz
Sent: Wednesday, July 19, = 2017 12:32 PM
To: Bertz, Lyle T [CTO] <Lyle.T.Bertz@sprint.com>; = lionel.morand@orange.com; = dime@ietf.org list <dime@ietf.org>
Subject: = Re: [Dime] RFC 6733 Commands

 

Actually, we may have an issue there. The spec says that zero must be = used for base protocol messages (page 23):

 

Diameter messages pertaining to peer = connection

   establishment and maintenance such as = CER/CEA, DWR/DWA, and DPR/DPA

   MUST carry an Application Id of zero = (0).

 

But does not say that it must not be used for anything else (or at = least I failed to find such text). Do you think such text should be = added?

Note that there is such text regarding = vendor-id.

 

From: DiME = [mailto:dime-bounces@ietf.org] = On Behalf Of Bertz, Lyle T [CTO]
Sent: Monday, July 17, = 2017 6:04 PM
To: lionel.morand@orange.com; = dime@ietf.org = list
Subject: Re: [Dime] RFC 6733 = Commands

 

agreed, we have = encountered some folks tying the ACR/ACA to app id 0 in open = source.

 =

 =

F= rom: = lionel.morand@orange.com = <lionel.morand@orange.com>=
Sent: Monday, July 17, 2017 9:32 AM
To: Bertz, Lyle = T [CTO]; dime@ietf.org = list
Subject: RE: RFC 6733 Commands =

 

Hi = Lyle,

&nb= sp;

I = think that there is no specific reason. By definition, the command is = independent of any application. So when describing the command code, it = may or may not be contained in the command code header. It is consistent = with the CCF specification:

&nb= sp;

   = header           =3D = "<Diameter-Header:" command-id

         = ;            =     [r-bit] [p-bit] [e-bit] = [application-id]">"

&nb= sp;

The= CCF is mainly used to identify the set of AVP that can be present in = the command.

&nb= sp;

Reg= ards,

&nb= sp;

Lio= nel

&nb= sp;

= De := DiME [mailto:dime-bounces@ietf.org] = De la part de Bertz, Lyle T [CTO]
Envoy=E9 : lundi = 17 juillet 2017 12:12
=C0 : dime@ietf.org = list
Objet : [Dime] RFC 6733 = Commands

 

In the spec was = there a particular reason why we did not specify the application = Identifier in the header for each of the command codes, e.g. = ACR/ACA assigned to application ID 3?

 =

Lyle

 =


T= his e-mail may contain Sprint proprietary information intended for the = sole use of the recipient(s). Any use by others is prohibited. If you = are not the intended recipient, please contact the sender and delete all = copies of the message.

_________________________________________________=
________________________________________________________________________<=
/span>
 
Ce message et ses pieces jointes peuvent =
contenir des informations confidentielles ou privilegiees et ne doivent =
donc
pas etre =
diffuses, exploites ou copies sans autorisation. Si vous avez recu ce =
message par erreur, veuillez le =
signaler
a =
l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles =
d'alteration,
Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. =
Merci.
 
This message and its attachments may contain =
confidential or privileged information that may be protected by =
law;
they =
should not be distributed, used or copied without =
authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its =
attachments.
As emails may be altered, Orange is not liable =
for messages that have been modified, changed or =
falsified.
Thank =
you.
------=_NextPart_000_5619_01D30097.DEACE1D0-- From nobody Wed Jul 19 04:56:05 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B91131CD6 for ; Wed, 19 Jul 2017 04:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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 yHlLe_rf9ZJ1 for ; Wed, 19 Jul 2017 04:55:58 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0115.outbound.protection.outlook.com [104.47.36.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 608B3131CD5 for ; Wed, 19 Jul 2017 04:55:58 -0700 (PDT) Received: from CY1PR05CA0007.namprd05.prod.outlook.com (10.166.186.145) by BN1PR05MB437.namprd05.prod.outlook.com (10.141.58.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.4; Wed, 19 Jul 2017 11:55:55 +0000 Received: from BN3NAM01FT011.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e41::209) by CY1PR05CA0007.outlook.office365.com (2a01:111:e400:c5a4::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4 via Frontend Transport; Wed, 19 Jul 2017 11:55:55 +0000 Authentication-Results: spf=pass (sender IP is 144.230.32.80) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.32.80 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.80; helo=preapdm1.corp.sprint.com; Received: from preapdm1.corp.sprint.com (144.230.32.80) by BN3NAM01FT011.mail.protection.outlook.com (10.152.67.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1240.9 via Frontend Transport; Wed, 19 Jul 2017 11:55:55 +0000 Received: from pps.filterd (preapdm1.corp.sprint.com [127.0.0.1]) by preapdm1.corp.sprint.com (8.16.0.17/8.16.0.17) with SMTP id v6JBiBfN024442; Wed, 19 Jul 2017 07:55:54 -0400 Received: from plswe13m04.ad.sprint.com (plswe13m04.corp.sprint.com [144.229.214.23]) by preapdm1.corp.sprint.com with ESMTP id 2bqfhf41na-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 19 Jul 2017 07:55:54 -0400 Received: from PLSWE13M04.ad.sprint.com (2002:90e5:d617::90e5:d617) by plswe13m04.ad.sprint.com (2002:90e5:d617::90e5:d617) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 19 Jul 2017 06:55:53 -0500 Received: from PLSWE13M04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a]) by plswe13m04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a%24]) with mapi id 15.00.1263.000; Wed, 19 Jul 2017 06:55:53 -0500 From: "Bertz, Lyle T [CTO]" To: Jouni , 'Yuval Lifshitz' , "lionel.morand@orange.com" , "dime@ietf.org" Thread-Topic: [Dime] RFC 6733 Commands Thread-Index: AQHS/uUJB8h6U5QREEmZorl9T0AXrqJYEfmAgAAL0HqAAscIwIAAXNyAgAAFYoCAAAxqgP//uZFl Date: Wed, 19 Jul 2017 11:55:52 +0000 Message-ID: <1500465352738.7744@sprint.com> References: <1500286334617.86980@sprint.com>, <8331_1500301978_596CCA9A_8331_333_1_6B7134B31289DC4FAF731D844122B36E2D1B5E23@OPEXCLILM43.corporate.adroot.infra.ftgroup> <1500303827591.97405@sprint.com> <559e01d30075$d36b13e0$7a413ba0$@gmail.com> , <561801d3007e$b95bd940$2c138bc0$@gmail.com> In-Reply-To: <561801d3007e$b95bd940$2c138bc0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.229.91.96] Content-Type: multipart/alternative; boundary="_000_15004653527387744sprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.32.80; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(39450400003)(39850400002)(39400400002)(39860400002)(39410400002)(39840400002)(2980300002)(438002)(51444003)(189002)(199003)(377454003)(9170700003)(478600001)(106466001)(19627405001)(14454004)(50986999)(2201001)(36756003)(76176999)(30436002)(53936002)(117636001)(38730400002)(84326002)(54356999)(236005)(93886004)(6246003)(54896002)(3846002)(97876018)(102836003)(512944002)(6116002)(2950100002)(8676002)(2906002)(229853002)(626005)(4546004)(5890100001)(5660300001)(53546010)(356003)(81166006)(2501003)(7736002)(189998001)(39060400002)(5250100002)(8936002)(2900100001)(86362001)(19607625011)(19627315001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB437; H:preapdm1.corp.sprint.com; FPR:; SPF:Pass; MLV:ovrnspm; MX:1; A:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN3NAM01FT011; 1:uQv4zpoeqwV4DkvcWU8XjQ+ciUmlYhNCBqmKY+6cOCVLsk8su2VQYbXTtRX9VeyR986+eYpJ2kwuwxbY3wpkWB3d5Mc3ToOtQQt5Icnb6pm23bJIy6yLV1EpRbv4kIvlLl2M8vg8RPyStu5oUAZGIMFSFux5eg4yJJjrjkYeRAsEtp6/RJVyf1XtY1/ZOl1ragT7S3gpTOzB6zOmaLCT9THXDN7scUf4nmTAs+63ukruktbQ2OtPn6nTdizC5dfs80moYdRilQFGtLiD9vAKMg3k/1EFnHeGQAd5lrio/RTmbW1zhNGXrRRrH2z9S2x4h4CDhh/C15TLKg1M+AmDB1TgKxJJl8lJenMZMUuS52nYQSK7+t4jbE0mYXGMf6UTX3DxG5YDDKrmqOwkpY+FBtLE+ExKWrn3plzkdDRW8FvLgZ3mIM8F5tfd6qXhO15rKoRPTDhriDsHRhroaHUgv0HkhQwW+0d7jCKtUijK7i/Zm6wNG7zgYfdsrYrxEMqdQByBdDdg8STKQHPzsTcuUXojoTzrMroDVClerwOYVAE4RRYXyMeeb5nTIXIVyQygPjMBz/4IXdZ/y0Ad77/5euSl7Kp72dEX/cPBMa7Hch9va62h2y6BfW0X0IC95PQebaCVL6upoyQy2P4qZEDrnmMfWv06dP33VYqWBdliN+gqIet9CVTDSxYsnSz2CHDOLzI8OFrYcpUN4Q4a0JDMr/d7EseOz3o2RiefmcAvV4+zhCDDfGq3JH+VsuT+bNF1O4n7uxnEzEPNlPIdWfs9YC8xTVXnJeFuiQPEbg5G+RWhSri4KqECnrzA06VZf0W4mAzzv4pPYdHmN3zRo/am2U7RImDpt9D++K1f+Yg51AzUDTAXSZp0mvsRZvrI2CVH+bFtPrL5NhYZ4dU9Z3CqT/UhPZ5GdNaPchsja6ONTPA= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4afb96a6-0fa6-444d-88af-08d4ce9d1ca3 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(8251501002)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN1PR05MB437; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1PR05MB437; 3:7sWVSVY2Ft3Lcl3ETWAO52D74DSiwPj/E4IGGER0hXs?= =?us-ascii?Q?DAzIr3pKcUmfvErjf2Z68+3DGatXcXRGUmBv2Xmof3usjN6wCYMkd4JRnG4F?= =?us-ascii?Q?/Ga6NyD12WH00ATFEX3wEFP6gCUYH9Zk5YKtE4hyVw1fyfoorIdYskeEsIhY?= =?us-ascii?Q?ws3fyzY+3lmPLL/aR4XJxska1rA14VRVatOuvXKuSXoKxaHdTsRp+mwLlrd4?= =?us-ascii?Q?vSte5ANbr5xRvosGOhO2HpjzWpK8//Zbq5Qbt9Mqbwlal1hZFXcxy3w4MbGX?= =?us-ascii?Q?cVYDuW0jb9fbkV0/k2CiEZuLDJsEGV0Px6O11G3x8rsbh4aMUV6wKZnd1sdL?= =?us-ascii?Q?b0AonMzwySck4no1NdIonJg446QMl9ztqfQKcaENEwtrxiuTV64eLJdPo+h0?= =?us-ascii?Q?Ug7K6Oc7xFJXbm2yzxsaHAzdpw9GLoovXeC13SPnwN/denA5gOyrmQ8kX6Oh?= =?us-ascii?Q?MXkS/3+uW6a046VzVaxE6RzE7L9U9ZHnYAqMXCN6zOgjemSoRQH7Zcr1LtAv?= =?us-ascii?Q?3kIbx5SdjZl6c0M7kHt1Wj1ovbaX43x4vCavYyXgpglgdbe7TiMjBP0f2cK7?= =?us-ascii?Q?fqCfgHRCaRKU/q/vdQ8Ftjct/ThZngAdMyVq4R4D3OkV4+At0ZSTW3CVTqAh?= =?us-ascii?Q?i4SbavxVCWDEwjOPaBFe3kuIkSyDGpkKWv0y5hQDBBQAnUYoeXTV7VkiOyje?= =?us-ascii?Q?mdOHUk06U08B5MSlJavAhUkV5pMXWFexpodvMmeRmvm1neqm/t7vWwT4+IGg?= =?us-ascii?Q?r2waelixsLPskMB3tJAUkpxCrZwQ4q0VmR40tG3CN8/6xZrHv+fB3gk7OD//?= =?us-ascii?Q?m6BNENH7UbIzxcenAa0BLRS9xZhw2uQf35Q6jpeYHrSPPbGfPMuSYNFw+kld?= =?us-ascii?Q?KqU2iPiHwCeJ71tdS3RPuN6JZWaE872KHcTF49gkK6o4FaUkni8/tjnrvXrq?= =?us-ascii?Q?j2zIkzn6IFFI38LzcyLCmCTe0NpkM10hxu2QvEw=3D=3D?= X-MS-TrafficTypeDiagnostic: BN1PR05MB437: X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB437; 25:I4XDE4OTOo8aRy4nJNJe7S7BFGOQ80SSjE97bR5QgW+KLhdBqMoAE1LobW1rbWB0HPE+42+psTpbjlVGwHnJWcbFDIXbyWLf20lGlR9EJqZBi28KAhRmgMyqKlcTO6WCgMCNn1jI3k6lFPOGFCNk2GqPm9+EZWaPY/z9o7b8GMAnciFPcF5y+MQ0N6FJ4wS/IqlNRCpZSTlWH5aVzH/HpbqHsDNNj7MYLh2b9BmLnfPTRoN0EEkoWn1KMuf2yO8/7Mz3KY02NYX8nwfeBPIU/ghPYDjUeu7I8la4K6eGHG+/4OWEEc5Qy+R6+ONEe2Qrz/uh9H8AxSe1aL6XFi6taAh1kzhTvTUegneMH18Jh33iunu4tgaq5If2EzhN77hCAdVgGArUQ7FEnhUDQclP3hrmNfAB/KUbVYV5/gu2kyuoe1xjBnIp2I5qW6UD0vY9h6jhZ8JVSpUcPJMpkiJvcWfGV/da6Tbw1xc0wlG1LWAkm00Avmc8RtSgCRAJaTmds7ZszHKcSTfZuAWr2Bbt4+PDdXy8d1IQgsSHB5S14lda85xZ7YFEknoYr9DOVVqPbYxKvQVgNWzAEjY3OK/qQ39lw8OjK1F/UL4B2jr4t150o2dKeQy+5HM7+Vm81Wk/BBRFdEIGKILy+8UIxhKJqrrz+kEngt1IPEhgliHFi6CtcIxIdFIaKCuMO0d1QQH71dC63DPrCp7sdLcdbr5DatUJfUxadVeNSWRgHSXeQXBifvuBXd0FkJfbNZ0gcJAYFDgDhpxksgYB/h4YucvTbauj7Dmve+jpE7ePxqzu7aM4GupyyqDffatXGCpcuT9PY/jRMH2k70laRTA+YCYJQNRjvwSbSBfxmAGbre9v2OtwSrOIXZjtB7TGkSzclTs4Rw+GVUyRZHtL7yHzhBP2TnWSH2x+c1/7ArS1ZpgZ6cA= X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB437; 31:fDhpEVWMbgP6efKsg4EpRJ7Vfg/fR0tiLUZbeOCGpNStGzL7wWme4+Nq3oss4EXHvvSxMHLoceEfxm0jPZ4Uruz7Jd82C1l86GYKgPzGI3wmTS42NA+SBUPRn/zgDEgaz9hPclwfbHh7Jnby2M3A5NY7euqtuSo+rhfLpz84Hjuc0hghe2xZdl0CslHmEhbZkVM9n85nVtJyvC4ALh0xdKlRGd7uuA0F7N+QeYT+K/rgYhzWh7rEcNVwdjKp+SF9ymf2w6586celXfCQHIjJVxKMAKdGL523Lc10++eJgnV+e4U7aiF1ehna2g57kvi8GsOYd2XEbIkxTzbwOL5g7vea54HqzXXIzu/IDyRkDKChZemTUOvDMDlhCBMsFo3rzyINEkRTonQw4gi9ett3Mv5BUOMeBews8q6Hjdh4GMRiiwXobp0ykOJGTgS0D3g1yYecNUKId/SI0p0ugWsE+ZftQZfsMozVbua5CuKC2Ef8XFRDH4wX1bftIzrlqY/H2pKRbFW3qHBJ103Z0gR99jTVYw0Mkxba85Cc98hYVjO6VqAcXMpSNnBzehbQXSLLQlaIgvYLBTYFzEGi8vxCWiEqyNAkHhkvJcQhmQeEewGSUM+lURGjQRe+eI8EraCSyM/0osHqBncL+hoCwKavPtpft8zPsiLYKW1fk0roRVO8u0tPH1M96Z+GoW3YMBOEKL7Grfn8wxjMgWp5C3vH1Q== X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB437; 20:g61hlZRK5YvYIprJJvQWEl4vXmy8LIULnooSP25LkOd+toGorADyEP0Gpp36n5UEPUbLyOuveh4U0Z7L/P16wSZdiXYvYjjARaZ33INzmTb2U5W3Od5QUdlukEoHXbdsL1+CflRmK/m9K2aMcMcHytn8DQmW82PK2E2ueFcaVqmYDHbEMCFANWFHKuK/O2qCJOq8q67QVmh8l0J+eyubdURMFMNBIXZhlGUzJBtyyPg0SfjgDgdUvAZz/84LuwFOUVWz66B1P3bXhOdnF0snMulIBmnzCJjPdGN+6FlXQYkHsO12Ewg+2WOUnpqDZCWNJby8/UJWCXSlpE8AH40SWdsmEVx2q2xDOTLHlDCTgYxGuS0YwJ7X+Vw2fnbhRsP+PLevjRR5UaGEFdUUsABVkaeVZIWRB5OWososKV0LOG49nK9rl0leTiUEFHeM02f25tgLjUknx2FCXtGPFgKrrKL7w4pOiMR2lwghmJeKyuO7njL5VacKcN7BtcdxPmcA X-Exchange-Antispam-Report-Test: UriScan:(278178393323532)(236129657087228)(18430343700868)(148574349560750)(18271650672692)(209349559609743)(247924648384137); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(13018025)(2017060910075)(8121501046)(13016025)(5005006)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93004095)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123555025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN1PR05MB437; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN1PR05MB437; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1PR05MB437; 4:dVUy9MvH6Ij3gLYaxq4SPvemsCvJMYC9lJmI4rgsrW3?= =?us-ascii?Q?/L/LONWz4ZcJXdb0dvcUumNzUg3QQyWNa38qtn5xCH6CMqgjopGbr12sYp1/?= =?us-ascii?Q?KmVihKyu4tlQXtgwSo2rcEAPvlzZ0PQvrWTAyrftSB6y+BHGXJ4RLU3X1iuQ?= =?us-ascii?Q?/qX8N6vLVSrwLryotF5kLnG5noITnHX1BcIuNZfsrhRew9RsHx570EgSHAky?= =?us-ascii?Q?BhoH99Q9DPrblijKSgcqQre92xf0BV762/H7e+kFEdGcub4HWkCusM5qBDWX?= =?us-ascii?Q?pp3avML8cju97NbWAoFw5RvGRYwCcrlKyim3swbUblnWrh0rw6RJrZJvRUu+?= =?us-ascii?Q?xQ7FViH90KzHlx+h5uEKpKgyRehfXamHqqi4HS0iVdRZ7KaQCuocMxKid7Wp?= =?us-ascii?Q?vxYDZV35peDl6f02sJHsszWeDbRyZRC9/+2E6FgbaxlJ93wLnZmM/Of7YJqy?= =?us-ascii?Q?9KWE8nPRxWX6wS2+AJj77/6y7JO54TKaVv24Gyn0/fGPitjQ20Ev+mwPw2YV?= =?us-ascii?Q?VDZoShKIoKLhFvdLUBPTo+gHhT3cf5vphhXVvjuSyfeQDvbp5D2N6WExDXks?= =?us-ascii?Q?X5b8lyvQNWosSeyGTbqUdjSvEvZJA0dg/odhZ1BdFWvCLE5vLPq3yYDCvwP5?= =?us-ascii?Q?6ugTFLZCSi8Sa834fcXIDZFLyG7FDLW0+tThilNvhD4njeMdF6P3iVDzQYfN?= =?us-ascii?Q?qjH3RdWj7UgM20hgxDOkK8ePcCg7Rp6a9OB3AK9N20HkZLLv76gKmyqOaffX?= =?us-ascii?Q?J1dMk+LwY7N6urwUuC0G6oyjGx/r3ZoRcBvKHq9d0jIxdtugW0qY2t3Gs9XQ?= =?us-ascii?Q?jY4U5vkklAaMrIb7p2wgt/4ED2ut1AEkBzIPBk23WtfBAERHe2EmM+Ocu5Ij?= =?us-ascii?Q?rtXk6vnxeUjShNrS+TaSXBMaRvuAdkvR0851RiHjqyBtmhwyw5vOuk6+wPCr?= =?us-ascii?Q?pgRrHMnTWnpZxc/YdOPPM+dxz7TGldZ9SsgagxuPzLbiSpq3MfpogmO91xFk?= =?us-ascii?Q?VBHJViz/xlL0EqnO0xJhsZ0bAVBsyahOLJERLewkBVvASg9VFl+kvNsH2k+s?= =?us-ascii?Q?Ub+EKdNe+5JuOF0DNPMknSIzIgwl9SAD0+ZG3/aT3kotsuzDUESNbqG5HJ9l?= =?us-ascii?Q?58t+4D8J8hIzCqveA7ooPNNxZ04xNWrzrOl+Y/+cyxNEFU3mQ7lLjFxDsvM5?= =?us-ascii?Q?f+kc3+2vgus4lJ7fk+Dri2ENuMI7U7f7w3IoRhIcATdIWcP+mauznjJ6OTy+?= =?us-ascii?Q?/2R/We2J9Z7+eFiOyQkZluRykDKL26BvM6nu5YxsDvUbl5VUNz7BfTdIgkwb?= =?us-ascii?Q?qYw3rbGFzCjV4UpiaxxMSdO9VFEG+p0/3MoSTXagkHBafxWZyHbtCTt9UX2J?= =?us-ascii?Q?7M7bRZwX4u/pTswx0RbWd3IY902oj+5tZJ4gd5m6Z4enWgR3uggQrOlz50T7?= =?us-ascii?Q?kvVcYW1cJbagCcQRzKi+e6CNMbee05bvU9vg98cLoVRDNNJy81ILvf6HAfN/?= =?us-ascii?Q?+9RyLquowHA=3D=3D?= X-Forefront-PRVS: 0373D94D15 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1PR05MB437; 23:e/T7JpxCMm7h76zKncdFtQBK1SVCCQhIA+Uq9gfrAJ?= =?us-ascii?Q?WqibKiFFunJwryOnofJHJzwDzHq0yZJ9X29kVBuotK1OIvxUugxtURUramzN?= =?us-ascii?Q?JqZ35NGuNKlUDJOXYj+Ca9uXRRprapDF+kRhZtgEsqB26kjDVzswBE+hLY2Z?= =?us-ascii?Q?81zAoX621NhMxSJLBf2Rj0Si5Yiv1n25BEcZF5L+SzG9cJUOIRuTVZgeF7/T?= =?us-ascii?Q?Gxdlix16SXJqiTP0CrEvoiml2JkquPxdwMzgEtsLaGRMIYcWGAWMdCmyvJ9g?= =?us-ascii?Q?SumKogKzn9dxrkWWa2YdTXREjVrjWHetdtUZmM2OuyPoey1EJJbLAkxGZS7T?= =?us-ascii?Q?hLmeQt4C0nDMBZxuVHKJxOxV+ChwsWRkohmFanCcZ47dK7U8aP6wXUaawkgH?= =?us-ascii?Q?3FuTWDw3iDyRl2qic9rF3HbnHMg9MVIIkJZ/s8xdDl6euEspVPJ7SjJWhrMK?= =?us-ascii?Q?QyPBSVCscN0YkW5NiJtb9uMXtrGp0zqPg/hwd9tazaywv4rLljx0BjTRqaYN?= =?us-ascii?Q?hFmHr13ehr4PdeDianpvXqZ+jZMF8+otexJKeDHhBi5mlEnpibOmpvXP9r5+?= =?us-ascii?Q?djvDnZ1R9LxCE1FsgJiBMZ/5mWOz+s6kukFc321/i3/7YwH69PowElfIYZPu?= =?us-ascii?Q?rvU3aHsoKMo3gObtfLQhuPCIbOj3rD7dksmtlfP3VyOq3u7D9vz0UG3JbOKL?= =?us-ascii?Q?+FFyhbHQZoCf3kJGQqZy6PLj2NEkYSyrIhYX4OwXa+82YsVMQ7aqAVquas/V?= =?us-ascii?Q?TVnUyCsnX6FQAh2h0Gdm03ta3jDJSpdQshzcrwUCh2tg3dnOA7u+yBNP8I+g?= =?us-ascii?Q?G9FOHeS3Ho5L2OmNt9Qr1dtTqbKlOWVt11C262BUfAVtXw+91EJQe1lgZQLs?= =?us-ascii?Q?/xj46v+Ua9CWkMaERtmdENJfJbeztgwTfv0pwD94/AGX/8FMi8UIG6lmXetq?= =?us-ascii?Q?kHcGX2h1cANjP9An031SeQUr20AxBZSXKcXDVZEcBfZGCfvFmEzBHakocube?= =?us-ascii?Q?ZKimIRRTjXBmDUV725COxWlNGFF3eCgzMwuVMhEfNmJb5BtR2qcLJ+oA2NL0?= =?us-ascii?Q?gFl5hw9L/iCGI6XhSmqqXY2bFpgSLHDym0fUpncwRiQ04se9p923QKeeCwaW?= =?us-ascii?Q?U8SpbzH/vc3GsclLI/o+JuKB5+KTGcVFuf+0jItzn0cx/V1WHNneMcdKyMrR?= =?us-ascii?Q?q+Nhu/jSW4tiluh+ycb0AHchLRRVT2GDF8ibLw/+8qD4XyV7qj6NNgVVY/Pc?= =?us-ascii?Q?t59D1/EsBtsYu7TgOOzHHxcptpxCUfiOPprWvmla6ogn53QHOgfd447HLIKl?= =?us-ascii?Q?9buPOWT/5kP1/70M/y+xCTJGOc0tnxx/T9oR8EC7VNcHHj6GRX4cSexcRYJz?= =?us-ascii?Q?yTgEAKQqP7e7V3y6m0qRzlbdMozvfPM6OK9hbA6soI7U3p?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1PR05MB437; 6:CjTRc6K9cJp5cuE089ksJ0s6n/F8QKRTOlu8tcmuivD?= =?us-ascii?Q?1RzaqnAQgTVGLDYHZxVgdfpe6U8ZqfxFdX2mIfKftmEE0jACft2/8I+CQgyE?= =?us-ascii?Q?3DLmbwzEs3x+ycf8nWWFGFDmLSrfbdykVKUszSCjhBWqvGfy+OBM8pCLbcON?= =?us-ascii?Q?gt7yr3CqBBefad/wyU+LdprZcXFgXO7/UoYmJDQ68AVt+6wtFIwcZneuXCQg?= =?us-ascii?Q?9GBhszZ8MIxJ9VtlzHDOhbHm7e8SqTxL/Lfm0/XL+s6fywTv21UGi65x+ybz?= =?us-ascii?Q?cgOOLT+bbCTUdxih9GVW/Rl0FSJMoVyvGe190r9gEhXB+Mr8+KBXz4rrRmKt?= =?us-ascii?Q?dG0OlRKeA+S2Wb4fo8hvrQvtZdCjuSkVGCb6llnp5zU0I1kw6PqZDGbrOrsR?= =?us-ascii?Q?/McbGgxmchkMZHIsB7wILzKg1WF81RxA8xdGoSW2Y6t5ofwJj2X447i61wfU?= =?us-ascii?Q?cgd6lCLUUdL0tuKD/DBVgDgMliFqupgMu5Y8oTXn+gNRqJ+4bz9Sr4PEBKS/?= =?us-ascii?Q?TB2fgyMJG4sWp5eghwcBl/tqTKCEECLf+6tFmECxKcpcBbm+1JRlkZcfN6iA?= =?us-ascii?Q?NKpVYJRWKtNizB/BAyW21A8BB9wzZEaLPaTXCNxlWG5sYru/DQblkdMcuIm7?= =?us-ascii?Q?uDBvy29pz/U2IuGTvBIOtgZyZEhVCNHAv338CYiCadZ1iXbDBDFxvFqKZjGs?= =?us-ascii?Q?8hoOq+gf8SRJJpnkzf8dU32f1gp7VhWpPn8e+FcrUYVbnF7N9S4n6VFsLL/P?= =?us-ascii?Q?c7Ei+luuNBfhYADR7uZ7PLUQxwHTCLdhHwp0eTz4vxQe6VeyyEe+0Fz5PJdO?= =?us-ascii?Q?AsUHdXl4o3JtlLgE0Bheb+48SQXVg05F8oH0YCceo0N9Wi4pSITsCraMK1hZ?= =?us-ascii?Q?0luZSkyTTtlRgLJLw+sAu5uU0ccq6NGGrg2hU5XqAU91OmiV8LKJ/DikSpqk?= =?us-ascii?Q?kRawNp7LCHGDntUjYARTX8XwFMwBNmg9NGBFdfG2wCGfKd1D0sC9Aff+dU68?= =?us-ascii?Q?DOJcvkPvZ2MB0foHXlukO?= X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB437; 5:bi2TVB/0dg8vubMYOkEexTnAnnrhq9v9iq77cXjg3qg3+b8IfjH6Q1WBTGQlvYobu+vulNp/yAYyO8crD1HqXQMLgNUb+54vWqK56K/xbS/PAd5c7jTh5Meu96A0Reu6wrktAGmkSH/hQLtNE4qHKQv293hLsn6rqsJI0BPyMgNKnso1lVIsJJuq3TiakQWXh26hzL2+iivGhxWGnmZxO6iPEVyceXzuIsEEioT/3TaFWXZxMNjZiP8TaIO71rjyCXJ0TmOF2VGuQnvc8LjY26itjPVZvgNvE0c8W8NB4BScPr1XT91vFhbYWfHrGfulKEyLnROzBpg4VuQq87zX+CONN6TvX3VBJ6cFftYrrQdQAmNzcU7AeJ8FnL/gKU5Qfv45EPxUssT0up7xTf0Z0dx/Ruk8mBYFeryNge3feKDVlGnUC5vvllWpE09Wr7ox8RpEcjGILEmzSAnN7X4MFVGWRcSb3Bv0rr3aKGPA6JwHxSkdwxKcgCPtriOk40bg; 24:cHH4i1Yk3OaF8sjRs2gyJSbP/1sDlIHMgLbwfWg+5MnW8PwIxKS0ZSUzrGB8B8LJFeCyK4ZSzW2+jsfV+vC8x0gePImVAXN0mSaLFfEYPa8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB437; 7:cbnrHyZV0wRukY9sWBw8m3l75ZgMS5m1LFP472RirllAMV4e95YoxoCofK7b6U7Taqpf8sKl6XdHl100ta7Utd85s7NtoPR7xA8nTThKwVEOJWhf0r0uIh2PtNbaTXy9uByq1HoTyiSsaEz4UX/ix7nDHS2nJiUnQwWRwuF1x7vooNuZxn0KMZDTRiuPGsVtJ4arvUDttTPGGfpUpi9mxTnTAwNs7aODuysSIDchAN0n/HWx3ctUG6gbQSRVjpw++FsqeLfhaf5sNhNnQ1dQlgBNuiYc4GoP9u7+ZkcANs7873nQzhjVrog88IXQNaeYMdNMZT9NxZiOdpa64HjpKY2N1j537i1WaZfSghBrMKYBPyOF73wu6eJi0X5ZBoLg+6/PS8WMU8QHaJtOHKmleNa0Aor2dPQ1Lt3BNHnJMSqaxg3Y+NTg7LPhBVp3+LzaXysyHKg6+E9JO3jaml4StvLhkWgYrIiAOaGndBPPe3xwoGiuH7w5Rkg1XviVvdvCqdmDTYuZcHn+JxeeHoxe2EWZLfJFbb1qcwR2jjipQ3AzbnAhgMPEsv+s2/PJ9d+f7PwpMq5kCKuEgFutSd8mLJjitK7UrsrUw4EJ+UkcwZvf4cTOvo08Z/D5N5z0SlAEA8c+8k7XqZMc23ejiw6zpQ0deLkbI4Hd9Uljt/ysenKvI9AlhkzkHEbsU1e4B8pONAoeFFnMmKa1Lg+fXQxEUUF6sZcnPqogeCNKUC7CZ/1rdIVJJNJ3As5jH5UGkXGGMqwb6xJzJGSEhLEjIhL6GceSG7V5Fa8kb8A+U4k5ux4= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jul 2017 11:55:55.0968 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.80]; Helo=[preapdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB437 Archived-At: Subject: Re: [Dime] RFC 6733 Commands X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 11:56:03 -0000 --_000_15004653527387744sprintcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable My issue (and the motive for the e-mail) is that some lazy implementors tie= d the ACR/ACA to 0 which should not have happened. Although optional, having placed the App ID of 3 in the ACR/ACA would have = at least begged the question of how did you miss that? It is pretty clear= to me that the dev only looked @ the CCF and not the rest of the document.= However, if the app id was in the CCF that specific issue would have bee= n avoided. We can't fix one's inability to read the whole document but we can take ste= ps to lower the probability of an error when they take shortcuts. ________________________________ From: Jouni Sent: Wednesday, July 19, 2017 6:03 AM To: 'Yuval Lifshitz'; Bertz, Lyle T [CTO]; lionel.morand@orange.com; dime@i= etf.org Subject: RE: [Dime] RFC 6733 Commands If you go for new protocol version that opens a door for a lot of things. G= enerally adding commands to base protocol using app-id 0 is not possible wi= thout a new protocol version. I do not see a reason for any extra clarifica= tions. I would be reluctant to assume app-id 0 is forever for peer level co= mmands. We have other ways to impose that restriction at the AVP level wher= e such things actually belong (see Section 6.1). - JOuni From: Yuval Lifshitz [mailto:ylifshitz@sandvine.com] Sent: Wednesday, July 19, 2017 13:20 PM To: Jouni ; 'Bertz, Lyle T [CTO]' ; lionel.morand@orange.com; dime@ietf.org Cc: Yuval Lifshitz Subject: RE: [Dime] RFC 6733 Commands You mean, that if someone implement a new protocol but does not change defi= nitions from base, not add any new stuff which is mandatory, they are allow= ed to use application-id zero for commands other than (CERA, DPR/A, DWR/A)? Shouldn=92t we block that? Would imagine there are implementations where th= ey assume zero is only for peer level messages? From: Jouni [mailto:jouni.nospam@gmail.com] Sent: Wednesday, July 19, 2017 1:00 PM To: Yuval Lifshitz; 'Bertz, Lyle T [CTO]'; lionel.morand@orange.com; dime@ietf.org Subject: RE: [Dime] RFC 6733 Commands Unless you extend and existing application within the rules in Section 1.3.= 4 you always get a new application. And if you wish to extend the existing = base protocol application with new commands that most likely would require = a new protocol version. I think we are good here with the current text. - Jouni From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Yuval Lifshitz Sent: Wednesday, July 19, 2017 12:32 PM To: Bertz, Lyle T [CTO] >; lionel.morand@orange.com; dime@iet= f.org list > Subject: Re: [Dime] RFC 6733 Commands Actually, we may have an issue there. The spec says that zero must be used = for base protocol messages (page 23): Diameter messages pertaining to peer connection establishment and maintenance such as CER/CEA, DWR/DWA, and DPR/DPA MUST carry an Application Id of zero (0). But does not say that it must not be used for anything else (or at least I = failed to find such text). Do you think such text should be added? Note that there is such text regarding vendor-id. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Bertz, Lyle T [CTO] Sent: Monday, July 17, 2017 6:04 PM To: lionel.morand@orange.com; dime@ietf.or= g list Subject: Re: [Dime] RFC 6733 Commands agreed, we have encountered some folks tying the ACR/ACA to app id 0 in ope= n source. ________________________________ From: lionel.morand@orange.com > Sent: Monday, July 17, 2017 9:32 AM To: Bertz, Lyle T [CTO]; dime@ietf.org list Subject: RE: RFC 6733 Commands Hi Lyle, I think that there is no specific reason. By definition, the command is ind= ependent of any application. So when describing the command code, it may or= may not be contained in the command code header. It is consistent with the= CCF specification: header =3D "" The CCF is mainly used to identify the set of AVP that can be present in th= e command. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Bertz, Lyle T [CTO] Envoy=E9 : lundi 17 juillet 2017 12:12 =C0 : dime@ietf.org list Objet : [Dime] RFC 6733 Commands In the spec was there a particular reason why we did not specify the applic= ation Identifier in the header for each of the command codes, e.g. ACR/ACA = assigned to application ID 3? Lyle ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_15004653527387744sprintcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

There is Acct-Application-Id in the CCF.. so what’s the = difference?

“If present in a message other than

=A0=A0 CER and CEA, the value of the Acct-Application-Id AVP MUST match = the

=A0=A0 Application Id present in the Diameter message = header.”

 

 

-        = JOuni

 

From:<= /b> = Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com]
Sent: = Wednesday, July 19, 2017 14:56 PM
To: Jouni = <jouni.nospam@gmail.com>; 'Yuval Lifshitz' = <ylifshitz@sandvine.com>; lionel.morand@orange.com; = dime@ietf.org
Subject: Re: [Dime] RFC 6733 = Commands

 

My issue (and the = motive for the e-mail) is that some lazy implementors tied the ACR/ACA = to 0 which should not have happened.

 <= /span>

Although = optional, having placed the App ID of 3 in the ACR/ACA would have at = least begged the question of how did you miss that?   It is pretty = clear to me that the dev only looked @ the CCF and not the rest of the = document.   However, if the app id was in the CCF that specific = issue would have been avoided.

 <= /span>

We can't fix = one's inability to read the whole document but we can take steps to = lower the probability of an error when they take = shortcuts.

 <= /span>

F= rom: = Jouni <jouni.nospam@gmail.com>
= Sent: Wednesday, July 19, 2017 6:03 AM
To: 'Yuval = Lifshitz'; Bertz, Lyle T [CTO]; lionel.morand@orange.com; = dime@ietf.org
Subject: = RE: [Dime] RFC 6733 Commands =

 

If you go for new protocol version that opens a door for a lot of = things. Generally adding commands to base protocol using app-id 0 is not = possible without a new protocol version. I do not see a reason for any = extra clarifications. I would be reluctant to assume app-id 0 is forever = for peer level commands. We have other ways to impose that restriction = at the AVP level where such things actually belong (see Section = 6.1).

 

-     &nb= sp;  JOuni

 

From: Yuval Lifshitz [mailto:ylifshitz@sandvine.com]=
Sent: Wednesday, July 19, 2017 13:20 PM
To: Jouni = <jouni.nospam@gmail.com>; = 'Bertz, Lyle T [CTO]' <Lyle.T.Bertz@sprint.com>; = lionel.morand@orange.com; = dime@ietf.org
Cc: Yuval = Lifshitz <ylifshitz@sandvine.com>
= Subject: RE: [Dime] RFC 6733 Commands

 

You mean, that if someone implement a new protocol but does not change = definitions from base, not add any new stuff which is mandatory, they = are allowed to use application-id zero for commands other than (CERA, = DPR/A, DWR/A)?

Shouldn’t we block that? Would imagine there are implementations = where they assume zero is only for peer level messages?

 

= From:= Jouni [mailto:jouni.nospam@gmail.com]=
Sent: Wednesday, July 19, 2017 1:00 PM
To: Yuval = Lifshitz; 'Bertz, Lyle T [CTO]'; lionel.morand@orange.com; = dime@ietf.org
Subject: = RE: [Dime] RFC 6733 Commands

 

Unless you extend and existing application within the rules in Section = 1.3.4 you always get a new application. And if you wish to extend the = existing base protocol application with new commands that most likely = would require a new protocol version. I think we are good here with the = current text.

 

-     &nb= sp;  Jouni

 

From: DiME [mailto:dime-bounces@ietf.org] = On Behalf Of Yuval Lifshitz
Sent: Wednesday, July 19, = 2017 12:32 PM
To: Bertz, Lyle T [CTO] <Lyle.T.Bertz@sprint.com>; = lionel.morand@orange.com; = dime@ietf.org list <dime@ietf.org>
Subject: = Re: [Dime] RFC 6733 Commands

 

Actually, we may have an issue there. The spec says that zero must be = used for base protocol messages (page 23):

 

Diameter messages pertaining to peer = connection

   establishment and maintenance such as = CER/CEA, DWR/DWA, and DPR/DPA

   MUST carry an Application Id of zero = (0).

 

But does not say that it must not be used for anything else (or at = least I failed to find such text). Do you think such text should be = added?

Note that there is such text regarding vendor-id.

 

= From:= DiME [mailto:dime-bounces@ietf.org] = On Behalf Of Bertz, Lyle T [CTO]
Sent: Monday, July 17, = 2017 6:04 PM
To: lionel.morand@orange.com; = dime@ietf.org = list
Subject: Re: [Dime] RFC 6733 Commands

 

agreed, we have = encountered some folks tying the ACR/ACA to app id 0 in open = source.

 

 

F= rom: = lionel.morand@orange.com = <lionel.morand@orange.com>=
Sent: Monday, July 17, 2017 9:32 AM
To: Bertz, Lyle = T [CTO]; dime@ietf.org = list
Subject: RE: RFC 6733 Commands

 

Hi = Lyle,

&nb= sp;

I = think that there is no specific reason. By definition, the command is = independent of any application. So when describing the command code, it = may or may not be contained in the command code header. It is consistent = with the CCF specification:

&nb= sp;

   = header           =3D = "<Diameter-Header:" command-id

         = ;            =     [r-bit] [p-bit] [e-bit] = [application-id]">"

&nb= sp;

The= CCF is mainly used to identify the set of AVP that can be present in = the command.

&nb= sp;

Reg= ards,

&nb= sp;

Lio= nel

&nb= sp;

= De := DiME [mailto:dime-bounces@ietf.org] = De la part de Bertz, Lyle T [CTO]
Envoy=E9 : lundi = 17 juillet 2017 12:12
=C0 : dime@ietf.org = list
Objet : [Dime] RFC 6733 Commands

 

In the spec was = there a particular reason why we did not specify the application = Identifier in the header for each of the command codes, e.g. = ACR/ACA assigned to application ID 3?

 

Lyle

 


T= his e-mail may contain Sprint proprietary information intended for the = sole use of the recipient(s). Any use by others is prohibited. If you = are not the intended recipient, please contact the sender and delete all = copies of the message.

_________________________________________________=
________________________________________________________________________<=
o:p>
 
Ce message et ses pieces jointes peuvent =
contenir des informations confidentielles ou privilegiees et ne doivent =
donc
pas etre =
diffuses, exploites ou copies sans autorisation. Si vous avez recu ce =
message par erreur, veuillez le =
signaler
a =
l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles =
d'alteration,
Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. =
Merci.
 
This message and its attachments may contain =
confidential or privileged information that may be protected by =
law;
they =
should not be distributed, used or copied without =
authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its =
attachments.
As emails may be altered, Orange is not liable =
for messages that have been modified, changed or =
falsified.
Thank =
you.
------=_NextPart_000_567C_01D300A3.42E1A630-- From nobody Thu Jul 20 00:20:45 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B992E127735 for ; Thu, 20 Jul 2017 00:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, 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 g1fNpbPegA17 for ; Thu, 20 Jul 2017 00:20:39 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0130.outbound.protection.outlook.com [104.47.42.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BB4A126557 for ; Thu, 20 Jul 2017 00:20:39 -0700 (PDT) Received: from BN6PR05CA0003.namprd05.prod.outlook.com (10.174.92.144) by BLUPR0501MB866.namprd05.prod.outlook.com (10.141.254.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Thu, 20 Jul 2017 07:20:36 +0000 Received: from BY2NAM01FT041.eop-nam01.prod.protection.outlook.com (2a01:111:f400:7e42::203) by BN6PR05CA0003.outlook.office365.com (2603:10b6:405:39::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4 via Frontend Transport; Thu, 20 Jul 2017 07:20:36 +0000 Authentication-Results: spf=pass (sender IP is 144.230.32.82) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.32.82 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.32.82; helo=preapdm3.corp.sprint.com; Received: from preapdm3.corp.sprint.com (144.230.32.82) by BY2NAM01FT041.mail.protection.outlook.com (10.152.68.167) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1240.9 via Frontend Transport; Thu, 20 Jul 2017 07:20:35 +0000 Received: from pps.filterd (preapdm3.corp.sprint.com [127.0.0.1]) by preapdm3.corp.sprint.com (8.16.0.17/8.16.0.17) with SMTP id v6K7FJnx023683; Thu, 20 Jul 2017 03:20:35 -0400 Received: from plswe13m04.ad.sprint.com (plswe13m04.corp.sprint.com [144.229.214.23]) by preapdm3.corp.sprint.com with ESMTP id 2bqda79y64-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 20 Jul 2017 03:20:35 -0400 Received: from PLSWE13M04.ad.sprint.com (2002:90e5:d617::90e5:d617) by plswe13m04.ad.sprint.com (2002:90e5:d617::90e5:d617) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 20 Jul 2017 02:20:33 -0500 Received: from PLSWE13M04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a]) by plswe13m04.ad.sprint.com ([fe80::2c01:fcb8:e729:4a7a%24]) with mapi id 15.00.1263.000; Thu, 20 Jul 2017 02:20:33 -0500 From: "Bertz, Lyle T [CTO]" To: Jouni , 'Yuval Lifshitz' , "lionel.morand@orange.com" , "dime@ietf.org" Thread-Topic: [Dime] RFC 6733 Commands Thread-Index: AQHS/uUJB8h6U5QREEmZorl9T0AXrqJYEfmAgAAL0HqAAscIwIAAXNyAgAAFYoCAAAxqgP//uZFlgABdNQCAAOkX+A== Date: Thu, 20 Jul 2017 07:20:33 +0000 Message-ID: <1500535233161.28783@sprint.com> References: <1500286334617.86980@sprint.com>, <8331_1500301978_596CCA9A_8331_333_1_6B7134B31289DC4FAF731D844122B36E2D1B5E23@OPEXCLILM43.corporate.adroot.infra.ftgroup> <1500303827591.97405@sprint.com> <559e01d30075$d36b13e0$7a413ba0$@gmail.com> , <561801d3007e$b95bd940$2c138bc0$@gmail.com> <1500465352738.7744@sprint.com>,<567b01d3008a$1d8be2b0$58a3a810$@gmail.com> In-Reply-To: <567b01d3008a$1d8be2b0$58a3a810$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.229.91.93] Content-Type: multipart/alternative; boundary="_000_150053523316128783sprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:144.230.32.82; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(39840400002)(39860400002)(39850400002)(39450400003)(39400400002)(39410400002)(2980300002)(438002)(199003)(377454003)(51444003)(189002)(9170700003)(53546010)(117636001)(39060400002)(97876018)(19627405001)(356003)(84326002)(229853002)(106466001)(6246003)(38730400002)(2501003)(81166006)(626005)(93886004)(236005)(7736002)(50986999)(2950100002)(54356999)(76176999)(53936002)(2201001)(8676002)(5890100001)(5250100002)(53946003)(36756003)(512874002)(54896002)(8936002)(189998001)(102836003)(3846002)(30436002)(478600001)(6116002)(2900100001)(4546004)(2906002)(5660300001)(14454004)(86362001)(19627315001)(19607625011); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB866; H:preapdm3.corp.sprint.com; FPR:; SPF:Pass; MLV:ovrnspm; A:1; MX:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM01FT041; 1:WS8EKQ60lk0Zjr3fxZxksYYDAq+ssaYUrWTh1ffN8Gmb2kI4sITslOpJe8V+IhbLNhOhQP50U5QeuhVAJ89j7qcF0L265cKz0xTeD7EZCI2HhzTuIz6GpGIqvSR1upOi7dVw11OUSaGNSuj/+OglhA+c3EOVstiWBf9/UE4+sG/C7ec0KT8LlX0Cu+Uh+Ky3MwXhGAxtT+OdooyuKtE57FMZv5HXEPWbeTMHSwh65tuZ4Z3aKHgrnMa9Jn256MbgZ9Lfx76Qzl0BSAqjrLdMAoz2cdNwh3HtHTzD43vDIxhUjNiQsXSW1eZeQQI8L5708TiDA5lH99c0QPn2p6zqOgPTwN6t3YrieB3XRy7USBO5xxKMPiP9c8SFLOBdBM8a2tQQxQPo11uWb/NxyF52Dv2UjrUqgqjX6GcvHZ1l3eRV2TjgRn1RcAlhfOwCxrvoLHZu00vSQGEGlWFPCYbmLFV94kiqAScEhoTpuSMT54cYozoyyedjKX0S6kyoW1eEH++U1E6TkJvJoQMnB8sdt/bgRXlDoOD6xuZpBS60k0K+wih7i9Hu10nyEto4oBUtVIMAMrthAn+E99bBbL/QqVnSprWEpfCuVlqrQqJ94lQZDKe5bcJ8iW7VUbGBEqx9tD9cpe9LjyK2PUOV8bmnF/8v9yuOhDl0Vbm/3aq/n2hpBYtoN7SwP/Tag3/Sa5gutNHyCwdCMuKaeWU2T2YlaaxOvJu711/FbjwLXw2hxN35LBQoes6kDCEv15jVc7yWo+AXVk4odgxrviPvXmovzZ/P0uF7ak54ipVdx9+sL8MEa3tW92f9tyAiRJeER8cYU8+oCvNr2BjEPto9HKlSQXuOmNwq+J0e8hcvk0woMBIFRT0rJ5ruALxKi7j4KTgPlLV+52ypfM15UdHdzUJvdI9ihSq0RThvK5UaN3DBrXAbyqPKdi qFngNcYhGXdlDa X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e36bee9c-64ac-4e71-391a-08d4cf3fd0e8 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(8251501002)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR0501MB866; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB866; 3:8ngMjLBefQkqNO1WKW2AuX9YB6v1g3mfvPu/Pp67S+rBTxSzApZr0GTmw/nKz06VpicfNBz1rPE/l8eNTqWkRubx0Ek6JyMkOU/lt0s8D1x/eCSrnitElWLl86XeYE/3zo2xMAIepIdyY0wujyxhn8mEeBOrSCTgRdjoMlrCu/oKzOlQZnKsymD1G90MIgThptFI9TWTPq4IXEP9u1mWKSeeZmttcitnWIcQrsGg9JSyJugOJtpmfomPGxlgWCy0jozbYiOmKEqRkhDd7pSlxbhRyeESQvsPdPUEz1xiV3qs1MegyYdgdHcBRQRzdfeBNreqjSscH0zIgETtlcG2V3EQ02Der126MQ1xL5CM8mhKXdxFFB7DZD69sg2xyoXIcGgKm0va3Dwrw83JVWxL2sCJ0yCnSJtU7VI+Qr/sHf1DlsQ6o8e1HtOaiantHNoNuU0F4LI0Y0g5YEEcw/XXaaCNn0PoCuWxuAV9ufb478EYNUxzUyEWKrTRzs+8OIB9lWywS7HGiiD+sLR/N42+B3ljoJcHuuWYumKFgX7sPcrHyWxd8ZNtXZLvFhTnYy592qMvrsoBG2kXcxpt0e00HE4L+etqqlf8i/rjhfBzt/cogaoGwTWxoMLcab29Yzf5BIAShL7mMV8cSoXJX55X/53VvvxtdHXA0n5bUa3LzTqHTinD1b90fJzEKdws1blagNY8o+mDSxVsIOZMnL7z+gN/UIqTDHuqL/yytPlW/I2SYpP8gBD9r50Btoyk7TvhkpIdTvyZJPXtcju01Dkaq7RW2+o6dNmN3yw9J+5Bu4bF8DgS/Rjy9K8gCeL+ZbdMsvCRUAyGhVtz99zN3FrwFa1CqChmpvgpxuU5ec3GLubpcXO8kTfLnwwTcuWfJ6v/4jb/ougYPokuGHBDWe6MNMTlZema/wLPcbeViMB7RNo= X-MS-TrafficTypeDiagnostic: BLUPR0501MB866: X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB866; 25:Ay+sETf7jzWk7gCCA+2XwDMEv42mHUZW4TkZG2B2Li35O0H7xIKGpIWCJ38ZY41Dv+VeCN9rE8Fnp5rppouLL0fMjrbjdT4uP69nkO/7FpbfQq9lo8RExQQq4xzJ7eI/NfjnkJpFODivUDaNIEWw/PpIJ/u3gD9FPQZpoFc8W4lbiOrYELUuby1m+UdAIS/tMWA1jXYJ+ouN0CVqDIC3FkYfCjwTIQg+apB9/GPruzfw93gS7fTuS7hfQI/hRl4+kesooC7BbyjCnt2zmU11gKd/K+VAL9ITxBE5b6MAJVN5QoUOI1BhwgNz09YQ4k7TYxCFsS/9URSsLPmIY6G6D1F7m4ONWT2OUy3m2tvYNh8WJRDQBTfztZSzAQ19v9oaJw72GxRM/SJuKkSioqccdSrARaXufMI6uh2shHV2dP+Z1gVIwkGO8iw4iDGwbYRJPAMoeDf3G5mHqj+ITKa53ua8sB2havjjIwCKu1OvakMEX2lYsQHe3gE3HUiy5anGZE/fUUM5sDjH/nYMnzL+L8o1Jrc8PiA2gmVF+d1MiYNelxV6H01iqGkSQpUS0bkL4kMuevwnY4hifhZSsXfKkb72HBXe1z0+QlVEOl5V8X8Z5s9feVk+e75bCblLZaYSWoEDV+/qSbWyjuAJSD0Pdnv6rqtgLNxtMMP+Tqd9rYUyf6pkd763RPHwrRNIKu+HOFne2ThbH9jwuUYWiizolBVINjUnzuHEB8u6g7WAvcB+vCmyR1yAAbTxslpTfvJ6bUihfl09HsTBP5TVnDW0akRk5mcQTwQ6VTSOBduNrz4Ed4Zfid/gGNgRjv6IqfWM1au+8VC1MS5Dv2FARcTrOtb/o++Lk9rf426HPnh846m/JPLfyOsTmlwCXxlLLiscSORXVmH/ViKOiMhRUtBM0zlcHSRv7fhlKjRyP+C3kb8= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB866; 31:+6EOC0i/BDnvq/fNrS2vOjq3umKC6enyfVE5MPqx7PCwD8x7eqS5jbzLb2oPG/1IY/wtnJPqnG1FGKhQ7Y7OBteph8sWKK/TON19tW7+AYsBVhzuteLL8Ou5nAW5qViz84W8gp/VCqoM2wj87RC8L1WC6gA0pbWlp8O/NjKhycPvRnJPlzkVMkojZqSWmBJQpnWTaSMuHTOVvt7YOnqGMgt+gTxSuGNdKpjqVBnplRN1WplpTTu1Y3U+061l7Kr9biy8W4pved5kJoj9e887hg+JjayG5cvqbpmZiOIxD52fZxIcyv5jqRJpOpDXWAK2ZuQ5ZyhyDdZSWPTQh5QXDMKIRKBDD/ey6oJiUUB9DxuHTUobL/2Q2pkEoEoA5hif/J50Mi9VLstWSSdOsHjNsVeTy4OpSkgQaN9QV9z5WbInkT+De2D2B1IiTm8FL99LdeCxOG+uFwAJe5rN9P81kqXfzTT7QJ2nE+m6br7OpFhpmGLoygCpkdDZJn22KW0cvrrGTKJy5UmPIaE3uJdpKn42NFhS0XAK2zNdzFOiqbCYzC2kvHGH8C1d423VqpuCuYrfXTNr024M+Vq+qyfC1xMlyezJl2jG/G4OZ8rDI6iVaqrUJIm5fVHWbfN+WN+vmu4WCo0mEHyZeXPJNQISJZaHMTsc4OPCjO6gSl22+GbZRTq1TMdSzxo4hMcTIdYsiG6IHUhNwhSPfwX9fmUqhA== X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB866; 20:D04A80QL63PwKj7Rxx7176DA0Bp0WTLAT0dndA1hh/1k2Tmhp2nbag5C72ihKoV8JxkbLxbY+zh32VuIPbAsCJN1dXguV/b2wGzWl4qzvbZJ/XcoSpvP3bJfGEonK7XWfX7ly6ejdt6JNLiExBXaSaEbAST3f8lonrAwMfH+1Bff3fZkB0OERFLjl0yyneQ44aEZ7uUGNwjIZ+A+aphsJj2ZldE1cTLcYczNYZohM4sU8zKEDpOOs82CT/kONw/oKcj3yDPn3lkJaZfS4vr7X7at8dGAqrDGEPf6zA26cT0j1iAcI8asxy7Qs08t2ZLyEbIVQvyaDKcBYELafsGn6lCAGfrg6xLNTSaSdgJGN8zkxk7u6mXy8Y/8Lj5nwp+4q2+Pe03QFdLzDDhRYYrODhQtkZ4ZLT9epYm2kR76U0QdNykZHxipiJV2ye3uUB2flsSdZdm/JMn9reHiCO3fWKdN5X3QW51lMNv0sQz5wxYEpFYohucKMJlk/zJsXTVV X-Exchange-Antispam-Report-Test: UriScan:(278178393323532)(236129657087228)(18430343700868)(148574349560750)(18271650672692)(209349559609743)(247924648384137); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(13016025)(8121501046)(13018025)(2017060910075)(10201501046)(93006095)(93004095)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123555025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR0501MB866; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR0501MB866; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0501MB866; 4:3MsTFxT74v8TykY18DYHHGm2DtPJ9oSeXwIx5TFO7?= =?us-ascii?Q?CawniuW2uzz9vjiQ3TE22VGPmqLK7egLNKpRx/xSoFs5oNutO6SFBI9s9GRV?= =?us-ascii?Q?vjpp3XfLpAtPTSoIFQJD6d6EyitZ2P7URmmB3CzmJFdgmQjU79NgtlBA4KjR?= =?us-ascii?Q?CaE/1FzG7Qm8qMFvk4LCL3nLb8xFEIU5WF2umRDh+qCeEi5x0SrL0Ysb0o6A?= =?us-ascii?Q?C/XVMC94qgmtGIrswQiz2W+IYcuPB2KnT9/2LWDtLf6Aj5HFOZzfngrwIBeA?= =?us-ascii?Q?PPJCBGrwEpX1v3w8u/Uropml237rZxHbIYxgBvAkms79wdZriARcmcVzighi?= =?us-ascii?Q?8QUU4KDCaQ79NXzRpBSUT2ix3GzPmfsJtfvJloeFc6D0g2A0hs9+KZkPDIUo?= =?us-ascii?Q?ToV6bQBXfhmlEvAJ01F4IHfrsjDA73yzb2nldhDQW5s/atsMkshLYncYUmZQ?= =?us-ascii?Q?vanIlvoGnL5S9CP6WtGUW7qWGdkBdX3w2mXYVTQUDi+/Vm1VKULrL6JWUDU5?= =?us-ascii?Q?64sukECmVhMh/VwYmtzr9Zg6dHafOXNgWc98Yjta3amBVqdtURaP1yJFfxOJ?= =?us-ascii?Q?qw2WPhrI0JHdrKNFcLQH4TVvqi8IBORKKre+gUw7T0noNCZp+tVhOn1UL9el?= =?us-ascii?Q?8YFY9cl/PL84L/7tmyQcOKuAR3etND3lNlxBRGPUbX3oR8Z03Q16qdqMDJaS?= =?us-ascii?Q?tcVQwPgZBRAC4X9QPiBRSw3zD0Pr10RsKCqwYDcy0mPcFOEK7OkLwDazVs/I?= =?us-ascii?Q?6T77UGjx5FgjmtGe3fljUOH2KXamhCcM3Gk0VLbxprIX1ZdK8jhIvZIZCy3c?= =?us-ascii?Q?5NA9Y+D5Rj5rEvrM77jOIJV1DXInhQGvGPoL1K3R8N8DHsRA1uEt7ORSlrip?= =?us-ascii?Q?AzjW4bsUNnPcdPWnUTysnzTo5TDxxOVpNAX9AkoYXz/MecypOEYPYvWtXRS0?= =?us-ascii?Q?WTxvB6OEPV3yFDv/KJAKuo4AXq4vZ+b191IKqaQxIYXqMRbzz9+DESlFYZ+D?= =?us-ascii?Q?s3pdy4Xr51GhTNr7SembE++z9HbtoogkpWZsjvPLMcWAjL0lXidoCFAzoGZf?= =?us-ascii?Q?PfAQVv9tPa1z0XYJ+Lx2Yu/QdupkTE6CB5axaO2tY4O5VTK42tTQzj/Lklks?= =?us-ascii?Q?GBDqbO2Ddo2x1jkiNPhkT//VGtbbXc2suApzXuvm420q7AgY/TBOKpkTyDCj?= =?us-ascii?Q?/biOZEv2S2WU5nMUhq718R6y48ep2QkqfIA57y1vCzUq+Y/zj6gfytHktjb1?= =?us-ascii?Q?3Ex2wEyMU59rHNGzBeeDHZ/F+YBpk7GX2K/b+dgvR0auih01EyTw44mtvYEQ?= =?us-ascii?Q?fxdm39LzW5me90WCA9ZUpSMMEUdLLR40Y7/WXFlnicfO2dwbMx+oPAC6qoNj?= =?us-ascii?Q?MK3YtxYaeThYxc/q0Fq36Pzv+LKBaVAb6c5B9Ds0p3/hVs5I66zhYod2y50N?= =?us-ascii?Q?KYbQ6AaOrKxhkIVhgjSjm1dTfmxEmBaFLoZsxPUZkrcBG3/Ct+Dz5lpoTwbT?= =?us-ascii?Q?8rfUCtW3v+qKg=3D=3D?= X-Forefront-PRVS: 0374433C81 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0501MB866; 23:64xN+2gnXldkJDVxUGjOYcryzjbdYruBy49uTDXi?= =?us-ascii?Q?/kIQNK2wEELZ+8IxPUHZUwSR9GD8Pnlwuhwxxk4xtDjnTC7p7Dbdbq4fyKjm?= =?us-ascii?Q?RFt60tFzKRbdSsSYtbfbD9ymYU0zSapTs9wDMwTuui0bV5zL4/jtsNThc6FG?= =?us-ascii?Q?/E255Vvu3rj3f74A3GCL0quogkBBsiNhAtpZ5MUGSjjTYFnqQosalQFQSr1w?= =?us-ascii?Q?jf+Ki9ySqMmLKJv7y+jTvtrcK/zoEmmEWjfcuClKHAGi+C9gbDL2Uess+EtY?= =?us-ascii?Q?VStzYbbaeZyB7XxU4io5rDlxJDvcSSDRa3exSHA5rCl/pHByWdTb5D65MLgQ?= =?us-ascii?Q?CO4JaXmm0g5NcW5ubbBWEKC6qZUUhRKX94LyJrvvx+CocwqtNy9Tdr2lMaP1?= =?us-ascii?Q?95bnk1fd286wIdLVFOj4M1eeRDBNrqzqyuMw992kvGalclRSRrduByST2Xkf?= =?us-ascii?Q?R+ItSsTik41mmjHasaIlabNBxwtzRz4hNOU4YqYSFs5ah/g86+5f+W059JuP?= =?us-ascii?Q?fRgI0bumHi6QTW2p5KJip3SdYf75pN8CRMuGMSJRq+qQirxrA27QEy1t19ur?= =?us-ascii?Q?AYaIU3TKC8ZjvSU/Q6yOzRcfPvH6SSVTD/DHZSu+tFsyzAnLdZJDemKdb7nI?= =?us-ascii?Q?I0aymQbOPysS9NXWcbhsynbhVm0bznOfq7o8mssWcgIvBMLyNBeqQXu0jHNw?= =?us-ascii?Q?YpRhm1r/lY2hzZOiarOSGEoaSrwW/sXrBe25Y55tL1zDSmOxYUyfLhoOFVau?= =?us-ascii?Q?uLYzyEoOFGRsH8zrXkgOSs//p9Ik3Cgo3LO5AQWBKb6zcLdWNWGmvV73HzTG?= =?us-ascii?Q?utiDPbJVT1gv2SEcclhOoQvI92rCcEISVYZw4rLyzU6lC4gPzskPyUkXz93u?= =?us-ascii?Q?LbQACXI8M1jmqI2XN02Kfcwgw0XR1ngMuigeph2nr9X+moxogzrns5hg1Xcv?= =?us-ascii?Q?eGKkn0FkKksbmxGDbFIe2Uf5TGhb3HcGnqqlzEHnuzUafYrzXhI8SPvF8I8t?= =?us-ascii?Q?DmLEsdm1ugppFW0wVmCi7M9adnnr8/G/DPUlCZZOH1PvKb7S9Nsh93P32v+i?= =?us-ascii?Q?AIEFnhkvuuXPCGL1woi+htzhNRzdcaOPGL/EEjOvgLpENtGR+Z3kxJqWLe89?= =?us-ascii?Q?SqVHGCuS3WWW9Jrpr18J5GYOaesZ2j1Dgz7xaAY62sAm9Q9DjQO4mgDa4r0O?= =?us-ascii?Q?FRgfBIUUp9y88pQvcHFTVeclED+OrJERIAOwhcn3GpAEjik0Z8Y4otZaM29z?= =?us-ascii?Q?/Z1xpPRODTxBY9cJrVjqiKARLMbyqW1LGzXJK+Piy1ASp9GRnNBugsrMDcMg?= =?us-ascii?Q?CasSLlrgJydrtCj6w9P3hPpM5BqZbamXXOGrlmcfrRJSedR1QdVvsOH0fJQi?= =?us-ascii?Q?InvdZQyJcEJ3gihvW+ccfBF8iGl2rRgJXVW530JqG/QewQhMdGY2FdhlHoTj?= =?us-ascii?Q?LXl+80EQuw=3D=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0501MB866; 6:9N9AuNWVceQ+F/c9mYEfRpy6aTu97nncPyPXhvwZQ?= =?us-ascii?Q?3YQm1si11q5WbdLu64txoqPbu4Ja8NU7pg+jK9fsPeDjBlWtMfzzXOVsUZbE?= =?us-ascii?Q?cRKClknxjp0ejGIfT2cGZvJfG3Luurc3oS2Ub+J1aLKTx3KaBm8QWnEXVWV4?= =?us-ascii?Q?xqSqGr1JN4rIf1LwmT/mn4xbS4wE2cRmoTkYbtPv7jegiBIOHPWeYezSzlqs?= =?us-ascii?Q?TVZlOXoTAaw6c+hTbwUVvjNKNWqKA4wC6UmG/3Z9MnhZVvKX6ta4o1us7CJG?= =?us-ascii?Q?k3ch0xQrA+pDmekpEKIVt2RbnQmezJQjKzegjDd38Vpwoe0tNyKuBdg5J05z?= =?us-ascii?Q?s3YcpMjP9JbV+DkLtukL5LA5vGrkk53oVGupPF8Uu7hRBHScLyFBkNu5lvG3?= =?us-ascii?Q?bntJb/ZPGMTWor40saqk04tjlbgPIYfsA0YXtsasAs8oo/qT5gqjFDVU0uXK?= =?us-ascii?Q?Qccxk83FyrbjnEMvPJGQAqPrE9a25aV5td+7r4r/vtV1FlPI7h2X9nGqT06s?= =?us-ascii?Q?PHHvy1L/sf0ffcIQOIjcxmh4G3ZFukMkWW9y8t411LEtvVQBIzjUKRab1rqp?= =?us-ascii?Q?RW7CWz15TXUdAffkPSISZxXY+907auEpn8f70c/7mzgqWus2zD9hm68jG+EL?= =?us-ascii?Q?OOFLAY/GziIuOsNd2+d4iOY73835xE5h9LsLVhC771NNNJpi8mVD+otjEukA?= =?us-ascii?Q?Y15ZCYnb5ufjR+JMJe9lMydj9MBeTCyPOd52aG6Y/Tz4scGM0BIV/UTn/Xf3?= =?us-ascii?Q?C32Srq5drq+CBC5blkkGrDGGtjI0LYg2v4+qrKbhY1NoH8roCRKW3Ny6+e7N?= =?us-ascii?Q?IGzDVRKCuq4DQDCQ9s/HJx7pnDGFpirR5CNd0XZCGHllVuTjd0jOyfTkAc0f?= =?us-ascii?Q?z7Rw+lVTbZPD/LP34D5J2VjunEI22KdaeSbrxpwXB6NI4Q8C+CS/M4Bd2J1U?= =?us-ascii?Q?yPMu4gncbatA/jUbQeJkaixOMmG9aDMw6SwO0IwAmmCZ3FHV+sPl12CFVyS9?= =?us-ascii?Q?uXSabBVV3XbXWPVz2LbGWzj?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB866; 5:ib82nNsLlyVPHGr18Pj/JRb4kOLt7P2+vWkdapMWMNGguSQgbGXJOpW5uItZcmQCA60LQqnarbP96hYQ0NqO5dZILncS8tvVSfKJgLQQi1BQORAtfVdwFl4HGKlCFtZXZO5Hv2XxuSkw6C4mBMKYlJb4n5Zu18fbQMUv3rLmcmd1l3G+jzrH4F6HZsBnXdz8+3S5C9eqxRocTpMBROrfB1ALMBn1HP15c8Fv5LEVr6P/zjxWT0huOhtdMfU7SOmsu6b9hjBFG4ayWsXymP+7fvkfhwwuwpikWzvPQqPVikFYnRdlIPSoJSxVwInSbkQCC+HQSU5r6JmR/p6y4JQqcLLrsGCn8LQmfzc9BqQXRefOZ41At2hCj8cKOLDIdjr+MYFZLLNJizLXsn8E3Q2MmZ9DjkZy4hXgbsBA6JzZgMn1i8I3IpMH1q/i3cHwsmAtUJa7+I9Y3ekspsPi7ohCbBPn7MdgWGHVPOVvCiVtCGtyzKpucRVBDTf6sd4/VAeG; 24:BTNRaD8U8FnEXr+JOuGZ/NCWmFABt+TMjf5jI3qqZoHocIAL+4E3CVvt/iFYAnpK/8Ip8plMFr0NHchy/Oq/t27CAz6DKugsG5JJGwfY24g= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB866; 7:eoqtm8Phbnj9cPrbfRPzS3I2kc3kWLLxAHjPBuy/w6GLX7MmJljyyJrnwTIahK6WkPzZ2VGyiKWZXDGOpkNGLI4y3me75P9BARyRw3RjTvLSEiTcVEuRrR78UPGoNDSG/HnllVqib1yp71HSe/Fa1d/nCYV+jIc3yhSWMkHb4/umR7IlCQtRbf7zXn1vwPKNOyGAuEQlBz1Z82WPupB9nHo0R/m/l/mqrvv/fN6ZeW90ltGDf34NAZztZ03w3YgKnGS5c26sZj3aE77gw34mjQI1airWNCVtVuNC8EMCUY1fnGS+/yV1qukxzzuWNpfSOP+XaL0sgeMH1LtkbhnK+AJodbYKJ0kCr5H9jg1j98Ee0u6ObvIXoe9V/3Ik6AWQOLSfyTjINAFUCDdduFZqibklvjwd/hJ7R98EpE8PHFh2TYqrbwIB0Udc42Wx+EIdshKhPI1eUOUIgD6P47KqBIp9a+0IzQ21puMo40y8KcgiMDGiaTiDnFnCOPnc3AnDybx/btOWrM93Vk5o0TZUPqUvulqbkm3/ZQv4Hj/uihsEBxwHQFSZGPG6Sd4NS5NK8gRO4+wfp0ic7o3C9a7VNpI1+EZoSjYtj0iuiCzN0k98hVNl6toOW/VZMxhk6VYVcpludrbVG6cxR8P4gZDb/5TFumNBQypdgo3bD4blNxBjx88RlltwbWab1Juq7jTHIfDZm82D3KLK3LhqBdkOletoA7+8+Kl44a8hoUp2S6RlpQ83SoQNLozhD9gj5JEO0mpBp2yHtDBU/hSeggX+8t/5zZaBqqDU9BV79dnA7bg= X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jul 2017 07:20:35.8351 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.32.82]; Helo=[preapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB866 Archived-At: Subject: Re: [Dime] RFC 6733 Commands X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 07:20:44 -0000 --_000_150053523316128783sprintcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCLTm8gc3BlYyBpc3N1ZXMgaGVyZS4gSnVzdCBwZW9wbGUgbm90IHJlYWRpbmcgdGhlIGVudGly ZSBzcGVjIGFuZCBwaWNraW5nIHVwIG9uIGV2ZXJ5IHNlbnRlbmNlIChvciByZWFkaW5nIGl0IGFs bCBpbW8pLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogSm91bmkg PGpvdW5pLm5vc3BhbUBnbWFpbC5jb20+DQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMTksIDIwMTcg NzoyNSBBTQ0KVG86IEJlcnR6LCBMeWxlIFQgW0NUT107ICdZdXZhbCBMaWZzaGl0eic7IGxpb25l bC5tb3JhbmRAb3JhbmdlLmNvbTsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtEaW1lXSBS RkMgNjczMyBDb21tYW5kcw0KDQpUaGVyZSBpcyBBY2N0LUFwcGxpY2F0aW9uLUlkIGluIHRoZSBD Q0YuLiBzbyB3aGF04oCZcyB0aGUgZGlmZmVyZW5jZT8NCuKAnElmIHByZXNlbnQgaW4gYSBtZXNz YWdlIG90aGVyIHRoYW4NCiAgIENFUiBhbmQgQ0VBLCB0aGUgdmFsdWUgb2YgdGhlIEFjY3QtQXBw bGljYXRpb24tSWQgQVZQIE1VU1QgbWF0Y2ggdGhlDQogICBBcHBsaWNhdGlvbiBJZCBwcmVzZW50 IGluIHRoZSBEaWFtZXRlciBtZXNzYWdlIGhlYWRlci7igJ0NCg0KDQoNCi0gICAgICAgIEpPdW5p DQoNCkZyb206IEJlcnR6LCBMeWxlIFQgW0NUT10gW21haWx0bzpMeWxlLlQuQmVydHpAc3ByaW50 LmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgSnVseSAxOSwgMjAxNyAxNDo1NiBQTQ0KVG86IEpvdW5p IDxqb3VuaS5ub3NwYW1AZ21haWwuY29tPjsgJ1l1dmFsIExpZnNoaXR6JyA8eWxpZnNoaXR6QHNh bmR2aW5lLmNvbT47IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTsgZGltZUBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtEaW1lXSBSRkMgNjczMyBDb21tYW5kcw0KDQoNCk15IGlzc3VlIChhbmQgdGhl IG1vdGl2ZSBmb3IgdGhlIGUtbWFpbCkgaXMgdGhhdCBzb21lIGxhenkgaW1wbGVtZW50b3JzIHRp ZWQgdGhlIEFDUi9BQ0EgdG8gMCB3aGljaCBzaG91bGQgbm90IGhhdmUgaGFwcGVuZWQuDQoNCg0K DQpBbHRob3VnaCBvcHRpb25hbCwgaGF2aW5nIHBsYWNlZCB0aGUgQXBwIElEIG9mIDMgaW4gdGhl IEFDUi9BQ0Egd291bGQgaGF2ZSBhdCBsZWFzdCBiZWdnZWQgdGhlIHF1ZXN0aW9uIG9mIGhvdyBk aWQgeW91IG1pc3MgdGhhdD8gICBJdCBpcyBwcmV0dHkgY2xlYXIgdG8gbWUgdGhhdCB0aGUgZGV2 IG9ubHkgbG9va2VkIEAgdGhlIENDRiBhbmQgbm90IHRoZSByZXN0IG9mIHRoZSBkb2N1bWVudC4g ICBIb3dldmVyLCBpZiB0aGUgYXBwIGlkIHdhcyBpbiB0aGUgQ0NGIHRoYXQgc3BlY2lmaWMgaXNz dWUgd291bGQgaGF2ZSBiZWVuIGF2b2lkZWQuDQoNCg0KDQpXZSBjYW4ndCBmaXggb25lJ3MgaW5h YmlsaXR5IHRvIHJlYWQgdGhlIHdob2xlIGRvY3VtZW50IGJ1dCB3ZSBjYW4gdGFrZSBzdGVwcyB0 byBsb3dlciB0aGUgcHJvYmFiaWxpdHkgb2YgYW4gZXJyb3Igd2hlbiB0aGV5IHRha2Ugc2hvcnRj dXRzLg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IEpvdW5p IDxqb3VuaS5ub3NwYW1AZ21haWwuY29tPG1haWx0bzpqb3VuaS5ub3NwYW1AZ21haWwuY29tPj4N ClNlbnQ6IFdlZG5lc2RheSwgSnVseSAxOSwgMjAxNyA2OjAzIEFNDQpUbzogJ1l1dmFsIExpZnNo aXR6JzsgQmVydHosIEx5bGUgVCBbQ1RPXTsgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0 bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20+OyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGll dGYub3JnPg0KU3ViamVjdDogUkU6IFtEaW1lXSBSRkMgNjczMyBDb21tYW5kcw0KDQpJZiB5b3Ug Z28gZm9yIG5ldyBwcm90b2NvbCB2ZXJzaW9uIHRoYXQgb3BlbnMgYSBkb29yIGZvciBhIGxvdCBv ZiB0aGluZ3MuIEdlbmVyYWxseSBhZGRpbmcgY29tbWFuZHMgdG8gYmFzZSBwcm90b2NvbCB1c2lu ZyBhcHAtaWQgMCBpcyBub3QgcG9zc2libGUgd2l0aG91dCBhIG5ldyBwcm90b2NvbCB2ZXJzaW9u LiBJIGRvIG5vdCBzZWUgYSByZWFzb24gZm9yIGFueSBleHRyYSBjbGFyaWZpY2F0aW9ucy4gSSB3 b3VsZCBiZSByZWx1Y3RhbnQgdG8gYXNzdW1lIGFwcC1pZCAwIGlzIGZvcmV2ZXIgZm9yIHBlZXIg bGV2ZWwgY29tbWFuZHMuIFdlIGhhdmUgb3RoZXIgd2F5cyB0byBpbXBvc2UgdGhhdCByZXN0cmlj dGlvbiBhdCB0aGUgQVZQIGxldmVsIHdoZXJlIHN1Y2ggdGhpbmdzIGFjdHVhbGx5IGJlbG9uZyAo c2VlIFNlY3Rpb24gNi4xKS4NCg0KDQotICAgICAgICBKT3VuaQ0KDQpGcm9tOiBZdXZhbCBMaWZz aGl0eiBbbWFpbHRvOnlsaWZzaGl0ekBzYW5kdmluZS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEp1 bHkgMTksIDIwMTcgMTM6MjAgUE0NClRvOiBKb3VuaSA8am91bmkubm9zcGFtQGdtYWlsLmNvbTxt YWlsdG86am91bmkubm9zcGFtQGdtYWlsLmNvbT4+OyAnQmVydHosIEx5bGUgVCBbQ1RPXScgPEx5 bGUuVC5CZXJ0ekBzcHJpbnQuY29tPG1haWx0bzpMeWxlLlQuQmVydHpAc3ByaW50LmNvbT4+OyBs aW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT47 IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQpDYzogWXV2YWwgTGlmc2hpdHog PHlsaWZzaGl0ekBzYW5kdmluZS5jb208bWFpbHRvOnlsaWZzaGl0ekBzYW5kdmluZS5jb20+Pg0K U3ViamVjdDogUkU6IFtEaW1lXSBSRkMgNjczMyBDb21tYW5kcw0KDQpZb3UgbWVhbiwgdGhhdCBp ZiBzb21lb25lIGltcGxlbWVudCBhIG5ldyBwcm90b2NvbCBidXQgZG9lcyBub3QgY2hhbmdlIGRl ZmluaXRpb25zIGZyb20gYmFzZSwgbm90IGFkZCBhbnkgbmV3IHN0dWZmIHdoaWNoIGlzIG1hbmRh dG9yeSwgdGhleSBhcmUgYWxsb3dlZCB0byB1c2UgYXBwbGljYXRpb24taWQgemVybyBmb3IgY29t bWFuZHMgb3RoZXIgdGhhbiAoQ0VSQSwgRFBSL0EsIERXUi9BKT8NClNob3VsZG7igJl0IHdlIGJs b2NrIHRoYXQ/IFdvdWxkIGltYWdpbmUgdGhlcmUgYXJlIGltcGxlbWVudGF0aW9ucyB3aGVyZSB0 aGV5IGFzc3VtZSB6ZXJvIGlzIG9ubHkgZm9yIHBlZXIgbGV2ZWwgbWVzc2FnZXM/DQoNCkZyb206 IEpvdW5pIFttYWlsdG86am91bmkubm9zcGFtQGdtYWlsLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwg SnVseSAxOSwgMjAxNyAxOjAwIFBNDQpUbzogWXV2YWwgTGlmc2hpdHo7ICdCZXJ0eiwgTHlsZSBU IFtDVE9dJzsgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0bzpsaW9uZWwubW9yYW5kQG9y YW5nZS5jb20+OyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KU3ViamVjdDog UkU6IFtEaW1lXSBSRkMgNjczMyBDb21tYW5kcw0KDQpVbmxlc3MgeW91IGV4dGVuZCBhbmQgZXhp c3RpbmcgYXBwbGljYXRpb24gd2l0aGluIHRoZSBydWxlcyBpbiBTZWN0aW9uIDEuMy40IHlvdSBh bHdheXMgZ2V0IGEgbmV3IGFwcGxpY2F0aW9uLiBBbmQgaWYgeW91IHdpc2ggdG8gZXh0ZW5kIHRo ZSBleGlzdGluZyBiYXNlIHByb3RvY29sIGFwcGxpY2F0aW9uIHdpdGggbmV3IGNvbW1hbmRzIHRo YXQgbW9zdCBsaWtlbHkgd291bGQgcmVxdWlyZSBhIG5ldyBwcm90b2NvbCB2ZXJzaW9uLiBJIHRo aW5rIHdlIGFyZSBnb29kIGhlcmUgd2l0aCB0aGUgY3VycmVudCB0ZXh0Lg0KDQoNCi0gICAgICAg IEpvdW5pDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBZdXZhbCBMaWZzaGl0eg0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDE5LCAyMDE3IDEy OjMyIFBNDQpUbzogQmVydHosIEx5bGUgVCBbQ1RPXSA8THlsZS5ULkJlcnR6QHNwcmludC5jb208 bWFpbHRvOkx5bGUuVC5CZXJ0ekBzcHJpbnQuY29tPj47IGxpb25lbC5tb3JhbmRAb3JhbmdlLmNv bTxtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPjsgZGltZUBpZXRmLm9yZzxtYWlsdG86 ZGltZUBpZXRmLm9yZz4gbGlzdCA8ZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4+ DQpTdWJqZWN0OiBSZTogW0RpbWVdIFJGQyA2NzMzIENvbW1hbmRzDQoNCkFjdHVhbGx5LCB3ZSBt YXkgaGF2ZSBhbiBpc3N1ZSB0aGVyZS4gVGhlIHNwZWMgc2F5cyB0aGF0IHplcm8gbXVzdCBiZSB1 c2VkIGZvciBiYXNlIHByb3RvY29sIG1lc3NhZ2VzIChwYWdlIDIzKToNCg0KRGlhbWV0ZXIgbWVz c2FnZXMgcGVydGFpbmluZyB0byBwZWVyIGNvbm5lY3Rpb24NCiAgIGVzdGFibGlzaG1lbnQgYW5k IG1haW50ZW5hbmNlIHN1Y2ggYXMgQ0VSL0NFQSwgRFdSL0RXQSwgYW5kIERQUi9EUEENCiAgIE1V U1QgY2FycnkgYW4gQXBwbGljYXRpb24gSWQgb2YgemVybyAoMCkuDQoNCkJ1dCBkb2VzIG5vdCBz YXkgdGhhdCBpdCBtdXN0IG5vdCBiZSB1c2VkIGZvciBhbnl0aGluZyBlbHNlIChvciBhdCBsZWFz dCBJIGZhaWxlZCB0byBmaW5kIHN1Y2ggdGV4dCkuIERvIHlvdSB0aGluayBzdWNoIHRleHQgc2hv dWxkIGJlIGFkZGVkPw0KTm90ZSB0aGF0IHRoZXJlIGlzIHN1Y2ggdGV4dCByZWdhcmRpbmcgdmVu ZG9yLWlkLg0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgQmVydHosIEx5bGUgVCBbQ1RPXQ0KU2VudDogTW9uZGF5LCBKdWx5IDE3LCAyMDE3 IDY6MDQgUE0NClRvOiBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFpbHRvOmxpb25lbC5tb3Jh bmRAb3JhbmdlLmNvbT47IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+IGxpc3QN ClN1YmplY3Q6IFJlOiBbRGltZV0gUkZDIDY3MzMgQ29tbWFuZHMNCg0KDQphZ3JlZWQsIHdlIGhh dmUgZW5jb3VudGVyZWQgc29tZSBmb2xrcyB0eWluZyB0aGUgQUNSL0FDQSB0byBhcHAgaWQgMCBp biBvcGVuIHNvdXJjZS4NCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KRnJvbTogbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPG1haWx0bzpsaW9uZWwubW9yYW5kQG9y YW5nZS5jb20+IDxsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFpbHRvOmxpb25lbC5tb3JhbmRA b3JhbmdlLmNvbT4+DQpTZW50OiBNb25kYXksIEp1bHkgMTcsIDIwMTcgOTozMiBBTQ0KVG86IEJl cnR6LCBMeWxlIFQgW0NUT107IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+IGxp c3QNClN1YmplY3Q6IFJFOiBSRkMgNjczMyBDb21tYW5kcw0KDQpIaSBMeWxlLA0KDQpJIHRoaW5r IHRoYXQgdGhlcmUgaXMgbm8gc3BlY2lmaWMgcmVhc29uLiBCeSBkZWZpbml0aW9uLCB0aGUgY29t bWFuZCBpcyBpbmRlcGVuZGVudCBvZiBhbnkgYXBwbGljYXRpb24uIFNvIHdoZW4gZGVzY3JpYmlu ZyB0aGUgY29tbWFuZCBjb2RlLCBpdCBtYXkgb3IgbWF5IG5vdCBiZSBjb250YWluZWQgaW4gdGhl IGNvbW1hbmQgY29kZSBoZWFkZXIuIEl0IGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgQ0NGIHNwZWNp ZmljYXRpb246DQoNCiAgIGhlYWRlciAgICAgICAgICAgPSAiPERpYW1ldGVyLUhlYWRlcjoiIGNv bW1hbmQtaWQNCiAgICAgICAgICAgICAgICAgICAgICAgICBbci1iaXRdIFtwLWJpdF0gW2UtYml0 XSBbYXBwbGljYXRpb24taWRdIj4iDQoNClRoZSBDQ0YgaXMgbWFpbmx5IHVzZWQgdG8gaWRlbnRp ZnkgdGhlIHNldCBvZiBBVlAgdGhhdCBjYW4gYmUgcHJlc2VudCBpbiB0aGUgY29tbWFuZC4NCg0K UmVnYXJkcywNCg0KTGlvbmVsDQoNCkRlIDogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRm Lm9yZ10gRGUgbGEgcGFydCBkZSBCZXJ0eiwgTHlsZSBUIFtDVE9dDQpFbnZvecOpIDogbHVuZGkg MTcganVpbGxldCAyMDE3IDEyOjEyDQrDgCA6IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0 Zi5vcmc+IGxpc3QNCk9iamV0IDogW0RpbWVdIFJGQyA2NzMzIENvbW1hbmRzDQoNCg0KSW4gdGhl IHNwZWMgd2FzIHRoZXJlIGEgcGFydGljdWxhciByZWFzb24gd2h5IHdlIGRpZCBub3Qgc3BlY2lm eSB0aGUgYXBwbGljYXRpb24gSWRlbnRpZmllciBpbiB0aGUgaGVhZGVyIGZvciBlYWNoIG9mIHRo ZSBjb21tYW5kIGNvZGVzLCBlLmcuIEFDUi9BQ0EgYXNzaWduZWQgdG8gYXBwbGljYXRpb24gSUQg Mz8NCg0KDQoNCkx5bGUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVGhp cyBlLW1haWwgbWF5IGNvbnRhaW4gU3ByaW50IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uIGludGVu ZGVkIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIHJlY2lwaWVudChzKS4gQW55IHVzZSBieSBvdGhl cnMgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg cGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhlIG1l c3NhZ2UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVz IHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJp dmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KDQphIGwnZXhwZWRpdGV1ciBl dCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMg ZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KDQpPcmFuZ2Ug ZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwg ZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1h dGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5IHNob3VsZCBub3QgYmUg ZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQoNCkFz IGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2Vz IHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KVGhhbmsg eW91Lg0K --_000_150053523316128783sprintcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZSI+PCEtLSBQIHsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAw cHg7IH0gQGZvbnQtZmFjZSB7IGZvbnQtZmFtaWx5OiBXaW5nZGluZ3M7IH0gQGZvbnQtZmFjZSB7 IGZvbnQtZmFtaWx5OiAnQ2FtYnJpYSBNYXRoJzsgfSBAZm9udC1mYWNlIHsgZm9udC1mYW1pbHk6 IENhbGlicmk7IH0gQGZvbnQtZmFjZSB7IGZvbnQtZmFtaWx5OiBDb25zb2xhczsgfSBAZm9udC1m YWNlIHsgZm9udC1mYW1pbHk6IFRhaG9tYTsgfSBAZm9udC1mYWNlIHsgZm9udC1mYW1pbHk6ICdT ZWdvZSBVSSc7IH0gcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbCB7IG1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyB9IGE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsgeyBjb2xv cjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IH0gYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkIHsgY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRl cmxpbmU7IH0gcHJlIHsgbWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7 IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyB9IHAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0 ZSwgZGl2Lk1zb0FjZXRhdGUgeyBtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog OHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyB9IHAuTXNvTGlzdFBhcmFncmFw aCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGggeyBtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQgMC41aW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsgfSBzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyIHsgZm9udC1m YW1pbHk6IENvbnNvbGFzOyB9IHAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25v cm1hbDAgeyBtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgfSBzcGFuLkJhbGxvb25UZXh0Q2hhciB7 IGZvbnQtZmFtaWx5OiAnU2Vnb2UgVUknLCBzYW5zLXNlcmlmOyB9IHAubXNvbm9ybWFsMDAsIGxp Lm1zb25vcm1hbDAwLCBkaXYubXNvbm9ybWFsMDAgeyBtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsg fSBwLm1zb2NocGRlZmF1bHQsIGxpLm1zb2NocGRlZmF1bHQsIGRpdi5tc29jaHBkZWZhdWx0IHsg bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IH0gc3Bhbi5odG1scHJlZm9ybWF0dGVkY2hhcjAgeyBm b250LWZhbWlseTogQ29uc29sYXM7IH0gc3Bhbi5iYWxsb29udGV4dGNoYXIwIHsgZm9udC1mYW1p bHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsgfSBzcGFuLmVtYWlsc3R5bGUxOCB7IGZvbnQtZmFtaWx5 OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyBmb250LXdlaWdodDogbm9ybWFsOyBm b250LXN0eWxlOiBub3JtYWw7IH0gc3Bhbi5wcmZvcm1hdGh0bWxjYXIgeyBmb250LWZhbWlseTog J0NvdXJpZXIgTmV3JzsgfSBzcGFuLmVtYWlsc3R5bGUyNyB7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgfSBzcGFuLmVtYWlsc3R5bGUy OCB7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3Mywg MTI1KTsgfSBzcGFuLmVtYWlsc3R5bGUyOSB7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgfSBzcGFuLmVtYWlsc3R5bGUzMCB7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgfSBz cGFuLkVtYWlsU3R5bGUzNCB7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsgfSAuTXNvQ2hwRGVmYXVsdCB7IGZvbnQtc2l6ZTogMTBwdDsg fSBAcGFnZSBXb3JkU2VjdGlvbjEgeyBtYXJnaW46IDFpbjsgfSBkaXYuV29yZFNlY3Rpb24xIHsg fSBvbCB7IG1hcmdpbi1ib3R0b206IDBpbjsgfSB1bCB7IG1hcmdpbi1ib3R0b206IDBpbjsgfS0t Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBkaXI9Imx0ciIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0 O2NvbG9yOiMwMDAwMDA7YmFja2dyb3VuZC1jb2xvcjojRkZGRkZGO2ZvbnQtZmFtaWx5OkNhbGli cmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWY7Ij4NCjxwPuKAi05vIHNwZWMgaXNzdWVzIGhl cmUuIEp1c3QgcGVvcGxlIG5vdCByZWFkaW5nIHRoZSBlbnRpcmUgc3BlYyBhbmQgcGlja2luZyB1 cCBvbiBldmVyeSBzZW50ZW5jZSAob3IgcmVhZGluZyBpdCBhbGwgaW1vKS48YnI+DQo8L3A+DQo8 ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDMzLCAzMywgMzMpOyI+DQo8aHIgdGFiaW5kZXg9Ii0xIiBz dHlsZT0iZGlzcGxheTppbmxpbmUtYmxvY2s7IHdpZHRoOjk4JSI+DQo8ZGl2IGlkPSJkaXZScGx5 RndkTXNnIiBkaXI9Imx0ciI+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgc2Fucy1zZXJpZiIgY29sb3I9 IiMwMDAwMDAiIHN0eWxlPSJmb250LXNpemU6MTFwdCI+PGI+RnJvbTo8L2I+IEpvdW5pICZsdDtq b3VuaS5ub3NwYW1AZ21haWwuY29tJmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEp1 bHkgMTksIDIwMTcgNzoyNSBBTTxicj4NCjxiPlRvOjwvYj4gQmVydHosIEx5bGUgVCBbQ1RPXTsg J1l1dmFsIExpZnNoaXR6JzsgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tOyBkaW1lQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbRGltZV0gUkZDIDY3MzMgQ29tbWFuZHM8L2ZvbnQ+ DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMxRjQ5 N0QiPlRoZXJlIGlzIEFjY3QtQXBwbGljYXRpb24tSWQgaW4gdGhlIENDRi4uIHNvIHdoYXTigJlz IHRoZSBkaWZmZXJlbmNlPzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmOyBjb2xvcjojMUY0OTdEIj7igJxJZiBwcmVzZW50IGluIGEgbWVzc2FnZSBvdGhl ciB0aGFuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 IGNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBDRVIgYW5kIENFQSwgdGhlIHZhbHVlIG9mIHRo ZSBBY2N0LUFwcGxpY2F0aW9uLUlkIEFWUCBNVVNUIG1hdGNoIHRoZTwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjojMUY0OTdEIj4mbmJzcDsm bmJzcDsgQXBwbGljYXRpb24gSWQgcHJlc2VudCBpbiB0aGUgRGlhbWV0ZXIgbWVzc2FnZSBoZWFk ZXIu4oCdPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 IGNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmOyBjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7IGNvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSIiPi08c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjsgY29sb3I6IzFGNDk3RCI+Sk91bmk8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjsgY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lOyBib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0OyBwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTsg Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0OyBwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQmVydHosIEx5bGUgVCBbQ1RPXSBbbWFpbHRvOkx5bGUu VC5CZXJ0ekBzcHJpbnQuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSnVseSAx OSwgMjAxNyAxNDo1NiBQTTxicj4NCjxiPlRvOjwvYj4gSm91bmkgJmx0O2pvdW5pLm5vc3BhbUBn bWFpbC5jb20mZ3Q7OyAnWXV2YWwgTGlmc2hpdHonICZsdDt5bGlmc2hpdHpAc2FuZHZpbmUuY29t Jmd0OzsgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tOyBkaW1lQGlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbRGltZV0gUkZDIDY3MzMgQ29tbWFuZHM8L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxwPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOmJsYWNr Ij5NeSBpc3N1ZSAoYW5kIHRoZSBtb3RpdmUgZm9yIHRoZSBlLW1haWwpIGlzIHRoYXQgc29tZSBs YXp5IGltcGxlbWVudG9ycyB0aWVkIHRoZSBBQ1IvQUNBIHRvIDAgd2hpY2ggc2hvdWxkIG5vdCBo YXZlIGhhcHBlbmVkLjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwv cD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7IGNvbG9yOmJsYWNrIj5BbHRob3VnaCBvcHRpb25hbCwgaGF2aW5nIHBsYWNlZCB0aGUg QXBwIElEIG9mIDMgaW4gdGhlIEFDUi9BQ0Egd291bGQgaGF2ZSBhdCBsZWFzdCBiZWdnZWQgdGhl IHF1ZXN0aW9uIG9mIGhvdyBkaWQgeW91IG1pc3MgdGhhdD8gJm5ic3A7IEl0IGlzIHByZXR0eSBj bGVhciB0byBtZSB0aGF0IHRoZSBkZXYgb25seSBsb29rZWQgQCB0aGUgQ0NGIGFuZA0KIG5vdCB0 aGUgcmVzdCBvZiB0aGUgZG9jdW1lbnQuICZuYnNwOyBIb3dldmVyLCBpZiB0aGUgYXBwIGlkIHdh cyBpbiB0aGUgQ0NGIHRoYXQgc3BlY2lmaWMgaXNzdWUgd291bGQgaGF2ZSBiZWVuIGF2b2lkZWQu PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHA+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjsgY29sb3I6 YmxhY2siPldlIGNhbid0IGZpeCBvbmUncyBpbmFiaWxpdHkgdG8gcmVhZCB0aGUgd2hvbGUgZG9j dW1lbnQgYnV0IHdlIGNhbiB0YWtlIHN0ZXBzIHRvIGxvd2VyIHRoZSBwcm9iYWJpbGl0eSBvZiBh biBlcnJvciB3aGVuIHRoZXkgdGFrZSBzaG9ydGN1dHMuPC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOmJs YWNrIj4mbmJzcDs8L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjojMjEyMTIxIj4NCjxo ciBzaXplPSIzIiB3aWR0aD0iOTglIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxk aXYgaWQ9ImRpdlJwbHlGd2RNc2ciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjsgY29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmOyBj b2xvcjpibGFjayI+IEpvdW5pICZsdDs8YSBocmVmPSJtYWlsdG86am91bmkubm9zcGFtQGdtYWls LmNvbSI+am91bmkubm9zcGFtQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U2VudDo8L2I+IFdl ZG5lc2RheSwgSnVseSAxOSwgMjAxNyA2OjAzIEFNPGJyPg0KPGI+VG86PC9iPiAnWXV2YWwgTGlm c2hpdHonOyBCZXJ0eiwgTHlsZSBUIFtDVE9dOyA8YSBocmVmPSJtYWlsdG86bGlvbmVsLm1vcmFu ZEBvcmFuZ2UuY29tIj4NCmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT47IDxhIGhyZWY9Im1h aWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSRTogW0RpbWVdIFJGQyA2NzMzIENvbW1hbmRzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMyMTIxMjEiPg0KPC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjojMjEyMTIxIj4mbmJz cDs8L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjsgY29sb3I6IzFGNDk3RCI+SWYgeW91IGdvIGZvciBu ZXcgcHJvdG9jb2wgdmVyc2lvbiB0aGF0IG9wZW5zIGEgZG9vciBmb3IgYSBsb3Qgb2YgdGhpbmdz LiBHZW5lcmFsbHkgYWRkaW5nIGNvbW1hbmRzIHRvIGJhc2UgcHJvdG9jb2wgdXNpbmcgYXBwLWlk IDAgaXMgbm90IHBvc3NpYmxlIHdpdGhvdXQNCiBhIG5ldyBwcm90b2NvbCB2ZXJzaW9uLiBJIGRv IG5vdCBzZWUgYSByZWFzb24gZm9yIGFueSBleHRyYSBjbGFyaWZpY2F0aW9ucy4gSSB3b3VsZCBi ZSByZWx1Y3RhbnQgdG8gYXNzdW1lIGFwcC1pZCAwIGlzIGZvcmV2ZXIgZm9yIHBlZXIgbGV2ZWwg Y29tbWFuZHMuIFdlIGhhdmUgb3RoZXIgd2F5cyB0byBpbXBvc2UgdGhhdCByZXN0cmljdGlvbiBh dCB0aGUgQVZQIGxldmVsIHdoZXJlIHN1Y2ggdGhpbmdzIGFjdHVhbGx5IGJlbG9uZyAoc2VlIFNl Y3Rpb24NCiA2LjEpLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmOyBjb2xvcjojMUY0OTdEIj4tPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny4wcHQ7IGNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMxRjQ5N0QiPkpPdW5p PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjsgY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7IGJvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7IHBhZGRpbmc6MGluIDBpbiAw aW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lOyBib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7IHBhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjsgY29sb3I6IzIxMjEyMSI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMyMTIxMjEiPiBZdXZhbCBMaWZzaGl0eiBb PGEgaHJlZj0ibWFpbHRvOnlsaWZzaGl0ekBzYW5kdmluZS5jb20iPm1haWx0bzp5bGlmc2hpdHpA c2FuZHZpbmUuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEp1bHkgMTks IDIwMTcgMTM6MjAgUE08YnI+DQo8Yj5Ubzo8L2I+IEpvdW5pICZsdDs8YSBocmVmPSJtYWlsdG86 am91bmkubm9zcGFtQGdtYWlsLmNvbSI+am91bmkubm9zcGFtQGdtYWlsLmNvbTwvYT4mZ3Q7OyAn QmVydHosIEx5bGUgVCBbQ1RPXScgJmx0OzxhIGhyZWY9Im1haWx0bzpMeWxlLlQuQmVydHpAc3By aW50LmNvbSI+THlsZS5ULkJlcnR6QHNwcmludC5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0 bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20iPmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT47 IDxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj4NCmRpbWVAaWV0Zi5vcmc8L2E+PGJyPg0K PGI+Q2M6PC9iPiBZdXZhbCBMaWZzaGl0eiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlsaWZzaGl0ekBz YW5kdmluZS5jb20iPnlsaWZzaGl0ekBzYW5kdmluZS5jb208L2E+Jmd0Ozxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSRTogW0RpbWVdIFJGQyA2NzMzIENvbW1hbmRzPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjojMjEyMTIxIj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjsgY29sb3I6IzFGNDk3RCI+WW91IG1l YW4sIHRoYXQgaWYgc29tZW9uZSBpbXBsZW1lbnQgYSBuZXcgcHJvdG9jb2wgYnV0IGRvZXMgbm90 IGNoYW5nZSBkZWZpbml0aW9ucyBmcm9tIGJhc2UsIG5vdCBhZGQgYW55IG5ldyBzdHVmZiB3aGlj aCBpcyBtYW5kYXRvcnksIHRoZXkgYXJlIGFsbG93ZWQgdG8NCiB1c2UgYXBwbGljYXRpb24taWQg emVybyBmb3IgY29tbWFuZHMgb3RoZXIgdGhhbiAoQ0VSQSwgRFBSL0EsIERXUi9BKT88L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEiPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjojMUY0OTdEIj5TaG91bGRu4oCZdCB3ZSBibG9j ayB0aGF0PyBXb3VsZCBpbWFnaW5lIHRoZXJlIGFyZSBpbXBsZW1lbnRhdGlvbnMgd2hlcmUgdGhl eSBhc3N1bWUgemVybyBpcyBvbmx5IGZvciBwZWVyIGxldmVsIG1lc3NhZ2VzPzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6IzIxMjEyMSI+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6IzIxMjEyMSI+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTsgYm9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0OyBwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjsgY29sb3I6 IzIxMjEyMSI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjsgY29sb3I6IzIxMjEyMSI+ IEpvdW5pIFs8YSBocmVmPSJtYWlsdG86am91bmkubm9zcGFtQGdtYWlsLmNvbSI+bWFpbHRvOmpv dW5pLm5vc3BhbUBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwg SnVseSAxOSwgMjAxNyAxOjAwIFBNPGJyPg0KPGI+VG86PC9iPiBZdXZhbCBMaWZzaGl0ejsgJ0Jl cnR6LCBMeWxlIFQgW0NUT10nOyA8YSBocmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2Uu Y29tIj4NCmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpkaW1l QGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0Rp bWVdIFJGQyA2NzMzIENvbW1hbmRzPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMjEyMTIxIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjsgY29sb3I6IzFGNDk3RCI+VW5sZXNzIHlvdSBleHRlbmQgYW5k IGV4aXN0aW5nIGFwcGxpY2F0aW9uIHdpdGhpbiB0aGUgcnVsZXMgaW4gU2VjdGlvbiAxLjMuNCB5 b3UgYWx3YXlzIGdldCBhIG5ldyBhcHBsaWNhdGlvbi4gQW5kIGlmIHlvdSB3aXNoIHRvIGV4dGVu ZCB0aGUgZXhpc3RpbmcgYmFzZSBwcm90b2NvbA0KIGFwcGxpY2F0aW9uIHdpdGggbmV3IGNvbW1h bmRzIHRoYXQgbW9zdCBsaWtlbHkgd291bGQgcmVxdWlyZSBhIG5ldyBwcm90b2NvbCB2ZXJzaW9u LiBJIHRoaW5rIHdlIGFyZSBnb29kIGhlcmUgd2l0aCB0aGUgY3VycmVudCB0ZXh0Ljwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6IzIxMjEyMSI+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjoj MUY0OTdEIj4tPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7IGNvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMxRjQ5N0QiPkpvdW5pDQo8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOiMyMTIxMjEiPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmOyBjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OiMyMTIxMjEiPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTsgYm9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDsgcGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7IGJvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDsg cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmOyBjb2xvcjojMjEyMTIxIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjsgY29sb3I6IzIxMjEyMSI+IERpTUUgWzxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNA aWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5ZdXZhbCBMaWZzaGl0ejxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEp1bHkg MTksIDIwMTcgMTI6MzIgUE08YnI+DQo8Yj5Ubzo8L2I+IEJlcnR6LCBMeWxlIFQgW0NUT10gJmx0 OzxhIGhyZWY9Im1haWx0bzpMeWxlLlQuQmVydHpAc3ByaW50LmNvbSI+THlsZS5ULkJlcnR6QHNw cmludC5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5j b20iPmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpkaW1lQGll dGYub3JnIj4NCmRpbWVAaWV0Zi5vcmc8L2E+IGxpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzpkaW1l QGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtEaW1lXSBSRkMgNjczMyBDb21tYW5kczwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEy MSI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzIxMjEyMSI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMxRjQ5N0QiPkFjdHVhbGx5LCB3ZSBtYXkg aGF2ZSBhbiBpc3N1ZSB0aGVyZS4gVGhlIHNwZWMgc2F5cyB0aGF0IHplcm8gbXVzdCBiZSB1c2Vk IGZvciBiYXNlIHByb3RvY29sIG1lc3NhZ2VzIChwYWdlIDIzKTo8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOiMyMTIxMjEiPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmOyBjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OiMyMTIxMjEiPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IGNv bG9yOmJsYWNrIj5EaWFtZXRlciBtZXNzYWdlcyBwZXJ0YWluaW5nIHRvIHBlZXIgY29ubmVjdGlv bjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OzsgY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBlc3RhYmxp c2htZW50IGFuZCBtYWludGVuYW5jZSBzdWNoIGFzIENFUi9DRUEsIERXUi9EV0EsIGFuZCBEUFIv RFBBPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyBjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IE1VU1Qg Y2FycnkgYW4gQXBwbGljYXRpb24gSWQgb2YgemVybyAoMCkuPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjojMjEyMTIxIj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjsgY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjoj MjEyMTIxIj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZjsgY29sb3I6IzFGNDk3RCI+QnV0IGRvZXMgbm90IHNheSB0aGF0IGl0IG11c3Qgbm90IGJlIHVz ZWQgZm9yIGFueXRoaW5nIGVsc2UgKG9yIGF0IGxlYXN0IEkgZmFpbGVkIHRvIGZpbmQgc3VjaCB0 ZXh0KS4gRG8geW91IHRoaW5rIHN1Y2ggdGV4dCBzaG91bGQgYmUgYWRkZWQ/PC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjojMjEyMTIxIj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjsgY29sb3I6IzFGNDk3RCI+Tm90ZSB0aGF0IHRoZXJlIGlzIHN1Y2gg dGV4dCByZWdhcmRpbmcgdmVuZG9yLWlkLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEy MSI+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTsgYm9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0OyBwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjsgY29sb3I6IzIxMjEyMSI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssc2Fucy1zZXJpZjsgY29sb3I6IzIxMjEyMSI+IERpTUUgWzxhIGhyZWY9Im1haWx0 bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CZXJ0eiwgTHlsZSBUIFtDVE9dPGJyPg0KPGI+U2VudDo8 L2I+IE1vbmRheSwgSnVseSAxNywgMjAxNyA2OjA0IFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVm PSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIj5saW9uZWwubW9yYW5kQG9yYW5nZS5j b208L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L2E+ IGxpc3Q8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEaW1lXSBSRkMgNjczMyBDb21tYW5kczwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+Jm5i c3A7PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOmJsYWNrIj5hZ3JlZWQsIHdlIGhhdmUgZW5jb3VudGVy ZWQgc29tZSBmb2xrcyB0eWluZyB0aGUgQUNSL0FDQSB0byBhcHAgaWQgMCBpbiBvcGVuIHNvdXJj ZS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjsgY29sb3I6IzIxMjEyMSI+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjsgY29sb3I6IzIxMjEyMSI+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjsgY29sb3I6IzIxMjEyMSI+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjsgY29sb3I6 IzIxMjEyMSI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9Ijk4JSIgYWxpZ249ImNlbnRlciI+DQo8L3Nw YW4+PC9kaXY+DQo8ZGl2IGlkPSJkaXZScGx5RndkTXNnIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjsgY29sb3I6YmxhY2siPg0KPGEgaHJlZj0ibWFpbHRvOmxpb25lbC5tb3JhbmRA b3JhbmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPiAmbHQ7PGEgaHJlZj0ibWFp bHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9h PiZndDs8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBKdWx5IDE3LCAyMDE3IDk6MzIgQU08YnI+ DQo8Yj5Ubzo8L2I+IEJlcnR6LCBMeWxlIFQgW0NUT107IDxhIGhyZWY9Im1haWx0bzpkaW1lQGll dGYub3JnIj5kaW1lQGlldGYub3JnPC9hPiBsaXN0PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBS RkMgNjczMyBDb21tYW5kczwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjojMjEyMTIxIj4NCjwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6IzIxMjEyMSI+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm OyBjb2xvcjojMjEyMTIxIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEi Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjsgY29sb3I6YmxhY2siPkhpIEx5bGUsPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjojMjEyMTIxIj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOiMyMTIxMjEiPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjsgY29sb3I6YmxhY2siPkkgdGhpbmsgdGhhdCB0aGVyZSBpcyBubyBzcGVjaWZpYyByZWFz b24uIEJ5IGRlZmluaXRpb24sIHRoZSBjb21tYW5kIGlzIGluZGVwZW5kZW50IG9mIGFueSBhcHBs aWNhdGlvbi4gU28gd2hlbiBkZXNjcmliaW5nIHRoZSBjb21tYW5kIGNvZGUsIGl0IG1heSBvciBt YXkgbm90IGJlDQogY29udGFpbmVkIGluIHRoZSBjb21tYW5kIGNvZGUgaGVhZGVyLiBJdCBpcyBj b25zaXN0ZW50IHdpdGggdGhlIENDRiBzcGVjaWZpY2F0aW9uOjwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6IzIxMjEyMSI+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmOyBjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMjEy MTIxIj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyBjb2xvcjoj MjEyMTIxIj4mbmJzcDsmbmJzcDsgaGVhZGVyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ID0gJnF1b3Q7Jmx0O0RpYW1ldGVyLUhlYWRl cjomcXVvdDsgY29tbWFuZC1pZDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0OyBmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsgY29sb3I6IzIxMjEyMSI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtyLWJpdF0gW3AtYml0XSBbZS1iaXRdIFth cHBsaWNhdGlvbi1pZF0mcXVvdDsmZ3Q7JnF1b3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjoj MjEyMTIxIj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 IGNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEiPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjsgY29sb3I6Ymxh Y2siPlRoZSBDQ0YgaXMgbWFpbmx5IHVzZWQgdG8gaWRlbnRpZnkgdGhlIHNldCBvZiBBVlAgdGhh dCBjYW4gYmUgcHJlc2VudCBpbiB0aGUgY29tbWFuZC48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OiMyMTIxMjEiPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZjsgY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjpi bGFjayI+UmVnYXJkcyw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEiPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsg Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjsgY29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjpibGFjayI+TGlvbmVsDQo8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEiPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjsgY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6IzIxMjEyMSI+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l OyBib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0OyBwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTsgYm9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0OyBwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssc2Fucy1zZXJpZjsgY29sb3I6IzIxMjEyMSI+RGUmbmJzcDs6PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMyMTIxMjEiPiBEaU1FIFs8YSBocmVmPSJtYWlsdG86 ZGltZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPl0N CjxiPkRlIGxhIHBhcnQgZGU8L2I+IEJlcnR6LCBMeWxlIFQgW0NUT108YnI+DQo8Yj5FbnZvecOp Jm5ic3A7OjwvYj4gbHVuZGkgMTcganVpbGxldCAyMDE3IDEyOjEyPGJyPg0KPGI+w4AmbmJzcDs6 PC9iPiA8YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT4gbGlz dDxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gW0RpbWVdIFJGQyA2NzMzIENvbW1hbmRzPC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj4mbmJzcDs8 L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjsgY29sb3I6YmxhY2siPkluIHRoZSBzcGVjIHdhcyB0aGVyZSBhIHBhcnRp Y3VsYXIgcmVhc29uIHdoeSB3ZSBkaWQgbm90IHNwZWNpZnkgdGhlIGFwcGxpY2F0aW9uIElkZW50 aWZpZXIgaW4gdGhlIGhlYWRlciZuYnNwO2ZvciBlYWNoIG9mIHRoZSBjb21tYW5kIGNvZGVzLCBl LmcuIEFDUi9BQ0EgYXNzaWduZWQgdG8gYXBwbGljYXRpb24gSUQgMz88L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjsgY29sb3I6IzIx MjEyMSI+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjsgY29sb3I6IzIx MjEyMSI+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOmJsYWNrIj5MeWxlPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNvbG9yOiMyMTIx MjEiPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjpibGFjayI+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj48L3NwYW4+PC9wPg0KPGRpdiBjbGFz cz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7IGNv bG9yOmJsYWNrIj4NCjxociBzaXplPSIzIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8 L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuNXB0OyBmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmOyBjb2xvcjpn cmF5Ij48YnI+DQpUaGlzIGUtbWFpbCBtYXkgY29udGFpbiBTcHJpbnQgcHJvcHJpZXRhcnkgaW5m b3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMpLiBB bnkgdXNlIGJ5IG90aGVycyBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNv cGllcyBvZiB0aGUgbWVzc2FnZS48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEiPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEy MSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEi PiZuYnNwOzwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEiPkNl IG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9y bWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9u Yzwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiMyMTIxMjEiPnBhcyBldHJl IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz IGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+YSBsJ2V4cGVkaXRl dXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh Z2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj5PcmFuZ2UgZGVjbGluZSB0 b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBv dSBmYWxzaWZpZS4gTWVyY2kuPC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 IzIxMjEyMSI+Jm5ic3A7PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6IzIx MjEyMSI+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5 IGxhdzs8L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj50aGV5 IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9y aXNhdGlvbi48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj5J ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjojMjEyMTIxIj5BcyBlbWFpbHMgbWF5 IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUg YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iY29sb3I6IzIxMjEyMSI+VGhhbmsgeW91Ljwvc3Bhbj48L3ByZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_150053523316128783sprintcom_-- From nobody Thu Jul 20 03:18:53 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB0F131C07 for ; Thu, 20 Jul 2017 03:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ZzHys9VahYlA for ; Thu, 20 Jul 2017 03:18:47 -0700 (PDT) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B20B4131C06 for ; Thu, 20 Jul 2017 03:18:46 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 2830F60406; Thu, 20 Jul 2017 12:18:45 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 06D341800E6; Thu, 20 Jul 2017 12:18:45 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0352.000; Thu, 20 Jul 2017 12:18:44 +0200 From: To: "A. Jean Mahoney" , "dime@ietf.org" Thread-Topic: [Dime] 99 IETF DIME session notes Thread-Index: AQHS/8uhtNUpB2gy/USG+OmxoOsyFKJcgw6g Date: Thu, 20 Jul 2017 10:18:43 +0000 Message-ID: <24216_1500545925_59708385_24216_13_1_6B7134B31289DC4FAF731D844122B36E2D1BD1D1@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <9ec38b25-41d4-a751-aa97-d8af0f9022c5@nostrum.com> In-Reply-To: <9ec38b25-41d4-a751-aa97-d8af0f9022c5@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] 99 IETF DIME session notes X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 10:18:49 -0000 Thank you! Not only for this one but also for your kind and precious help (minutes, co= ntributions, reviews) for all these year! Lionel > -----Message d'origine----- > De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de A. Jean Mahoney > Envoy=E9=A0: mardi 18 juillet 2017 15:42 > =C0=A0: dime@ietf.org > Objet=A0: [Dime] 99 IETF DIME session notes >=20 > Hi all, >=20 > Below are my notes from the session yesterday. >=20 > Thanks! >=20 > Jean >=20 >=20 > -------------------------------------------------------------------------= ------------------ >=20 > IETF-99 DIME >=20 > 1740-1840 July 17, 2017, Monday Afternoon session III meeting room: Karl= in III > Jabber room: dime at jabber.ietf.org (Please join) >=20 > Chairs:Jouni Korhonen, Lionel Morand > AD: Ben Campbell >=20 > 17:40 - 17:45, Preliminaries, Chairs (5 minutes) > ------------------------------------------ > Presentation: > https://www.ietf.org/proceedings/99/slides/slides-99-dime-agenda-wg-statu= s- > 00.pdf >=20 > slide 1: Title >=20 > Lionel Morand: Jouni is not able to make it to the meeting. >=20 > slide 2: Note Well >=20 > slide 3: Agenda >=20 > Note taker/Jabber scribe: Jean Mahoney >=20 > Martin Dolly: when will Diameter security discussion happen? >=20 > Lionel: end of the session. >=20 >=20 > 17:45 - 17:50, WG Document Status, Chairs (5 minutes) > ------------------------------------------ >=20 > *draft-ietf-dime-agent-overload-11 --> RFC Ed Queue > *draft-ietf-dime-doic-rate-control-06 --> Waiting for Write-Up > *draft-ietf-dime-group-signaling-08 --> In WG Last Call > *draft-ietf-dime-load-09 --> RFC Ed Queue > *draft-ietf-dime-rfc4006bis-03 --> In WG Last Call >=20 > slide 4: WG Status Update >=20 > Lionel: Both overload and load are in the RFC editor queue due to a MISRE= F. I'll > take care of it after this meeting. >=20 > Steve Donovan: Just a nit on the slide - I'm the editor on load informati= on, I'm not > the editor for 4006bis. >=20 > Lionel: Group signaling - the author's think it's ready. We need more rev= iews. > Marco? >=20 > Marco Liebsch: we've updated it before Chicago. We've covered all comment= s. Is > ready for expert review. >=20 > Lionel: we've received a good technical review from Steve. Needs another = before > WGLC. Rate control is missing its writeup. >=20 > Steve: Has it finished WGLC? >=20 > Lionel: Yes, needs writeup. Rate-control didn't receive a deep technical = review. > Need further review. From SA5 guys in 3GPP, since they are the main users. >=20 > slide 5: WG Status update (2/2) >=20 > Lionel: AVP level security (e2e) draft has expired - Jouni is not able to= support the > workload alone. I will go to the SAAG meeting and will ask for support fr= om > security experts. Solution doesn't have to be Diameter specific. >=20 > Ben Campbell: I would personally like to see this completed. Who will dep= loy it? >=20 > Martin Dolly: next round of FCC sys req, they just finished looking at > SS7 security vulnerabilities, next 2 years they'll look at Diameter. SA3 = coming up > in 3 weeks. I'll give them discussion paper, a status update of work here= . It gets > friendly talk there. It's been discussed with regard to 5G and security s= ystem. It's > now or never, forever-hold-your-peace time. >=20 > Lionel: GSMA would like a recommendation. If it's easy to implement, we h= ave > ongoing deployment. >=20 > Ben: They are welcome to come here and help. >=20 > Eric Guttman: for mission-critical deployments, there are 2 security doma= ins - > operator domain and mission-critical operator domain. We've looked at sec= uring at > a message or component to a SIP message level. The message has to be e2e > secure between client and host at the mission-critical ISP. Are there AAA > requirements where you can't expose certain AVPs to the operator? Need to > check. >=20 > Lionel: From the requirements POV, both should be available with the solu= tion. > Normally you would only be able to secure signaling between gateways for > instance. You may have e2e secure exchange between any Diameter client and > any Diameter server. >=20 > Martin: I don't think that's a case. 401 specifies that equipment manufac= turers > must support IPsec for communication within the EPC, but says it optional= to > deploy. No one has deployed. For 5G, the European operators are fighting = pulling > the security into the EPC not at the ENodeB. Some of those statements are= n't > true. >=20 > Lionel: Ben, you see there is some interest. We would like to see this wo= rk done in > IETF. >=20 > Ben: I observe an interest in using the work. I need to observe interest = in doing > the work. Maybe SAAG will help. >=20 > Lionel: It's more a security discussion than a Diameter discussion. Need = help from > security area. >=20 > Eric: There was a mechanism for using an SMIME encapsulation. That became > historic? >=20 > Lionel: deprecated. A new mechanism will be defined outside the base prot= ocol. All > new drafts are based on this. >=20 >=20 >=20 > 17:50 - 18:35 Individual draft discussions (45 minutes) > ------------------------------------------- >=20 > 17:50 - 18:10 Diameter Policy Groups and Sets, Lyle (20min) > Draft: https://tools.ietf.org/html/draft-bertz-dime-predictunits-02 > Draft: https://tools.ietf.org/html/draft-bertz-dime-policygroups-04 > Presentation: > https://www.ietf.org/proceedings/99/slides/slides-99-dime-predicted-units= -policy- > groups-00.pdf >=20 >=20 > slide 1: Title >=20 > slide 2: Predicted Units v02 - Motivation >=20 > Lyle: It takes 3-4 minutes to spin up a VM. >=20 > slide 3: Predicted Units v02 - Update >=20 > Lyle: Have not received any new updates. I would like to ask for adoption. >=20 > Lionel: Who has read? I wasn't in the last meeting what was the feeling > in the room? >=20 > Ben: Besides the chair and the AD? >=20 > Jean: About 7 people total. >=20 > Lionel: I've read it and understood the mechanism, which is good. Check > on the ML if there is support for adoption. There's not much to do on > this doc. >=20 > slide 4: Intermission >=20 > slide 5: Purpose >=20 > slide 6: Policy Groups - Update >=20 > slide 7: Relationship Model >=20 > slide 8: Policy Groups Example 1, Overlap Deduplication at Enforcement > Point - Adding Membership Assignment to Filters >=20 > Lyle: SDN switches have limitations of tables (13 tables in OpenFlow). > Can concatenate tables. The rules no longer overlap. How to use your > metadata field and tie it back to a customer? >=20 > slide 9: Policy Groups Example 2, Application at the Decision Point Proce= ss >=20 > Lyle: We don't change the user's relationship to their services > mid-session. Usually reauthorize them before doing that. >=20 > slide 10: Applications >=20 > slide 11: Next Steps >=20 > Lyle: Would like to hear more from the group before asking for adoption. >=20 > Lionel: who has read? >=20 > Lionel: Go back to the Purpose slide. >=20 > Lyle: didn't want to confuse people but wanted a similar aggregation > concept with backwards compatibility. It's similar to ... It's a > membership domain. >=20 > Lionel: I need to review it again. It would be useful to have more review. >=20 > Lyle: I'm not happy with the examples, I'd like them to be consistent > through the doc. >=20 > Lionel: the draft needs to clearly identify why you can't do this with > existing mechanisms. >=20 > Lyle: all of our filters are based on time and what's in the packets. > When the time is the same and the rule is a default rule, that's the > most overlap in the system. >=20 > Lionel: It's not that clear from the creation of AVP, be good to > describe it. >=20 >=20 > 18:10 - 18:35 Diameter Specification Recommendations, Lyle (25min) > Draft: https://tools.ietf.org/html/draft-bertz-dime-diamimpr-00 > Pres: > https://www.ietf.org/proceedings/99/slides/slides-99-dime-diameter-specif= ication- > recommendations-00.pdf >=20 > slide 1: Title >=20 > slide 2: Motivation >=20 > Lyle: 85% of the time, errors due to ambiguity. >=20 > slide 3: Findings >=20 > Eric Guttman: send this to SA5 charging if you have a delegate. >=20 > Lyle: we don't, but wanted to get it out. >=20 > slide 4: Methodology >=20 > slide 5: Unexpected Use Cases >=20 > slide 6: We are not immune >=20 > slide 7: Enumerations >=20 > slide 8: Recommendations >=20 > slide 9: Defined AVP Recommendations >=20 > slide 10: Defined AVPs Recommended Formats >=20 > slide 11: Imported AVP Recommendations >=20 > slide 12: Grouped AVP / Command Refinement >=20 > slide 13: Example Refinement >=20 > slide 14: Command Recommendations >=20 > slide 15: Enumeration Recommendations >=20 > slide 16: GAPs for Automated Validation >=20 > slide 17: Example to Close Gaps >=20 > slide 18: Enumeration Example Format >=20 > slide 19: Open Questions >=20 > slide 20: Summary >=20 > slide 21: Next steps >=20 > Lionel: who has read? (Three people raised hands) >=20 > Lyle: Dave Dolson and Jouni read it. >=20 > Lionel: in 3GPP it's not really refinement, because in 3GPP just > highlight the AVPs they use. We you take a specification and not reading > anything - >=20 > Lyle: they want to just write the code and be done. >=20 > Lionel: For new drafts, it should be taken into consideration. For > existing RFCs, these are documentation errors. When it's clarification, > it needs to go through the errata process. For the 3GPP specs, CRs need > to be opened. >=20 > Lyle: This has a lot of errors documented. Would this be informational? > How would it progress? >=20 > Lionel: It can be informational, and can be referenced by other docs. No > guideline here. Just highlight what could go wrong. >=20 > Lyle: I would change the style. Make it more of a report. >=20 > Lionel: It's not unusual for the IETF to explain issues with > implementations. >=20 >=20 > 18:35 - 18:40 Wrap-up and Next, Chairs/AD (5 minutes) > ----------------------------- >=20 > WG Goals/Milestones status - skipped >=20 > Next steps/Action Points - Future of the WG >=20 > Lionel: We have 3 remaining documents. >=20 > Ben: And two that you are thinking of adopting. >=20 > Lionel: few people in room, not much activity on the list. I won't be > able to continue with the chair position - too much work in the 3GPP. > Same with Jouni - he changed companies, won't be able to continue. What > is the next step except closing the group? >=20 > Ben: The existing documents are post or near WGLC. Those can be in the > hands of the ADs before long. What's you're time frame for needing to > step down? >=20 > Lionel: I need to know when to stop adopting new documents. Even for Joun= i. >=20 > Ben: Of the 2 drafts for the adoption - the predictive units can be AD > sponsored. The group one is on the border, a little more complex. I > don't have to be the AD that sponsors it. >=20 > Lionel: For the group one, I need to see more interest. >=20 > Ben: even if I AD sponsor, I want someone to review them. >=20 > Lionel: E2E security needs to be done. If we get volunteers from SAAG. >=20 > Ben: lets see what happens in SAAG. If there's interest - maybe we can > spin up some mini-group. Or just speculating here - recharter dime with > new chairs to just do that. >=20 > Lionel: If it is only to go with existing drafts, I think it can be done > in short timeframe. Need to confirm with Jouni. Defining new charter > with new chairs may not be useful. >=20 > Ben: E2E security may go into the security area. >=20 > Lionel: Are there any other comments? (none from the room). To summarize > - existing WG documents will be pushed forward. For predictive units, > confirm on ML that it's a WG doc, for the group one, we'll check. After > those documents, we'll close the WG. >=20 > Ben: Those 2 new drafts - predictive definitely and maybe group - can be > AD sponsored. They can still change to AD sponsorship if we need to > close the working group sooner. I'm skeptical of bringing new work into > the group, unless we see interest. >=20 > Lionel: Thank you. >=20 > ACTION: Chairs to push existing WG documents forward. >=20 > ACTION: Lionel to bring the e2e security draft to the SAAG session this > week to ask for support in finishing it. >=20 > ACTION: Confirm interest on mailing list for adopting > draft-bertz-dime-predictunits. >=20 > ACTION: Confirm interest on mailing list for adopting > draft-bertz-dime-policygroups. >=20 > ACTION: Ben to look more closely at draft-bertz-dime-policygroups as a > candidate for AD sponsorship. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Jul 27 07:14:59 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BEF131C96; Thu, 27 Jul 2017 07:14:58 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 MVums7YYiV0J; Thu, 27 Jul 2017 07:14:56 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C8D8131C84; Thu, 27 Jul 2017 07:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36312; q=dns/txt; s=iport; t=1501164895; x=1502374495; h=subject:from:to:cc:references:message-id:date: mime-version:in-reply-to; bh=X/A1DqJJGM7RTxIlRGnx29/KykgzCKCEUP5eMOIqbDI=; b=a3wdTjOEGN8cbJ8Tas4qRYw5Ben/FrNbfDOMbR6hAWFcIWugV5s5OC8z pKXBOgzqvWpbtVx2EA07GOYs4Fa9HZ/6Dw8+3cg9Zch6170kDpgCRqp1w +SEPi7cdHJBweOpmQU+7GY4QNfb/M0ocsDbQIaxbS3KUA75HVSu6Ahwae c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoAADU9HlZ/xbLJq1CGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJvPoERbSeODXOQbogwjVoOggEDIQEKhRsChCEYAQIBAQEBAQE?= =?us-ascii?q?BayiFGAEBAQEDAQElBkELEAsRAwECIQEGByEGHwkIBgEMBgIBAYoTAxUQMrEyO?= =?us-ascii?q?ieHCw2EAQEBAQEBAQEBAQEBAQEBAQEBAQEBAR2DKINNgWErgW2BDIE8gRtPgQg?= =?us-ascii?q?SARIBPwwKhR8fAQSJYxOGcIFihRSHTjyPNIRxggyFUoNVhwmJU4JIcoQnhD4fO?= =?us-ascii?q?BZpCzIhCBwVHyqFFgwQgWk+NgEUhzqCMQEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,419,1496102400"; d="scan'208,217";a="656379053" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jul 2017 14:14:50 +0000 Received: from [10.55.221.37] (ams-bclaise-nitro4.cisco.com [10.55.221.37]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v6REEoIc014497; Thu, 27 Jul 2017 14:14:50 GMT From: Benoit Claise To: lionel.morand@orange.com, "aaa-doctors@ietf.org" , "sec-ads@ietf.org" Cc: "dime@ietf.org" , "holger+ietf@freyther.de" References: <20160913214213.4DBFAB80B89@rfc-editor.org> <372e075c-1564-b36a-1eb3-e62c8717535f@cisco.com> <2069_1483442208_586B8820_2069_7324_1_6B7134B31289DC4FAF731D844122B36E0BFC5E94@OPEXCLILM43.corporate.adroot.infra.ftgroup> <17526_1483443934_586B8EDE_17526_11792_1_6B7134B31289DC4FAF731D844122B36E0BFC600A@OPEXCLILM43.corporate.adroot.infra.ftgroup> <1c695767-703d-bd22-73e0-b66a0ae92941@cisco.com> Message-ID: <00d0fbfb-c609-eef8-df5e-c75009aa52e2@cisco.com> Date: Thu, 27 Jul 2017 16:14:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1c695767-703d-bd22-73e0-b66a0ae92941@cisco.com> Content-Type: multipart/alternative; boundary="------------21F6C032CFCF5FD38FA6FDF2" Content-Language: en-US Archived-At: Subject: Re: [Dime] [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC6733 (4803) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 14:14:58 -0000 This is a multi-part message in MIME format. --------------21F6C032CFCF5FD38FA6FDF2 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Ok, in the end, I made the changes myself and approved it. Regards, B. > Holger, > > Can you please update the errata with the information below. > > Regards, Benoit >> >> This errata report is correct on the inconsistency regarding the >> definition of the command header and AVP header and how they are used >> in the rest of the document in the ABNF description of commands and >> Grouped AVPs. >> >> For commands, the header is defined as follow: >> >> header = "> >> [r-bit] [p-bit] [e-bit] [application-id]">" >> >> whereas "> >> Same for Grouped AVP. It is defined as follow: >> >> header = "<" "AVP-Header:" avpcode [vendor] ">" >> >> whereas "> >> Considering that most (if not all) the ABNF descriptions have been >> copied from the commands and Grouped AVPs defined in the RFC3588 or >> RFC6733, I would be in favor to correct the specification by >> modifying the definition of the headers, i.e. >> >> --> In section 3.2. Command Code Format Specification >> >> OLD: >> >> header = "> >> [r-bit] [p-bit] [e-bit] [application-id]">" >> >> NEW: >> >> header = "> >> [r-bit] [p-bit] [e-bit] [application-id]">" >> >> --> And in section 4.4 >> >> OLD: >> >> header = "<" "AVP-Header:" avpcode [vendor] ">" >> >> NEW: >> >> header = "<" "AVP Header:" avpcode [vendor] ">" >> >> ******************* >> >> There are other issues pointed out in this report. >> >> For command-def = "<" command-name ">" "::=" diameter-message, I >> would propose to simply correct the example as all the command >> definitions given in the document are following the command-def >> definition. >> >> For the grouped-avp-def, I don't know what would be the best >> approach. We could follow the same approach and require the addition >> of "<>" but I don't know what would be the impacts on existing >> Grouped AVPs defined without. >> >> Regards, >> >> Lionel. >> >> >> -------- Forwarded Message -------- >> >> *Subject: * >> >> >> >> [Editorial Errata Reported] RFC6733 (4803) >> >> *Date: * >> >> >> >> Tue, 13 Sep 2016 14:42:13 -0700 >> >> *From: * >> >> >> >> RFC Errata System >> >> >> *To: * >> >> >> >> vf0213@gmail.com , jari.arkko@ericsson.com >> , john.loughney@nokia.com >> , glenzorn@gmail.com >> , bclaise@cisco.com >> , joelja@bogus.com >> , jouni.nospam@gmail.com >> , lionel.morand@orange.com >> >> >> *CC: * >> >> >> >> holger+ietf@freyther.de , >> dime@ietf.org , rfc-editor@rfc-editor.org >> >> >> The following errata report has been submitted for RFC6733, >> "Diameter Base Protocol". >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4803 >> -------------------------------------- >> Type: Editorial >> Reported by: Holger Freyther >> Section: 3.2 >> Original Text >> ------------- >> Example-Request ::= < Diameter Header: 9999999, REQ, PXY > >> { User-Name } >> 1* { Origin-Host } >> * [ AVP ] >> Corrected Text >> -------------- >> ::= < Diameter-Header: 9999999, REQ, PXY > >> { User-Name } >> 1* { Origin-Host } >> * [ AVP ] >> Notes >> ----- >> I converted the BNF into a PetitParser parser in Smalltalk/Pharo and noticed that example and grammar do not match. The first issue is with the example following the grammar but most definitions do not follow the BNF so maybe it is best to update the BNF. >> header = "> [r-bit] [p-bit] [e-bit] [application-id]">" >> But "Diameter-Header:" is not used throughout the text so maybe it is better to update the grammar to "Diameter Header:". >> command-def = "<" command-name ">" "::=" diameter-message >> but the example is not using <> for the command-name ("Example-Request"). For the grouped-avp-def application is sometimes used with "<" name ">" and sometimes just name. >> 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 (IESG) >> can log in to change the status and edit the report, if necessary. >> -------------------------------------- >> RFC6733 (draft-ietf-dime-rfc3588bis-33) >> -------------------------------------- >> Title : Diameter Base Protocol >> Publication Date : October 2012 >> Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. >> Category : PROPOSED STANDARD >> Source : Diameter Maintenance and Extensions >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG >> . >> _________________________________________________________________________________________________________________________ >> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >> This message and its attachments may contain confidential or privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >> Thank you. >> _________________________________________________________________________________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >> Thank you. > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------21F6C032CFCF5FD38FA6FDF2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Ok, in the end, I made the changes myself and approved it.

Regards, B.
Holger,

Can you please update the errata with the information below.

Regards, Benoit

This errata report is correct on the inconsistency regarding the definition of the command header and AVP header and how they are used in the rest of the document in the ABNF description of commands and Grouped AVPs.

 

For commands, the header is defined as follow:

 

   header           = "<Diameter-Header:" command-id

                         [r-bit] [p-bit] [e-bit] [application-id]">"

 

whereas "<Diameter Header:" is used when defining commands.

 

Same for Grouped AVP. It is defined as follow:

 

         header           = "<" "AVP-Header:" avpcode [vendor] ">"

 

whereas "<AVP Header:" is used when defining Grouped AVPs.

 

Considering that most (if not all) the ABNF descriptions have been copied from the commands and Grouped AVPs defined in the RFC3588 or RFC6733, I would be in favor to correct the specification by modifying the definition of the headers, i.e.

 

--> In section 3.2.  Command Code Format Specification

 

OLD:

 

   header           = "<Diameter-Header:" command-id

                         [r-bit] [p-bit] [e-bit] [application-id]">"

 

NEW:

 

   header           = "<Diameter Header:" command-id

                         [r-bit] [p-bit] [e-bit] [application-id]">"

 

 

--> And in section 4.4

 

OLD:

 

         header           = "<" "AVP-Header:" avpcode [vendor] ">"

 

NEW:

 

         header           = "<" "AVP Header:" avpcode [vendor] ">"

 

*******************

There are other issues pointed out in this report.

 

For command-def  = "<" command-name ">" "::=" diameter-message, I would propose to simply correct the example as all the command definitions given in the document are following the command-def definition.

For the grouped-avp-def, I don't know what would be the best approach. We could follow the same approach and require the addition of "<>" but I don't know what would be the impacts on existing Grouped AVPs defined without.

 

Regards,

 

Lionel.

 


-------- Forwarded Message --------

Subject:

[Editorial Errata Reported] RFC6733 (4803)

Date:

Tue, 13 Sep 2016 14:42:13 -0700

From:

RFC Errata System <rfc-editor@rfc-editor.org>

To:

vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com, jouni.nospam@gmail.com, lionel.morand@orange.com

CC:

holger+ietf@freyther.de, dime@ietf.org, rfc-editor@rfc-editor.org

 

The following errata report has been submitted for RFC6733,
"Diameter Base Protocol".
 
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4803
 
--------------------------------------
Type: Editorial
Reported by: Holger Freyther <holger+ietf@freyther.de>
 
Section: 3.2
 
Original Text
-------------
   Example-Request ::= < Diameter Header: 9999999, REQ, PXY >
                       { User-Name }
                    1* { Origin-Host }
                     * [ AVP ]
 
 
 
Corrected Text
--------------
   <Example-Request> ::= < Diameter-Header: 9999999, REQ, PXY >
                       { User-Name }
                    1* { Origin-Host }
                     * [ AVP ]
 
 
 
Notes
-----
I converted the BNF into a PetitParser parser in Smalltalk/Pharo and noticed that example and grammar do not match. The first issue is with the example following the grammar but most definitions do not follow the BNF so maybe it is best to update the BNF. 
 
  header           = "<Diameter-Header:" command-id
                         [r-bit] [p-bit] [e-bit] [application-id]">"
 
But "Diameter-Header:" is not used throughout the text so maybe it is better to update the grammar to "Diameter Header:".
 
 
 command-def      = "<" command-name ">" "::=" diameter-message
 
but the example is not using <> for the command-name ("Example-Request"). For the grouped-avp-def application is sometimes used with "<" name ">" and sometimes just name.
 
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 (IESG)
can log in to change the status and edit the report, if necessary. 
 
--------------------------------------
RFC6733 (draft-ietf-dime-rfc3588bis-33)
--------------------------------------
Title               : Diameter Base Protocol
Publication Date    : October 2012
Author(s)           : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed.
Category            : PROPOSED STANDARD
Source              : Diameter Maintenance and Extensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG
 
.
 
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.




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

--------------21F6C032CFCF5FD38FA6FDF2-- From nobody Thu Jul 27 07:15:58 2017 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B145D132038; Thu, 27 Jul 2017 07:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 ndQOPqIKtvMy; Thu, 27 Jul 2017 07:15:51 -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 E9883131C96; Thu, 27 Jul 2017 07:15:51 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1077AB810BD; Thu, 27 Jul 2017 07:15:41 -0700 (PDT) To: holger+ietf@freyther.de, vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: bclaise@cisco.com, iesg@ietf.org, dime@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170727141541.1077AB810BD@rfc-editor.org> Date: Thu, 27 Jul 2017 07:15:41 -0700 (PDT) Archived-At: Subject: [Dime] [Errata Verified] RFC6733 (4803) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 14:15:54 -0000 The following errata report has been verified for RFC6733, "Diameter Base Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid4803 -------------------------------------- Status: Verified Type: Editorial Reported by: Holger Freyther Date Reported: 2016-09-13 Verified by: Benoit Claise (IESG) Section: 3.2 Original Text ------------- In section 3.2 header = "" In section 3.4 header = "<" "AVP-Header:" avpcode [vendor] ">" Corrected Text -------------- In section 3.2 header = "" In section 3.4 header = "<" "AVP Header:" avpcode [vendor] ">" Notes ----- Background: There was an initial errata (kept for background information at the bottom of this note). After some discussion with the dime WG, this errata was modified. This errata report is correct on the inconsistency regarding the definition of the command header and AVP header and how they are used in the rest of the document in the ABNF description of commands and Grouped AVPs. For commands, the header is defined as follow: header = "" whereas "" whereas " In section 3.2. Command Code Format Specification OLD: header = "" NEW: header = "" --> And in section 4.4 OLD: header = "<" "AVP-Header:" avpcode [vendor] ">" NEW: header = "<" "AVP Header:" avpcode [vendor] ">" ============================================================================= This initial errata is below: Original text: Example-Request ::= < Diameter Header: 9999999, REQ, PXY > { User-Name } 1* { Origin-Host } * [ AVP ] Corrected text: ::= < Diameter-Header: 9999999, REQ, PXY > { User-Name } 1* { Origin-Host } * [ AVP ] I converted the BNF into a PetitParser parser in Smalltalk/Pharo and noticed that example and grammar do not match. The first issue is with the example following the grammar but most definitions do not follow the BNF so maybe it is best to update the BNF. header = "" But "Diameter-Header:" is not used throughout the text so maybe it is better to update the grammar to "Diameter Header:". command-def = "<" command-name ">" "::=" diameter-message but the example is not using <> for the command-name ("Example-Request"). For the grouped-avp-def application is sometimes used with "<" name ">" and sometimes just name. -------------------------------------- RFC6733 (draft-ietf-dime-rfc3588bis-33) -------------------------------------- Title : Diameter Base Protocol Publication Date : October 2012 Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. Category : PROPOSED STANDARD Source : Diameter Maintenance and Extensions Area : Operations and Management Stream : IETF Verifying Party : IESG