From dlehmann@ulticom.com Wed Sep 1 05:55:27 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12B3E3A6A2F for ; Wed, 1 Sep 2010 05:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuKn3c99DPjv for ; Wed, 1 Sep 2010 05:55:11 -0700 (PDT) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id D356F3A693D for ; Wed, 1 Sep 2010 05:55:06 -0700 (PDT) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id 91A6B15EC9D3191F; Wed, 1 Sep 2010 08:55:35 -0400 (EDT) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id o81CtI30020900; Wed, 1 Sep 2010 08:55:30 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB49D4.EDD57DB2" Date: Wed, 1 Sep 2010 08:55:18 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RFC 3588 - fixed positioned session-ID AVPs Thread-Index: ActJSqLR1l2whWnNTGaCYMPp20UYIAAh5iow References: <009f01cb4913$e76b5b50$b64211f0$@net> From: "David Lehmann" To: "Victor Fajardo" Received-SPF: none Cc: dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 01 Sep 2010 12:55:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB49D4.EDD57DB2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OK, BNF rules. IMHO, this should be noted or clarified in section 8.8. e.g. "When present, the Session-Id SHOULD appear immediately following the Diameter Header. Further, the message BNF may mandate that the Session-Id MUST be positioned immediately following the message header. Indeed, all messages defined in this RFC require such a positioning. (see Section 3)" =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Victor Fajardo [mailto:vf0213@gmail.com]=20 Sent: Tuesday, August 31, 2010 4:25 PM To: David Lehmann Cc: Glen Zorn; dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs =20 yes. the BNF sets the positioning/sequencing rules. it's a common practice in BNFs to place session-id near the head to optimize msg processing .. etc. On Tue, Aug 31, 2010 at 3:22 PM, David Lehmann wrote: So you are stating that the Diameter protocol itself does NOT require all session-ID AVPs to follow immediately after the message header, but a message's BNF may require it? =20 =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Victor Fajardo [mailto:vf0213@gmail.com]=20 Sent: Tuesday, August 31, 2010 2:21 PM=20 To: David Lehmann Cc: Glen Zorn; dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs =20 =20 On Tue, Aug 31, 2010 at 1:54 PM, David Lehmann wrote: The existing text in 8.8 is contradicting the BNF. =20 =20 =20 Which BNF though ? There maybe apps beyond 3588 that may not necessarily put the session-id after the header in their BNF's. In that regard, the existing text is not contradictory but is meant to be generalized specially because it describes an AVP and is agnostic to any BNF. =20 my two cents, victor =20 =20 I am suggesting text that agrees and supports the BNF. =20 =20 If you don't want to modify the text to agree with the BNF, then I suggest removing the existing text which contradicts it. =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Victor Fajardo [mailto:vf0213@gmail.com]=20 Sent: Tuesday, August 31, 2010 11:52 AM To: David Lehmann Cc: Glen Zorn; dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs =20 Hi David, On Tue, Aug 31, 2010 at 10:37 AM, David Lehmann wrote: Glen, =20 That is not what the spec says. At least, the wording is not clear and, IMHO, is misleading. In which "some message" can the session-id AVP be in any position? =20 It seems to me that the wording in section 8.8 should be: "When present, the Session-Id MUST appear immediately following the Diameter Header (see Section 3)." =20 As Glen has mentioned, the BNF dictates the positioning of the AVP. If you add this text you are adding new rules beyond the BNF. =20 regards, victor =20 =20 =20 =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Glen Zorn [mailto:gwz@net-zen.net]=20 Sent: Tuesday, August 31, 2010 9:54 AM To: David Lehmann Cc: dime@ietf.org Subject: RE: [Dime] RFC 3588 - fixed positioned session-ID AVPs =20 David Lehmann [mailto://dlehmann@ulticom.com] writes: =09 =09 =09 =09 =20 =09 =09 =09 =09 =09 =20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 Hello, Hello. In RFC 3588 (and 3588bis), messages with session IDs are defined with the session ID AVPs with a fixed position which is immediately following the header. (e.g. section 8.3.1) =20 Yes. However, this is in contradiction with section 8.8 which states, "When present, the Session-Id SHOULD appear immediately following the Diameter Header (see Section 3)." No. By using "SHOULD", the spec is stating that the session-ID AVP could be in any position in the message. No, it is stating that the AVP could be in any position in some message. The syntax of the existing messages in RFC 3588 is defined by the associated BNF and in those messages the Session-Id AVP must immediately follow the Diameter header. =20 =20 Hope this helps. =20 ~gwz =09 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime =20 =20 =20 ------_=_NextPart_001_01CB49D4.EDD57DB2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

OK, BNF rules.    IMHO, this should be = noted or clarified in section 8.8. e.g.

“When present, the Session-Id SHOULD appear immediately following the Diameter Header. = Further, the message BNF may mandate that the Session-Id MUST be positioned = immediately following the message header.  Indeed, all messages defined in this = RFC require such a positioning. (see Section 3)”

 

--

David Lehmann

Ulticom, Inc.

856-787-2952

 

From:= Victor = Fajardo [mailto:vf0213@gmail.com]
Sent: Tuesday, August 31, 2010 4:25 PM
To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID = AVPs

 

yes. the BNF sets = the positioning/sequencing rules. it's a common practice in BNFs = to place session-id near the head to optimize msg processing .. = etc.

On Tue, Aug 31, 2010 at 3:22 PM, David Lehmann = <dlehmann@ulticom.com> = wrote:

So you are stating that the = Diameter protocol itself does NOT require all session-ID AVPs to follow = immediately after the message header, but a message’s BNF may require = it? 

 

--

David = Lehmann

Ulticom, = Inc.

856-787-2952

 

From: Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Tuesday, August 31, 2010 2:21 PM


To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID = AVPs

 <= /o:p>

 <= /p>

On Tue, Aug 31, 2010 at 1:54 PM, David Lehmann <dlehmann@ulticom.com> wrote:

The existing text in 8.8 is contradicting the BNF. 

 <= /o:p>

 <= /o:p>

Which BNF though ? There maybe apps beyond 3588 that may not necessarily put = the session-id after the header in their BNF's. In that regard, the existing text is = not contradictory but is meant to be generalized specially because it = describes an AVP and is agnostic to any BNF.

 <= /o:p>

my two cents,

victor<= /o:p>

 <= /o:p>

 <= /o:p>

=

I am suggesting text that = agrees and supports the BNF. 

 

If you don’t want to = modify the text to agree with the BNF, then I suggest removing the existing text = which contradicts it.

 

--

David = Lehmann

Ulticom, = Inc.

856-787-2952

 

From: Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Tuesday, August 31, 2010 11:52 AM
To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID = AVPs

 <= /o:p>

Hi David,

On Tue, Aug 31, 2010 at 10:37 AM, David Lehmann <dlehmann@ulticom.com> wrote:

Glen,

 

That is not what the spec says.  At least, = the wording is not clear and, IMHO, is misleading.  In which = “some message” can the session-id AVP be in any = position?

 

It seems to me that the wording in section 8.8 = should be:  “When present, the Session-Id MUST appear immediately following = the Diameter Header (see Section 3).”

 <= /o:p>

As Glen has mentioned, the BNF dictates the positioning of the AVP. If you = add this text you are adding new rules beyond the BNF.

 <= /o:p>

regards,

victor<= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

=

 

--

David = Lehmann

Ulticom, = Inc.

856-787-2952

 

From: Glen Zorn [mailto:gwz@net-zen.net]
Sent: Tuesday, August 31, 2010 9:54 AM
To: David Lehmann
Cc: dime@ietf.org
Subject: RE: [Dime] RFC 3588 - fixed positioned session-ID = AVPs

 <= /o:p>

David Lehmann [mailto://dlehmann@ulticom.com] =
writes:




 





 










 




















Hello,
Hello.
In RFC 3588 =
(and 3588bis), messages with session IDs are defined with the session ID =
AVPs with a fixed position which is immediately following the header. =
(e.g. section 8.3.1)  
Yes.
However, this =
is in contradiction with section 8.8 which states, “When present, =
the Session-Id SHOULD appear immediately following the Diameter Header =
(see Section 3).”
No.
By using =
“SHOULD”, the spec is stating that the session-ID AVP could =
be in any position in the message.

No, it is stating that the AVP = could be in any position in some message.  The syntax of the existing messages in RFC 3588 is defined by the associated BNF and in = those messages the Session-Id AVP must immediately follow the Diameter = header.

 

 

Hope this = helps.

 

 ~gwz

=


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

 <= /o:p>

 <= /o:p>

 

------_=_NextPart_001_01CB49D4.EDD57DB2-- From vf0213@gmail.com Wed Sep 1 06:15:32 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A9693A6A1B for ; Wed, 1 Sep 2010 06:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZLQnIpW3M2L for ; Wed, 1 Sep 2010 06:15:29 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 343F03A6A2F for ; Wed, 1 Sep 2010 06:14:14 -0700 (PDT) Received: by wwb17 with SMTP id 17so1078850wwb.13 for ; Wed, 01 Sep 2010 06:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=3PS952v/WxSR37YdvWLaqR27Qe4mnbAisHEDeeWYBRI=; b=u6JkfZOA2t1BK5IDx2S65ytkQ8UgZiipZUw6eg1MVprM+EJCfD0RsR91X7w5l/FEoZ gbqoaW4Hpv60kNfo/1LD7aWNfeR7L03PaNYsrP/0B4pLVfboiNgHoBs1Ey7EOZKsgqLy KfWMOLc23nsHVNJ3yPwM7QSjkDr6MXOHhqy0E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ovAjvvFjy5IsksI+pvpQIZOpKeCac88iShaQakDk6ESj9SC4kCXTwGOa3O8pjjSHuQ n2EqPYuBPIGrcPX3q+gjlGYQgvmJrpQc1Gm/1obEWVmkmpztD5ZgTv/iznVz8PwAwN56 Kkh4rmAzlzuCTCIIfUYWacNQb53c68s4qeFqA= MIME-Version: 1.0 Received: by 10.216.51.212 with SMTP id b62mr286845wec.97.1283346761941; Wed, 01 Sep 2010 06:12:41 -0700 (PDT) Received: by 10.216.58.130 with HTTP; Wed, 1 Sep 2010 06:12:41 -0700 (PDT) In-Reply-To: References: <009f01cb4913$e76b5b50$b64211f0$@net> Date: Wed, 1 Sep 2010 09:12:41 -0400 Message-ID: From: Victor Fajardo To: David Lehmann Content-Type: multipart/alternative; boundary=0016e6dd8a18de83d7048f327314 Cc: dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 01 Sep 2010 13:15:32 -0000 --0016e6dd8a18de83d7048f327314 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Its good to have some clarity, though the statement below probably needs some re-org since SHOULD is followed with a MUST and theres a conditional 'may' in between. Anyway, the statement maybe redundant since each BNF already tells you where the session-id can be found .. my 2 cents. On Wed, Sep 1, 2010 at 8:55 AM, David Lehmann wrote: > OK, BNF rules. IMHO, this should be noted or clarified in section 8.8= . > e.g. > > =93When present, the Session-Id SHOULD appear immediately following the > Diameter Header. Further, the message BNF may mandate that the Session-Id > MUST be positioned immediately following the message header. Indeed, all > messages defined in this RFC require such a positioning. (see Section 3)= =94 > > > > -- > > *David Lehmann* > > Ulticom, Inc. > > 856-787-2952 > > > > *From:* Victor Fajardo [mailto:vf0213@gmail.com] > *Sent:* Tuesday, August 31, 2010 4:25 PM > > *To:* David Lehmann > *Cc:* Glen Zorn; dime@ietf.org > *Subject:* Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs > > > > yes. the BNF sets the positioning/sequencing rules. it's a common > practice in BNFs to place session-id near the head to optimize msg > processing .. etc. > > On Tue, Aug 31, 2010 at 3:22 PM, David Lehmann > wrote: > > So you are stating that the Diameter protocol itself does NOT require all > session-ID AVPs to follow immediately after the message header, but a > message=92s BNF may require it? > > > > -- > > *David Lehmann* > > Ulticom, Inc. > > 856-787-2952 > > > > *From:* Victor Fajardo [mailto:vf0213@gmail.com] > *Sent:* Tuesday, August 31, 2010 2:21 PM > > > *To:* David Lehmann > *Cc:* Glen Zorn; dime@ietf.org > *Subject:* Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs > > > > > > On Tue, Aug 31, 2010 at 1:54 PM, David Lehmann > wrote: > > The existing text in 8.8 is contradicting the BNF. > > > > > > Which BNF though ? There maybe apps beyond 3588 that may not necessarily > put the session-id after the header in their BNF's. In that regard, the > existing text is not contradictory but is meant to be generalized special= ly > because it describes an AVP and is agnostic to any BNF. > > > > my two cents, > > victor > > > > > > I am suggesting text that agrees and supports the BNF. > > > > If you don=92t want to modify the text to agree with the BNF, then I sugg= est > removing the existing text which contradicts it. > > > > -- > > *David Lehmann* > > Ulticom, Inc. > > 856-787-2952 > > > > *From:* Victor Fajardo [mailto:vf0213@gmail.com] > *Sent:* Tuesday, August 31, 2010 11:52 AM > *To:* David Lehmann > *Cc:* Glen Zorn; dime@ietf.org > *Subject:* Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs > > > > Hi David, > > On Tue, Aug 31, 2010 at 10:37 AM, David Lehmann > wrote: > > Glen, > > > > That is not what the spec says. At least, the wording is not clear and, > IMHO, is misleading. In which =93*some* message=94 can the session-id AV= P be > in any position? > > > > It seems to me that the wording in section 8.8 should be: =93When presen= t, > the Session-Id MUST appear immediately following the Diameter Header (see > Section 3).=94 > > > > As Glen has mentioned, the BNF dictates the positioning of the AVP. If yo= u > add this text you are adding new rules beyond the BNF. > > > > regards, > > victor > > > > > > > > > > -- > > *David Lehmann* > > Ulticom, Inc. > > 856-787-2952 > > > > *From:* Glen Zorn [mailto:gwz@net-zen.net] > *Sent:* Tuesday, August 31, 2010 9:54 AM > *To:* David Lehmann > *Cc:* dime@ietf.org > *Subject:* RE: [Dime] RFC 3588 - fixed positioned session-ID AVPs > > > > David Lehmann [mailto://dlehmann@ulticom.com] <[mailto://dlehmann@ulticom= .com%5d> writes: > > > > > > > > > > > > > > > > > > > > > > Hello, > > Hello. > > In RFC 3588 (and 3588bis), messages with session IDs are defined with the= session ID AVPs with a fixed position which is immediately following the h= eader. (e.g. section 8.3.1) > > Yes. > > However, this is in contradiction with section 8.8 which states, =93When = present, the Session-Id SHOULD appear immediately following the Diameter He= ader (see Section 3).=94 > > No. > > By using =93SHOULD=94, the spec is stating that the session-ID AVP could = be in any position in the message. > > No, it is stating that the AVP could be in any position in *some*message.= The syntax of the existing messages in RFC 3588 is defined by the > associated BNF and in *those* messages the Session-Id AVP *must*immediate= ly follow the Diameter header. > > > > > > Hope this helps. > > > > ~gwz > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > > > > > --0016e6dd8a18de83d7048f327314 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Its good to have some clarity,=A0though the statement below probably n= eeds some re-org since=A0SHOULD is followed with a MUST and theres a condit= ional=A0'may' in between. Anyway, the statement maybe redundant sin= ce=A0each BNF already tells you where the session-id can be found ..
=A0
my 2 cents.

On Wed, Sep 1, 2010 at 8:55 AM, David Lehmann <dlehmann@ultico= m.com> wrote:

OK, = BNF rules.=A0=A0=A0 IMHO, this should be noted or clarified in section 8.8.= e.g.

= =93When present, the Session-Id SHOULD appear immediately following the Dia= meter Header. Further, the message BNF may mandate that the Session-Id MUST= be positioned immediately following the message header.=A0 Indeed, all mes= sages defined in this RFC require such a positioning. (see Section 3)=94

=A0<= /span>

--

D= avid Lehmann

Ulti= com, Inc.

856-= 787-2952

=A0<= /span>

From:<= span style=3D"FONT-SIZE: 10pt"> Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Tu= esday, August 31, 2010 4:25 PM=20


To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Sub= ject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs

=A0

yes. the BNF sets the = positioning/sequencing rules. it's a common practice=A0in=A0BNFs to pla= ce session-id=A0near the head to optimize msg processing .. etc.

On Tue, Aug 31, 2010 at 3:22 PM, David Lehmann <<= a href=3D"mailto:dlehmann@ulticom.com" target=3D"_blank">dlehmann@ulticom.c= om> wrote:

So y= ou are stating that the Diameter protocol itself does NOT require all sessi= on-ID AVPs to follow immediately after the message header, but a message=92= s BNF may require it?=A0

=A0<= /span>

--

D= avid Lehmann

Ulti= com, Inc.

856-= 787-2952

=A0<= /span>

From:<= span style=3D"FONT-SIZE: 10pt"> Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Tu= esday, August 31, 2010 2:21 PM


To: David= Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] RFC 3588 - fixe= d positioned session-ID AVPs

=A0

=A0

On Tue, Aug 31, 2010 at 1:54 PM, David Lehmann <<= a href=3D"mailto:dlehmann@ulticom.com" target=3D"_blank">dlehmann@ulticom.c= om> wrote:

The = existing text in 8.8 is contradicting the BNF.=A0

=A0

=A0

Which BNF though ? There maybe apps beyond 3588 that= may not necessarily put the session-id after the header in their BNF's= . In that regard, the existing text is not contradictory but is meant to be= generalized specially because it describes an AVP and is agnostic to any B= NF.

=A0

my two cents,

victor

=A0

=A0

I am= suggesting text that agrees and supports the BNF.=A0

=A0<= /span>

If y= ou don=92t want to modify the text to agree with the BNF, then I suggest re= moving the existing text which contradicts it.

=A0<= /span>

--

D= avid Lehmann

Ulti= com, Inc.

856-= 787-2952

=A0<= /span>

From:<= span style=3D"FONT-SIZE: 10pt"> Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Tu= esday, August 31, 2010 11:52 AM
To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] R= FC 3588 - fixed positioned session-ID AVPs

=A0

Hi David,

On Tue, Aug 31, 2010 at 10:37 AM, David Lehmann <= dlehmann@ulticom.= com> wrote:

Glen,

=A0

That is not what the = spec says.=A0 At least, the wording is not clear and, IMHO, is misleading.= =A0 In which =93some message=94 can the session-id AVP be in any pos= ition?

=A0

It seems to me that t= he wording in section 8.8 should be:=A0 =93When present, the Session= -Id MUST appear immediately following the Diameter Header (see Section 3).= =94

=A0

As Glen has mentioned, the BNF dictates the position= ing of the AVP. If you add this text you are adding new rules beyond the BN= F.

=A0

regards,

victor

=A0

=A0

=A0

=A0

--

D= avid Lehmann

Ulti= com, Inc.

856-= 787-2952

=A0

From:<= span style=3D"FONT-SIZE: 10pt"> Glen Zorn [mailto:gwz@net-zen.net]
Sent: Tuesday, = August 31, 2010 9:54 AM
To: David Lehmann
Cc: dime@ietf.org
Subject: RE: [Dime] RFC 3588 - f= ixed positioned session-ID AVPs

=A0

David Lehmann [mailto://dlehmann@u=
lticom.com] writes:





=A0





=A0










=A0




















Hello,
Hello.
In RFC 3588 (and 3588bis), messages with session IDs are def=
ined with the session ID AVPs with a fixed position which is immediately fo=
llowing the header. (e.g. section 8.3.1)=A0 
Yes.
However, this is =
in contradiction with section 8.8 which states, =93When present, the Sessio=
n-Id SHOULD appear immediately following the Diameter Header (see Section 3=
).=94
No.
By using =93SHOULD=
=94, the spec is stating that the session-ID AVP could be in any position i=
n the message.

No, = it is stating that the AVP could be in any position in some message.= =A0 The syntax of the existing messages in RFC 3588 is defined by the assoc= iated BNF and in those messages the Session-Id AVP must immed= iately follow the Diameter header.

=A0

=A0<= /span>

Hope= this helps.

=A0<= /span>

=A0~= gwz


__________________= _____________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailm= an/listinfo/dime

=A0

=A0

=A0


--0016e6dd8a18de83d7048f327314-- From tena@huawei.com Wed Sep 1 06:28:29 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 957853A6868 for ; Wed, 1 Sep 2010 06:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.283 X-Spam-Level: X-Spam-Status: No, score=-100.283 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fn1ieyUdT0LE for ; Wed, 1 Sep 2010 06:28:22 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 671413A67E4 for ; Wed, 1 Sep 2010 06:28:21 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L82000TILFTNN@szxga05-in.huawei.com> for dime@ietf.org; Wed, 01 Sep 2010 21:28:41 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L8200MWYLFSUS@szxga05-in.huawei.com> for dime@ietf.org; Wed, 01 Sep 2010 21:28:41 +0800 (CST) Received: from [192.168.5.100] ([113.116.39.145]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L8200D0QLFRXJ@szxml01-in.huawei.com>; Wed, 01 Sep 2010 21:28:40 +0800 (CST) Date: Wed, 01 Sep 2010 21:28:38 +0800 From: Tina TSOU In-reply-to: To: Victor Fajardo Message-id: <0B007EBD-29E0-422D-BE99-7217A98231D6@huawei.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.936) Content-type: multipart/alternative; boundary="Boundary_(ID_RJhKHZiyNnEqXtt8anImVw)" References: <009f01cb4913$e76b5b50$b64211f0$@net> Cc: dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 01 Sep 2010 13:28:29 -0000 --Boundary_(ID_RJhKHZiyNnEqXtt8anImVw) Content-type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-transfer-encoding: quoted-printable Fully agree with Victor for the previous email. B. R. Tina http://tinatsou.weebly.com/index.html On Sep 1, 2010, at 9:12 PM, Victor Fajardo wrote: > Its good to have some clarity, though the statement below probably =20 > needs some re-org since SHOULD is followed with a MUST and theres a =20= > conditional 'may' in between. Anyway, the statement maybe redundant =20= > since each BNF already tells you where the session-id can be found .. > > my 2 cents. > > On Wed, Sep 1, 2010 at 8:55 AM, David Lehmann =20= > wrote: > OK, BNF rules. IMHO, this should be noted or clarified in section =20= > 8.8. e.g. > > =93When present, the Session-Id SHOULD appear immediately following =20= > the Diameter Header. Further, the message BNF may mandate that the =20 > Session-Id MUST be positioned immediately following the message =20 > header. Indeed, all messages defined in this RFC require such a =20 > positioning. (see Section 3)=94 > > > -- > > David Lehmann > > Ulticom, Inc. > > 856-787-2952 > > > From: Victor Fajardo [mailto:vf0213@gmail.com] > Sent: Tuesday, August 31, 2010 4:25 PM > > > To: David Lehmann > Cc: Glen Zorn; dime@ietf.org > Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs > > > > yes. the BNF sets the positioning/sequencing rules. it's a common =20 > practice in BNFs to place session-id near the head to optimize msg =20 > processing .. etc. > > On Tue, Aug 31, 2010 at 3:22 PM, David Lehmann =20 > wrote: > > So you are stating that the Diameter protocol itself does NOT =20 > require all session-ID AVPs to follow immediately after the message =20= > header, but a message=92s BNF may require it? > > > -- > > David Lehmann > > Ulticom, Inc. > > 856-787-2952 > > > From: Victor Fajardo [mailto:vf0213@gmail.com] > Sent: Tuesday, August 31, 2010 2:21 PM > > > To: David Lehmann > Cc: Glen Zorn; dime@ietf.org > Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs > > > > On Tue, Aug 31, 2010 at 1:54 PM, David Lehmann =20 > wrote: > > The existing text in 8.8 is contradicting the BNF. > > > > Which BNF though ? There maybe apps beyond 3588 that may not =20 > necessarily put the session-id after the header in their BNF's. In =20 > that regard, the existing text is not contradictory but is meant to =20= > be generalized specially because it describes an AVP and is agnostic =20= > to any BNF. > > > my two cents, > > victor > > > > I am suggesting text that agrees and supports the BNF. > > > If you don=92t want to modify the text to agree with the BNF, then I =20= > suggest removing the existing text which contradicts it. > > > -- > > David Lehmann > > Ulticom, Inc. > > 856-787-2952 > > > From: Victor Fajardo [mailto:vf0213@gmail.com] > Sent: Tuesday, August 31, 2010 11:52 AM > To: David Lehmann > Cc: Glen Zorn; dime@ietf.org > Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs > > > Hi David, > > On Tue, Aug 31, 2010 at 10:37 AM, David Lehmann =20 > wrote: > > Glen, > > > That is not what the spec says. At least, the wording is not clear =20= > and, IMHO, is misleading. In which =93some message=94 can the = session-=20 > id AVP be in any position? > > > It seems to me that the wording in section 8.8 should be: =93When =20 > present, the Session-Id MUST appear immediately following the =20 > Diameter Header (see Section 3).=94 > > > As Glen has mentioned, the BNF dictates the positioning of the AVP. =20= > If you add this text you are adding new rules beyond the BNF. > > > regards, > > victor > > > > > > -- > > David Lehmann > > Ulticom, Inc. > > 856-787-2952 > > > From: Glen Zorn [mailto:gwz@net-zen.net] > Sent: Tuesday, August 31, 2010 9:54 AM > To: David Lehmann > Cc: dime@ietf.org > Subject: RE: [Dime] RFC 3588 - fixed positioned session-ID AVPs > > > David Lehmann [mailto://dlehmann@ulticom.com] writes: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello, > Hello. > In RFC 3588 (and 3588bis), messages with session IDs are defined =20 > with the session ID AVPs with a fixed position which is immediately =20= > following the header. (e.g. section 8.3.1) > Yes. > However, this is in contradiction with section 8.8 which states, =20 > =93When present, the Session-Id SHOULD appear immediately following =20= > the Diameter Header (see Section 3).=94 > No. > By using =93SHOULD=94, the spec is stating that the session-ID AVP = could =20 > be in any position in the message. > No, it is stating that the AVP could be in any position in some =20 > message. The syntax of the existing messages in RFC 3588 is defined =20= > by the associated BNF and in those messages the Session-Id AVP must =20= > immediately follow the Diameter header. > > > > Hope this helps. > > > ~gwz > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --Boundary_(ID_RJhKHZiyNnEqXtt8anImVw) Content-type: text/html; charset=WINDOWS-1252 Content-transfer-encoding: quoted-printable Fully agree with Victor for the = previous email.

<= div>
B. = R.
http://tinatsou.weebly.com/= index.html
<= /div>
=
On Sep 1, 2010, at 9:12 PM, Victor Fajardo = wrote:

Its good to have some clarity, though the = statement below probably needs some re-org since SHOULD is followed = with a MUST and theres a conditional 'may' in between. Anyway, the = statement maybe redundant since each BNF already tells you where = the session-id can be found ..
 
my 2 = cents.

On Wed, Sep 1, 2010 at = 8:55 AM, David Lehmann <dlehmann@ulticom.com> = wrote:

OK, = BNF rules.    IMHO, this should be noted or clarified in = section 8.8. e.g.

=93When present, the Session-Id = SHOULD appear immediately following the Diameter Header. Further, the = message BNF may mandate that the Session-Id MUST be positioned = immediately following the message header.  Indeed, all messages = defined in this RFC require such a positioning. (see Section = 3)=94

 

--

David Lehmann

Ulticom, Inc.

856-787-2952

 

From: Victor Fajardo = [mailto:vf0213@gmail.com]
Sent: Tuesday, August = 31, 2010 4:25 PM


To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] RFC = 3588 - fixed positioned session-ID AVPs


=
 
=

yes. the BNF = sets the positioning/sequencing rules. it's a common = practice in BNFs to place session-id near the head to = optimize msg processing .. etc.

On = Tue, Aug 31, 2010 at 3:22 PM, David Lehmann <dlehmann@ulticom.com> wrote:

So = you are stating that the Diameter protocol itself does NOT require all = session-ID AVPs to follow immediately after the message header, but a = message=92s BNF may require it? 

 

--

David Lehmann

Ulticom, Inc.

856-787-2952

 

From: Victor Fajardo = [mailto:vf0213@gmail.com]
Sent: Tuesday, August = 31, 2010 2:21 PM


To: David Lehmann
Cc: = Glen Zorn; dime@ietf.org
Subject: Re: [Dime] RFC = 3588 - fixed positioned session-ID AVPs

=
 
 

On Tue, Aug 31, 2010 at 1:54 PM, David Lehmann = <dlehmann@ulticom.com> wrote:

The = existing text in 8.8 is contradicting the BNF.  =

 
 

Which BNF though ? There maybe apps beyond 3588 that = may not necessarily put the session-id after the header in their BNF's. = In that regard, the existing text is not contradictory but is meant to = be generalized specially because it describes an AVP and is agnostic to = any BNF.

 

my two cents,

victor

 
 

I am suggesting text that agrees and supports = the BNF. 

 

If = you don=92t want to modify the text to agree with the BNF, then I = suggest removing the existing text which contradicts it.

=
 

--

David Lehmann

Ulticom, Inc.

856-787-2952

 

From: Victor Fajardo = [mailto:vf0213@gmail.com]
Sent: Tuesday, August = 31, 2010 11:52 AM
To: David Lehmann
Cc: Glen Zorn; = dime@ietf.org
Subject: Re: [Dime] RFC = 3588 - fixed positioned session-ID AVPs

=
 

Hi David,

On Tue, Aug 31, 2010 at 10:37 AM, David Lehmann = <dlehmann@ulticom.com> wrote:

Glen,

 

That is not what the = spec says.  At least, the wording is not clear and, IMHO, is = misleading.  In which =93some message=94 can the session-id = AVP be in any position?

 

It seems to me that = the wording in section 8.8 should be:  =93When present, the = Session-Id MUST appear immediately following the Diameter Header (see = Section 3).=94

 

As Glen has mentioned, the BNF dictates the = positioning of the AVP. If you add this text you are adding new rules = beyond the BNF.

 

regards,

victor

 
 
 
 
=

--

David Lehmann

Ulticom, Inc.

856-787-2952

 

From: Glen Zorn = [mailto:gwz@net-zen.net]
Sent: Tuesday, August = 31, 2010 9:54 AM
To: David Lehmann
Cc: dime@ietf.org
Subject: RE: [Dime] RFC = 3588 - fixed positioned session-ID AVPs

=
 
David Lehmann [mailto://dlehmann@ulticom.com] =
writes:





 





 










 




















Hello,
Hello.
In RFC 3588 (and 3588bis), messages =
with session IDs are defined with the session ID AVPs with a fixed =
position which is immediately following the header. (e.g. section =
8.3.1)  
Yes.
However, this is in contradiction with =
section 8.8 which states, =93When present, the Session-Id SHOULD appear =
immediately following the Diameter Header (see Section 3).=94
= 
No.
By using =
=93SHOULD=94, the spec is stating that the session-ID AVP could be in =
any position in the message.

No, it is stating that the AVP = could be in any position in some message.  The syntax of the = existing messages in RFC 3588 is defined by the associated BNF and in = those messages the Session-Id AVP must immediately follow = the Diameter header.

 
 

Hope = this helps.

 

 ~gwz


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

=
 
 
 

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

= --Boundary_(ID_RJhKHZiyNnEqXtt8anImVw)-- From dlehmann@ulticom.com Wed Sep 1 06:29:14 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B7A13A6A37 for ; Wed, 1 Sep 2010 06:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqZfX4Dfp3j8 for ; Wed, 1 Sep 2010 06:29:01 -0700 (PDT) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id 0F9FF3A6A32 for ; Wed, 1 Sep 2010 06:28:52 -0700 (PDT) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id 3ADF837D49E1E208; Wed, 1 Sep 2010 09:29:22 -0400 (EDT) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id o81DSheW022449; Wed, 1 Sep 2010 09:29:13 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB49D9.98B7ACCA" Date: Wed, 1 Sep 2010 09:28:42 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RFC 3588 - fixed positioned session-ID AVPs Thread-Index: ActJ16YzHGwaHp3KS4i3F5TYV0NoAwAAF/yQ References: <009f01cb4913$e76b5b50$b64211f0$@net> From: "David Lehmann" To: "Victor Fajardo" Received-SPF: none Cc: dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 01 Sep 2010 13:29:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB49D9.98B7ACCA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reword as necessary. =20 The reason that a "SHOULD" is followed by a "MUST" is because that seems to be how diameter is defined, according to the previous posts. =20 The diameter protocol says "SHOULD" as far as positioning, but the BNF may override the "SHOULD" with a "MUST". It seems you are agreeing that it is confusing. ;-) This is why clarification is needed. =20 I think the wording that I provided is dead on, but as I stated, reword as necessary. =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Victor Fajardo [mailto:vf0213@gmail.com]=20 Sent: Wednesday, September 01, 2010 9:13 AM To: David Lehmann Cc: Glen Zorn; dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs =20 Its good to have some clarity, though the statement below probably needs some re-org since SHOULD is followed with a MUST and theres a conditional 'may' in between. Anyway, the statement maybe redundant since each BNF already tells you where the session-id can be found .. =20 my 2 cents. On Wed, Sep 1, 2010 at 8:55 AM, David Lehmann wrote: OK, BNF rules. IMHO, this should be noted or clarified in section 8.8. e.g. "When present, the Session-Id SHOULD appear immediately following the Diameter Header. Further, the message BNF may mandate that the Session-Id MUST be positioned immediately following the message header. Indeed, all messages defined in this RFC require such a positioning. (see Section 3)" =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Victor Fajardo [mailto:vf0213@gmail.com]=20 Sent: Tuesday, August 31, 2010 4:25 PM=20 To: David Lehmann Cc: Glen Zorn; dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs =20 yes. the BNF sets the positioning/sequencing rules. it's a common practice in BNFs to place session-id near the head to optimize msg processing .. etc. On Tue, Aug 31, 2010 at 3:22 PM, David Lehmann wrote: So you are stating that the Diameter protocol itself does NOT require all session-ID AVPs to follow immediately after the message header, but a message's BNF may require it? =20 =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Victor Fajardo [mailto:vf0213@gmail.com]=20 Sent: Tuesday, August 31, 2010 2:21 PM=20 To: David Lehmann Cc: Glen Zorn; dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs =20 =20 On Tue, Aug 31, 2010 at 1:54 PM, David Lehmann wrote: The existing text in 8.8 is contradicting the BNF. =20 =20 =20 Which BNF though ? There maybe apps beyond 3588 that may not necessarily put the session-id after the header in their BNF's. In that regard, the existing text is not contradictory but is meant to be generalized specially because it describes an AVP and is agnostic to any BNF. =20 my two cents, victor =20 =20 I am suggesting text that agrees and supports the BNF. =20 =20 If you don't want to modify the text to agree with the BNF, then I suggest removing the existing text which contradicts it. =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Victor Fajardo [mailto:vf0213@gmail.com]=20 Sent: Tuesday, August 31, 2010 11:52 AM To: David Lehmann Cc: Glen Zorn; dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs =20 Hi David, On Tue, Aug 31, 2010 at 10:37 AM, David Lehmann wrote: Glen, =20 That is not what the spec says. At least, the wording is not clear and, IMHO, is misleading. In which "some message" can the session-id AVP be in any position? =20 It seems to me that the wording in section 8.8 should be: "When present, the Session-Id MUST appear immediately following the Diameter Header (see Section 3)." =20 As Glen has mentioned, the BNF dictates the positioning of the AVP. If you add this text you are adding new rules beyond the BNF. =20 regards, victor =20 =20 =20 =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Glen Zorn [mailto:gwz@net-zen.net]=20 Sent: Tuesday, August 31, 2010 9:54 AM To: David Lehmann Cc: dime@ietf.org Subject: RE: [Dime] RFC 3588 - fixed positioned session-ID AVPs =20 David Lehmann [mailto://dlehmann@ulticom.com] writes: =09 =09 =09 =09 =20 =09 =09 =09 =09 =09 =20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 Hello, Hello. In RFC 3588 (and 3588bis), messages with session IDs are defined with the session ID AVPs with a fixed position which is immediately following the header. (e.g. section 8.3.1) =20 Yes. However, this is in contradiction with section 8.8 which states, "When present, the Session-Id SHOULD appear immediately following the Diameter Header (see Section 3)." No. By using "SHOULD", the spec is stating that the session-ID AVP could be in any position in the message. No, it is stating that the AVP could be in any position in some message. The syntax of the existing messages in RFC 3588 is defined by the associated BNF and in those messages the Session-Id AVP must immediately follow the Diameter header. =20 =20 Hope this helps. =20 ~gwz =09 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime =20 =20 =20 =20 ------_=_NextPart_001_01CB49D9.98B7ACCA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reword as necessary.

 

The reason that a “SHOULD” is followed by a = “MUST” is because that seems to be how diameter is defined, according to the = previous posts.

 

The diameter protocol says “SHOULD” as far as positioning, but the BNF may override the “SHOULD” = with a “MUST”.  It seems you are agreeing that it is confusing. ;-)  This is why = clarification is needed.

 

I think the wording that I provided is dead on, but as I = stated, reword as necessary.

 

--

David Lehmann

Ulticom, Inc.

856-787-2952

 

From:= Victor = Fajardo [mailto:vf0213@gmail.com]
Sent: Wednesday, September 01, 2010 9:13 AM
To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID = AVPs

 

Its good to have some clarity, though the = statement below probably needs some re-org since SHOULD is followed with a = MUST and theres a conditional 'may' in between. Anyway, the statement maybe redundant since each BNF already tells you where the session-id can = be found ..

 

my 2 = cents.

On Wed, Sep 1, 2010 at 8:55 AM, David Lehmann = <dlehmann@ulticom.com> = wrote:

OK, BNF = rules.    IMHO, this should be noted or clarified in section 8.8. = e.g.

“When present, the Session-Id = SHOULD appear immediately following the Diameter Header. Further, the message = BNF may mandate that the Session-Id MUST be positioned immediately following the message header.  Indeed, all messages defined in this RFC require = such a positioning. (see Section 3)”

 

--

David = Lehmann

Ulticom, = Inc.

856-787-2952

 

From: Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Tuesday, August 31, 2010 4:25 PM


To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID = AVPs

 <= /o:p>

yes. the BNF sets the positioning/sequencing rules. it's a common practice in BNFs to place session-id near the head to = optimize msg processing .. etc.

On Tue, Aug 31, 2010 at 3:22 PM, David Lehmann <dlehmann@ulticom.com> wrote:

So you are stating that the = Diameter protocol itself does NOT require all session-ID AVPs to follow = immediately after the message header, but a message’s BNF may require = it? 

 

--

David = Lehmann

Ulticom, = Inc.

856-787-2952

 

From: Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Tuesday, August 31, 2010 2:21 PM


To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID = AVPs

 <= /o:p>

 <= /p>

On Tue, Aug 31, 2010 at 1:54 PM, David Lehmann <dlehmann@ulticom.com> wrote:

The existing text in 8.8 is contradicting the BNF. 

 <= /o:p>

 <= /o:p>

Which BNF though ? There maybe apps beyond 3588 that may not necessarily put = the session-id after the header in their BNF's. In that regard, the existing = text is not contradictory but is meant to be generalized specially because it describes an AVP and is agnostic to any BNF.

 <= /o:p>

my two cents,

victor<= /o:p>

 <= /o:p>

 <= /o:p>

=

I am suggesting text that = agrees and supports the BNF. 

 

If you don’t want to = modify the text to agree with the BNF, then I suggest removing the existing text = which contradicts it.

 

--

David = Lehmann

Ulticom, = Inc.

856-787-2952

 

From: Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Tuesday, August 31, 2010 11:52 AM
To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID = AVPs

 <= /o:p>

Hi David,

On Tue, Aug 31, 2010 at 10:37 AM, David Lehmann <dlehmann@ulticom.com> wrote:

Glen,

 

That is not what the spec says.  At least, = the wording is not clear and, IMHO, is misleading.  In which = “some message” can the session-id AVP be in any = position?

 

It seems to me that the wording in section 8.8 = should be:  “When present, the Session-Id MUST appear immediately following = the Diameter Header (see Section 3).”

 <= /o:p>

As Glen has mentioned, the BNF dictates the positioning of the AVP. If you = add this text you are adding new rules beyond the BNF.

 <= /o:p>

regards,

victor<= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

=

 

--

David = Lehmann

Ulticom, = Inc.

856-787-2952

 

From: Glen Zorn [mailto:gwz@net-zen.net]
Sent: Tuesday, August 31, 2010 9:54 AM
To: David Lehmann
Cc: dime@ietf.org
Subject: RE: [Dime] RFC 3588 - fixed positioned session-ID = AVPs

 <= /o:p>

David Lehmann [mailto://dlehmann@ulticom.com] =
writes:




 





 










 




















 








































Hello,
Hello.
In RFC 3588 =
(and 3588bis), messages with session IDs are defined with the session ID =
AVPs with a fixed position which is immediately following the header. =
(e.g. section 8.3.1)  
Yes.
However, this =
is in contradiction with section 8.8 which states, “When present, =
the Session-Id SHOULD appear immediately following the Diameter Header =
(see Section 3).”
No.
By using =
“SHOULD”, the spec is stating that the session-ID AVP could =
be in any position in the message.

No, it is stating that the AVP = could be in any position in some message.  The syntax of the existing messages in RFC 3588 is defined by the associated BNF and in = those messages the Session-Id AVP must immediately follow the Diameter = header.

 

 

Hope this = helps.

 

 ~gwz

=


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

 <= /o:p>

 <= /o:p>

 <= /o:p>

 

------_=_NextPart_001_01CB49D9.98B7ACCA-- From vf0213@gmail.com Wed Sep 1 06:45:37 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 857743A6893 for ; Wed, 1 Sep 2010 06:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ejncc2JxCT1v for ; Wed, 1 Sep 2010 06:45:36 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 2EB5F3A6A37 for ; Wed, 1 Sep 2010 06:45:32 -0700 (PDT) Received: by wyi11 with SMTP id 11so9870039wyi.31 for ; Wed, 01 Sep 2010 06:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=fiOvecE9fUqi3dFfesM24uwDkZSXntIeKQomYni+r/8=; b=TroBLlg036E+bkOIf15uOplPWTUo4yQGLa2LYg5fmWcnbmWf6dxqfrrs5Eerv+6wet 8c+NDjtcVc6zKLpjbG0Hdsn1PkO3BGb4V2vIlO54M+uyb9upZiAMcCVEDTTB8XC4o0sZ Tv4gRZ+pbVEakxuefI90nJj+DLWS7nlxwP0e4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VbSdkHZxKfVIyuaDfitupPObvQ8BmQXYNxXPoLs1oUhoUsoADUYv7guQRMewF0zWCC nPrQJREaYFCNyDHhTo/yWoIZMuxrBx63gZ3gjinte7N6X+0QVFanziD0va96dNo3W5/r u0xDcp0GDfMn4I5mNcGZGtRUYOpA05uIwEPtg= MIME-Version: 1.0 Received: by 10.216.157.81 with SMTP id n59mr7854344wek.84.1283348758017; Wed, 01 Sep 2010 06:45:58 -0700 (PDT) Received: by 10.216.58.130 with HTTP; Wed, 1 Sep 2010 06:45:57 -0700 (PDT) In-Reply-To: References: <009f01cb4913$e76b5b50$b64211f0$@net> Date: Wed, 1 Sep 2010 09:45:57 -0400 Message-ID: From: Victor Fajardo To: David Lehmann Content-Type: multipart/alternative; boundary=0016e65a0222d8955c048f32eac9 Cc: dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 01 Sep 2010 13:45:37 -0000 --0016e65a0222d8955c048f32eac9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable hmm actually I prefer not to change anything :) ... the current text is clear that the BNF defines everything. And that the original SHOULD is ther= e as a clear recommendation On Wed, Sep 1, 2010 at 9:28 AM, David Lehmann wrote: > Reword as necessary. > > > > The reason that a =93SHOULD=94 is followed by a =93MUST=94 is because tha= t seems to > be how diameter is defined, according to the previous posts. > > > > The diameter protocol says =93SHOULD=94 as far as positioning, but the BN= F * > may* override the =93SHOULD=94 with a =93MUST=94. It seems you are agree= ing that > it is confusing. ;-) This is why clarification is needed. > > > > I think the wording that I provided is dead on, but as I stated, reword a= s > necessary. > > > > -- > > *David Lehmann* > > Ulticom, Inc. > > 856-787-2952 > > > > *From:* Victor Fajardo [mailto:vf0213@gmail.com] > *Sent:* Wednesday, September 01, 2010 9:13 AM > > *To:* David Lehmann > *Cc:* Glen Zorn; dime@ietf.org > *Subject:* Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs > > > > Its good to have some clarity, though the statement below probably needs > some re-org since SHOULD is followed with a MUST and theres a > conditional 'may' in between. Anyway, the statement maybe redundant > since each BNF already tells you where the session-id can be found .. > > > > my 2 cents. > > On Wed, Sep 1, 2010 at 8:55 AM, David Lehmann > wrote: > > OK, BNF rules. IMHO, this should be noted or clarified in section 8.8. > e.g. > > =93When present, the Session-Id SHOULD appear immediately following the > Diameter Header. Further, the message BNF may mandate that the Session-Id > MUST be positioned immediately following the message header. Indeed, all > messages defined in this RFC require such a positioning. (see Section 3)= =94 > > > > -- > > *David Lehmann* > > Ulticom, Inc. > > 856-787-2952 > > > > *From:* Victor Fajardo [mailto:vf0213@gmail.com] > *Sent:* Tuesday, August 31, 2010 4:25 PM > > > *To:* David Lehmann > *Cc:* Glen Zorn; dime@ietf.org > *Subject:* Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs > > > > yes. the BNF sets the positioning/sequencing rules. it's a common > practice in BNFs to place session-id near the head to optimize msg > processing .. etc. > > On Tue, Aug 31, 2010 at 3:22 PM, David Lehmann > wrote: > > So you are stating that the Diameter protocol itself does NOT require all > session-ID AVPs to follow immediately after the message header, but a > message=92s BNF may require it? > > > > -- > > *David Lehmann* > > Ulticom, Inc. > > 856-787-2952 > > > > *From:* Victor Fajardo [mailto:vf0213@gmail.com] > *Sent:* Tuesday, August 31, 2010 2:21 PM > > > *To:* David Lehmann > *Cc:* Glen Zorn; dime@ietf.org > *Subject:* Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs > > > > > > On Tue, Aug 31, 2010 at 1:54 PM, David Lehmann > wrote: > > The existing text in 8.8 is contradicting the BNF. > > > > > > Which BNF though ? There maybe apps beyond 3588 that may not necessarily > put the session-id after the header in their BNF's. In that regard, the > existing text is not contradictory but is meant to be generalized special= ly > because it describes an AVP and is agnostic to any BNF. > > > > my two cents, > > victor > > > > > > I am suggesting text that agrees and supports the BNF. > > > > If you don=92t want to modify the text to agree with the BNF, then I sugg= est > removing the existing text which contradicts it. > > > > -- > > *David Lehmann* > > Ulticom, Inc. > > 856-787-2952 > > > > *From:* Victor Fajardo [mailto:vf0213@gmail.com] > *Sent:* Tuesday, August 31, 2010 11:52 AM > *To:* David Lehmann > *Cc:* Glen Zorn; dime@ietf.org > *Subject:* Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs > > > > Hi David, > > On Tue, Aug 31, 2010 at 10:37 AM, David Lehmann > wrote: > > Glen, > > > > That is not what the spec says. At least, the wording is not clear and, > IMHO, is misleading. In which =93*some* message=94 can the session-id AV= P be > in any position? > > > > It seems to me that the wording in section 8.8 should be: =93When presen= t, > the Session-Id MUST appear immediately following the Diameter Header (see > Section 3).=94 > > > > As Glen has mentioned, the BNF dictates the positioning of the AVP. If yo= u > add this text you are adding new rules beyond the BNF. > > > > regards, > > victor > > > > > > > > > > -- > > *David Lehmann* > > Ulticom, Inc. > > 856-787-2952 > > > > *From:* Glen Zorn [mailto:gwz@net-zen.net] > *Sent:* Tuesday, August 31, 2010 9:54 AM > *To:* David Lehmann > *Cc:* dime@ietf.org > *Subject:* RE: [Dime] RFC 3588 - fixed positioned session-ID AVPs > > > > David Lehmann [mailto://dlehmann@ulticom.com] <[mailto://dlehmann@ulticom= .com%5d> writes: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello, > > Hello. > > In RFC 3588 (and 3588bis), messages with session IDs are defined with the= session ID AVPs with a fixed position which is immediately following the h= eader. (e.g. section 8.3.1) > > Yes. > > However, this is in contradiction with section 8.8 which states, =93When = present, the Session-Id SHOULD appear immediately following the Diameter He= ader (see Section 3).=94 > > No. > > By using =93SHOULD=94, the spec is stating that the session-ID AVP could = be in any position in the message. > > No, it is stating that the AVP could be in any position in *some*message.= The syntax of the existing messages in RFC 3588 is defined by the > associated BNF and in *those* messages the Session-Id AVP *must*immediate= ly follow the Diameter header. > > > > > > Hope this helps. > > > > ~gwz > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > > > > > > > --0016e65a0222d8955c048f32eac9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
hmm actually I prefer not to change anything :) ... the current text= =A0is clear that the BNF defines everything.=A0And that the original SHOULD= is there as a clear recommendation


=A0
On Wed, Sep 1, 2010 at 9:28 AM, David Lehmann <dlehmann@ultico= m.com> wrote:

Rewo= rd as necessary.

=A0<= /span>

The = reason that a =93SHOULD=94 is followed by a =93MUST=94 is because that seem= s to be how diameter is defined, according to the previous posts.

=A0<= /span>

The = diameter protocol says =93SHOULD=94 as far as positioning, but the BNF m= ay override the =93SHOULD=94 with a =93MUST=94.=A0 It seems you are agr= eeing that it is confusing. ;-) =A0This is why clarification is needed.

=A0<= /span>

I th= ink the wording that I provided is dead on, but as I stated, reword as nece= ssary.

=A0<= /span>

--

D= avid Lehmann

Ulti= com, Inc.

856-= 787-2952

=A0<= /span>

From:<= span style=3D"FONT-SIZE: 10pt"> Victor Fajardo [mailto:vf0213@gmail.com]
Sent: We= dnesday, September 01, 2010 9:13 AM=20


To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Sub= ject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs

=A0

Its good to have some clarity,=A0though the statemen= t below probably needs some re-org since=A0SHOULD is followed with a MUST a= nd theres a conditional=A0'may' in between. Anyway, the statement m= aybe redundant since=A0each BNF already tells you where the session-id can = be found ..

=A0

my 2 cents.

On Wed, Sep 1, 2010 at 8:55 AM, David Lehmann <dlehmann@ulticom.co= m> wrote:

OK, = BNF rules.=A0=A0=A0 IMHO, this should be noted or clarified in section 8.8.= e.g.

= =93When present, the Session-Id SHOULD appear immediately following the Dia= meter Header. Further, the message BNF may mandate that the Session-Id MUST= be positioned immediately following the message header.=A0 Indeed, all mes= sages defined in this RFC require such a positioning. (see Section 3)=94

=A0<= /span>

--

D= avid Lehmann

Ulti= com, Inc.

856-= 787-2952

=A0<= /span>

From:<= span style=3D"FONT-SIZE: 10pt"> Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Tu= esday, August 31, 2010 4:25 PM


To: David= Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] RFC 3588 - fixe= d positioned session-ID AVPs

=A0

yes. the BNF sets the = positioning/sequencing rules. it's a common practice=A0in=A0BNFs to pla= ce session-id=A0near the head to optimize msg processing .. etc.

On Tue, Aug 31, 2010 at 3:22 PM, David Lehmann <<= a href=3D"mailto:dlehmann@ulticom.com" target=3D"_blank">dlehmann@ulticom.c= om> wrote:

So y= ou are stating that the Diameter protocol itself does NOT require all sessi= on-ID AVPs to follow immediately after the message header, but a message=92= s BNF may require it?=A0

=A0<= /span>

--

D= avid Lehmann

Ulti= com, Inc.

856-= 787-2952

=A0<= /span>

From:<= span style=3D"FONT-SIZE: 10pt"> Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Tu= esday, August 31, 2010 2:21 PM


To: David= Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] RFC 3588 - fixe= d positioned session-ID AVPs

=A0

=A0

On Tue, Aug 31, 2010 at 1:54 PM, David Lehmann <<= a href=3D"mailto:dlehmann@ulticom.com" target=3D"_blank">dlehmann@ulticom.c= om> wrote:

The = existing text in 8.8 is contradicting the BNF.=A0

=A0

=A0

Which BNF though ? There maybe apps beyond 3588 that= may not necessarily put the session-id after the header in their BNF's= . In that regard, the existing text is not contradictory but is meant to be= generalized specially because it describes an AVP and is agnostic to any B= NF.

=A0

my two cents,

victor

=A0

=A0

I am= suggesting text that agrees and supports the BNF.=A0

=A0<= /span>

If y= ou don=92t want to modify the text to agree with the BNF, then I suggest re= moving the existing text which contradicts it.

=A0<= /span>

--

D= avid Lehmann

Ulti= com, Inc.

856-= 787-2952

=A0<= /span>

From:<= span style=3D"FONT-SIZE: 10pt"> Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Tu= esday, August 31, 2010 11:52 AM
To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] R= FC 3588 - fixed positioned session-ID AVPs

=A0

Hi David,

On Tue, Aug 31, 2010 at 10:37 AM, David Lehmann <= dlehmann@ulticom.= com> wrote:

Glen,

=A0

That is not what the = spec says.=A0 At least, the wording is not clear and, IMHO, is misleading.= =A0 In which =93some message=94 can the session-id AVP be in any pos= ition?

=A0

It seems to me that t= he wording in section 8.8 should be:=A0 =93When present, the Session= -Id MUST appear immediately following the Diameter Header (see Section 3).= =94

=A0

As Glen has mentioned, the BNF dictates the position= ing of the AVP. If you add this text you are adding new rules beyond the BN= F.

=A0

regards,

victor

=A0

=A0

=A0

=A0

--

D= avid Lehmann

Ulti= com, Inc.

856-= 787-2952

=A0

From:<= span style=3D"FONT-SIZE: 10pt"> Glen Zorn [mailto:gwz@net-zen.net]
Sent: Tuesday, = August 31, 2010 9:54 AM
To: David Lehmann
Cc: dime@ietf.org
Subject: RE: [Dime] RFC 3588 - f= ixed positioned session-ID AVPs

=A0

David Lehmann [mailto://dlehmann@u=
lticom.com] writes:





=A0





=A0










=A0




















=A0








































Hello,
Hello.
In RFC 3588 (and 3588bis), messages with session IDs are def=
ined with the session ID AVPs with a fixed position which is immediately fo=
llowing the header. (e.g. section 8.3.1)=A0 
Yes.
However, this is =
in contradiction with section 8.8 which states, =93When present, the Sessio=
n-Id SHOULD appear immediately following the Diameter Header (see Section 3=
).=94
No.
By using =93SHOULD=
=94, the spec is stating that the session-ID AVP could be in any position i=
n the message.

No, = it is stating that the AVP could be in any position in some message.= =A0 The syntax of the existing messages in RFC 3588 is defined by the assoc= iated BNF and in those messages the Session-Id AVP must immed= iately follow the Diameter header.

=A0

=A0<= /span>

Hope= this helps.

=A0<= /span>

=A0~= gwz


__________________= _____________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailm= an/listinfo/dime

=A0

=A0

=A0

=A0


--0016e65a0222d8955c048f32eac9-- From vf0213@gmail.com Wed Sep 1 07:15:47 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBFBC3A6893 for ; Wed, 1 Sep 2010 07:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21PHvHfNukiv for ; Wed, 1 Sep 2010 07:15:45 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 8C52C3A67A5 for ; Wed, 1 Sep 2010 07:15:44 -0700 (PDT) Received: by wwj40 with SMTP id 40so8661wwj.13 for ; Wed, 01 Sep 2010 07:16:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=cfCEg17gV6XUut1WOjzLSXg1BwU/+kP/qd/AKGBpX4w=; b=OU06+s15xkmPVFNe8yJmyUA7UI+MyQnIt9+uStNnk2vE7m7ct8c46i6mC6T1jzYRCQ JoGR7MqPBzHlF3uIiRUkwnk7GE0mP2O+i31x36drOdh6lzAPjbr46rjdcRL+NtmnnrNg eiISuSNL6GMpEdFy7CTj9T6d+i8JFErhdmoP8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rfGw4qaVD4ioucc+xtNNTxtMFyY+RHg2Gz8/TLT92ngkb7bKvlyAOQiWAiZ8X8Z83m 39Jq72pfVcDaQux/Ch8H4cgCc3ND1d5d2ry/Y9z3+BG1TWWMgniVXRqdwWCHky5yniEQ cToKgj6ArVg3di7MJAROqPPPKjk0e+3eBO+Tg= MIME-Version: 1.0 Received: by 10.216.185.211 with SMTP id u61mr353531wem.12.1283350433580; Wed, 01 Sep 2010 07:13:53 -0700 (PDT) Received: by 10.216.58.130 with HTTP; Wed, 1 Sep 2010 07:13:53 -0700 (PDT) In-Reply-To: References: <009f01cb4913$e76b5b50$b64211f0$@net> Date: Wed, 1 Sep 2010 10:13:53 -0400 Message-ID: From: Victor Fajardo To: David Lehmann Content-Type: multipart/alternative; boundary=0016367fad89b7490f048f334e0a Cc: dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 01 Sep 2010 14:15:48 -0000 --0016367fad89b7490f048f334e0a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Just to be clear in my prev email. I prefer not to change anything in bis. On Wed, Sep 1, 2010 at 9:45 AM, Victor Fajardo wrote: > hmm actually I prefer not to change anything :) ... the current text is > clear that the BNF defines everything. And that the original SHOULD is th= ere > as a clear recommendation > > > > On Wed, Sep 1, 2010 at 9:28 AM, David Lehmann wrote= : > >> Reword as necessary. >> >> >> >> The reason that a =93SHOULD=94 is followed by a =93MUST=94 is because th= at seems >> to be how diameter is defined, according to the previous posts. >> >> >> >> The diameter protocol says =93SHOULD=94 as far as positioning, but the B= NF * >> may* override the =93SHOULD=94 with a =93MUST=94. It seems you are agre= eing that >> it is confusing. ;-) This is why clarification is needed. >> >> >> >> I think the wording that I provided is dead on, but as I stated, reword = as >> necessary. >> >> >> >> -- >> >> *David Lehmann* >> >> Ulticom, Inc. >> >> 856-787-2952 >> >> >> >> *From:* Victor Fajardo [mailto:vf0213@gmail.com] >> *Sent:* Wednesday, September 01, 2010 9:13 AM >> >> *To:* David Lehmann >> *Cc:* Glen Zorn; dime@ietf.org >> *Subject:* Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs >> >> >> >> Its good to have some clarity, though the statement below probably needs >> some re-org since SHOULD is followed with a MUST and theres a >> conditional 'may' in between. Anyway, the statement maybe redundant >> since each BNF already tells you where the session-id can be found .. >> >> >> >> my 2 cents. >> >> On Wed, Sep 1, 2010 at 8:55 AM, David Lehmann >> wrote: >> >> OK, BNF rules. IMHO, this should be noted or clarified in section 8.8= . >> e.g. >> >> =93When present, the Session-Id SHOULD appear immediately following the >> Diameter Header. Further, the message BNF may mandate that the Session-I= d >> MUST be positioned immediately following the message header. Indeed, al= l >> messages defined in this RFC require such a positioning. (see Section 3)= =94 >> >> >> >> -- >> >> *David Lehmann* >> >> Ulticom, Inc. >> >> 856-787-2952 >> >> >> >> *From:* Victor Fajardo [mailto:vf0213@gmail.com] >> *Sent:* Tuesday, August 31, 2010 4:25 PM >> >> >> *To:* David Lehmann >> *Cc:* Glen Zorn; dime@ietf.org >> *Subject:* Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs >> >> >> >> yes. the BNF sets the positioning/sequencing rules. it's a common >> practice in BNFs to place session-id near the head to optimize msg >> processing .. etc. >> >> On Tue, Aug 31, 2010 at 3:22 PM, David Lehmann >> wrote: >> >> So you are stating that the Diameter protocol itself does NOT require al= l >> session-ID AVPs to follow immediately after the message header, but a >> message=92s BNF may require it? >> >> >> >> -- >> >> *David Lehmann* >> >> Ulticom, Inc. >> >> 856-787-2952 >> >> >> >> *From:* Victor Fajardo [mailto:vf0213@gmail.com] >> *Sent:* Tuesday, August 31, 2010 2:21 PM >> >> >> *To:* David Lehmann >> *Cc:* Glen Zorn; dime@ietf.org >> *Subject:* Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs >> >> >> >> >> >> On Tue, Aug 31, 2010 at 1:54 PM, David Lehmann >> wrote: >> >> The existing text in 8.8 is contradicting the BNF. >> >> >> >> >> >> Which BNF though ? There maybe apps beyond 3588 that may not necessarily >> put the session-id after the header in their BNF's. In that regard, the >> existing text is not contradictory but is meant to be generalized specia= lly >> because it describes an AVP and is agnostic to any BNF. >> >> >> >> my two cents, >> >> victor >> >> >> >> >> >> I am suggesting text that agrees and supports the BNF. >> >> >> >> If you don=92t want to modify the text to agree with the BNF, then I sug= gest >> removing the existing text which contradicts it. >> >> >> >> -- >> >> *David Lehmann* >> >> Ulticom, Inc. >> >> 856-787-2952 >> >> >> >> *From:* Victor Fajardo [mailto:vf0213@gmail.com] >> *Sent:* Tuesday, August 31, 2010 11:52 AM >> *To:* David Lehmann >> *Cc:* Glen Zorn; dime@ietf.org >> *Subject:* Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs >> >> >> >> Hi David, >> >> On Tue, Aug 31, 2010 at 10:37 AM, David Lehmann >> wrote: >> >> Glen, >> >> >> >> That is not what the spec says. At least, the wording is not clear and, >> IMHO, is misleading. In which =93*some* message=94 can the session-id A= VP be >> in any position? >> >> >> >> It seems to me that the wording in section 8.8 should be: =93When prese= nt, >> the Session-Id MUST appear immediately following the Diameter Header (se= e >> Section 3).=94 >> >> >> >> As Glen has mentioned, the BNF dictates the positioning of the AVP. If y= ou >> add this text you are adding new rules beyond the BNF. >> >> >> >> regards, >> >> victor >> >> >> >> >> >> >> >> >> >> -- >> >> *David Lehmann* >> >> Ulticom, Inc. >> >> 856-787-2952 >> >> >> >> *From:* Glen Zorn [mailto:gwz@net-zen.net] >> *Sent:* Tuesday, August 31, 2010 9:54 AM >> *To:* David Lehmann >> *Cc:* dime@ietf.org >> *Subject:* RE: [Dime] RFC 3588 - fixed positioned session-ID AVPs >> >> >> >> David Lehmann [mailto://dlehmann@ulticom.com] <[mailto://dlehmann@ultico= m.com%5d> writes: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hello, >> >> Hello. >> >> In RFC 3588 (and 3588bis), messages with session IDs are defined with th= e session ID AVPs with a fixed position which is immediately following the = header. (e.g. section 8.3.1) >> >> Yes. >> >> However, this is in contradiction with section 8.8 which states, =93When= present, the Session-Id SHOULD appear immediately following the Diameter H= eader (see Section 3).=94 >> >> No. >> >> By using =93SHOULD=94, the spec is stating that the session-ID AVP could= be in any position in the message. >> >> No, it is stating that the AVP could be in any position in *some*message= . The syntax of the existing messages in RFC 3588 is defined by the >> associated BNF and in *those* messages the Session-Id AVP *must*immediat= ely follow the Diameter header. >> >> >> >> >> >> Hope this helps. >> >> >> >> ~gwz >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> >> >> >> >> >> >> >> >> > > --0016367fad89b7490f048f334e0a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Just to be clear in my prev email. I prefer not to change anything in = bis.

On Wed, Sep 1, 2010 at 9:45 AM, Victor Fajardo <= span dir=3D"ltr"><vf0213@gmail.com> wrote:
hmm actually I prefer not to change anything :) ... the current text= =A0is clear that the BNF defines everything.=A0And that the original SHOULD= is there as a clear recommendation


=A0
On Wed, Sep 1, 2010 at 9:28 AM, David Lehmann <dlehmann@ulticom.com> wrote:

Rewo= rd as necessary.

=A0<= /span>

The = reason that a =93SHOULD=94 is followed by a =93MUST=94 is because that seem= s to be how diameter is defined, according to the previous posts.

=A0<= /span>

The = diameter protocol says =93SHOULD=94 as far as positioning, but the BNF m= ay override the =93SHOULD=94 with a =93MUST=94.=A0 It seems you are agr= eeing that it is confusing. ;-) =A0This is why clarification is needed.

=A0<= /span>

I th= ink the wording that I provided is dead on, but as I stated, reword as nece= ssary.

=A0<= /span>

--

D= avid Lehmann

Ulti= com, Inc.

856-= 787-2952

=A0<= /span>

From:<= span style=3D"FONT-SIZE: 10pt"> Victor Fajardo [mailto:vf0213@gmail.com]
Sent: We= dnesday, September 01, 2010 9:13 AM=20


To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re:= [Dime] RFC 3588 - fixed positioned session-ID AVPs

=A0

Its good to have some clarity,=A0though the statemen= t below probably needs some re-org since=A0SHOULD is followed with a MUST a= nd theres a conditional=A0'may' in between. Anyway, the statement m= aybe redundant since=A0each BNF already tells you where the session-id can = be found ..

=A0

my 2 cents.

On Wed, Sep 1, 2010 at 8:55 AM, David Lehmann <dlehmann@ulticom.co= m> wrote:

OK, = BNF rules.=A0=A0=A0 IMHO, this should be noted or clarified in section 8.8.= e.g.

= =93When present, the Session-Id SHOULD appear immediately following the Dia= meter Header. Further, the message BNF may mandate that the Session-Id MUST= be positioned immediately following the message header.=A0 Indeed, all mes= sages defined in this RFC require such a positioning. (see Section 3)=94

=A0<= /span>

--

D= avid Lehmann

Ulti= com, Inc.

856-= 787-2952

=A0<= /span>

From:<= span style=3D"FONT-SIZE: 10pt"> Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Tu= esday, August 31, 2010 4:25 PM


To: David= Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] RFC 3588 - fixe= d positioned session-ID AVPs

=A0

yes. the BNF sets the = positioning/sequencing rules. it's a common practice=A0in=A0BNFs to pla= ce session-id=A0near the head to optimize msg processing .. etc.

On Tue, Aug 31, 2010 at 3:22 PM, David Lehmann <<= a href=3D"mailto:dlehmann@ulticom.com" target=3D"_blank">dlehmann@ulticom.c= om> wrote:

So y= ou are stating that the Diameter protocol itself does NOT require all sessi= on-ID AVPs to follow immediately after the message header, but a message=92= s BNF may require it?=A0

=A0<= /span>

--

D= avid Lehmann

Ulti= com, Inc.

856-= 787-2952

=A0<= /span>

From:<= span style=3D"FONT-SIZE: 10pt"> Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Tu= esday, August 31, 2010 2:21 PM


To: David= Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] RFC 3588 - fixe= d positioned session-ID AVPs

=A0

=A0

On Tue, Aug 31, 2010 at 1:54 PM, David Lehmann <<= a href=3D"mailto:dlehmann@ulticom.com" target=3D"_blank">dlehmann@ulticom.c= om> wrote:

The = existing text in 8.8 is contradicting the BNF.=A0

=A0

=A0

Which BNF though ? There maybe apps beyond 3588 that= may not necessarily put the session-id after the header in their BNF's= . In that regard, the existing text is not contradictory but is meant to be= generalized specially because it describes an AVP and is agnostic to any B= NF.

=A0

my two cents,

victor

=A0

=A0

I am= suggesting text that agrees and supports the BNF.=A0

=A0<= /span>

If y= ou don=92t want to modify the text to agree with the BNF, then I suggest re= moving the existing text which contradicts it.

=A0<= /span>

--

D= avid Lehmann

Ulti= com, Inc.

856-= 787-2952

=A0<= /span>

From:<= span style=3D"FONT-SIZE: 10pt"> Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Tu= esday, August 31, 2010 11:52 AM
To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] R= FC 3588 - fixed positioned session-ID AVPs

=A0

Hi David,

On Tue, Aug 31, 2010 at 10:37 AM, David Lehmann <= dlehmann@ulticom.= com> wrote:

Glen,

=A0

That is not what the = spec says.=A0 At least, the wording is not clear and, IMHO, is misleading.= =A0 In which =93some message=94 can the session-id AVP be in any pos= ition?

=A0

It seems to me that t= he wording in section 8.8 should be:=A0 =93When present, the Session= -Id MUST appear immediately following the Diameter Header (see Section 3).= =94

=A0

As Glen has mentioned, the BNF dictates the position= ing of the AVP. If you add this text you are adding new rules beyond the BN= F.

=A0

regards,

victor

=A0

=A0

=A0

=A0

--

D= avid Lehmann

Ulti= com, Inc.

856-= 787-2952

=A0

From:<= span style=3D"FONT-SIZE: 10pt"> Glen Zorn [mailto:gwz@net-zen.net]
Sent: Tuesday, = August 31, 2010 9:54 AM
To: David Lehmann
Cc: dime@ietf.org
Subject: RE: [Dime] RFC 3588 - f= ixed positioned session-ID AVPs

=A0

David Lehmann [mailto://dlehmann@u=
lticom.com] writes:






=A0





=A0










=A0




















=A0








































Hello,
Hello.
In RFC 3588 (and 3588bis), messages with session IDs are def=
ined with the session ID AVPs with a fixed position which is immediately fo=
llowing the header. (e.g. section 8.3.1)=A0 
Yes.
However, this is =
in contradiction with section 8.8 which states, =93When present, the Sessio=
n-Id SHOULD appear immediately following the Diameter Header (see Section 3=
).=94
No.
By using =93SHOULD=
=94, the spec is stating that the session-ID AVP could be in any position i=
n the message.

No, = it is stating that the AVP could be in any position in some message.= =A0 The syntax of the existing messages in RFC 3588 is defined by the assoc= iated BNF and in those messages the Session-Id AVP must immed= iately follow the Diameter header.

=A0

=A0<= /span>

Hope= this helps.

=A0<= /span>

=A0~= gwz


__________________= _____________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailm= an/listinfo/dime

=A0

=A0

=A0

=A0



--0016367fad89b7490f048f334e0a-- From dlehmann@ulticom.com Wed Sep 1 07:38:44 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 064D93A6812 for ; Wed, 1 Sep 2010 07:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id le39ztLn-qGx for ; Wed, 1 Sep 2010 07:38:31 -0700 (PDT) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id 5BE773A690E for ; Wed, 1 Sep 2010 07:38:29 -0700 (PDT) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id D68BB27FC5C09537; Wed, 1 Sep 2010 10:38:57 -0400 (EDT) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id o81Ecmlm008448; Wed, 1 Sep 2010 10:38:52 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB49E3.63677E92" Date: Wed, 1 Sep 2010 10:37:00 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RFC 3588 - fixed positioned session-ID AVPs Thread-Index: ActJ4ETL60Aqpbj2TqOZRviCW6O1vgAAiBdQ References: <009f01cb4913$e76b5b50$b64211f0$@net> From: "David Lehmann" To: "Victor Fajardo" Received-SPF: none Cc: dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 01 Sep 2010 14:38:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB49E3.63677E92 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well, at least we found something that we can agree upon! J =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Victor Fajardo [mailto:vf0213@gmail.com]=20 Sent: Wednesday, September 01, 2010 10:14 AM To: David Lehmann Cc: Glen Zorn; dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs =20 Just to be clear in my prev email. I prefer not to change anything in bis. On Wed, Sep 1, 2010 at 9:45 AM, Victor Fajardo wrote: hmm actually I prefer not to change anything :) ... the current text is clear that the BNF defines everything. And that the original SHOULD is there as a clear recommendation =20 On Wed, Sep 1, 2010 at 9:28 AM, David Lehmann wrote: Reword as necessary. =20 The reason that a "SHOULD" is followed by a "MUST" is because that seems to be how diameter is defined, according to the previous posts. =20 The diameter protocol says "SHOULD" as far as positioning, but the BNF may override the "SHOULD" with a "MUST". It seems you are agreeing that it is confusing. ;-) This is why clarification is needed. =20 I think the wording that I provided is dead on, but as I stated, reword as necessary. =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Victor Fajardo [mailto:vf0213@gmail.com]=20 Sent: Wednesday, September 01, 2010 9:13 AM=20 To: David Lehmann Cc: Glen Zorn; dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs =20 Its good to have some clarity, though the statement below probably needs some re-org since SHOULD is followed with a MUST and theres a conditional 'may' in between. Anyway, the statement maybe redundant since each BNF already tells you where the session-id can be found .. =20 my 2 cents. On Wed, Sep 1, 2010 at 8:55 AM, David Lehmann wrote: OK, BNF rules. IMHO, this should be noted or clarified in section 8.8. e.g. "When present, the Session-Id SHOULD appear immediately following the Diameter Header. Further, the message BNF may mandate that the Session-Id MUST be positioned immediately following the message header. Indeed, all messages defined in this RFC require such a positioning. (see Section 3)" =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Victor Fajardo [mailto:vf0213@gmail.com]=20 Sent: Tuesday, August 31, 2010 4:25 PM=20 To: David Lehmann Cc: Glen Zorn; dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs =20 yes. the BNF sets the positioning/sequencing rules. it's a common practice in BNFs to place session-id near the head to optimize msg processing .. etc. On Tue, Aug 31, 2010 at 3:22 PM, David Lehmann wrote: So you are stating that the Diameter protocol itself does NOT require all session-ID AVPs to follow immediately after the message header, but a message's BNF may require it? =20 =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Victor Fajardo [mailto:vf0213@gmail.com]=20 Sent: Tuesday, August 31, 2010 2:21 PM=20 To: David Lehmann Cc: Glen Zorn; dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs =20 =20 On Tue, Aug 31, 2010 at 1:54 PM, David Lehmann wrote: The existing text in 8.8 is contradicting the BNF. =20 =20 =20 Which BNF though ? There maybe apps beyond 3588 that may not necessarily put the session-id after the header in their BNF's. In that regard, the existing text is not contradictory but is meant to be generalized specially because it describes an AVP and is agnostic to any BNF. =20 my two cents, victor =20 =20 I am suggesting text that agrees and supports the BNF. =20 =20 If you don't want to modify the text to agree with the BNF, then I suggest removing the existing text which contradicts it. =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Victor Fajardo [mailto:vf0213@gmail.com]=20 Sent: Tuesday, August 31, 2010 11:52 AM To: David Lehmann Cc: Glen Zorn; dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs =20 Hi David, On Tue, Aug 31, 2010 at 10:37 AM, David Lehmann wrote: Glen, =20 That is not what the spec says. At least, the wording is not clear and, IMHO, is misleading. In which "some message" can the session-id AVP be in any position? =20 It seems to me that the wording in section 8.8 should be: "When present, the Session-Id MUST appear immediately following the Diameter Header (see Section 3)." =20 As Glen has mentioned, the BNF dictates the positioning of the AVP. If you add this text you are adding new rules beyond the BNF. =20 regards, victor =20 =20 =20 =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: Glen Zorn [mailto:gwz@net-zen.net]=20 Sent: Tuesday, August 31, 2010 9:54 AM To: David Lehmann Cc: dime@ietf.org Subject: RE: [Dime] RFC 3588 - fixed positioned session-ID AVPs =20 David Lehmann [mailto://dlehmann@ulticom.com] writes: =09 =09 =09 =09 =20 =20 =09 =09 =09 =09 =09 =20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 Hello, Hello. In RFC 3588 (and 3588bis), messages with session IDs are defined with the session ID AVPs with a fixed position which is immediately following the header. (e.g. section 8.3.1) =20 Yes. However, this is in contradiction with section 8.8 which states, "When present, the Session-Id SHOULD appear immediately following the Diameter Header (see Section 3)." No. By using "SHOULD", the spec is stating that the session-ID AVP could be in any position in the message. No, it is stating that the AVP could be in any position in some message. The syntax of the existing messages in RFC 3588 is defined by the associated BNF and in those messages the Session-Id AVP must immediately follow the Diameter header. =20 =20 Hope this helps. =20 ~gwz =09 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01CB49E3.63677E92 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Well, at least we found something that we can agree upon! = J

 

--

David Lehmann

Ulticom, Inc.

856-787-2952

 

From:= Victor = Fajardo [mailto:vf0213@gmail.com]
Sent: Wednesday, September 01, 2010 10:14 AM
To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID = AVPs

 

Just to be clear in = my prev email. I prefer not to change anything in bis.

On Wed, Sep 1, 2010 at 9:45 AM, Victor Fajardo = <vf0213@gmail.com> = wrote:

hmm actually I prefer not to change anything :) ... = the current text is clear that the BNF defines everything. And = that the original SHOULD is there as a clear recommendation



 

On Wed, Sep 1, 2010 at 9:28 AM, David Lehmann = <dlehmann@ulticom.com> wrote:

Reword as = necessary.

 

The reason that a = “SHOULD” is followed by a “MUST” is because that seems to be how = diameter is defined, according to the previous posts.

 

The diameter protocol says “SHOULD” as far as positioning, but the BNF may = override the “SHOULD” with a “MUST”.  It seems you are = agreeing that it is confusing. ;-)  This is why clarification is = needed.

 

I think the wording that I = provided is dead on, but as I stated, reword as necessary.

 

--

David = Lehmann

Ulticom, = Inc.

856-787-2952

 

From: Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Wednesday, September 01, 2010 9:13 AM =


To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID = AVPs

 <= /o:p>

Its good to have some clarity, though the statement below probably = needs some re-org since SHOULD is followed with a MUST and theres a conditional 'may' in between. Anyway, the statement maybe redundant since each BNF already tells you where the session-id can be found = ..

 <= /o:p>

my 2 cents.

On Wed, Sep 1, 2010 at 8:55 AM, David Lehmann <dlehmann@ulticom.com> wrote:

OK, BNF = rules.    IMHO, this should be noted or clarified in section 8.8. = e.g.

“When present, the Session-Id = SHOULD appear immediately following the Diameter Header. Further, the message = BNF may mandate that the Session-Id MUST be positioned immediately following the message header.  Indeed, all messages defined in this RFC require = such a positioning. (see Section 3)”

 

--

David = Lehmann

Ulticom, = Inc.

856-787-2952

 

From: Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Tuesday, August 31, 2010 4:25 PM


To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID = AVPs

 <= /o:p>

yes. the BNF sets the positioning/sequencing rules. it's a common practice in BNFs to place session-id near the head to = optimize msg processing .. etc.

On Tue, Aug 31, 2010 at 3:22 PM, David Lehmann <dlehmann@ulticom.com> wrote:

So you are stating that the = Diameter protocol itself does NOT require all session-ID AVPs to follow = immediately after the message header, but a message’s BNF may require = it? 

 

--

David = Lehmann

Ulticom, = Inc.

856-787-2952

 

From: Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Tuesday, August 31, 2010 2:21 PM


To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID = AVPs

 <= /o:p>

 <= /p>

On Tue, Aug 31, 2010 at 1:54 PM, David Lehmann <dlehmann@ulticom.com> wrote:

The existing text in 8.8 is contradicting the BNF. 

 <= /o:p>

 <= /o:p>

Which BNF though ? There maybe apps beyond 3588 that may not necessarily put = the session-id after the header in their BNF's. In that regard, the existing = text is not contradictory but is meant to be generalized specially because it describes an AVP and is agnostic to any BNF.

 <= /o:p>

my two cents,

victor<= /o:p>

 <= /o:p>

 <= /o:p>

=

I am suggesting text that = agrees and supports the BNF. 

 

If you don’t want to = modify the text to agree with the BNF, then I suggest removing the existing text = which contradicts it.

 

--

David = Lehmann

Ulticom, = Inc.

856-787-2952

 

From: Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Tuesday, August 31, 2010 11:52 AM
To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID = AVPs

 <= /o:p>

Hi David,

On Tue, Aug 31, 2010 at 10:37 AM, David Lehmann <dlehmann@ulticom.com> wrote:

Glen,

 

That is not what the spec says.  At least, = the wording is not clear and, IMHO, is misleading.  In which = “some message” can the session-id AVP be in any = position?

 

It seems to me that the wording in section 8.8 = should be:  “When present, the Session-Id MUST appear immediately following = the Diameter Header (see Section 3).”

 <= /o:p>

As Glen has mentioned, the BNF dictates the positioning of the AVP. If you = add this text you are adding new rules beyond the BNF.

 <= /o:p>

regards,

victor<= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

=

 

--

David = Lehmann

Ulticom, = Inc.

856-787-2952

 

From: Glen Zorn [mailto:gwz@net-zen.net]
Sent: Tuesday, August 31, 2010 9:54 AM
To: David Lehmann
Cc: dime@ietf.org
Subject: RE: [Dime] RFC 3588 - fixed positioned session-ID = AVPs

 <= /o:p>

David Lehmann [mailto://dlehmann@ulticom.com] =
writes:




 
 





 










 




















 








































 
















































































Hello,
Hello.
In RFC 3588 =
(and 3588bis), messages with session IDs are defined with the session ID =
AVPs with a fixed position which is immediately following the header. =
(e.g. section 8.3.1)  
Yes.
However, this =
is in contradiction with section 8.8 which states, “When present, =
the Session-Id SHOULD appear immediately following the Diameter Header =
(see Section 3).”
No.
By using =
“SHOULD”, the spec is stating that the session-ID AVP could =
be in any position in the message.

No, it is stating that the AVP = could be in any position in some message.  The syntax of the existing messages in RFC 3588 is defined by the associated BNF and in = those messages the Session-Id AVP must immediately follow the Diameter = header.

 

 

Hope this = helps.

 

 ~gwz

=


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

 <= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

 

 

------_=_NextPart_001_01CB49E3.63677E92-- From root@core3.amsl.com Wed Sep 1 14:00:07 2010 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8BCB33A689F; Wed, 1 Sep 2010 14:00:07 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100901210007.8BCB33A689F@core3.amsl.com> Date: Wed, 1 Sep 2010 14:00:07 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-app-design-guide-12.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 01 Sep 2010 21:00:07 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Applications Design Guidelines Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-app-design-guide-12.txt Pages : 26 Date : 2010-09-01 The Diameter Base protocol provides updated rules on how to extend Diameter by modifying and/or deriving from existing applications or creating entirely new applications. This is a companion document to the Diameter Base protocol that further explains and clarifies these rules. It is meant as a guidelines document and therefore it does not add, remove or change existing rules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-app-design-guide-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-09-01134913.I-D@ietf.org> --NextPart-- From gwz@net-zen.net Wed Sep 1 20:58:44 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FA9E3A687A for ; Wed, 1 Sep 2010 20:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.185 X-Spam-Level: X-Spam-Status: No, score=-102.185 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXygMhuuKiZu for ; Wed, 1 Sep 2010 20:58:36 -0700 (PDT) Received: from smtpauth16.prod.mesa1.secureserver.net (smtpauth16.prod.mesa1.secureserver.net [64.202.165.22]) by core3.amsl.com (Postfix) with SMTP id 9215F3A68BF for ; Wed, 1 Sep 2010 20:58:36 -0700 (PDT) Received: (qmail 25163 invoked from network); 2 Sep 2010 03:57:32 -0000 Received: from unknown (124.157.141.122) by smtpauth16.prod.mesa1.secureserver.net (64.202.165.22) with ESMTP; 02 Sep 2010 03:57:29 -0000 From: "Glen Zorn" To: "'Victor Fajardo'" , "'David Lehmann'" References: <009f01cb4913$e76b5b50$b64211f0$@net> In-Reply-To: Date: Thu, 2 Sep 2010 10:58:27 +0700 Organization: Network Zen Message-ID: <017b01cb4a53$1bf2a960$53d7fc20$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_017C_01CB4A8D.C8518160" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActJ16XhJZkEbtqoSdupLMdMVsb99wAeo1Ug Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 02 Sep 2010 03:58:44 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_017C_01CB4A8D.C8518160 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Victor Fajardo [mailto:vf0213@gmail.com] writes: Its good to have some clarity, Clarity is a wonderful thing & 3588bis could probably (still!) use a little more of it but this point seems so blindingly obvious that further wordsmithing would be just a waste of time. though the statement below probably needs some re-org since SHOULD is followed with a MUST and theres a conditional 'may' in between. Anyway, the statement maybe redundant since each BNF already tells you where the session-id can be found .. my 2 cents. On Wed, Sep 1, 2010 at 8:55 AM, David Lehmann wrote: OK, BNF rules. IMHO, this should be noted or clarified in section 8.8. e.g. "When present, the Session-Id SHOULD appear immediately following the Diameter Header. Further, the message BNF may mandate that the Session-Id MUST be positioned immediately following the message header. Indeed, all messages defined in this RFC require such a positioning. (see Section 3)" -- David Lehmann Ulticom, Inc. 856-787-2952 From: Victor Fajardo [mailto:vf0213@gmail.com] Sent: Tuesday, August 31, 2010 4:25 PM To: David Lehmann Cc: Glen Zorn; dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs yes. the BNF sets the positioning/sequencing rules. it's a common practice in BNFs to place session-id near the head to optimize msg processing .. etc. On Tue, Aug 31, 2010 at 3:22 PM, David Lehmann wrote: So you are stating that the Diameter protocol itself does NOT require all session-ID AVPs to follow immediately after the message header, but a message's BNF may require it? -- David Lehmann Ulticom, Inc. 856-787-2952 From: Victor Fajardo [mailto:vf0213@gmail.com] Sent: Tuesday, August 31, 2010 2:21 PM To: David Lehmann Cc: Glen Zorn; dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs On Tue, Aug 31, 2010 at 1:54 PM, David Lehmann wrote: The existing text in 8.8 is contradicting the BNF. Which BNF though ? There maybe apps beyond 3588 that may not necessarily put the session-id after the header in their BNF's. In that regard, the existing text is not contradictory but is meant to be generalized specially because it describes an AVP and is agnostic to any BNF. my two cents, victor I am suggesting text that agrees and supports the BNF. If you don't want to modify the text to agree with the BNF, then I suggest removing the existing text which contradicts it. -- David Lehmann Ulticom, Inc. 856-787-2952 From: Victor Fajardo [mailto:vf0213@gmail.com] Sent: Tuesday, August 31, 2010 11:52 AM To: David Lehmann Cc: Glen Zorn; dime@ietf.org Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID AVPs Hi David, On Tue, Aug 31, 2010 at 10:37 AM, David Lehmann wrote: Glen, That is not what the spec says. At least, the wording is not clear and, IMHO, is misleading. In which "some message" can the session-id AVP be in any position? It seems to me that the wording in section 8.8 should be: "When present, the Session-Id MUST appear immediately following the Diameter Header (see Section 3)." As Glen has mentioned, the BNF dictates the positioning of the AVP. If you add this text you are adding new rules beyond the BNF. regards, victor -- David Lehmann Ulticom, Inc. 856-787-2952 From: Glen Zorn [mailto:gwz@net-zen.net] Sent: Tuesday, August 31, 2010 9:54 AM To: David Lehmann Cc: dime@ietf.org Subject: RE: [Dime] RFC 3588 - fixed positioned session-ID AVPs David Lehmann [mailto://dlehmann@ulticom.com] writes: Hello, Hello. In RFC 3588 (and 3588bis), messages with session IDs are defined with the session ID AVPs with a fixed position which is immediately following the header. (e.g. section 8.3.1) Yes. However, this is in contradiction with section 8.8 which states, "When present, the Session-Id SHOULD appear immediately following the Diameter Header (see Section 3)." No. By using "SHOULD", the spec is stating that the session-ID AVP could be in any position in the message. No, it is stating that the AVP could be in any position in some message. The syntax of the existing messages in RFC 3588 is defined by the associated BNF and in those messages the Session-Id AVP must immediately follow the Diameter header. Hope this helps. ~gwz _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ------=_NextPart_000_017C_01CB4A8D.C8518160 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Victor Fajardo [mailto:vf0213@gmail.com] writes:

Its good to have some clarity, 

Clarity is a wonderful thing & 3588bis could probably (still!) use a little = more of it but this point seems so blindingly obvious that further wordsmithing = would be just a waste of time.

though the statement below probably needs some = re-org since SHOULD is followed with a MUST and theres a = conditional 'may' in between. Anyway, the statement maybe redundant since each BNF = already tells you where the session-id can be found ..

 

my 2 = cents.

On Wed, Sep 1, 2010 at 8:55 AM, David Lehmann = <dlehmann@ulticom.com> = wrote:

OK, BNF = rules.    IMHO, this should be noted or clarified in section 8.8. = e.g.

“When present, the Session-Id = SHOULD appear immediately following the Diameter Header. Further, the message = BNF may mandate that the Session-Id MUST be positioned immediately following the message header.  Indeed, all messages defined in this RFC require = such a positioning. (see Section 3)”

 

--

David = Lehmann

Ulticom, = Inc.

856-787-2952

 

From: Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Tuesday, August 31, 2010 4:25 PM


To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID = AVPs

 <= /o:p>

yes. the BNF sets the positioning/sequencing rules. it's a common practice in BNFs to place session-id near the head to = optimize msg processing .. etc.

On Tue, Aug 31, 2010 at 3:22 PM, David Lehmann <dlehmann@ulticom.com> wrote:

So you are stating that the = Diameter protocol itself does NOT require all session-ID AVPs to follow = immediately after the message header, but a message’s BNF may require = it? 

 

--

David = Lehmann

Ulticom, = Inc.

856-787-2952

 

From: Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Tuesday, August 31, 2010 2:21 PM


To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID = AVPs

 <= /o:p>

 <= /p>

On Tue, Aug 31, 2010 at 1:54 PM, David Lehmann <dlehmann@ulticom.com> wrote:

The existing text in 8.8 is contradicting the BNF. 

 <= /o:p>

 <= /o:p>

Which BNF though ? There maybe apps beyond 3588 that may not necessarily put = the session-id after the header in their BNF's. In that regard, the existing = text is not contradictory but is meant to be generalized specially because it describes an AVP and is agnostic to any BNF.

 <= /o:p>

my two cents,

victor<= /o:p>

 <= /o:p>

 <= /o:p>

=

I am suggesting text that = agrees and supports the BNF. 

 

If you don’t want to = modify the text to agree with the BNF, then I suggest removing the existing text = which contradicts it.

 

--

David = Lehmann

Ulticom, = Inc.

856-787-2952

 

From: Victor Fajardo [mailto:vf0213@gmail.com]
Sent: Tuesday, August 31, 2010 11:52 AM
To: David Lehmann
Cc: Glen Zorn; dime@ietf.org
Subject: Re: [Dime] RFC 3588 - fixed positioned session-ID = AVPs

 <= /o:p>

Hi David,

On Tue, Aug 31, 2010 at 10:37 AM, David Lehmann <dlehmann@ulticom.com> wrote:

Glen,

 

That is not what the spec says.  At least, = the wording is not clear and, IMHO, is misleading.  In which = “some message” can the session-id AVP be in any = position?

 

It seems to me that the wording in section 8.8 = should be:  “When present, the Session-Id MUST appear immediately following = the Diameter Header (see Section 3).”

 <= /o:p>

As Glen has mentioned, the BNF dictates the positioning of the AVP. If you = add this text you are adding new rules beyond the BNF.

 <= /o:p>

regards,

victor<= /o:p>

 <= /o:p>

 <= /o:p>

 <= /o:p>

=

 

--

David = Lehmann

Ulticom, = Inc.

856-787-2952

 

From: Glen Zorn [mailto:gwz@net-zen.net]
Sent: Tuesday, August 31, 2010 9:54 AM
To: David Lehmann
Cc: dime@ietf.org
Subject: RE: [Dime] RFC 3588 - fixed positioned session-ID = AVPs

 <= /o:p>

David Lehmann [mailto://dlehmann@ulticom.com] =
writes:




 





 










 




















 








































Hello,
Hello.
In RFC 3588 =
(and 3588bis), messages with session IDs are defined with the session ID =
AVPs with a fixed position which is immediately following the header. =
(e.g. section 8.3.1)  
Yes.
However, this =
is in contradiction with section 8.8 which states, “When present, =
the Session-Id SHOULD appear immediately following the Diameter Header =
(see Section 3).”
No.
By using =
“SHOULD”, the spec is stating that the session-ID AVP could =
be in any position in the message.

No, it is stating that the AVP = could be in any position in some message.  The syntax of the existing messages in RFC 3588 is defined by the associated BNF and in = those messages the Session-Id AVP must immediately follow the Diameter = header.

 

 

Hope this = helps.

 

 ~gwz

=


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

 <= /o:p>

 <= /o:p>

 <= /o:p>

 

------=_NextPart_000_017C_01CB4A8D.C8518160-- From root@core3.amsl.com Thu Sep 2 05:30:16 2010 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 072593A6AA2; Thu, 2 Sep 2010 05:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100902123016.072593A6AA2@core3.amsl.com> Date: Thu, 2 Sep 2010 05:30:02 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-25.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 02 Sep 2010 12:30:16 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Base Protocol Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-rfc3588bis-25.txt Pages : 158 Date : 2010-09-02 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services used by all Diameter applications. The Diameter base protocol as defined in this document must be supported by all Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-25.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-rfc3588bis-25.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-09-02052721.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Thu Sep 2 07:30:01 2010 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9B2AE3A6A4E; Thu, 2 Sep 2010 07:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100902143001.9B2AE3A6A4E@core3.amsl.com> Date: Thu, 2 Sep 2010 07:30:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-extended-naptr-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 02 Sep 2010 14:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Extended NAPTR Author(s) : M. Jones, J. Korhonen Filename : draft-ietf-dime-extended-naptr-02.txt Pages : 10 Date : 2010-09-02 This document describes an extended format for the S-NAPTR Application Service Tag used in dynamic Diameter agent discovery. The extended format allows NAPTR queries to contain Diameter Application-Id information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-extended-naptr-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-extended-naptr-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-09-02072817.I-D@ietf.org> --NextPart-- From mark@azu.ca Thu Sep 2 07:34:53 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 001373A6A31 for ; Thu, 2 Sep 2010 07:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.327 X-Spam-Level: X-Spam-Status: No, score=-1.327 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zj5ZXnd9uz2W for ; Thu, 2 Sep 2010 07:34:52 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id F34FD3A6AA8 for ; Thu, 2 Sep 2010 07:34:51 -0700 (PDT) Received: by qyk1 with SMTP id 1so2055488qyk.10 for ; Thu, 02 Sep 2010 07:35:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.96.150 with SMTP id h22mr6548371qan.173.1283438121502; Thu, 02 Sep 2010 07:35:21 -0700 (PDT) Received: by 10.229.225.143 with HTTP; Thu, 2 Sep 2010 07:35:21 -0700 (PDT) In-Reply-To: <20100902143001.9B2AE3A6A4E@core3.amsl.com> References: <20100902143001.9B2AE3A6A4E@core3.amsl.com> Date: Thu, 2 Sep 2010 10:35:21 -0400 Message-ID: From: Mark Jones To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Dime] I-D Action:draft-ietf-dime-extended-naptr-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 02 Sep 2010 14:34:53 -0000 The changes in this revision are: - Added usage guidelines as requested at IETF#78. - Updated ref to Diameter QoS Application RFC (5866). Comments welcome. Regards Mark On Thu, Sep 2, 2010 at 10:30 AM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Diameter Maintenance and Extensions Work= ing Group of the IETF. > > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Diameter Extended NAPTR > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : M. Jones, J. Korhonen > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-dime-extended-naptr-0= 2.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 10 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2010-09-02 > > This document describes an extended format for the S-NAPTR > Application Service Tag used in dynamic Diameter agent discovery. > The extended format allows NAPTR queries to contain Diameter > Application-Id information. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dime-extended-naptr-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > From jouni.nospam@gmail.com Thu Sep 2 09:57:55 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57FD33A69A3 for ; Thu, 2 Sep 2010 09:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.075 X-Spam-Level: X-Spam-Status: No, score=-3.075 tagged_above=-999 required=5 tests=[AWL=0.524, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUlzEhwQGne4 for ; Thu, 2 Sep 2010 09:57:54 -0700 (PDT) Received: from vs11.mail.saunalahti.fi (vs11.mail.saunalahti.fi [195.197.172.106]) by core3.amsl.com (Postfix) with ESMTP id 0DD1A3A688C for ; Thu, 2 Sep 2010 09:57:53 -0700 (PDT) Received: from saunalahti-vams (localhost [127.0.0.1]) by vs11.mail.saunalahti.fi (Postfix) with SMTP id 0AE5D1A505C; Thu, 2 Sep 2010 19:58:22 +0300 (EEST) Received: from vs11.mail.saunalahti.fi ([127.0.0.1]) by vs11.mail.saunalahti.fi ([195.197.172.106]) with SMTP (gateway) id A05B62070BA; Thu, 02 Sep 2010 19:58:22 +0300 Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by vs11.mail.saunalahti.fi (Postfix) with ESMTP id ECAC91A505C; Thu, 2 Sep 2010 19:58:21 +0300 (EEST) Received: from a83-245-209-228.elisa-laajakaista.fi (a83-245-209-228.elisa-laajakaista.fi [83.245.209.228]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id D5A651396B3; Thu, 2 Sep 2010 19:58:19 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: Date: Thu, 2 Sep 2010 19:58:18 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <02286582-8AF6-40F9-8444-A8FCBEA1E401@gmail.com> References: <20100902143001.9B2AE3A6A4E@core3.amsl.com> To: dime@ietf.org X-Mailer: Apple Mail (2.1081) X-Antivirus: VAMS Subject: Re: [Dime] I-D Action:draft-ietf-dime-extended-naptr-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 02 Sep 2010 16:57:55 -0000 Hi, The latest draft revision addresses the comments raised against it. = Apart from the informative addition the draft has been technically = stable for quite some time. The authors (including me) think that the = draft is ready for a WGLC. The start of the WGLC will be announced soon. - Jouni On Sep 2, 2010, at 5:35 PM, Mark Jones wrote: > The changes in this revision are: >=20 > - Added usage guidelines as requested at IETF#78. > - Updated ref to Diameter QoS Application RFC (5866). >=20 > Comments welcome. >=20 > Regards > Mark >=20 > On Thu, Sep 2, 2010 at 10:30 AM, wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Diameter Maintenance and Extensions = Working Group of the IETF. >>=20 >>=20 >> Title : Diameter Extended NAPTR >> Author(s) : M. Jones, J. Korhonen >> Filename : draft-ietf-dime-extended-naptr-02.txt >> Pages : 10 >> Date : 2010-09-02 >>=20 >> This document describes an extended format for the S-NAPTR >> Application Service Tag used in dynamic Diameter agent discovery. >> The extended format allows NAPTR queries to contain Diameter >> Application-Id information. >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-ietf-dime-extended-naptr-02.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From Internet-Drafts@ietf.org Thu Sep 2 11:24:49 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 871793A67F3; Thu, 2 Sep 2010 11:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.199 X-Spam-Level: X-Spam-Status: No, score=-101.199 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, HELO_EQ_DK=1.009, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5tQcI3Moqe4; Thu, 2 Sep 2010 11:24:48 -0700 (PDT) Received: from smtpsrv11.tdc.dk (smtpsrv11.tdc.dk [192.66.33.190]) by core3.amsl.com (Postfix) with ESMTP id 7B3A63A6813; Thu, 2 Sep 2010 11:24:40 -0700 (PDT) Received: from mail pickup service by smtpsrv11.tdc.dk with Microsoft SMTPSVC; Thu, 2 Sep 2010 20:25:53 +0200 Received: from mail.ietf.org ([64.170.98.32]) by smtpsrv10.tdc.dk with Microsoft SMTPSVC(5.0.2195.7381); Thu, 2 Sep 2010 16:35:02 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A525F3A6AA2; Thu, 2 Sep 2010 07:30:04 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9B2AE3A6A4E; Thu, 2 Sep 2010 07:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100902143001.9B2AE3A6A4E@core3.amsl.com> Date: Thu, 2 Sep 2010 07:30:01 -0700 (PDT) X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-OriginalArrivalTime: 02 Sep 2010 14:35:02.0437 (UTC) FILETIME=[071D1D50:01CB4AAC] Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-extended-naptr-02.txt X-BeenThere: dime@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 18:24:49 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Extended NAPTR Author(s) : M. Jones, J. Korhonen Filename : draft-ietf-dime-extended-naptr-02.txt Pages : 10 Date : 2010-09-02 This document describes an extended format for the S-NAPTR Application Service Tag used in dynamic Diameter agent discovery. The extended format allows NAPTR queries to contain Diameter Application-Id information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-extended-naptr-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-extended-naptr-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-09-02072817.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- From Internet-Drafts@ietf.org Thu Sep 2 12:05:58 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 974803A69A0; Thu, 2 Sep 2010 12:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.373 X-Spam-Level: X-Spam-Status: No, score=-101.373 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, HELO_EQ_DK=1.009, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daJzctrLN6N6; Thu, 2 Sep 2010 12:05:57 -0700 (PDT) Received: from smtpsrv11.tdc.dk (smtpsrv11.tdc.dk [192.66.33.190]) by core3.amsl.com (Postfix) with ESMTP id 594B23A6962; Thu, 2 Sep 2010 12:05:57 -0700 (PDT) Received: from mail pickup service by smtpsrv11.tdc.dk with Microsoft SMTPSVC; Thu, 2 Sep 2010 21:07:10 +0200 Received: from mail.ietf.org ([64.170.98.32]) by smtpsrv10.tdc.dk with Microsoft SMTPSVC(5.0.2195.7381); Thu, 2 Sep 2010 14:41:52 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98A5E3A6AB8; Thu, 2 Sep 2010 05:33:39 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 072593A6AA2; Thu, 2 Sep 2010 05:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100902123016.072593A6AA2@core3.amsl.com> Date: Thu, 2 Sep 2010 05:30:02 -0700 (PDT) X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-OriginalArrivalTime: 02 Sep 2010 12:41:52.0390 (UTC) FILETIME=[37EE2A60:01CB4A9C] Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-25.txt X-BeenThere: dime@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 19:05:58 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Base Protocol Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-rfc3588bis-25.txt Pages : 158 Date : 2010-09-02 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services used by all Diameter applications. The Diameter base protocol as defined in this document must be supported by all Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-25.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-rfc3588bis-25.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-09-02052721.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- From jouni.nospam@gmail.com Fri Sep 3 04:44:49 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C16303A6856; Fri, 3 Sep 2010 04:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQj7cU-U6qW9; Fri, 3 Sep 2010 04:44:48 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 485383A6407; Fri, 3 Sep 2010 04:44:44 -0700 (PDT) Received: by fxm18 with SMTP id 18so1113195fxm.31 for ; Fri, 03 Sep 2010 04:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type:subject :date:message-id:cc:to:mime-version:x-mailer; bh=SVNjdAxg6d7KOIbqnpNjxD1d5Vj/vjkh4KfeLMCRQlE=; b=mCYu3ogjtV+u8cZ5XEerf43149TM3Oh9be2IvyJ9dwcS7P4TwcBtHFonBotSO/brT4 zX27yzFPnLkGMT9pnJYp6AU9goGisbvUucGRXui0HBaAZN1rXaXmXhzvYQsnNLjvJ9Aj BULUnNpSYXV78sL9hE/Eu9eMFgtG75rYhfCXk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:subject:date:message-id:cc:to:mime-version :x-mailer; b=vm6eBgyCc/zbDOg7DPx6pOm6KAFvVFnniVIRkiWXp3fGX6o+ypGXtvagGCpXB9rnr7 8v4DeJ+/WFt5hQQ+quDteUDqpsougSqueWI0lVm2T8NGhSXVaSlB1ycTIDlKSh2WUFy7 Zv8MAVEo4kGTzjwURs7DNAg9h1MLK9X8w/S+Y= Received: by 10.223.104.148 with SMTP id p20mr526358fao.11.1283514313082; Fri, 03 Sep 2010 04:45:13 -0700 (PDT) Received: from a88-114-169-148.elisa-laajakaista.fi (a88-114-169-148.elisa-laajakaista.fi [88.114.169.148]) by mx.google.com with ESMTPS id r4sm770686faa.43.2010.09.03.04.45.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 03 Sep 2010 04:45:11 -0700 (PDT) From: jouni korhonen Content-Type: multipart/mixed; boundary=Apple-Mail-3-264443023 Date: Fri, 3 Sep 2010 14:45:20 +0300 Message-Id: To: iesg-secretary@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Cc: dime@ietf.org, dime-chairs@tools.ietf.org Subject: [Dime] Publication request for RFC3588bis - draft-ietf-dime-rfc3588bis-25 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 03 Sep 2010 11:44:49 -0000 --Apple-Mail-3-264443023 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Secretary, This is a request for publication of draft-ietf-dime-rfc3588bis-25 as a = standards track RFC. I am attaching the document shepherd proto = write-up. - Jouni --Apple-Mail-3-264443023 Content-Disposition: attachment; filename=rfc3588bis_proto.txt Content-Type: text/plain; name="rfc3588bis_proto.txt" Content-Transfer-Encoding: 7bit (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? -- Jouni Korhonen (jouni.korhonen@nsn.com, jouni.nospam@gmail.com) is the Document Shepherd, Dime co-chair. He has done a review on the document and believes it is ready to be forwarded to IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? -- The document has had an extensive review by the DIME WG and the larger community interested in Diameter. The shepherd has reviewed the document himself and has no issue with it. Nor the shepherd has issues with the reviews done by others. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? -- No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. -- No. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? -- The consensus behind the document is solid and a result of a long process. The document spent quite few years in the WG. Therefore, if someone in the WG had real concerns those have been heard and addressed. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) -- No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? -- The shepherd has checked the document with the idnits tool. No errors are reported. Warnings reported are due the indits tool misinterpreting some abbreviations as references or editorials that can only be fixed manually. Comments have similar indits reports as warnings. The document does not need MIB doctor review. Possible media and URI types are directly lifted from the existing RFC 3588, thus not needing any further reviews. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. -- References are split accordingly and there are no references to documents with unclear status or are in progress. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol -- Yes. extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If -- Yes. Care should taken by IANA when verifying IANA considerations as this document is a bis to RFC 3588 and therefore most of the IANA registries have already been created. the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? -- For the Expert Review members of the AAA Doctors should be appointed to the review process. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? -- Yes. Note that the RFC 3588bis uses a modified ABNF, which means the online ABNF checker tool will report an error e.g. for Grouped AVPs. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary -- This document is a bis version of RFC 3588 and will eventually obsolete RFC 3588. The document corrects a number of known errors and flaws in RFC 3588, and deprecates some feature that are known to be unusable. For a detailed list of changes refer to Section 1.1.3. of this document. Working Group Summary --- The document spent almost four years in the WG, which is unreasonably long time. This was not a result of large controversy, but rather ensuring nothing important breaks in backwards compatibility. Document Quality --- FreeDiameter (www.freediameter.net) implements -21 version of the specification. A number of vendors have indicated interest on implementing the specification due it correcting several known flaws. There has been no MIB Doctor or Media Type reviews as those were not seen relevant for the bis version of the specification. There has not been explicitly requested expert reviews outside the WG as we believe most if not all important technical experts are already represented in the WG and its mailing list. The document has received multiple reviews while in WGLC. --Apple-Mail-3-264443023-- From root@core3.amsl.com Mon Sep 6 05:15:04 2010 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6740D3A68FA; Mon, 6 Sep 2010 05:15:04 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100906121504.6740D3A68FA@core3.amsl.com> Date: Mon, 6 Sep 2010 05:15:04 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-erp-04.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 06 Sep 2010 12:15:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Support for the EAP Re-authentication Protocol (ERP) Author(s) : J. Bournelle, et al. Filename : draft-ietf-dime-erp-04.txt Pages : 18 Date : 2010-09-06 The EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re- authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new AVPs that can be used to transport the cryptographic material needed by the re-authentication server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-erp-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-erp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-09-06050611.I-D@ietf.org> --NextPart-- From fbrockne@cisco.com Mon Sep 6 06:02:57 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2419F3A68E3 for ; Mon, 6 Sep 2010 06:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afSEf9CImAQj for ; Mon, 6 Sep 2010 06:02:56 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C96C73A67FF for ; Mon, 6 Sep 2010 06:02:55 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJ6DhExAZnwN/2dsb2JhbAChEnGgXJpahT0EjRY X-IronPort-AV: E=Sophos;i="4.56,325,1280707200"; d="scan'208";a="155925566" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 06 Sep 2010 13:03:22 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o86D32Fk022551; Mon, 6 Sep 2010 13:03:22 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Sep 2010 15:03:20 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Sep 2010 15:03:17 +0200 Message-ID: <0D212BD466921646B58854FB79092CEC02E37772@XMB-AMS-106.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Auth-Session-State (WGLC comments of draft-ietf-dime-nat-control-03) Thread-Index: ActNu/pxvnYmMNYPSbC5XYUBYnRy9QAApxKQ From: "Frank Brockners (fbrockne)" To: "jouni korhonen" X-OriginalArrivalTime: 06 Sep 2010 13:03:20.0049 (UTC) FILETIME=[E1165610:01CB4DC3] Cc: dime@ietf.org Subject: [Dime] Auth-Session-State (WGLC comments of draft-ietf-dime-nat-control-03) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 06 Sep 2010 13:02:57 -0000 Hi Jouni, Thanks for your detailed review of draft-ietf-dime-nat-control-03.=20 Wrt/ your comment on the use of " Auth-Session-State AVP", I agree that the use of this AVP is redundant and not really useful, because I'll have the default value in all cases, given that in DNCA both manager and agent are stateful. In order to avoid confusion, I'd follow your implicit suggestion to remove the AVP - and - more importantly add additional details on how state is maintained. Simply referring back to RFC 3588 for a description of state machines unfortunately does not work here. Per our earlier discussions in the working group, the nomenclature of "server" and "client" does not really apply to the DNCA use case, hence the use of "manager" and "agent" for the two involved Diameter entities.=20 My suggestion would be that we add another section which show state machines at agent and manager in detail (obviously reusing the format in RFC 3588). Would that be an agreeable way forward? Thanks & regards, Frank > Ticket #9: http://trac.tools.ietf.org/wg/dime/trac/ticket/9 > > During the WGLC review of draft-ietf-dime-nat-control-03 I started to > think about the Auth-Session-State AVP and the associated semantics. > The draft should state, even if it seems obvious, whether the state is > maintained or not. And whether it applies to all possible messages > exchanges. Can Auth-Session-State be on NCA or in NCR during > QUERY_REQUEST? >=20 > How well the DNCA "view" of the session state goes along with RFC3588 > authz session state machine? From fbrockne@cisco.com Mon Sep 6 06:03:04 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E16C3A6926 for ; Mon, 6 Sep 2010 06:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zm5zvqoCImFH for ; Mon, 6 Sep 2010 06:03:03 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 1F8953A67FF for ; Mon, 6 Sep 2010 06:03:03 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJ6DhEyrR7H+/2dsb2JhbAChEnGgXJpahT0EjRY X-IronPort-AV: E=Sophos;i="4.56,325,1280707200"; d="scan'208";a="250374040" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 06 Sep 2010 13:03:31 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o86D3PXf019240; Mon, 6 Sep 2010 13:03:31 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Sep 2010 15:03:28 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Sep 2010 15:03:26 +0200 Message-ID: <0D212BD466921646B58854FB79092CEC02E37774@XMB-AMS-106.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: on the use of Diameter commands (was WGLC comments of draft-ietf-dime-nat-control-03) Thread-Index: ActNvBSPWSxVW/48QumkODADJU0BAAABHvWg From: "Frank Brockners (fbrockne)" To: "jouni korhonen" X-OriginalArrivalTime: 06 Sep 2010 13:03:28.0815 (UTC) FILETIME=[E64FEBF0:01CB4DC3] Cc: dime@ietf.org Subject: [Dime] on the use of Diameter commands (was WGLC comments of draft-ietf-dime-nat-control-03) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 06 Sep 2010 13:03:04 -0000 Hi Jouni, all, Thanks for your detailed review of draft-ietf-dime-nat-control-03. Apart from the immediate issue mentioned, it brings up a wider question on how we use of commands. Wrt/ the specific issue: NCR w/ TERMINATE-REQUEST equals STR; and (I agree) should be replaced; this would be inline with the guidelines in dime-app-design-guide and 3588bis. The reason why the glitch happened and the document did not reuse STR right away, was because we somewhat followed the "TISPAN" or "3GPP" logic, i.e. incorporating several behaviors into a single command, which points to the more general discussion: In TISPAN or 3GPP one sometimes only defines a single command and overloads this command with different behaviors based on the value of a parameter/AVP (e.g. Gq' with the "Specific-Action AVP"). With this approach all the behaviors for an application are thus contained under a single "umbrella command" - specific to this application. This results in a smaller set of commands with a bit of a "hierarchical" structure - which some folks see as more readable - but also means that you have to provide differentiation below the command level if you implement the state machine. TISPAN and 3GPP also do not following this logic in all cases (largely because of command reuse), so one always ends up in some middle ground. IETF usually takes a cleaner approach, avoiding overloading of commands, but defining distinct commands per required atomic operation.=20 So what we could do for the draft is to (a) reuse existing commands as much as possible (i.e. reuse STR/STA), which after your comments is a no-brainer and (b) evolve to specifying individual commands for each operation, rather than overloading NCR/NCA (the change is really straight forward from a technical point of view). If we'd (as the working group) decide to evolve the document along the lines of (b) - avoiding the overloading of commands, the general recommendation about atomic commands could also be a good addition to the dime-app-design-guide ID - providing guidance for future cases... Appreciate your thoughts. Thanks and regards, Frank > Ticket #10: http://trac.tools.ietf.org/wg/dime/trac/ticket/10 > > During my WGLC review of draft-ietf-dime-nat-control-03 the reuse of > NCR/NCA commands for almost everything looked strange. Why NCR/NCA > during TERMINATE_REQUEST is not reusing RFC3588 STR/STA? >=20 > If there is no compelling reason of not reusing STR/STA, I would use > commands what we have in RFC3588... as the document already makes an > attempt to reuse ASR/ASA and ACR/ACA. From lionel.morand@orange-ftgroup.com Wed Sep 8 01:24:50 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9E333A681D for ; Wed, 8 Sep 2010 01:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.036 X-Spam-Level: X-Spam-Status: No, score=-102.036 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uI-GW28eIFtd for ; Wed, 8 Sep 2010 01:24:49 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id BCEED3A67E2 for ; Wed, 8 Sep 2010 01:24:49 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3E7D2FC4038 for ; Wed, 8 Sep 2010 10:20:34 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 7FE7DFC4032 for ; Wed, 8 Sep 2010 10:20:07 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Sep 2010 10:20:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Sep 2010 10:20:00 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Important Dates for IETF 79 Thread-Index: ActOmP4xp7nnphw3TWO1o4ScP7FV9wAlWajQ From: To: X-OriginalArrivalTime: 08 Sep 2010 08:20:00.0799 (UTC) FILETIME=[A19222F0:01CB4F2E] Subject: [Dime] Important Dates for IETF 79 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 08 Sep 2010 08:24:50 -0000 FYI Lionel & Jouni ----------------- Important dates for the Beijing IETF:=20 2010-09-13 (Monday): Cutoff date for BOF proposal requests to Area Directors at 17:00 PT (24:00 UTC). To request a BOF, please see instructions on Requesting a BOF.=20 2010-09-27 (Monday): Cutoff date for requests to schedule Working Group meetings at 17:00 PT (24:00 UTC). To request a Working Group session, use the IETF Meeting Session Request Tool.=20 2010-09-27 (Monday): Cutoff date for Area Directors to approve BOFs at 17:00 PT (24:00 UTC).=20 2010-10-06 (Wednesday): Preliminary agenda published for comment.=20 2010-10-11 (Monday): Cutoff date for requests to reschedule Working Group and BOF meetings 17:00 PT (24:00 UTC).=20 2010-10-11 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by 17:00 PT (24:00 UTC).=20 2010-10-15 (Friday): Final agenda to be published.=20 2010-10-18 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (24:00 UTC), upload using IETF ID Submission Tool.=20 2010-10-25 (Monday): Internet Draft final submission cut-off by 17:00 PT (24:00 UTC), upload using IETF ID Submission Tool.=20 2010-10-27 (Wednesday): Draft Working Group agendas due by 17:00 PT (24:00 UTC), upload using IETF Meeting Materials Management Tool.=20 2010-11-01 (Monday): Revised Working Group agendas due by 17:00 PT (01:00 Tuesday, November 02 UTC), upload using IETF Meeting Materials Management Tool.=20 Note that the first two cutoff dates (BOF requests, WG meetings scheduling) are very close.=20 From lionel.morand@orange-ftgroup.com Thu Sep 9 11:02:40 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 904C23A6823 for ; Thu, 9 Sep 2010 11:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.885 X-Spam-Level: X-Spam-Status: No, score=-102.885 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cl0uy7EhalKa for ; Thu, 9 Sep 2010 11:02:39 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 4237D3A680C for ; Thu, 9 Sep 2010 11:02:39 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 492C779800D for ; Thu, 9 Sep 2010 20:05:32 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 62F70778001 for ; Thu, 9 Sep 2010 20:05:13 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Sep 2010 20:01:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Sep 2010 20:01:47 +0200 Message-ID: In-Reply-To: <02286582-8AF6-40F9-8444-A8FCBEA1E401@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] I-D Action:draft-ietf-dime-extended-naptr-02.txt Thread-Index: ActKwDQv8nP/mq4dQNuGjHwxszjBXgFhs0XQ References: <20100902143001.9B2AE3A6A4E@core3.amsl.com> <02286582-8AF6-40F9-8444-A8FCBEA1E401@gmail.com> From: To: X-OriginalArrivalTime: 09 Sep 2010 18:01:48.0921 (UTC) FILETIME=[12D89690:01CB5049] Subject: Re: [Dime] I-D Action:draft-ietf-dime-extended-naptr-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 09 Sep 2010 18:02:40 -0000 Based on the last version, I also think that the draft is ready for a = WGLC. The problem statement is clear and the proposed solution stable enough. It would be helpful to have commited reviewers of the draft (apart from = the authors) for the WGLC. Any volunteer? Lionel > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De=20 > la part de Jouni > Envoy=E9 : jeudi 2 septembre 2010 18:58 > =C0 : dime@ietf.org > Objet : Re: [Dime] I-D Action:draft-ietf-dime-extended-naptr-02.txt >=20 > Hi, >=20 > >=20 > The latest draft revision addresses the comments raised=20 > against it. Apart from the informative addition the draft has=20 > been technically stable for quite some time. The authors=20 > (including me) think that the draft is ready for a WGLC. The=20 > start of the WGLC will be announced soon. >=20 > - Jouni >=20 >=20 >=20 > On Sep 2, 2010, at 5:35 PM, Mark Jones wrote: >=20 > > The changes in this revision are: > >=20 > > - Added usage guidelines as requested at IETF#78. > > - Updated ref to Diameter QoS Application RFC (5866). > >=20 > > Comments welcome. > >=20 > > Regards > > Mark > >=20 > > On Thu, Sep 2, 2010 at 10:30 AM, wrote: > >> A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > >> This draft is a work item of the Diameter Maintenance and=20 > Extensions Working Group of the IETF. > >>=20 > >>=20 > >> Title : Diameter Extended NAPTR > >> Author(s) : M. Jones, J. Korhonen > >> Filename : draft-ietf-dime-extended-naptr-02.txt > >> Pages : 10 > >> Date : 2010-09-02 > >>=20 > >> This document describes an extended format for the S-NAPTR=20 > >> Application Service Tag used in dynamic Diameter agent discovery. > >> The extended format allows NAPTR queries to contain Diameter=20 > >> Application-Id information. > >>=20 > >> A URL for this Internet-Draft is: > >>=20 > http://www.ietf.org/internet-drafts/draft-ietf-dime-extended-naptr-02 > >> .txt > >>=20 > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >>=20 > >> Below is the data which will enable a MIME compliant mail reader=20 > >> implementation to automatically retrieve the ASCII version of the=20 > >> Internet-Draft. > >>=20 > >>=20 > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www.ietf.org/mailman/listinfo/dime > >>=20 > >>=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 From jouni.nospam@gmail.com Fri Sep 17 00:06:33 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AD8C3A6AAF for ; Fri, 17 Sep 2010 00:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlFU6l8LZ4sm for ; Fri, 17 Sep 2010 00:06:31 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 95E5F3A68AB for ; Fri, 17 Sep 2010 00:06:31 -0700 (PDT) Received: by bwz9 with SMTP id 9so3233911bwz.31 for ; Fri, 17 Sep 2010 00:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=MTDgstTbVsouqicgJ5kCFvjs5V8XawPgtesLgB1jTl8=; b=L2l/25hQY3dX0ts5rHoT3v2Gov3/EvDD6nqW/g3xQV157SVpqPVN6wK1xHcveoPhC2 ZdOwK3wo8cmLdiPVNjsfJsNdch7gz/1jgG0PAnEn2Jzl4H5e4WsREdSC1T5gFTJZdGp5 gTM3NFkjyM3I/NoKYT636Q+vCFvq99eRAtq7s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=NLfuP7gg5S1G8YULFQ/dVTRr3BolQOa/PRrhGYiSANoeoj2IqFfwiH/L14S5lWb49/ KGPenPF+vsoaz+N6JL3fL1fGS9NIRR+9prD2HyFYLnsOu3Uq/biJBz42j5MW6m/GxXE7 yzfxh+Rn7cPbmQ320eHqesd1Rs2+R4yyt7Etk= Received: by 10.204.84.230 with SMTP id k38mr3423924bkl.160.1284707215643; Fri, 17 Sep 2010 00:06:55 -0700 (PDT) Received: from a88-112-140-227.elisa-laajakaista.fi (a88-112-140-227.elisa-laajakaista.fi [88.112.140.227]) by mx.google.com with ESMTPS id 24sm3305247bkr.19.2010.09.17.00.06.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 17 Sep 2010 00:06:54 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Sep 2010 10:07:03 +0300 Message-Id: <634EC378-DF1A-4E5D-BED2-C3CBB8C3987A@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [Dime] Fwd: NomCom 2010-2011: Call for More Nominations X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 17 Sep 2010 07:06:33 -0000 FYI ---------- Forwarded message ---------- From: NomCom Chair Date: Thu, Sep 16, 2010 at 6:26 PM Subject: NomCom 2010-2011: Call for More Nominations To: IETF Announcement list Hi Folks, Nominations have slowed down dramatically, so this update is to enlist the community in an effort to pick up the pace. We are very far behind in nominations for all the open positions but in particular we need nominations for the IESG and IAOC open positions. There have been no nominations received (other than for the incumbents) in INT, RAI, and RTG, and only 1 for OPS. Likewise, in IAOC there have been no nominations submitted other than the incumbent. The acceptance rates of those nominated has also been very slow. In order to initiate the open list of willing nominees we are in need of a reasonable number of acceptances, and due to the low number of nominees and acceptances have delayed the start date for publishing the first open list to September 20. So if you have been nominated and are willing to serve, but have not yet confirmed this by email back to the NomCom, please do so as soon as possible. We need Community input and participation! We cannot properly execute the task of selecting the best candidates for these positions with so few nominations and acceptances. So, please consider making nominations for the open positions, in particular those for which we have so few nominations =96 it takes just a few minutes of your time. Right now, we just need the names/email addresses. Why do we need more nominations? Well, even if you think a willing incumbent is doing a very good job and should be returned, his or her ability to serve again might be impacted by unforeseen circumstances between now and March. NomCom needs to consider multiple nominees to be prepared in the event one or more candidates is unable to serve come = next March and to ensure we have chosen the best candidate. There are several ways you can help the IETF Nominating Committee. - You may nominate yourself. - You can nominate someone you know whom you think would do a good job. Do not worry about whether they might already be nominated. We would much prefer to receive the same nomination several times rather than miss a good person we should consider. How to submit Nominations: -------------------------- The list of positions we need to fill, and the provided Job Descriptions, and forms for nominations, can be found in the call for nominations at: https://datatracker.ietf.org/ann/nomcom/2468/ You may enter a nomination by going to the following URL https://wiki.tools.ietf.org/group/nomcom/10/nominate You may also nominate someone by sending an email to nomcom10@ietf.org and giving us their name, email address and the open position you are nominating them for. We will take care of the rest. If you are asked for a user name and password, use an existing ietf = login and password. If you need a login and password, request one from the = tools page at the following URL http://trac.tools.ietf.org/newlogin Open List: ---------- As you already know, NomCom 2010-2011 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. Feedback Collection: -------------------- Once the open list is available, the entire community will be invited to provide feedback. I will send a further announcement requesting feedback on the nominees, describing how to submit feedback, and how to view the open list of nominees. Thank you, Thomas Walsh Chair, NomCom 2010-2011 nomcom-chair@ietf.org twalsh@juniper.net From dromasca@avaya.com Mon Sep 20 04:41:53 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AFD53A6936 for ; Mon, 20 Sep 2010 04:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoNnO8TI4cXo for ; Mon, 20 Sep 2010 04:41:51 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 88D163A6A92 for ; Mon, 20 Sep 2010 04:41:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,392,1280721600"; d="scan'208";a="35402986" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 20 Sep 2010 07:41:57 -0400 X-IronPort-AV: E=Sophos;i="4.56,392,1280721600"; d="scan'208";a="517973139" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 20 Sep 2010 07:41:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Sep 2010 13:41:49 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-dime-capablities-update-05 Thread-Index: ActYuNAHgWq9++BEQ7un4Mb4eDI9Wg== From: "Romascanu, Dan (Dan)" To: , "Glen Zorn" Cc: dime@ietf.org Subject: [Dime] AD review of draft-ietf-dime-capablities-update-05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 20 Sep 2010 11:41:53 -0000 Please find below the AD review of draft-ietf-dime-capablities-update-05. This document is ready for IETF Last Call, and I will initiate the Last Call soon. Please consider the comments below together with other comments that may be received during the IETF LC. The comments are divided into Technical (T) and Editorial (E).=20 T1. While some parts of the specification are aligned with [I-D.ietf-dime-rfc3588bis] (for example section 5 - Security Considerations), other refer to 3588 (Section 6 - IANA Considerations). We need consistency on this respect, and my suggestion is to align the document with [I-D.ietf-dime-rfc3588bis] as we do have a normative dependency on it anyway.=20 T2. What happens if the receiver of a CUR does not return a Capabilities-Update-Answer (CUA)? Is there any timeout or retransmission strategy in place? E1. I find this sentence at the end of the first paragraph in Section 4 to be imprecise:=20 > This message allows the update of a peer's capabilities (supported Diameter applications, etc.). What belongs to etc. must be defined clearly. Actually at this point there is need to define precisely what capabilities are covered by the message, and if there is a way to extend this list in the future.=20 E2. Expand acronyms at first occurrence: AVP, SCTP Regards, Dan From iesg-secretary@ietf.org Mon Sep 20 07:01:15 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EDAF3A6A67; Mon, 20 Sep 2010 07:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29JGWMyLjiqT; Mon, 20 Sep 2010 07:01:14 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C6703A6A63; Mon, 20 Sep 2010 07:01:14 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no Message-ID: <20100920140114.32211.48351.idtracker@localhost> Date: Mon, 20 Sep 2010 07:01:14 -0700 Cc: dime@ietf.org Subject: [Dime] Last Call: draft-ietf-dime-capablities-update (The Diameter Capabilities Update Application) to Proposed Standard X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 20 Sep 2010 14:01:15 -0000 The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'The Diameter Capabilities Update Application ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-10-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dime-capablities-update-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18954&rfc_flag=0 No IPR declarations were found that appear related to this I-D. From jouni.nospam@gmail.com Mon Sep 20 07:54:10 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 460C53A69C0 for ; Mon, 20 Sep 2010 07:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohWx+d3FF8dy for ; Mon, 20 Sep 2010 07:54:09 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id E6EB53A692B for ; Mon, 20 Sep 2010 07:54:08 -0700 (PDT) Received: by bwz9 with SMTP id 9so6047442bwz.31 for ; Mon, 20 Sep 2010 07:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=X+dsiyYrO6NQmRAQivAwgFSTlZEZZjw6LgFh8kNjK6Q=; b=iAu3gUXyhl4N2eVywgcDV5ZGKycnoAkU8w75nzeaLxNenDHPHhMk3akdYUcmSZJExs p0uz4iHoLd+51uzdjR8OsVZP3qn3JXDoesOeCqRvSdLeid21dcqqOVOJsGEbpFsQimDt /UPBXg3Zc5pn/Q1KWMM+89BLaEa57WoiCi8Hk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=F3pnVhgOjTBzXt5lEgIU09vHxiWycKxDBtIWF+qrM003+ux51pOcRQ5RF6HOu8M92u VWC7Ak8QGn8WLqs+a0POSm2OSbaf7Z8LsTuwy7jw/He3jY3EfoMh2JwZvpu3yqC+j+YQ UACgmnB5S0QSKaWWz5XxPuzrUXy3xpxSaN3LI= Received: by 10.204.118.202 with SMTP id w10mr6784120bkq.40.1284994471766; Mon, 20 Sep 2010 07:54:31 -0700 (PDT) Received: from a88-114-71-118.elisa-laajakaista.fi (a88-114-71-118.elisa-laajakaista.fi [88.114.71.118]) by mx.google.com with ESMTPS id d27sm6567374bku.10.2010.09.20.07.54.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 20 Sep 2010 07:54:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <0D212BD466921646B58854FB79092CEC02E37772@XMB-AMS-106.cisco.com> Date: Mon, 20 Sep 2010 17:54:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D212BD466921646B58854FB79092CEC02E37772@XMB-AMS-106.cisco.com> To: Frank Brockners (fbrockne) X-Mailer: Apple Mail (2.1078) Cc: dime@ietf.org Subject: Re: [Dime] Auth-Session-State (WGLC comments of draft-ietf-dime-nat-control-03) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 20 Sep 2010 14:54:10 -0000 Hi Frank, Sorry for the delay (actually the email filter put the mail into wrong = folder using some unknown logic). On Sep 6, 2010, at 4:03 PM, Frank Brockners (fbrockne) wrote: > Hi Jouni, >=20 > Thanks for your detailed review of draft-ietf-dime-nat-control-03.=20 >=20 > Wrt/ your comment on the use of " Auth-Session-State AVP", I agree = that > the use of this AVP is redundant and not really useful, because I'll > have the default value in all cases, given that in DNCA both manager = and > agent are stateful. In order to avoid confusion, I'd follow your > implicit suggestion to remove the AVP - and - more importantly add > additional details on how state is maintained. Ok good. >=20 > Simply referring back to RFC 3588 for a description of state machines > unfortunately does not work here. Per our earlier discussions in the > working group, the nomenclature of "server" and "client" does not = really > apply to the DNCA use case, hence the use of "manager" and "agent" for > the two involved Diameter entities.=20 >=20 > My suggestion would be that we add another section which show state > machines at agent and manager in detail (obviously reusing the format = in > RFC 3588). Would that be an agreeable way forward? That would be good. Please, propose some text and if that is a separate = section we could check it before shipping a new revision of the = document. - Jouni >=20 >=20 > Thanks & regards, Frank >=20 >=20 >> Ticket #9: http://trac.tools.ietf.org/wg/dime/trac/ticket/9 >>=20 >> During the WGLC review of draft-ietf-dime-nat-control-03 I started to >> think about the Auth-Session-State AVP and the associated semantics. >> The draft should state, even if it seems obvious, whether the state = is >> maintained or not. And whether it applies to all possible messages >> exchanges. Can Auth-Session-State be on NCA or in NCR during >> QUERY_REQUEST? >>=20 >> How well the DNCA "view" of the session state goes along with RFC3588 >> authz session state machine? From jouni.nospam@gmail.com Mon Sep 20 08:04:13 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 390D53A6A8A for ; Mon, 20 Sep 2010 08:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b10VurGiJtHS for ; Mon, 20 Sep 2010 08:04:12 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id E7BAB3A6925 for ; Mon, 20 Sep 2010 08:04:11 -0700 (PDT) Received: by bwz9 with SMTP id 9so6058969bwz.31 for ; Mon, 20 Sep 2010 08:04:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=139koqb2h02X/ahBlxvG1ca1uM3zwX/gxPvua/sPoAA=; b=gj9je/o/RlEZbcbNWXnj07ZRQfb1R/i1D0NW2FP0Z89EhW9jEoOSULproIwafmtsoc GKvvhLEVYsnhDzcqhQwOzYXD8CTPY35jtAj5rSr0jo/dVX/jGXXHTrutQg4NEVjjR+tF dtrjY+rk/yuEMTV3L90vTufH+E/OVHFpDASsY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=PSXLEFgNxHj+IKC1CdTXLgrP8hUoOovdgce7nQxhsSvZKUz9HERaA+b5bnXVOfI0c8 rwLompaBoJzqcWXzm3e6sQbrKa0EwkOndlggVNP+a5GtAFwb5s4P3q6E/08i9z/y15Ww FvsEv4S7sVo615OHGLfAH2L3WUwEcqP21njUg= Received: by 10.204.119.80 with SMTP id y16mr6776414bkq.113.1284995074924; Mon, 20 Sep 2010 08:04:34 -0700 (PDT) Received: from a88-114-71-118.elisa-laajakaista.fi (a88-114-71-118.elisa-laajakaista.fi [88.114.71.118]) by mx.google.com with ESMTPS id g12sm6583041bkb.2.2010.09.20.08.04.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 20 Sep 2010 08:04:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <0D212BD466921646B58854FB79092CEC02E37774@XMB-AMS-106.cisco.com> Date: Mon, 20 Sep 2010 18:04:47 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D212BD466921646B58854FB79092CEC02E37774@XMB-AMS-106.cisco.com> To: Frank Brockners (fbrockne) X-Mailer: Apple Mail (2.1078) Cc: dime@ietf.org Subject: Re: [Dime] on the use of Diameter commands (was WGLC comments of draft-ietf-dime-nat-control-03) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 20 Sep 2010 15:04:13 -0000 Hi Frank, Sorry for the delay (same excuse as earlier..) On Sep 6, 2010, at 4:03 PM, Frank Brockners (fbrockne) wrote: > Hi Jouni, all, >=20 > Thanks for your detailed review of draft-ietf-dime-nat-control-03. = Apart > from the immediate issue mentioned, it brings up a wider question on = how > we use of commands. >=20 > Wrt/ the specific issue: NCR w/ TERMINATE-REQUEST equals STR; and (I > agree) should be replaced; this would be inline with the guidelines in > dime-app-design-guide and 3588bis. The reason why the glitch happened > and the document did not reuse STR right away, was because we somewhat > followed the "TISPAN" or "3GPP" logic, i.e. incorporating several > behaviors into a single command, which points to the more general > discussion: Right. I would not take e.g. 3GPP as an example how to design Diameter = applications ;) >=20 > In TISPAN or 3GPP one sometimes only defines a single command and > overloads this command with different behaviors based on the value of = a > parameter/AVP (e.g. Gq' with the "Specific-Action AVP"). With this > approach all the behaviors for an application are thus contained under = a > single "umbrella command" - specific to this application. This results > in a smaller set of commands with a bit of a "hierarchical" structure = - > which some folks see as more readable - but also means that you have = to > provide differentiation below the command level if you implement the > state machine. > TISPAN and 3GPP also do not following this logic in all cases (largely > because of command reuse), so one always ends up in some middle = ground. > IETF usually takes a cleaner approach, avoiding overloading of = commands, > but defining distinct commands per required atomic operation.=20 I would say that if you bring a document to IETF, although its primary = use case/deployment would clearly be in other SDO architectures, then = better do it in IETF way. > So what we could do for the draft is to (a) reuse existing commands as > much as possible (i.e. reuse STR/STA), which after your comments is a > no-brainer and (b) evolve to specifying individual commands for each > operation, rather than overloading NCR/NCA (the change is really > straight forward from a technical point of view). >=20 > If we'd (as the working group) decide to evolve the document along the > lines of (b) - avoiding the overloading of commands, the general > recommendation about atomic commands could also be a good addition to > the dime-app-design-guide ID - providing guidance for future cases... I recommend going for (a). ASR/ASA and ACR/ACA are already reused, and = for session termination STR/STA would follow that path. I did not see = anything on this particular case what would require a new command for = "STR/STA purposes". If there is something that we cannot just achieve = using STR/STA and its current ABNF, then I think a new command can be = justified. - Jouni >=20 >=20 > Appreciate your thoughts. >=20 > Thanks and regards, Frank >=20 >=20 >> Ticket #10: http://trac.tools.ietf.org/wg/dime/trac/ticket/10 >>=20 >> During my WGLC review of draft-ietf-dime-nat-control-03 the reuse of >> NCR/NCA commands for almost everything looked strange. Why NCR/NCA >> during TERMINATE_REQUEST is not reusing RFC3588 STR/STA? >>=20 >> If there is no compelling reason of not reusing STR/STA, I would use >> commands what we have in RFC3588... as the document already makes an >> attempt to reuse ASR/ASA and ACR/ACA. From gwz@net-zen.net Mon Sep 20 09:06:37 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 378583A6AA6 for ; Mon, 20 Sep 2010 09:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.068 X-Spam-Level: X-Spam-Status: No, score=-102.068 tagged_above=-999 required=5 tests=[AWL=0.531, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5+GIfTH+6DD for ; Mon, 20 Sep 2010 09:06:36 -0700 (PDT) Received: from smtpauth05.prod.mesa1.secureserver.net (smtpauth05.prod.mesa1.secureserver.net [64.202.165.99]) by core3.amsl.com (Postfix) with SMTP id 9928C3A6AA1 for ; Mon, 20 Sep 2010 09:05:59 -0700 (PDT) Received: (qmail 25775 invoked from network); 20 Sep 2010 16:06:22 -0000 Received: from unknown (110.164.147.7) by smtpauth05.prod.mesa1.secureserver.net (64.202.165.99) with ESMTP; 20 Sep 2010 16:06:19 -0000 From: "Glen Zorn" To: "'Romascanu, Dan \(Dan\)'" References: In-Reply-To: Date: Mon, 20 Sep 2010 23:05:52 +0700 Organization: Network Zen Message-ID: <000001cb58dd$b6f53110$24df9330$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActYuNAHgWq9++BEQ7un4Mb4eDI9WgAAygEg Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] AD review of draft-ietf-dime-capablities-update-05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 20 Sep 2010 16:06:37 -0000 Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] writes: > Please find below the AD review of > draft-ietf-dime-capablities-update-05. This document is ready for IETF > Last Call, and I will initiate the Last Call soon. Please consider the > comments below together with other comments that may be received during > the IETF LC. The comments are divided into Technical (T) and Editorial > (E). > > T1. While some parts of the specification are aligned with > [I-D.ietf-dime-rfc3588bis] (for example section 5 - Security > Considerations), other refer to 3588 (Section 6 - IANA Considerations). > We need consistency on this respect, and my suggestion is to align the > document with [I-D.ietf-dime-rfc3588bis] as we do have a normative > dependency on it anyway. OK. > > T2. What happens if the receiver of a CUR does not return a > Capabilities-Update-Answer (CUA)? Is there any timeout or retransmission > strategy in place? Um, TCP? I guess that I don't understand the question. > > > E1. I find this sentence at the end of the first paragraph in Section 4 > to be imprecise: > > > This message allows the > update of a peer's capabilities (supported Diameter applications, > etc.). > > What belongs to etc. must be defined clearly. Actually at this point > there is need to define precisely what capabilities are covered by the > message, and if there is a way to extend this list in the future. Unfortunately, I'm not sure that such a list exists (or has ever existed ), even for the CER/CEA command pair; certainly, neither RFC 3588 nor 3588bis include one. Both say When two Diameter peers establish a transport connection, they MUST exchange the Capabilities Exchange messages, as specified in the peer state machine (see Section 5.6). This message allows the discovery of a peer's identity and its capabilities (protocol version number, supported Diameter applications, security mechanisms, etc.) The CUR/CEA messages only contain a subset of the capabilities advertised via the CER/CEA mechanism, so if it's really necessary to list them maybe the first thing to do is create the master list in 3588bis. > > E2. Expand acronyms at first occurrence: AVP, SCTP OK. > > Regards, > > Dan From dromasca@avaya.com Tue Sep 21 06:15:47 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A52C3A6A1F for ; Tue, 21 Sep 2010 06:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEX+7REQGvPx for ; Tue, 21 Sep 2010 06:15:41 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 9DF1D3A691F for ; Tue, 21 Sep 2010 06:15:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,399,1280721600"; d="scan'208";a="35601212" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 21 Sep 2010 09:16:05 -0400 X-IronPort-AV: E=Sophos;i="4.56,399,1280721600"; d="scan'208";a="513841794" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 21 Sep 2010 09:15:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Sep 2010 15:15:28 +0200 Message-ID: In-Reply-To: <000001cb58dd$b6f53110$24df9330$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-dime-capablities-update-05 Thread-Index: ActYuNAHgWq9++BEQ7un4Mb4eDI9WgAAygEgADSdkVA= References: <000001cb58dd$b6f53110$24df9330$@net> From: "Romascanu, Dan (Dan)" To: "Glen Zorn" Cc: dime@ietf.org Subject: Re: [Dime] AD review of draft-ietf-dime-capablities-update-05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 21 Sep 2010 13:15:47 -0000 Thanks for the answer. See in-line. OK parts deleted.=20 Regards, Dan > -----Original Message----- > From: Glen Zorn [mailto:gwz@net-zen.net]=20 > Sent: Monday, September 20, 2010 6:06 PM > To: Romascanu, Dan (Dan) > Cc: dime@ietf.org; kangjiao@huawei.com > Subject: RE: AD review of draft-ietf-dime-capablities-update-05 >=20 > Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] writes: >=20 ... >=20 > >=20 > > T2. What happens if the receiver of a CUR does not return a=20 > > Capabilities-Update-Answer (CUA)? Is there any timeout or=20 > > retransmission strategy in place? >=20 > Um, TCP? I guess that I don't understand the question. So the answer is that there is no mechanism for timeout / retransmission at the application layer.=20 > =20 > >=20 > >=20 > > E1. I find this sentence at the end of the first paragraph=20 > in Section=20 > > 4 to be imprecise: > >=20 > > > This message allows the > > update of a peer's capabilities (supported Diameter applications, > > etc.). > >=20 > > What belongs to etc. must be defined clearly. Actually at=20 > this point=20 > > there is need to define precisely what capabilities are=20 > covered by the=20 > > message, and if there is a way to extend this list in the future. >=20 > Unfortunately, I'm not sure that such a list exists (or has=20 > ever existed ), even for the CER/CEA command pair; certainly,=20 > neither RFC 3588 nor 3588bis include one. Both say=20 >=20 > When two Diameter peers establish a transport connection, they MUST > exchange the Capabilities Exchange messages, as specified=20 > in the peer > state machine (see Section 5.6). This message allows the discovery > of a peer's identity and its capabilities (protocol version number, > supported Diameter applications, security mechanisms, etc.) >=20 > The CUR/CEA messages only contain a subset of the=20 > capabilities advertised via the CER/CEA mechanism, so if it's=20 > really necessary to list them maybe the first thing to do is=20 > create the master list in 3588bis. >=20 Other opinions? What did people implement?=20 ... From gwz@net-zen.net Tue Sep 21 08:35:41 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 443473A6A4F for ; Tue, 21 Sep 2010 08:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.096 X-Spam-Level: X-Spam-Status: No, score=-102.096 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMS3lQ+p0TMi for ; Tue, 21 Sep 2010 08:35:39 -0700 (PDT) Received: from smtpout08.prod.mesa1.secureserver.net (smtpout08-01.prod.mesa1.secureserver.net [64.202.165.119]) by core3.amsl.com (Postfix) with SMTP id 8DB983A6A3F for ; Tue, 21 Sep 2010 08:35:39 -0700 (PDT) Received: (qmail 29082 invoked from network); 21 Sep 2010 15:36:02 -0000 Received: from unknown (110.164.147.175) by smtpout08.prod.mesa1.secureserver.net (64.202.165.119) with ESMTP; 21 Sep 2010 15:36:01 -0000 From: "Glen Zorn" To: "'Romascanu, Dan \(Dan\)'" References: <000001cb58dd$b6f53110$24df9330$@net> In-Reply-To: Date: Tue, 21 Sep 2010 22:35:28 +0700 Organization: Network Zen Message-ID: <000f01cb59a2$a28377d0$e78a6770$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActYuNAHgWq9++BEQ7un4Mb4eDI9WgAAygEgADSdkVAABP7k0A== Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] AD review of draft-ietf-dime-capablities-update-05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 21 Sep 2010 15:35:41 -0000 Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] writes: > > > T2. What happens if the receiver of a CUR does not return a > > > Capabilities-Update-Answer (CUA)? Is there any timeout or > > > retransmission strategy in place? > > > > Um, TCP? I guess that I don't understand the question. > > So the answer is that there is no mechanism for timeout / retransmission > at the application layer. I guess so. ... From jouni.nospam@gmail.com Wed Sep 22 11:47:37 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBCCF3A6A80 for ; Wed, 22 Sep 2010 11:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4bfPL-PxBMR for ; Wed, 22 Sep 2010 11:47:36 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id B06C13A6974 for ; Wed, 22 Sep 2010 11:47:35 -0700 (PDT) Received: by bwz9 with SMTP id 9so940341bwz.31 for ; Wed, 22 Sep 2010 11:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:cc:to :mime-version:x-mailer; bh=hO+SNzgg3LiW4CzdNpQKTs25HOKWvDRT4gt9kHc3SdU=; b=pSqv8ytcO/aKQ2Mv6KOiQ1+foOgyC71iz5UFXco2yhQBRcPU9ZR4d7KGUbZdYWUjGF L+0yCHyFs7iji2wRDV2OZMk2LxlnVVejZhwxsiyiyqHqdo5/GiBl/SgpgCqGhplLP3c9 v5TSMHpi5pwN/S5Jg2LYOlKidqIRP22Lb4tPs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=gqZnNC4ON5xdiHsRQ2Nh0NuskW2TlyAs06ck9kIywksDzh/3zInE0Nn4aC7dCON/Xb EfkS7WciA6M3z2RGZXTe3hBC/zka4E6ouvZ1gUw+AtXfgXqE3FMP7Hzy8MljID0ApiX0 nVu9wykRHAp+uQ0tXTJN71y+a49nXEMbBA75o= Received: by 10.204.2.140 with SMTP id 12mr315982bkj.100.1285181282653; Wed, 22 Sep 2010 11:48:02 -0700 (PDT) Received: from a83-245-210-64.elisa-laajakaista.fi (a83-245-210-64.elisa-laajakaista.fi [83.245.210.64]) by mx.google.com with ESMTPS id 11sm8959472bkj.23.2010.09.22.11.48.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 22 Sep 2010 11:48:01 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Sep 2010 21:48:12 +0300 Message-Id: <882A7B81-843B-4EA0-A26B-8456769A8484@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Cc: dime-chairs@tools.ietf.org Subject: [Dime] IETF#79 Dime WG meeting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 22 Sep 2010 18:47:37 -0000 Folks, We have requested a 2h slot for Beijing meeting. Apart from the normal = status update we have not seen too much movement on new topics and such. = We need to spend some online time discussion on documents that have = unresolved issues. Also, we plan reserving good deal of time discussing = and going through RFC4005bis and the design guidelines. Best regards, chairs= From violeta.cakulev@alcatel-lucent.com Wed Sep 22 12:55:48 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EFF33A685B for ; Wed, 22 Sep 2010 12:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUR2LvyGZwF4 for ; Wed, 22 Sep 2010 12:55:46 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 430D23A6ABC for ; Wed, 22 Sep 2010 12:55:45 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o8MJuCPk015025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 Sep 2010 14:56:13 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o8MJuCMs019236 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 22 Sep 2010 14:56:12 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.126]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Wed, 22 Sep 2010 14:56:12 -0500 From: "Cakulev, Violeta (Violeta)" To: "lionel.morand@orange-ftgroup.com" , "dime@ietf.org" Date: Wed, 22 Sep 2010 14:56:11 -0500 Thread-Topic: [dime] #12: Review of draft-ietf-dime-ikev2-psk-diameter-02 Thread-Index: Acs9YooxKq4wX5tRRC+T0JyNnhCMaQBsfJWAAmXEKBAEeP4yMA== Message-ID: References: <074.fd1143ff15296cc8707a663a09a095ab@tools.ietf.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [Dime] [dime] #12: Review of draft-ietf-dime-ikev2-psk-diameter-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 22 Sep 2010 19:55:48 -0000 Lionel, Thanks for the reply. Please see inline (>>VC:) -Violeta -----Original Message----- From: lionel.morand@orange-ftgroup.com [mailto:lionel.morand@orange-ftgroup= .com] Sent: Monday, August 30, 2010 9:33 PM To: Cakulev, Violeta (Violeta); dime@ietf.org Subject: RE: [dime] #12: Review of draft-ietf-dime-ikev2-psk-diameter-02 Hi Violeta, Thank you for having taken into account my comments. About the Auth-Request-AVP, no problem for me to state that AUTHORIZE-ONLY = is the unique value to use. However, this AVP is defined in RFC3588, and is defined with the following = possible values: AUTHENTICATE_ONLY 1 The request being sent is for authentication only, and MUST contain the relevant application specific authentication AVPs that are needed by the Diameter server to authenticate the user. AUTHORIZE_ONLY 2 The request being sent is for authorization only, and MUST contain the application specific authorization AVPs that are necessary to identify the service being requested/offered. AUTHORIZE_AUTHENTICATE 3 What should be the behaviour of the receiver if the Auth-Request-Type AVP i= s set to the value 1 or 3, which are valid values? What is the error code s= end back to the sender? >>VC: I agree 1 and 3 are the valid values in general but not for the appli= cation the document is defining. So we can return DIAMETER_INVALID_AVP_VALU= E and include the Auth-Request-AVP in the Failed-AVP AVP. DIAMETER_UNABLE_TO_COMPLY could also be returned, but in this case the rece= iver will not know why. Regards, Lionel > -----Message d'origine----- > De : Cakulev, Violeta (Violeta) > [mailto:violeta.cakulev@alcatel-lucent.com] > Envoy=E9 : lundi 30 ao=FBt 2010 22:14 > =C0 : dime@ietf.org; MORAND Lionel RD-CORE-ISS Objet : RE: [dime] #12: > Review of > draft-ietf-dime-ikev2-psk-diameter-02 > > > Lionel, > Thanks for the comments. > Please see inline (>>[VC]). > > I'll upload a new version (v3) of the draft shortly. > > -Violeta > > -----Original Message----- > From: dime issue tracker [mailto:trac@tools.ietf.org] > Sent: Monday, August 16, 2010 12:46 PM > To: lionel.morand@orange-ftgroup.com > Cc: dime@ietf.org; Cakulev, Violeta (Violeta) > Subject: [dime] #12: Review of draft-ietf-dime-ikev2-psk-diameter-02 > > #12: Review of draft-ietf-dime-ikev2-psk-diameter-02 > ----------------------------------------------+--------------- > ---------- > ----------------------------------------------+---- > Reporter: lionel.morand@... | Owner: > Type: defect | Status: new > Priority: major | Milestone: > Component: ikev2-psk-diameter | Version: > Severity: In WG Last Call | Keywords: > ----------------------------------------------+--------------- > ---------- > ----------------------------------------------+---- > I have reviewed this draft and is pretty good for publication. > > One remaining open issue from my side: > > 1/Is there any need for Authorize-Type AVP in the request if only > Authorize-Only is used in this application? > >>[VC] Please see my response to Sebastien. In short, today > this value is constrained and probably not necessary, but in future it > may change. In addition, it is better to be explicit. > > Additional comments/proposed modifications below. > > Regards, > > Lionel. > > ****************** > > > > 1. Introduction > > [RFC4306] defines Internet Key Exchange v2 as a protocol that > > =3D=3D> s/[RFC4306] defines Internet Key Exchange v2 as a protocol that/ > [RFC4306] defines the version 2 of the Internet Key Exchange > (IKE) protocol that > >>[VC] Changed. > > performs mutual authentication between two parties and establishes > a > security association (SA) that includes shared secret information > that can be used to efficiently establish SAs for Encapsulating > Security Payload (ESP) [RFC4303] and/or Authentication Header (AH) > [RFC4302], and a set of cryptographic algorithms to be used by the > SAs to protect the traffic that they carry. IKEv2 protocol allows > several different mechanisms for authenticating a IKEv2 Peer to be > used, such as the Extensible Authentication Protocol, > certificates, > and pre-shared secrets. > > From a service provider perspective it is important to ensure that > a > > =3D=3D> s/From a service provider perspective it is/From a service > provider perspective, it is > >>[VC] Changed. > > user is authorized to use the services. Therefore, the > IKEv2 Server > must verify that the IKEv2 Peer is authorized for the requested > services possibly with the assistance of the operator's Diameter > servers. [RFC 5778] defines the home agent as a Diameter client > to > the Diameter server communication when the mobile node > authenticates > using the IKEv2 protocol with the Extensible Authentication > Protocol > or using the Mobile IPv6 Authentication Protocol. This document > > =3D=3D> s/the Extensible Authentication Protocol or using the Mobile IPv= 6 > Authentication Protocol/ > the Extensible Authentication Protocol (EAP) [RFC 3748] or > using the Mobile IPv6 Authentication Protocol [RFC 4285]/ > >>[VC] Changed. > > extends the functionality offered by [RFC 5778] with pre-shared > key > based authentication offered by IKEv2. This document does not > assume > that the IKEv2 Server has the pre-shared secrets (PSK) with the > IKEv2 > Peer. Instead, it allows for PSK to be derived for a specific > IKEv2 > session and exchanged between IKEv2 Server and HAAA. This is > accomplished through the use of a new Diameter application > specifically designed for performing IKEv2 authorization > decisions. > > > [skip] > > > 4. Protocol Description > > 4.1. Support for IKEv2 and Pre-Shared Secrets > > When IKEv2 is used with PSK-based initiator authentication, the > Diameter commands IKEv2-PSK-Request and IKEv2-PSK-Answer defined > in > > =3D=3D> s/the Diameter commands IKEv2-PSK-Request and IKEv2-PSK-Answer > defined/ > the Diameter command pair IKEv2-PSK-Request/Answer defined > >>[VC] Changed. > > this document are used to authorize the IKEv2 Peer for the > services. > > =3D=3D> s/are used to authorize/are used between IKEv2 server and a Home > AAA server (HAAA) to authorize > >>[VC] Changed. > > > Upon receiving the IKE_AUTH message from the IKEv2 Peer, the IKEv2 > Server uses the information received in IDi to determine if it has > the PSK for this IKEv2 Peer. If there is no PSK found associated > with this IKEv2 Peer, the IKEv2 Server MUST send an Authorize-Only > (Auth-Request-Type set to "Authorize-Only") Diameter IKEv2-PSK > message with the IKEv2 Peer's IDi payload to the HAAA to obtain > the > PSK. > > =3D=3D> I think that the initial intention was to re-use RFC5778 and > existing commands. Now, as you're creating new command, why do you > have to re-use Auth-Request-Type AVP as it seems that only > "Authorize-Only" will be used in this application? > If removed from the command, this part will be modified. > >>[VC] Discussed above. > > The IDi payload extracted from the IKE_AUTH message has to > > =3D=3D> s/has to/MUST > >>[VC] Changed. > > contain an identity that is meaningful for the Diameter > infrastructure, such as a Network Access Identifier (NAI), since > it > is used by the IKEv2 Server to populate the User-Name AVP in the > Diameter message. The IKEv2 Server also includes in the > IKEv2-Nonces > AVP of the same Diameter message the initiator and responder > nonces > (Ni and Nr) exchanged during initial IKEv2 exchange. > > This message is routed to the IKEv2 Peer's HAAA. Upon receiving > Diameter IKEv2-PSK-Request message from the IKEv2 Server, the HAAA > SHALL use the User-Name AVP to retrieve the associated keying > material. The HAAA SHALL use the nonces Ni and Nr received in > IKEv2- > Nonces AVP to generate the PSK. It is outside of scope of this > document how the HAAA obtains or generates the PSK. For example, > if > the HAAA previously performed EAP based access authentication and > authorization of the IKEv2 Peer, it can use the available EMSK to > generate the PSK [RFC5295]. The HAAA returns the PSK to the IKEv2 > Server using the Key AVP as specified in > [I-D.ietf-dime-local-keytran]. > > =3D=3D> I would reorder the end of this paragraph and move the "it is > outside of scope..." at the end. It would look like: > > "This message is routed to the IKEv2 Peer's HAAA. Upon receiving > Diameter IKEv2-PSK-Request message from the IKEv2 Server, the HAAA > SHALL use the User-Name AVP to retrieve the associated keying > material. The HAAA SHALL use the nonces Ni and Nr received in > IKEv2- > Nonces AVP to generate the PSK. The HAAA returns the PSK to the > IKEv2 > Server using the Key AVP as specified in > [I-D.ietf-dime-local-keytran]. > > It is outside of scope of this document how the HAAA obtains or > generates the PSK. For example, if the HAAA previously performed > EAP > based access authentication and authorization of the > IKEv2 Peer, it > can use the available EMSK to generate the PSK [RFC5295]." > > >>[VC] Reordered. > > [skip] > > > 4.2.2. AbortSession-Request > > =3D=3D> AbortSession/Abort-Session > >>[VC] Changed. > > The Abort-Session-Request (ASR) message [RFC3588] is sent by the > HAAA > to the IKEv2 Server to terminate the authorized session. When the > IKEv2 Server receives the ASR message, it MUST delete the > corresponding IKE_SA and all CHILD_SAs set up through it. > > The Abort-Session-Answer (ASA) message [RFC3588] is sent by the > IKEv2 > Server in response to an ASR message. > > > [skip] > > > 5.1. IKEv2-PSK-Request (IKEPSKR) Command > > The IKEv2-PSK-Request message, indicated with the Command-Code set > to > TBD2 and the 'R' bit set in the Command Flags field is sent from > the > IKEv2 Server to the HAAA to initiate IKEv2 with PSK authorization. > In this case, the Application-ID field of the Diameter Header MUST > be > set to the Diameter IKE PSK Application ID (value of TDB1). > > Message format > > > ::=3D < Diameter Header: TBD2, REQ, PXY > > < Session-Id > > { Auth-Application-Id } > { Origin-Host } > { Origin-Realm } > { Destination-Realm } > { Auth-Request-Type } > [ Destination-Host ] > [ NAS-Identifier ] > [ NAS-IP-Address ] > [ NAS-IPv6-Address ] > [ NAS-Port ] > [ Origin-State-Id ] > { User-Name } > [ Auth-Session-State ] > { IKEv2-Nonces } > * [ Proxy-Info ] > * [ Route-Record ] > ... > * [ AVP ] > > IKEv2-PSK-Request message MUST include a IKEv2-Nonces AVP > containing > Ni and Nr nonces exchanged during initial IKEv2 exchange. > > =3D=3D> Check if the use of Auth-Request-Type AVp is really needed. If > not, remove it. > >>[VC] Discussed above. > > =3D=3D> Why do we have to insist on the presence of IKEv2-Nonces AVP as > this AVP is described as required in the ABNF? > >>[VC] Makes sense. However, focus was more on the fact that > those are the nonces exchanged between the peer and the server in IKE > messages. I believe it is not wrong to leave the text as it is. > > =3D=3D> In the AVP Occurence table, Key AVP can be found in the request > while this AVP is missing in the ABNF description. > inconsistency must fixed. > Moreover, if Key AVP can be found in the request, add some text to > explain why. > >>[VC] Good catch. Key AVP needs to be an optional AVP in the > request. If present it contains SPI. Some applications might use SPI > values for key identification purposes. Key AVP is added in the ABNF > description. > > [skip] > > > 7. AVP Occurrence Tables > > The following tables present the AVPs defined or used in this > document and their occurrences in Diameter messages. > Note that AVPs > that can only be present within a Grouped AVP are not represented > in > this table. > > The table uses the following symbols: > > 0: > > The AVP MUST NOT be present in the message. > > > 0+: > > Zero or more instances of the AVP MAY be present in the > message. > > > 0-1: > > Zero or one instance of the AVP MAY be present in the message. > > > 1: > > One instance of the AVP MUST be present in the message. > > > > +-------------------+ > | Command-Code | > |---------+---------+ > AVP Name | IKEPSKR | IKEPSKA | > -------------------------------|---------+---------+ > Key | 0-1 | 0-1 | > IKEv2-Nonces | 0-1 | 0 | > +---------+---------+ > > IKEPSKR and IKEPSKA Commands AVP Table > > =3D=3D> Inconsistency! IKEv2-Nonces is described are required in the > Request and the Occurence is then 1. Moreover, the use of Key AVP in > the request is not described, neither in the text nor in the request > ABNF description. > >>[VC] Agreed. Table is changed. > > > [skip] > > 11.2. Informative References > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and > H. > Levkowetz, "Extensible Authentication Protocol (EAP)", > RFC 3748, June 2004. > > [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. > Nakhjiri, > "Specification for the Derivation of Root Keys from an > Extended Master Session Key (EMSK)", RFC 5295, > August 2008. > > > =3D=3D> an informative reference to RFC 4285 should be added (cf. > previous > comment) > >>[VC] Added. > > -- > Ticket URL: > dime > > From hannes.tschofenig@gmx.net Thu Sep 23 08:53:46 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D91DB3A67A3 for ; Thu, 23 Sep 2010 08:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.818 X-Spam-Level: X-Spam-Status: No, score=-100.818 tagged_above=-999 required=5 tests=[AWL=-0.519, BAYES_00=-2.599, MANGLED_WRLDWD=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dv9hJcTYz-bC for ; Thu, 23 Sep 2010 08:53:45 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 5293B3A69D6 for ; Thu, 23 Sep 2010 08:53:45 -0700 (PDT) Received: (qmail invoked by alias); 23 Sep 2010 15:54:14 -0000 Received: from unknown (EHLO [10.254.0.174]) [192.100.123.77] by mail.gmx.net (mp050) with SMTP; 23 Sep 2010 17:54:14 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+6zxcDvQK6p5/xZYddrTadvusrx1lC1e+3QW9sxT 71nlHK3SvU56DA Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1081) From: Hannes Tschofenig Date: Thu, 23 Sep 2010 18:54:11 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2488D747-BF65-45BD-98EE-9D317BF7518D@gmx.net> References: <20100920210002.96EF53A6876@core3.amsl.com> To: radiusext@ops.ietf.org, dime@ietf.org X-Mailer: Apple Mail (2.1081) X-Y-GMX-Trusted: 0 Cc: Hannes Tschofenig Subject: [Dime] Fwd: Internet Privacy Workshop: 8 and 9 December 2010 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 23 Sep 2010 15:53:47 -0000 Privacy has come up in the AAA context and maybe someone of you has a = chance to share their thoughts at this workshop.=20 Begin forwarded message: > From: IETF Secretariat > Date: September 21, 2010 12:00:02 AM GMT+03:00 > To: ietf-announce@ietf.org > Subject: Internet Privacy Workshop: 8 and 9 December 2010=20 >=20 > The Internet Architecture Board (IAB), World Wide Web Consortium = (W3C), > Internet Society (ISOC) and Massachusetts Institute of Technology = (MIT) > will hold a joint Internet privacy workshop on 8 and 9 December 2010 = at > MIT, Cambridge, Massachusetts on the question: >=20 > "How Can Technology Help to Improve Privacy on the Internet?" >=20 > Information about who we are, what we own, what we have experienced, = how > we behave, where we are located, and how we can be reached are among = the > most personal pieces of information about us. This information is > increasingly being made more easily available electronically via the > Internet, often without the consent of the subject. >=20 > The question for the workshop therefore is: How can we ensure that > architectures and technologies for the Internet, including the World > Wide Web, are developed in ways that respects users=82 intentions = about > their privacy? >=20 > This workshop aims to explore the experience and approaches taken by > developers of Internet including Web technology, when designing = privacy > into these protocols and architectures. Engineers know that many = design > considerations need to be taken into account when developing = solutions. > Balancing between the conflicting goals of openness, privacy, = economics, > and security is often difficult, as illustrated by Clark, et al. in > "Tussle in Cyberspace: Defining Tomorrow's Internet", see > http://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle2002.pdf >=20 > As a member of the technical community, we invite you to share your > experiences by participating in this important workshop. Workshop > participants will focus on the core privacy challenges, the approaches > taken to deal with them, and the status of the work in the field. The > objective is to draw a relationship with other application areas and > other privacy work in an effort to discuss how specific approaches can > be generalized. >=20 > Interested parties must submit a brief contribution describing their > work or approach as it relates to the workshop theme. We welcome > visionary ideas for how to tackle Internet privacy problems, as well = as > write-ups of existing concepts, deployed technologies, and > lessons-learned from successful or failed attempts at deploying = privacy > technologies. Contributions are not required to be original in = content. >=20 > Submitters of accepted position papers will be invited to the = workshop. > The workshop will be structured as a series of working sessions, > punctuated by invited speakers, who will present relevant background > information or controversial ideas that will motivate participants to > reach a deeper understanding of the subject. The organizing committee > may ask submitters of particularly topical papers to present their = ideas > and experiences to the workshop. >=20 > We will publish submitted position papers and slides together with a > summary report of the workshop. >=20 > There are no plans for any remote participation in this workshop. >=20 > To be invited to the workshop, please submit position papers to > privacy@iab.org by November, 5th 2010. >=20 > More detailed information about the workshop, including further = details > about the position paper requirements, is available at: > http://www.iab.org/about/workshops/privacy/ >=20 > We look forward to your input, > Bernard Aboba (IAB), Trent Adams (ISOC), Daniel Appelquist (W3C), = Karen > O'Donoghue (ISOC), Jon Peterson (IAB), Thomas Roessler (W3C), Karen > Sollins (MIT), Hannes Tschofenig (IAB) > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From shwethab@cisco.com Fri Sep 24 18:37:18 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0193A6A90 for ; Fri, 24 Sep 2010 18:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-aqIXquYJrb for ; Fri, 24 Sep 2010 18:37:16 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id CAA063A6A13 for ; Fri, 24 Sep 2010 18:37:15 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFbvnEyQ/khM/2dsb2JhbACiRnGqQpwkhUMEhE6IcA X-IronPort-AV: E=Sophos;i="4.57,232,1283731200"; d="scan'208";a="65160913" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 25 Sep 2010 01:37:47 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o8P1bk94002270; Sat, 25 Sep 2010 01:37:47 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 25 Sep 2010 07:07:45 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 25 Sep 2010 07:08:10 +0530 Message-ID: <04BD913C7AD1B84297D26D5614FBE133018B7E1F@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] on the use of Diameter commands (was WGLC comments ofdraft-ietf-dime-nat-control-03) Thread-Index: ActY1Ur4WH5JOqySSmGP1s/UNkuDSwDe++Zw References: <0D212BD466921646B58854FB79092CEC02E37774@XMB-AMS-106.cisco.com> From: "Shwetha Bhandari (shwethab)" To: "jouni korhonen" , "Frank Brockners (fbrockne)" X-OriginalArrivalTime: 25 Sep 2010 01:37:45.0865 (UTC) FILETIME=[410D3790:01CB5C52] Cc: dime@ietf.org Subject: Re: [Dime] on the use of Diameter commands (was WGLC comments ofdraft-ietf-dime-nat-control-03) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Sep 2010 01:37:18 -0000 Hi Jouni, Regarding overloading and reusing a single command with type attribute to define different behaviour, along with many Diameter applications designed in 3GPP, DCCA application - RFC 4006 does that too. It will be good to have some guidelines on command overload in draft-ietf-dime-app-design-guide. Thanks, Shwetha -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of jouni korhonen Sent: Monday, September 20, 2010 8:35 PM To: Frank Brockners (fbrockne) Cc: dime@ietf.org Subject: Re: [Dime] on the use of Diameter commands (was WGLC comments ofdraft-ietf-dime-nat-control-03) Hi Frank, Sorry for the delay (same excuse as earlier..) On Sep 6, 2010, at 4:03 PM, Frank Brockners (fbrockne) wrote: > Hi Jouni, all, >=20 > Thanks for your detailed review of draft-ietf-dime-nat-control-03.=20 > Apart from the immediate issue mentioned, it brings up a wider=20 > question on how we use of commands. >=20 > Wrt/ the specific issue: NCR w/ TERMINATE-REQUEST equals STR; and (I > agree) should be replaced; this would be inline with the guidelines in > dime-app-design-guide and 3588bis. The reason why the glitch happened=20 > and the document did not reuse STR right away, was because we somewhat > followed the "TISPAN" or "3GPP" logic, i.e. incorporating several=20 > behaviors into a single command, which points to the more general > discussion: Right. I would not take e.g. 3GPP as an example how to design Diameter applications ;) >=20 > In TISPAN or 3GPP one sometimes only defines a single command and=20 > overloads this command with different behaviors based on the value of=20 > a parameter/AVP (e.g. Gq' with the "Specific-Action AVP"). With this=20 > approach all the behaviors for an application are thus contained under > a single "umbrella command" - specific to this application. This=20 > results in a smaller set of commands with a bit of a "hierarchical"=20 > structure - which some folks see as more readable - but also means=20 > that you have to provide differentiation below the command level if=20 > you implement the state machine. > TISPAN and 3GPP also do not following this logic in all cases (largely > because of command reuse), so one always ends up in some middle ground. > IETF usually takes a cleaner approach, avoiding overloading of=20 > commands, but defining distinct commands per required atomic operation. I would say that if you bring a document to IETF, although its primary use case/deployment would clearly be in other SDO architectures, then better do it in IETF way. > So what we could do for the draft is to (a) reuse existing commands as > much as possible (i.e. reuse STR/STA), which after your comments is a=20 > no-brainer and (b) evolve to specifying individual commands for each=20 > operation, rather than overloading NCR/NCA (the change is really=20 > straight forward from a technical point of view). >=20 > If we'd (as the working group) decide to evolve the document along the > lines of (b) - avoiding the overloading of commands, the general=20 > recommendation about atomic commands could also be a good addition to=20 > the dime-app-design-guide ID - providing guidance for future cases... I recommend going for (a). ASR/ASA and ACR/ACA are already reused, and for session termination STR/STA would follow that path. I did not see anything on this particular case what would require a new command for "STR/STA purposes". If there is something that we cannot just achieve using STR/STA and its current ABNF, then I think a new command can be justified. - Jouni >=20 >=20 > Appreciate your thoughts. >=20 > Thanks and regards, Frank >=20 >=20 >> Ticket #10: http://trac.tools.ietf.org/wg/dime/trac/ticket/10 >>=20 >> During my WGLC review of draft-ietf-dime-nat-control-03 the reuse of=20 >> NCR/NCA commands for almost everything looked strange. Why NCR/NCA=20 >> during TERMINATE_REQUEST is not reusing RFC3588 STR/STA? >>=20 >> If there is no compelling reason of not reusing STR/STA, I would use=20 >> commands what we have in RFC3588... as the document already makes an=20 >> attempt to reuse ASR/ASA and ACR/ACA. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From shwethab@cisco.com Tue Sep 28 00:21:28 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF05B3A6C7E for ; Tue, 28 Sep 2010 00:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.669 X-Spam-Level: X-Spam-Status: No, score=-9.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rontnq8LLNxz for ; Tue, 28 Sep 2010 00:21:27 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D11F13A6D2A for ; Tue, 28 Sep 2010 00:20:50 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssDALM0oUyQ/khNgWdsb2JhbACiHRUBARYiIqsxjQePdIVEBIROiHE X-IronPort-AV: E=Sophos;i="4.57,246,1283731200"; d="scan'208";a="65317703" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 28 Sep 2010 07:21:30 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o8S7LQ0Q006523; Tue, 28 Sep 2010 07:21:30 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Sep 2010 12:50:55 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Sep 2010 12:51:22 +0530 Message-ID: <04BD913C7AD1B84297D26D5614FBE133018B82D3@XMB-BGL-417.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Auth-Session-State (WGLC comments ofdraft-ietf-dime-nat-control-03) Thread-Index: ActY08nw4UVzOLXCTauXj0siouUb5wGB5jKQ References: <0D212BD466921646B58854FB79092CEC02E37772@XMB-AMS-106.cisco.com> From: "Shwetha Bhandari (shwethab)" To: "jouni korhonen" , "Frank Brockners (fbrockne)" X-OriginalArrivalTime: 28 Sep 2010 07:20:55.0262 (UTC) FILETIME=[B0871FE0:01CB5EDD] Cc: dime@ietf.org Subject: Re: [Dime] Auth-Session-State (WGLC comments ofdraft-ietf-dime-nat-control-03) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 28 Sep 2010 07:21:28 -0000 Hi Jouni, We are planning to modify draft-ietf-dime-nat-control as per our last email discussion, appreciate if you could review and provide you comments on the text being proposed. =20 Following is the new section to be added to define State machine for DNCA manager and agent: 7. NAT Control Application Session State Machine This section contains a set of finite state machines, representing the life cycle of DNCA session, which MUST be observed by all implementations of the DNCA Diameter application. DNCA Agent and Manager are stateful and the state machine maintained is similar to the stateful Client and Server authorization state machine described in RFC3588. When a session is moved to the Idle state, any resources that were allocated for the particular session must be released. Any event not listed in the state machines MUST be considered as an error condition, and an answer, if applicable, MUST be returned to the originator of the message. In the state table, the event 'Failure to send NCR' means that the DNCA Manager is unable to send command NCR to the desired destination. This could be due to the peer being down, or due to the peer sending back a transient failure or temporary protocol error notification DIAMETER_TOO_BUSY or DIAMETER_LOOP_DETECTED in the Result-Code AVP of NCA. In the state table "FAILED NCA" means that the DNCA Agent was not able to honor corresponding NCR. This can happen due to any of the transient and permanent error at DNCA Agent indicated by the following error Result-Code values - RESOURCE_FAILURE, UNKNOWN_BINDING_RULE_NAME, BINDING_FAILURE, MAXIMUM_BINDINGS_REACHED_FOR_ENDPOINT, SESSION_EXISTS, INSUFFICIENT_CLASSIFIERS The following state machine is observed by a DNCA Manager: MANAGER State Event Action New State ------------------------------------------------------------- Idle New Host detected that Send Pending requires NAT Control NCR Initial Request Idle ASR Received Send ASA Idle for unknown session with Result-Code =3D UNKNOWN_ SESSION_ID Pending Successful NCA Setup Open received complete Pending Successful NCA Sent STR Discon received but Agent unable to provide service Pending Error processing successful Sent STR Discon NCA Pending Failed Cleanup Idle NCA received Open NAT control Send Open update required NCR Update Request Open Successful Open NCA received Open Failed Cleanup Idle NCA received. Open Access Session end detected Send STR Discon Open ASR Received, Send ASA Discon client will comply with with request to end the session Result-Code =3D SUCCESS, Send STR. Open ASR Received, Send ASA Open client will not comply with with request to end the session Result-Code !=3D SUCCESS Discon ASR Received Send ASA Idle Discon STA Received Discon. Idle user/device The following state machine is observed by a DNCA Agent: AGENT State Event Action New State ------------------------------------------------------------- Idle NCR request Send Open received, and successful able to provide requested NCA NAT control service Idle NCR request Send Idle received, and failed unable to provide requested NCA NAT control service Open NCR request Send Open received, and successful able to provide requested NCA NAT control service Open NCR request Send Idle received, and failed unable to provide requested NCA, NAT control service Cleanup Open Unable to continue Send ASR Discon providing requested NAT control service Discon Failure to send ASR Wait, Discon resend ASR Discon ASR successfully sent and Cleanup Idle ASA Received with Result-Code Not ASA Received None No Change. Discon Any STR Received Send STA, Idle Cleanup. We are reusing STR/STA and following is the modified section for session termination: 4.5. Session Termination The DNCA Manager generates a Session Terminate Request (STR) message to the DNCA Agent upon receiving a trigger signal. The source of the trigger signal is outside the scope of this document. The DNCA Agent sends accounting stop record reporting all the bindings and notifies the DNCA Manager about successful session termination using a Session Terminate Answer (STA) message with Result-Code set to DIAMETER_SUCCESS. Figure 8 shows the protocol interaction between the DNCA Manager and the DNCA Agent. If a DNCA Agent receives STR from a DNCA Manager and fails to find a matching session, the DNCA Agent returns STA with Result-Code set to DIAMETER_UNKNOWN_SESSION_ID. DNCA Manager DNCA Agent | | | | Trigger | | | | STR | |------------------------------------------->| | (session id) | | | | | | Remove NAT bindings | of session | | | | | Send accounting stop | |<-------------------------------------------| | for all session bindings | | | | Terminate Session / | Remove session state | | | | | | | STA | |<-------------------------------------------| | (Result-Code) | | | Figure 8: Terminate NAT Control session Thanks, Shwetha -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of jouni korhonen Sent: Monday, September 20, 2010 8:25 PM To: Frank Brockners (fbrockne) Cc: dime@ietf.org Subject: Re: [Dime] Auth-Session-State (WGLC comments ofdraft-ietf-dime-nat-control-03) Hi Frank, Sorry for the delay (actually the email filter put the mail into wrong folder using some unknown logic). On Sep 6, 2010, at 4:03 PM, Frank Brockners (fbrockne) wrote: > Hi Jouni, >=20 > Thanks for your detailed review of draft-ietf-dime-nat-control-03.=20 >=20 > Wrt/ your comment on the use of " Auth-Session-State AVP", I agree=20 > that the use of this AVP is redundant and not really useful, because=20 > I'll have the default value in all cases, given that in DNCA both=20 > manager and agent are stateful. In order to avoid confusion, I'd=20 > follow your implicit suggestion to remove the AVP - and - more=20 > importantly add additional details on how state is maintained. Ok good. >=20 > Simply referring back to RFC 3588 for a description of state machines=20 > unfortunately does not work here. Per our earlier discussions in the=20 > working group, the nomenclature of "server" and "client" does not=20 > really apply to the DNCA use case, hence the use of "manager" and=20 > "agent" for the two involved Diameter entities. >=20 > My suggestion would be that we add another section which show state=20 > machines at agent and manager in detail (obviously reusing the format=20 > in RFC 3588). Would that be an agreeable way forward? That would be good. Please, propose some text and if that is a separate section we could check it before shipping a new revision of the document. - Jouni >=20 >=20 > Thanks & regards, Frank >=20 >=20 >> Ticket #9: http://trac.tools.ietf.org/wg/dime/trac/ticket/9 >>=20 >> During the WGLC review of draft-ietf-dime-nat-control-03 I started to >> think about the Auth-Session-State AVP and the associated semantics. >> The draft should state, even if it seems obvious, whether the state=20 >> is maintained or not. And whether it applies to all possible messages >> exchanges. Can Auth-Session-State be on NCA or in NCR during=20 >> QUERY_REQUEST? >>=20 >> How well the DNCA "view" of the session state goes along with RFC3588 >> authz session state machine? _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Tue Sep 28 00:51:47 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B48A03A6C9B for ; Tue, 28 Sep 2010 00:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xFfhpvebNGh for ; Tue, 28 Sep 2010 00:51:46 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 1F1D33A6C8C for ; Tue, 28 Sep 2010 00:51:45 -0700 (PDT) Received: by fxm6 with SMTP id 6so4112883fxm.31 for ; Tue, 28 Sep 2010 00:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=usJUfSkJHr4XFXUJmAy1BT1bNWj4KPEJmVHNy6e6BEM=; b=K6ZJxFLMENZqfRrNqlcvnOcESpN/SwACLP+pzmxL26MrT9MnzdGNgGPnNbRhOhylUx wTaQ1jxAROalQMTkaFmQOe6iMuP0d/x1u5xHuEMAjcG+6BChALXmpaPS/TkWj4iFxv/L cTrevimFfbqnpe6PbegEPxxV7b/3dDLakuMoY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=TICQy81flyTR6KzkiT460zoyPtkGSWOu6a6tRwC1CWeT5lfJyTYZbDh+U9ZjShODb7 zOd8R6vyQg0WX8dqJ1pUYWQLNthQWZEKbeSZjQHsb4SBorf5zRt364swM/U7MY/rAOsp asGxJWRZw/6kh2MFYXMNUaUbsc5nuhpQwn1mE= Received: by 10.223.59.217 with SMTP id m25mr8757932fah.33.1285660346221; Tue, 28 Sep 2010 00:52:26 -0700 (PDT) Received: from a88-114-64-83.elisa-laajakaista.fi (a88-114-64-83.elisa-laajakaista.fi [88.114.64.83]) by mx.google.com with ESMTPS id f28sm2924970faa.0.2010.09.28.00.52.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 28 Sep 2010 00:52:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <04BD913C7AD1B84297D26D5614FBE133018B7E1F@XMB-BGL-417.cisco.com> Date: Tue, 28 Sep 2010 10:52:36 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0D212BD466921646B58854FB79092CEC02E37774@XMB-AMS-106.cisco.com> <04BD913C7AD1B84297D26D5614FBE133018B7E1F@XMB-BGL-417.cisco.com> To: Shwetha Bhandari (shwethab) X-Mailer: Apple Mail (2.1078) Cc: dime@ietf.org Subject: Re: [Dime] on the use of Diameter commands (was WGLC comments ofdraft-ietf-dime-nat-control-03) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 28 Sep 2010 07:51:47 -0000 Hi, On Sep 25, 2010, at 4:38 AM, Shwetha Bhandari (shwethab) wrote: > Hi Jouni, >=20 > Regarding overloading and reusing a single command with type attribute > to define different behaviour, along with many Diameter applications > designed in 3GPP, DCCA application - RFC 4006 does that too. It will = be > good to have some guidelines on command overload in > draft-ietf-dime-app-design-guide. Yes that would definitely be a good thing to discuss in the app-design = document. - Jouni >=20 > Thanks, > Shwetha > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf = Of > jouni korhonen > Sent: Monday, September 20, 2010 8:35 PM > To: Frank Brockners (fbrockne) > Cc: dime@ietf.org > Subject: Re: [Dime] on the use of Diameter commands (was WGLC comments > ofdraft-ietf-dime-nat-control-03) >=20 > Hi Frank, >=20 > Sorry for the delay (same excuse as earlier..) >=20 > On Sep 6, 2010, at 4:03 PM, Frank Brockners (fbrockne) wrote: >=20 >> Hi Jouni, all, >>=20 >> Thanks for your detailed review of draft-ietf-dime-nat-control-03.=20 >> Apart from the immediate issue mentioned, it brings up a wider=20 >> question on how we use of commands. >>=20 >> Wrt/ the specific issue: NCR w/ TERMINATE-REQUEST equals STR; and (I >> agree) should be replaced; this would be inline with the guidelines = in >=20 >> dime-app-design-guide and 3588bis. The reason why the glitch happened=20= >> and the document did not reuse STR right away, was because we = somewhat >=20 >> followed the "TISPAN" or "3GPP" logic, i.e. incorporating several=20 >> behaviors into a single command, which points to the more general >> discussion: >=20 > Right. I would not take e.g. 3GPP as an example how to design Diameter > applications ;) >=20 >>=20 >> In TISPAN or 3GPP one sometimes only defines a single command and=20 >> overloads this command with different behaviors based on the value of=20= >> a parameter/AVP (e.g. Gq' with the "Specific-Action AVP"). With this=20= >> approach all the behaviors for an application are thus contained = under >=20 >> a single "umbrella command" - specific to this application. This=20 >> results in a smaller set of commands with a bit of a "hierarchical"=20= >> structure - which some folks see as more readable - but also means=20 >> that you have to provide differentiation below the command level if=20= >> you implement the state machine. >> TISPAN and 3GPP also do not following this logic in all cases = (largely >=20 >> because of command reuse), so one always ends up in some middle > ground. >> IETF usually takes a cleaner approach, avoiding overloading of=20 >> commands, but defining distinct commands per required atomic > operation. >=20 > I would say that if you bring a document to IETF, although its primary > use case/deployment would clearly be in other SDO architectures, then > better do it in IETF way. >=20 >> So what we could do for the draft is to (a) reuse existing commands = as >=20 >> much as possible (i.e. reuse STR/STA), which after your comments is a=20= >> no-brainer and (b) evolve to specifying individual commands for each=20= >> operation, rather than overloading NCR/NCA (the change is really=20 >> straight forward from a technical point of view). >>=20 >> If we'd (as the working group) decide to evolve the document along = the >=20 >> lines of (b) - avoiding the overloading of commands, the general=20 >> recommendation about atomic commands could also be a good addition to=20= >> the dime-app-design-guide ID - providing guidance for future cases... >=20 > I recommend going for (a). ASR/ASA and ACR/ACA are already reused, and > for session termination STR/STA would follow that path. I did not see > anything on this particular case what would require a new command for > "STR/STA purposes". If there is something that we cannot just achieve > using STR/STA and its current ABNF, then I think a new command can be > justified. >=20 > - Jouni >=20 >=20 >>=20 >>=20 >> Appreciate your thoughts. >>=20 >> Thanks and regards, Frank >>=20 >>=20 >>> Ticket #10: http://trac.tools.ietf.org/wg/dime/trac/ticket/10 >>>=20 >>> During my WGLC review of draft-ietf-dime-nat-control-03 the reuse of=20= >>> NCR/NCA commands for almost everything looked strange. Why NCR/NCA=20= >>> during TERMINATE_REQUEST is not reusing RFC3588 STR/STA? >>>=20 >>> If there is no compelling reason of not reusing STR/STA, I would use=20= >>> commands what we have in RFC3588... as the document already makes an=20= >>> attempt to reuse ASR/ASA and ACR/ACA. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From lionel.morand@orange-ftgroup.com Tue Sep 28 01:43:24 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 924223A6D4B for ; Tue, 28 Sep 2010 01:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.984 X-Spam-Level: X-Spam-Status: No, score=-101.984 tagged_above=-999 required=5 tests=[AWL=-0.594, BAYES_20=-0.74, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-GK+RmYIyI0 for ; Tue, 28 Sep 2010 01:43:05 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 799CC3A6C7A for ; Tue, 28 Sep 2010 01:39:34 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EA30C8B8003 for ; Tue, 28 Sep 2010 10:39:29 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id D9F168B8007 for ; Tue, 28 Sep 2010 10:39:29 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Sep 2010 10:38:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Sep 2010 10:38:39 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DIME WG Last Call: "Diameter Extended NAPTR" Thread-Index: Acte6IxSpip5DuIrQYKCgq/LAl3uHQ== From: To: X-OriginalArrivalTime: 28 Sep 2010 08:38:38.0898 (UTC) FILETIME=[8C458120:01CB5EE8] Subject: [Dime] DIME WG Last Call: "Diameter Extended NAPTR" X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 28 Sep 2010 08:43:24 -0000 This is an announcement of the DIME WG last call on "Diameter Extended NAPTR", prior to sending the document to the IESG for publication as a proposed standard RFC.=20 The document is available for review here: http://tools.ietf.org/html/draft-ietf-dime-extended-naptr-02 The DIME WGLC will last until October 10, 2010. If you have comments on the document, please file using TRAC system. See below for summary of instructions.=20 Thanks, Lionel ***********************=20 1. To submit an issue in TRAC, please use : http://trac.tools.ietf.org/wg/dime/trac/ 2. If you don't already have a login ID, you can obtain one by navigating to this site: http://trac.tools.ietf.org/newlogin 3. Once you have obtained an account, and have logged in, you can file an issue by navigating to the ticket entry form: http://trac.tools.ietf.org/wg/dime/trac/newticket 4. When opening an issue: a. The Type: field should be set to "defect" for an issue with the current document text, or "enhancement" for a proposed addition of functionality (such as an additional requirement).=20 b. The Priority: field is set based on the severity of the Issue. For example, editorial issues are typically "minor" or "trivial".=20 c. The Milestone: field should be set to milestone1 (useless, I know).=20 d. The Component: field should be set to the document you are filing the issue on. =20 e. The Version: field should be set to "1.0".=20 f. The Severity: field should be set to based on the status of the document (e.g. "In WG Last Call" for a document in WG last call) g. The Keywords: and CC: fields can be left blank unless inspiration seizes you.=20 h. The Assign To: field is generally filled in with the email address of the editor.=20 5. Typically it won't be necessary to enclose a file with the ticket, but if you need to, select "I have files to attach to this ticket".=20 6. If you want to preview your Issue, click on the "Preview" button. When you're ready to submit the issue, click on the "Create Ticket" button.=20 7. If you want to update an issue, go to the "View Tickets" page: http://trac.tools.ietf.org/wg/dime/trac/report/1 Click on the ticket # you want to update, and then modify the ticket fields as required From jouni.nospam@gmail.com Tue Sep 28 02:18:57 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAB003A6DCC for ; Tue, 28 Sep 2010 02:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJLY1t8dNBat for ; Tue, 28 Sep 2010 02:18:53 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 0D58F3A6DA6 for ; Tue, 28 Sep 2010 02:17:17 -0700 (PDT) Received: by fxm6 with SMTP id 6so4148223fxm.31 for ; Tue, 28 Sep 2010 02:17:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=wOJBBNoHc/0KD8S47cdGdDI6PFU8ntnk/khypDRnFlo=; b=FzbeIB4QnqugED+DUYECZoI+3mozwm1Rto1bgg34FjK16w8cgRZ0NKXxLt8W6Y1PGE rJ22zcckt8EG5NbW96GjftelJwsTGq7oSwhsGDpkdQuqQjaOsLaKNrW5nb5hu79dPt6E zv5IQwOnVK+f4FnVqOjyrXYT2yzFvLX/FbzA0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=k6oM8Jh4HVF1Vu9gki0MtwW8G8g97ekkpcKU5hKkyPX2Rcr2O4VI5FyJUFePPb12B4 cUEZZQd9NCl0h6sAoi2y9idGopV0YcWJfooistccd+ErzHMyBxEJnfbvDYgnuwO7BzNo 6Q7I5Vc07X2H0KqKtZglziczY95TFoFtRFNp8= Received: by 10.223.144.85 with SMTP id y21mr8013775fau.87.1285665131803; Tue, 28 Sep 2010 02:12:11 -0700 (PDT) Received: from a88-114-64-83.elisa-laajakaista.fi (a88-114-64-83.elisa-laajakaista.fi [88.114.64.83]) by mx.google.com with ESMTPS id 10sm2953490fax.18.2010.09.28.02.12.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 28 Sep 2010 02:12:10 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <04BD913C7AD1B84297D26D5614FBE133018B82D3@XMB-BGL-417.cisco.com> Date: Tue, 28 Sep 2010 12:12:25 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <863D6624-1EBD-40EA-AFE4-D3D04D8FBE04@gmail.com> References: <0D212BD466921646B58854FB79092CEC02E37772@XMB-AMS-106.cisco.com> <04BD913C7AD1B84297D26D5614FBE133018B82D3@XMB-BGL-417.cisco.com> To: Shwetha Bhandari (shwethab) X-Mailer: Apple Mail (2.1078) Cc: dime@ietf.org Subject: Re: [Dime] Auth-Session-State (WGLC comments ofdraft-ietf-dime-nat-control-03) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 28 Sep 2010 09:18:57 -0000 Hi Shwetha, Section 7 is actually much more I was expecting and looks good to me. = Just remember to remove the Auth-Session-State from NCR ABNF and Section = 7.1. - Jouni On Sep 28, 2010, at 10:21 AM, Shwetha Bhandari (shwethab) wrote: > Hi Jouni, >=20 > We are planning to modify draft-ietf-dime-nat-control as per our last > email discussion, appreciate if you could review and provide you > comments on the text being proposed. =20 >=20 > Following is the new section to be added to define State machine for > DNCA manager and agent: >=20 > 7. NAT Control Application Session State Machine >=20 > This section contains a set of finite state machines, representing > the life cycle of DNCA session, which MUST be observed by all > implementations of the DNCA Diameter application. DNCA Agent and > Manager are stateful and the state machine maintained is similar to > the stateful Client and Server authorization state machine described > in RFC3588. When a session is moved to the Idle state, any = resources > that were allocated for the particular session must be released. = Any > event not listed in the state machines MUST be considered as an = error > condition, and an answer, if applicable, MUST be returned to the > originator of the message. >=20 > In the state table, the event 'Failure to send NCR' means that the > DNCA Manager is unable to send command NCR to the desired > destination. This could be due to the peer being down, or due to = the > peer sending back a transient failure or temporary protocol error > notification DIAMETER_TOO_BUSY or DIAMETER_LOOP_DETECTED in the > Result-Code AVP of NCA. >=20 > In the state table "FAILED NCA" means that the DNCA Agent was not > able to honor corresponding NCR. This can happen due to any of the > transient and permanent error at DNCA Agent indicated by the > following error Result-Code values - RESOURCE_FAILURE, > UNKNOWN_BINDING_RULE_NAME, BINDING_FAILURE, > MAXIMUM_BINDINGS_REACHED_FOR_ENDPOINT, SESSION_EXISTS, > INSUFFICIENT_CLASSIFIERS >=20 > The following state machine is observed by a DNCA Manager: > MANAGER > State Event Action New State > ------------------------------------------------------------- > Idle New Host detected that Send Pending > requires NAT Control NCR > Initial > Request >=20 > Idle ASR Received Send ASA Idle > for unknown session with > Result-Code > =3D UNKNOWN_ > SESSION_ID >=20 > Pending Successful NCA Setup Open > received complete >=20 > Pending Successful NCA Sent STR Discon > received > but Agent unable to provide > service >=20 > Pending Error processing successful Sent STR Discon > NCA >=20 > Pending Failed Cleanup Idle > NCA received >=20 > Open NAT control Send Open > update required NCR Update > Request >=20 > Open Successful Open > NCA received >=20 > Open Failed Cleanup Idle > NCA received. >=20 >=20 > Open Access Session end detected Send STR Discon >=20 > Open ASR Received, Send ASA Discon > client will comply with with > request to end the session Result-Code > =3D SUCCESS, > Send STR. >=20 > Open ASR Received, Send ASA Open > client will not comply with with > request to end the session Result-Code > !=3D SUCCESS >=20 > Discon ASR Received Send ASA Idle >=20 > Discon STA Received Discon. Idle > user/device >=20 > The following state machine is observed by a DNCA Agent: >=20 > AGENT > State Event Action New State > ------------------------------------------------------------- > Idle NCR request Send Open > received, and successful > able to provide requested NCA > NAT control service >=20 > Idle NCR request Send Idle > received, and failed > unable to provide requested NCA > NAT control service >=20 > Open NCR request Send Open > received, and successful > able to provide requested NCA > NAT control service >=20 > Open NCR request Send Idle > received, and failed > unable to provide requested NCA, > NAT control service Cleanup >=20 > Open Unable to continue Send ASR Discon > providing requested > NAT control service >=20 > Discon Failure to send ASR Wait, Discon > resend ASR >=20 > Discon ASR successfully sent and Cleanup Idle > ASA Received with Result-Code >=20 > Not ASA Received None No Change. > Discon >=20 > Any STR Received Send STA, Idle > Cleanup. >=20 >=20 > We are reusing STR/STA and following is the modified section for = session > termination: >=20 > 4.5. Session Termination >=20 > The DNCA Manager generates a Session Terminate Request (STR) message > to the DNCA Agent upon receiving a trigger signal. The source of = the > trigger signal is outside the scope of this document. The DNCA = Agent > sends accounting stop record reporting all the bindings and notifies > the DNCA Manager about successful session termination using a = Session > Terminate Answer (STA) message with Result-Code set to > DIAMETER_SUCCESS. Figure 8 shows the protocol interaction between > the DNCA Manager and the DNCA Agent. >=20 > If a DNCA Agent receives STR from a DNCA Manager and fails to find a > matching session, the DNCA Agent returns STA with Result-Code set to > DIAMETER_UNKNOWN_SESSION_ID. >=20 > DNCA Manager DNCA Agent > | | > | | > Trigger | > | | > | STR | > |------------------------------------------->| > | (session id) | > | | > | | > | Remove NAT bindings > | of session > | | > | | > | Send accounting stop | > |<-------------------------------------------| > | for all session bindings | > | | > | Terminate Session / > | Remove session state > | | > | | > | | > | STA | > |<-------------------------------------------| > | (Result-Code) | > | | >=20 > Figure 8: Terminate NAT Control session >=20 >=20 >=20 > Thanks, > Shwetha >=20 > -----Original Message----- >=20 > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf = Of > jouni korhonen > Sent: Monday, September 20, 2010 8:25 PM > To: Frank Brockners (fbrockne) > Cc: dime@ietf.org > Subject: Re: [Dime] Auth-Session-State (WGLC comments > ofdraft-ietf-dime-nat-control-03) >=20 > Hi Frank, >=20 > Sorry for the delay (actually the email filter put the mail into wrong > folder using some unknown logic). >=20 >=20 > On Sep 6, 2010, at 4:03 PM, Frank Brockners (fbrockne) wrote: >=20 >> Hi Jouni, >>=20 >> Thanks for your detailed review of draft-ietf-dime-nat-control-03.=20 >>=20 >> Wrt/ your comment on the use of " Auth-Session-State AVP", I agree=20 >> that the use of this AVP is redundant and not really useful, because=20= >> I'll have the default value in all cases, given that in DNCA both=20 >> manager and agent are stateful. In order to avoid confusion, I'd=20 >> follow your implicit suggestion to remove the AVP - and - more=20 >> importantly add additional details on how state is maintained. >=20 > Ok good. >=20 >>=20 >> Simply referring back to RFC 3588 for a description of state machines=20= >> unfortunately does not work here. Per our earlier discussions in the=20= >> working group, the nomenclature of "server" and "client" does not=20 >> really apply to the DNCA use case, hence the use of "manager" and=20 >> "agent" for the two involved Diameter entities. >>=20 >> My suggestion would be that we add another section which show state=20= >> machines at agent and manager in detail (obviously reusing the format=20= >> in RFC 3588). Would that be an agreeable way forward? >=20 > That would be good. Please, propose some text and if that is a = separate > section we could check it before shipping a new revision of the > document. >=20 > - Jouni >=20 >=20 >>=20 >>=20 >> Thanks & regards, Frank >>=20 >>=20 >>> Ticket #9: http://trac.tools.ietf.org/wg/dime/trac/ticket/9 >>>=20 >>> During the WGLC review of draft-ietf-dime-nat-control-03 I started = to >=20 >>> think about the Auth-Session-State AVP and the associated semantics. >>> The draft should state, even if it seems obvious, whether the state=20= >>> is maintained or not. And whether it applies to all possible = messages >=20 >>> exchanges. Can Auth-Session-State be on NCA or in NCR during=20 >>> QUERY_REQUEST? >>>=20 >>> How well the DNCA "view" of the session state goes along with = RFC3588 >=20 >>> authz session state machine? >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From trac@tools.ietf.org Tue Sep 28 01:05:41 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D91503A6C9B for ; Tue, 28 Sep 2010 01:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6OALcJYoqR7 for ; Tue, 28 Sep 2010 01:05:41 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F2D473A6C72 for ; Tue, 28 Sep 2010 01:05:40 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P0VCc-00030n-6y; Tue, 28 Sep 2010 01:06:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dime issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dime@ietf.org, jouni.nospam@gmail.com X-Trac-Project: dime Date: Tue, 28 Sep 2010 08:06:18 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/dime/trac/ticket/10#comment:1 Message-ID: <073.1954dc47fc7ae829d9359dac3975afff@tools.ietf.org> References: <064.d3153424a883f7de08540b9993659e5a@tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <064.d3153424a883f7de08540b9993659e5a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dime@ietf.org, jouni.nospam@gmail.com, dime-chairs@tools.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Tue, 28 Sep 2010 02:43:24 -0700 Cc: dime-chairs@tools.ietf.org Subject: Re: [Dime] [dime] #10: Use of commands X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 08:05:41 -0000 #10: Use of commands ------------------------------------+--------------------------------------- Reporter: jouni.nospam@… | Owner: dime@… Type: defect | Status: closed Priority: major | Milestone: Component: nat-control | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by jouni.nospam@…): * status: new => closed * resolution: => fixed Comment: {{{ Authors changed the text to reuse STR/STA and following is the modified section for session termination: 4.5. Session Termination The DNCA Manager generates a Session Terminate Request (STR) message to the DNCA Agent upon receiving a trigger signal. The source of the trigger signal is outside the scope of this document. The DNCA Agent sends accounting stop record reporting all the bindings and notifies the DNCA Manager about successful session termination using a Session Terminate Answer (STA) message with Result-Code set to DIAMETER_SUCCESS. Figure 8 shows the protocol interaction between the DNCA Manager and the DNCA Agent. If a DNCA Agent receives STR from a DNCA Manager and fails to find a matching session, the DNCA Agent returns STA with Result-Code set to DIAMETER_UNKNOWN_SESSION_ID. DNCA Manager DNCA Agent | | | | Trigger | | | | STR | |------------------------------------------->| | (session id) | | | | | | Remove NAT bindings | of session | | | | | Send accounting stop | |<-------------------------------------------| | for all session bindings | | | | Terminate Session / | Remove session state | | | | | | | STA | |<-------------------------------------------| | (Result-Code) | | | Figure 8: Terminate NAT Control session }}} -- Ticket URL: dime From trac@tools.ietf.org Tue Sep 28 02:20:28 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06EB73A6DA1 for ; Tue, 28 Sep 2010 02:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDRVmHyFS1S7 for ; Tue, 28 Sep 2010 02:20:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 64C4B3A6DA3 for ; Tue, 28 Sep 2010 02:19:23 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P0WLv-0003h7-3l; Tue, 28 Sep 2010 02:19:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dime issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dime@ietf.org, jouni.nospam@gmail.com X-Trac-Project: dime Date: Tue, 28 Sep 2010 09:19:58 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/dime/trac/ticket/9#comment:1 Message-ID: <073.edd1b10ca35c82fd58eeb6870e6a5e92@tools.ietf.org> References: <064.d0f1132239536534e32dced531e369ad@tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <064.d0f1132239536534e32dced531e369ad@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dime@ietf.org, jouni.nospam@gmail.com, dime-chairs@tools.ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Tue, 28 Sep 2010 02:43:24 -0700 Cc: dime-chairs@tools.ietf.org Subject: Re: [Dime] [dime] #9: Auth-Session-State X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 09:20:28 -0000 #9: Auth-Session-State ------------------------------------+--------------------------------------- Reporter: jouni.nospam@… | Owner: dime@… Type: defect | Status: closed Priority: major | Milestone: Component: nat-control | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by jouni.nospam@…): * status: new => closed * resolution: => fixed Comment: The authors have proposed new text to Section 7. The new text clears my concerns on the session state. The authors still need to remove the Auth- Sesstion-State AVP from NCR's ABNF and Section 7.1. See the proposed text http://www.ietf.org/mail- archive/web/dime/current/msg04468.html -- Ticket URL: dime From avi@bridgewatersystems.com Tue Sep 28 17:22:15 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DAAC3A6BF1 for ; Tue, 28 Sep 2010 17:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUsn6KbWOViz for ; Tue, 28 Sep 2010 17:22:13 -0700 (PDT) Received: from mail51.messagelabs.com (mail51.messagelabs.com [216.82.241.99]) by core3.amsl.com (Postfix) with ESMTP id 3C8CA3A6BE1 for ; Tue, 28 Sep 2010 17:22:13 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: avi@bridgewatersystems.com X-Msg-Ref: server-8.tower-51.messagelabs.com!1285719774!28906842!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [72.35.6.119] Received: (qmail 30700 invoked from network); 29 Sep 2010 00:22:55 -0000 Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-8.tower-51.messagelabs.com with RC4-SHA encrypted SMTP; 29 Sep 2010 00:22:55 -0000 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Tue, 28 Sep 2010 20:22:54 -0400 From: Avi Lior To: "dime@ietf.org" Date: Tue, 28 Sep 2010 20:21:55 -0400 Thread-Topic: Avi Lior Review of draft-ietf-dime-extended-naptr-02 Thread-Index: ActfbHU9MtQDCJnJSFCXqxLTyYwrjw== Message-ID: <94FE4DE4-BF0F-4EC9-A721-50DF8F5D778B@bridgewatersystems.com> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: f069778a-5a3c-4a57-aa01-0f5f3f2623e3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Mark Jones Subject: [Dime] Avi Lior Review of draft-ietf-dime-extended-naptr-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 29 Sep 2010 00:22:15 -0000 I have reviewed draft-ietf-dime-extended-naptr-02. Here is my review: Comment 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Improving understandability. The introduction does not defines the problem statement that this document = addresses. Even the Abstract does not tell us what problem we are solving. Why do we want the NAPTR queries to contain Diameter Application-Id informa= tion? The answer is not reached until section 4 which presents a wonderful backgr= ound to the problem. But still does not present the problem. Suggestion move section 4 material to the introduction. Alternatively, add= a Problem Statement / Background section as part of 1.0=20 Comment =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Terminology=20 "The Diameter base protocol specification (Section 1.4 of RFC 3588) defines most of the terminology used in this document." Where is the rest defined??? or does it not matter??? Comment =3D=3D=3D=3D=3D=3D=3D=3D Section 3: Question: Does NAPTR Service Field format always consists of Application S= ervice tag and Application Protocol tag? Check 3958 Comment =3D=3D=3D=3D=3D=3D=3D=3D Editorial=20 Section 3 supporting a specific Diameter application is show below. s/show/shown Comment =3D=3D=3D=3D=3D=3D=3D=3D=3D Section 3 editorial(s) Break the last par in this section after the first sentence. Also change: "The DNS administrator of some domain SHOULD also provision base RFC 3588 style NAPTR records [RFC2915] in order to guarantee backwards compatibility with legacy RFC 3588 compliant Diameter peers. " To" "DNS administrators SHOULD also provision base RFC 3588 style NAPTR records [RFC2915] in order to guarantee backwards compatibility with legacy RFC 3588 compliant Diameter peers."=20 Comment =3D=3D=3D=3D=3D=3D=3D=3D Editorial Section 4 a: s/The Diameter implementation performs/The Diameter peer performs/ or client??? Align with terminology used in step b. "If "X" contains the required Application Identifier and "Y" matches a transport protocol supported by the client," Comment =3D=3D=3D=3D=3D=3D=3D=3D Section 4 c: "c: and d:" is existing behavior right? So why are we talking about it. I= would mention it first and get it out of the way. Just elaborate on the n= ew stuff. Comment =3D=3D=3D=3D=3D=3D=3D=3D=3D 5 Usage Guidelines I am not getting this paragraph. It is stating the problem (which we could do earlier). But i am not gettin= g the last sentence. Why do we care if its a client or a peer: can this be not used by one peer = looking for a particular another peer supporting an application and protoco= l why does it have to only apply to client server? What am I missing???? Comment =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IANA Consideration 6.1=20 Is this a new registry???? Too bad we cant just say define a generic string/rule once and not require = IANA to create a new entry for each new application. Comment =3D=3D=3D=3D=3D=3D=3D=3D 6.2 Why are we doing this. We should make the usage consistent with first come= first served. Why require an RFC???? Specifically if I have a vendor specific application id and I want to use t= his scheme now I have to write an RFC? From trac@tools.ietf.org Wed Sep 29 01:35:30 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9A3E3A6C7F for ; Wed, 29 Sep 2010 01:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xsnex2yFahg9 for ; Wed, 29 Sep 2010 01:35:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B850B3A6C3F for ; Wed, 29 Sep 2010 01:35:27 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1P0s94-000400-21; Wed, 29 Sep 2010 01:36:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dime issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: lionel.morand@orange-ftgroup.com X-Trac-Project: dime Date: Wed, 29 Sep 2010 08:36:09 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/13 Message-ID: <074.f7270be5b911cb988a18928b054aa150@tools.ietf.org> X-Trac-Ticket-ID: 13 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: lionel.morand@orange-ftgroup.com, dime@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: dime@ietf.org Subject: [Dime] [dime] #13: Avi Lior Review of draft-ietf-dime-extended-naptr-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 08:35:30 -0000 #13: Avi Lior Review of draft-ietf-dime-extended-naptr-02 ----------------------------------------------+----------------------------- Reporter: lionel.morand@… | Owner: Avi Lior [avi@… Type: enhancement | Status: new Priority: major | Milestone: milestone1 Component: extended-naptr | Version: 1.0 Severity: In WG Last Call | Keywords: ----------------------------------------------+----------------------------- I have reviewed draft-ietf-dime-extended-naptr-02. Here is my review: Comment 1 ========== Improving understandability. The introduction does not defines the problem statement that this document addresses. Even the Abstract does not tell us what problem we are solving. Why do we want the NAPTR queries to contain Diameter Application-Id information? The answer is not reached until section 4 which presents a wonderful background to the problem. But still does not present the problem. Suggestion move section 4 material to the introduction. Alternatively, add a Problem Statement / Background section as part of 1.0 Comment ========== Terminology "The Diameter base protocol specification (Section 1.4 of RFC 3588) defines most of the terminology used in this document." Where is the rest defined??? or does it not matter??? Comment ======== Section 3: Question: Does NAPTR Service Field format always consists of Application Service tag and Application Protocol tag? Check 3958 Comment ======== Editorial Section 3 supporting a specific Diameter application is show below. s/show/shown Comment ========= Section 3 editorial(s) Break the last par in this section after the first sentence. Also change: "The DNS administrator of some domain SHOULD also provision base RFC 3588 style NAPTR records [RFC2915] in order to guarantee backwards compatibility with legacy RFC 3588 compliant Diameter peers. " To" "DNS administrators SHOULD also provision base RFC 3588 style NAPTR records [RFC2915] in order to guarantee backwards compatibility with legacy RFC 3588 compliant Diameter peers." Comment ======== Editorial Section 4 a: s/The Diameter implementation performs/The Diameter peer performs/ or client??? Align with terminology used in step b. "If "X" contains the required Application Identifier and "Y" matches a transport protocol supported by the client," Comment ======== Section 4 c: "c: and d:" is existing behavior right? So why are we talking about it. I would mention it first and get it out of the way. Just elaborate on the new stuff. Comment ========= 5 Usage Guidelines I am not getting this paragraph. It is stating the problem (which we could do earlier). But i am not getting the last sentence. Why do we care if its a client or a peer: can this be not used by one peer looking for a particular another peer supporting an application and protocol why does it have to only apply to client server? What am I missing???? Comment ========== IANA Consideration 6.1 Is this a new registry???? Too bad we cant just say define a generic string/rule once and not require IANA to create a new entry for each new application. Comment ======== 6.2 Why are we doing this. We should make the usage consistent with first come first served. Why require an RFC???? Specifically if I have a vendor specific application id and I want to use this scheme now I have to write an RFC? -- Ticket URL: dime From mark@azu.ca Wed Sep 29 06:58:32 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3C173A6DDA for ; Wed, 29 Sep 2010 06:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.544 X-Spam-Level: X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfC4RNf0U53B for ; Wed, 29 Sep 2010 06:58:27 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id F26203A6EAB for ; Wed, 29 Sep 2010 06:58:26 -0700 (PDT) Received: by qyk31 with SMTP id 31so1141715qyk.10 for ; Wed, 29 Sep 2010 06:59:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.51.203 with SMTP id e11mr1201185qag.213.1285768749916; Wed, 29 Sep 2010 06:59:09 -0700 (PDT) Received: by 10.229.11.139 with HTTP; Wed, 29 Sep 2010 06:59:09 -0700 (PDT) In-Reply-To: <94FE4DE4-BF0F-4EC9-A721-50DF8F5D778B@bridgewatersystems.com> References: <94FE4DE4-BF0F-4EC9-A721-50DF8F5D778B@bridgewatersystems.com> Date: Wed, 29 Sep 2010 09:59:09 -0400 Message-ID: From: Mark Jones To: Avi Lior Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "dime@ietf.org" Subject: Re: [Dime] Avi Lior Review of draft-ietf-dime-extended-naptr-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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, 29 Sep 2010 13:58:32 -0000 Hi Avi, Thanks for the detailed review. Responses are inline. On Tue, Sep 28, 2010 at 8:21 PM, Avi Lior wrot= e: > I have reviewed draft-ietf-dime-extended-naptr-02. =A0Here is my review: > > Comment =A01 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Improving understandability. > > The introduction does not defines the problem statement that this documen= t addresses. > > Even the Abstract does not tell us what problem we are solving. > > Why do we want the NAPTR queries to contain Diameter Application-Id infor= mation? > > The answer is not reached until section 4 which presents a wonderful back= ground to the problem. =A0But still does not present the problem. > > Suggestion move section 4 material to the introduction. =A0Alternatively,= add a Problem Statement / Background section as part of 1.0 > > Ok. I=92ll craft a problem statement. Something along the lines of: =93Using dynamic peer discovery as described in RFC3588, a given realm may advertise multiple Diameter nodes without revealing which Diameter application each node supports. A peer outside the realm would have to perform a CER/CEA exchange with every node in order to find which one supports the desired application. This draft describes an optimization using S-NAPTR entries that allows peer discovery including supported applications without doing CER/CEA exchange beforehand.=94 > Comment > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Terminology > > "The Diameter base protocol specification (Section 1.4 of RFC 3588) > =A0 defines most of the terminology used in this document." > > Where is the rest defined??? or does it not matter??? > Ok. I=92ll add RFC3958 which introduces the S-NAPTR terms then remove =93mo= st of=94. > Comment > =3D=3D=3D=3D=3D=3D=3D=3D > > Section 3: > > Question: =A0Does NAPTR Service Field format always consists of Applicati= on Service tag and Application Protocol tag? > No. It is S-NAPTR (and not NAPTR) that defines the appn-svc:appln-proto format which is what this section is covering. > Check 3958 > Checked. I believe we're good on this one. > > Comment > =3D=3D=3D=3D=3D=3D=3D=3D > Editorial > > Section 3 > > supporting a specific Diameter application is show below. > > s/show/shown > Ok. > Comment > =3D=3D=3D=3D=3D=3D=3D=3D=3D > Section 3 editorial(s) > > Break the last par in this section after the first sentence. > > Also change: > "The DNS administrator of some domain SHOULD also > =A0 provision base RFC 3588 style NAPTR records [RFC2915] in order to > =A0 guarantee backwards compatibility with legacy RFC 3588 compliant > =A0 Diameter peers. " > > To" > > "DNS administrators SHOULD also > =A0 provision base RFC 3588 style NAPTR records [RFC2915] in order to > =A0 guarantee backwards compatibility with legacy RFC 3588 compliant > =A0 Diameter peers." > Ok. > Comment > =3D=3D=3D=3D=3D=3D=3D=3D > > Editorial > > Section 4 a: > > s/The Diameter implementation performs/The Diameter peer performs/ > > or client??? > This text is consistent with Section 5.2 in RFC3588. Which is also inconsistent between steps. ;) > Align with terminology used in step b. > > "If "X" contains the required Application Identifier and "Y" > =A0 =A0 =A0 =A0 matches a transport protocol supported by the client," > I believe the "client" here is not a Diameter client but a NAPTR client, i.e. the Diameter peer performing the NAPTR query. Pretty longwinded but I'll try to reword to clarify. > Comment > =3D=3D=3D=3D=3D=3D=3D=3D > > Section 4 =A0c: > > "c: and d:" is existing behavior right? =A0So why are we talking about it= . =A0I would mention it first and get it out of the way. =A0Just elaborate = on the new stuff. > I repeated step c for readability because I thought having the S-NAPTR/NAPTR procedure steps would be more readable than having the reader trying to figure out how to mesh it with the logic for dynamic peer discovery in RFC3588. I believe I got the balance right here but take a look at the full procedure in RFC3588 and let me know if you disagree. > Comment > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > 5 Usage Guidelines > > I am not getting this paragraph. > > It is stating the problem (which we could do earlier). =A0But i am not ge= tting the last sentence. > > Why do we care if its a client or a peer: can this be not used by one pee= r looking for a particular another peer supporting an application and proto= col > Sure it could in a true peer-to-peer Diameter application there aren=92t any (AFAIK). The usage guidelines in this section only apply for Diameter applications that define client/server roles. > why does it have to only apply to client server? =A0What am I missing???? > Let=92s say I=92m an MME (S6a client) looking for an HSS (S6a Server). Since the S-NAPTR entry only identifies peers that support S6a then I will discover all the other MME in the network in addition to the HSS. Not very helpful. > Comment > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > IANA Consideration > > > 6.1 > > Is this a new registry???? > Nope. It reuses the S-NAPTR registry. > Too bad we cant just say define a generic string/rule once and not requir= e IANA to create a new entry for each new application. > Agreed but you can=92t do that without a new DDDS application and it is tough to justify that effort for this optimization. > > Comment > =3D=3D=3D=3D=3D=3D=3D=3D > 6.2 > > Why are we doing this. =A0We should make the usage consistent with first = come first served. > > Why require an RFC???? > Because we=92re using an existing IANA registry (S-NAPTR) and are bound by an existing allocation policy. This was discussed at IETF77 and the conclusion in the room was that this was the lesser of evils. > Specifically if I have a vendor specific application id and I want to use= this scheme now I have to write an RFC? > Yes but the S-NAPTR allocation policy allows an RFC =93of any category=94 (not standards track) so this should not present a major impediment to vendors/SDOs that require this optimization. --- I'll make the above changes in the next rev along with any other comments from WGLC. Regards Mark