Subject: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime)

From: IESG Secretary <[email-masked]>
Date: Tue, 23 Jun 2009 13:30:01 -0700 (PDT)

A modified charter has been submitted for the Diameter Maintenance and
Extensions (dime) working group in the Operations and Management Area of
the IETF.  The IESG has not made any determination as yet.  The modified
charter is provided below for informational purposes only.  Please send
your comments to the IESG mailing list ([email-masked]) by Tuesday, June
30, 2009.

Diameter Maintenance and Extensions (dime)
===========================================

Last Modified: 2009-06-10

Current Status: Working Group

Chair(s):
 Hannes Tschofenig <[email-masked]>
 Victor Fajardo <[email-masked]>

Operations and Management Area Director(s):
 Dan Romascanu <[email-masked]>
 Ronald Bonica <[email-masked]>

Operations and Management Area Advisor:
 Dan Romascanu <[email-masked]>

Mailing Lists:
 General Discussion: [email-masked]
 To Subscribe: https://www.ietf.org/mailman/listinfo/dime
 Archive: http://www.ietf.org/mail-archive/web/dime/current/maillist.html

Description of Working Group:

The Diameter Maintenance and Extensions WG will focus on maintenance
and extensions to the Diameter protocol required to enable its use for
authentication, authorization, accounting and provisioning in network
access as well as for other applications environments
(e.g., IP telephony, mobility).

The IETF has completed work on the Diameter Base protocol and is
working on revising the base protocol specification. There is on-going
work on defining RADIUS extensions and the DIME WG will ensure
that work done in RADEXT is also available for Diameter.

The DIME working group plains to address the following items:

- Maintaining and/or progressing, along the standards track, the
Diameter Base protocol and Diameter Applications. This includes
extensions to Diameter Base protocol that can be considered as enhanced
features or bug fixes, such NAI routing or capability update extensions.

- Diameter application design guideline. This document will provide
guidelines for design of Diameter extensions. It will detail when to
consider reusing an existing application and when to develop a new
application.

- Diameter QoS extensions. This work focuses on extensions to
Diameter to support QoS information to be authorized and provisioned
in AAA deployments.

- Protocol extensions for the management of Diameter entities. This work

focuses on the standardization of Management Information Bases (MIBs)
to configure Diameter entities (such as the Diameter Base protocol or
Diameter Credit Control nodes). The usage of other management protocols
for configuring Diameter entities may be future work within the group.

- Diameter extensions for mobility protocols, such as Mobile IPv6 and
Proxy Mobile IPv6. Diameter extensions to support handover keying
developed in the HOKEY WG are part of this effort.

- New Diameter applications, such as the Diameter NAT control
application.
This group will also conduct work on new Diameter applications with
a Diameter application for configuring NATs as the first item.

Additionally, AAA systems require interoperability in order to work.
The working group, along with the AD, will need to evaluate
any potential extensions and require verification that the proposed
extension is needed. Coordination with other IETF working groups
and other SDOs will used to ensure this.

Goals and Milestones:

Done Submit 'Diameter Mobile IPv6: Support for Home Agent to
Diameter Server Interaction' to the IESG for consideration as a Proposed
Standard
Done Submit 'Diameter Mobile IPv6: Support for Network Access
Server to Diameter Server Interaction' to the IESG for consideration as
a Proposed Standard
Done Submit 'Diameter API' to the IESG for consideration as
an Informational RFC
Done Submit 'Quality of Service Parameters for Usage with
Diameter' to the IESG for consideration as a Proposed Standard.
Nov 2009 Submit 'Revision of Diameter Base Protocol' to
the IESG for consideration as a Proposed Standard
Done Submit 'Diameter QoS Application' to the IESG for
consideration as a Proposed Standard
Done Submit 'Diameter Support for EAP Re-authentication
Protocol' as DIME working group item
Done Submit 'Diameter User-Name and Realm Based Request
Routing Clarifications' as DIME working group item
Done Submit 'Diameter Proxy Mobile IPv6' as DIME working
group item
Done Submit 'Quality of Service Attributes for Diameter' to
the IESG for consideration as a Proposed Standard
Aug 2009 Submit 'Diameter Application Design Guidelines'
to the IESG for consideration as a BCP document
Done Submit 'Diameter Proxy Mobile IPv6' to the IESG for
consideration as a Proposed Standard
Done Submit 'Diameter User-Name and Realm Based Request
Routing Clarifications' to the IESG for consideration as a Proposed
Standard
Jan 2010 Submit 'Diameter Support for EAP
Re-authentication Protocol' to the IESG for consideration as a Proposed
Standard
Jun 2009 Submit new DIME charter to the IESG
Jun 2009 Submit 'Updated IANA Considerations for Diameter
Command Code Allocations' as DIME working group item
Jul 2009 Submit 'Updated IANA Considerations for Diameter
Command Code Allocations' to the IESG for consideration as a Proposed
Standard
Jul 2009 Submit 'Diameter NAT Control Application' as
DIME working group item
Jul 2009 Submit 'Diameter Capabilities Update' as DIME
working group item
Nov 2009 Submit ' Diameter Credit Control Application
MIB' to the IESG for consideration as an Informational RFC
Nov 2009 Submit 'Diameter Base Protocol MIB' to the IESG
for consideration as an Informational RFC
Nov 2009 Submit 'Diameter Capabilities Update' to the
IESG for consideration as a Proposed Standard
Jan 2010 Submit 'Diameter NAT Control Application' to the
IESG for consideration as a Proposed Standard

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 25 Jun 2009 12:53:15 +0700

> your comments to the IESG mailing list ([email-masked]) by Tuesday, June

An email "hum" regarding the adoption of
http://www.ietf.org/internet-drafts/draft-tsou-dime-realm-based-redirect-00.
txt as a chartered working group item was begun on 12 June
(http://www.ietf.org/mail-archive/web/dime/current/msg03595.html).  The
"hum" period ends tomorrow, yet the new charter has already been submitted
to the IESG.  Apparently there has been some unintentional oversight.

...

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 25 Jun 2009 10:37:37 +0200

Glen,

Rechartering and the "hum" for adoption of a document as WG item need
not be necessarily serialized. Rechartering is about approving to work
on a specific problem. The "hum" acknowledges (or not) that a certain
document is good enough to be the 00 version of the WG I-D that will
provide a solution to the problem. Of course, if rechartering is not
approved the "hum" will not have any effect, but otherwise some time may
be won by runing the "hum" and the rechartering review in parallel. 

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Glen Zorn
> Sent: Thursday, June 25, 2009 8:53 AM
> To: [email-masked]
> Cc: 'Hannes Tschofenig'; [email-masked]; [email-masked]
> Subject: RE: WG Review: Recharter of Diameter Maintenance and 
> Extensions(dime) 
> 
> > Extensions (dime) working group in the Operations and 
> Management Area 
> > of the IETF.  The IESG has not made any determination as yet.  The 
> > modified charter is provided below for informational 
> purposes only.  
> > Please send your comments to the IESG mailing list 
> ([email-masked]) by 
> > Tuesday, June 30, 2009.
> 
> (http://www.ietf.org/mail-archive/web/dime/current/msg03595.ht
> ml).  The "hum" period ends tomorrow, yet the new charter has 
> already been submitted to the IESG.  Apparently there has 
> been some unintentional oversight.
> 
> ...
> 
>

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 25 Jun 2009 16:27:17 +0700

> be won by runing the "hum" and the rechartering review in parallel.

I see.  Unfortunately, I can't see any mention of the problem in the revised
charter, either, unless it is your opinion that realm-based redirection
would be an extension to the Diameter Base Protocol (not unreasonable). 

On a different topic: the new charter contains the sentence "There is
on-going work on defining RADIUS extensions and the DIME WG will ensure that
work done in RADEXT is also available for Diameter."  This is an incredibly
poor idea: it's bad enough to persist in allowing RADIUS to be "extended"
(though there's little real danger of that happening in the radext WG ;-),
but to tie Diameter & RADIUS together at the hip is practically criminal.
Backward compatibility with RADIUS is fine; on-going, _forward_
compatibility is not.  This was discussed, as you know, on the dime list
with no objections to the idea of limiting RADIUS-Diameter compatibility;
however the offending sentence remains.

...

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 25 Jun 2009 11:40:04 +0200

> From: Glen Zorn [mailto:[email-masked]] 
> Sent: Thursday, June 25, 2009 12:27 PM
> To: Romascanu, Dan (Dan)
> Cc: 'Hannes Tschofenig'; [email-masked]; 
> [email-masked]; [email-masked]
> > approved the "hum" will not have any effect, but otherwise 
> some time 
> > may be won by runing the "hum" and the rechartering review in 
> > parallel.
> 
> I see.  Unfortunately, I can't see any mention of the problem 
> in the revised charter, either, unless it is your opinion 
> that realm-based redirection would be an extension to the 
> Diameter Base Protocol (not unreasonable). 

Something on this lines. The  WG decided to use extensions as a generic
denomination of many applications of various kinds so that the text
needs not be changed each time. There is always an opportunity to
express concerns when a deliverable is out of what would be a
reasonable extension. 

> 
> On a different topic: the new charter contains the sentence 
> "There is on-going work on defining RADIUS extensions and the 
> DIME WG will ensure that work done in RADEXT is also 
> available for Diameter."  This is an incredibly poor idea: 
> it's bad enough to persist in allowing RADIUS to be "extended"
> (though there's little real danger of that happening in the 
> radext WG ;-), but to tie Diameter & RADIUS together at the 
> hip is practically criminal.
> Backward compatibility with RADIUS is fine; on-going, 
> _forward_ compatibility is not.  This was discussed, as you 
> know, on the dime list with no objections to the idea of 
> limiting RADIUS-Diameter compatibility; however the offending 
> sentence remains.
> 

I am not sure that the intention of this sentence is such a tight
interdependence or forward compatibility as you fear. I would let
however Hannes and Victor to comment first, 

Dan

---

From: jouni korhonen <[email-masked]>
Date: Thu, 25 Jun 2009 13:31:41 +0300

Hi,

On Jun 25, 2009, at 12:40 PM, Romascanu, Dan (Dan) wrote:

[snip]

> however Hannes and Victor to comment first,

I posted on this topic already earlier (probably missed in the mail  
flood). I share the concern Glen has regarding the RADIUS compatibility.

Cheers,
	Jouni

>
>
> Dan
>
>> ...
>>
>>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 25 Jun 2009 15:58:07 +0200

Jouni and Glen,

Can you be exact about what text in the current charter proposal you
consider problematic and how you propose to change it?

Dan

> From: jouni korhonen [mailto:[email-masked]] 
> Sent: Thursday, June 25, 2009 1:32 PM
> To: Romascanu, Dan (Dan)
> Cc: Glen Zorn; [email-masked]; [email-masked]
> Subject: Re: [Dime] WG Review: Recharter of Diameter 
> Maintenance and Extensions(dime)
> 
> Hi,
> 
> >> on-going work on defining RADIUS extensions and the DIME WG will 
> >> ensure that work done in RADEXT is also available for Diameter."  
> >> This is an incredibly poor idea:
> >> (though there's little real danger of that happening in 
> the radext WG 
> >> ;-), but to tie Diameter & RADIUS together at the hip is 
> practically 
> >> criminal.
> >> compatibility is not.  This was discussed, as you know, on 
> the dime 
> >> list with no objections to the idea of limiting RADIUS-Diameter 
> >> compatibility; however the offending sentence remains.
> >>
> >
> I posted on this topic already earlier (probably missed in 
> the mail flood). I share the concern Glen has regarding the 
> RADIUS compatibility.
> 
> Cheers,
> 	Jouni
> 
> 
> 
> >
> >
> > Dan
> >
> >> ...
> >>
> >>

---

From: Tom Taylor <[email-masked]>
Date: Thu, 25 Jun 2009 10:35:59 -0400

I asked the question on the DIME list. I'll ask it again. I believe I read below 
that if the realm-based redirection draft becomes sufficiently mature it can be 
adopted as a WG item within the scope of the currently proposed charter. Can you 
confirm this?

Tom

[snip]

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 25 Jun 2009 17:01:27 +0200

Tom,

This is my understanding. I would add the fact that there should be
enough active participants (editors, committed reviewers) for this work
to be undergone and completed.  

Dan

> From: Tom Taylor [mailto:[email-masked]] 
> Sent: Thursday, June 25, 2009 5:36 PM
> To: Romascanu, Dan (Dan)
> I asked the question on the DIME list. I'll ask it again. I 
> believe I read below that if the realm-based redirection 
> draft becomes sufficiently mature it can be adopted as a WG 
> item within the scope of the currently proposed charter. Can 
> you confirm this?
> 
> Tom
> 
> >> Cc: 'Hannes Tschofenig'; [email-masked]; [email-masked]; 
> >> [email-masked]
> >> I see.  Unfortunately, I can't see any mention of the 
> problem in the 
> >> revised charter, either, unless it is your opinion that 
> realm-based 
> >> redirection would be an extension to the Diameter Base 
> Protocol (not 
> >> unreasonable).
> > 
> > Something on this lines. The  WG decided to use extensions as a 
> > generic denomination of many applications of various kinds 
> so that the 
> > text needs not be changed each time. There is always an 
> opportunity to

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 25 Jun 2009 16:07:13 +0300

Glen, 

This is not the last time we are going to submit a recharter proposal to
the IESG. In fact, this recharter proposal is in relationship to the
Hums we did at the last IETF meeting.

The Hum and the rechartering activity are not related to each other. 

Ciao
Hannes

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Romascanu, Dan (Dan)
>Sent: 25 June, 2009 10:38
>To: Glen Zorn; [email-masked]
>Cc: [email-masked]
>Maintenance andExtensions(dime)
>
>Glen,
>
>Rechartering and the "hum" for adoption of a document as WG 
>item need not be necessarily serialized. Rechartering is about 
>approving to work on a specific problem. The "hum" 
>acknowledges (or not) that a certain document is good enough 
>to be the 00 version of the WG I-D that will provide a 
>solution to the problem. Of course, if rechartering is not 
>some time may be won by runing the "hum" and the rechartering 
>review in parallel. 
>
>Dan
>
>
>> From: [email-masked] [mailto:[email-masked]] On Behalf 
>> Of Glen Zorn
>> ml).  The "hum" period ends tomorrow, yet the new charter 
>has already 
>> been submitted to the IESG.  Apparently there has been some 
>> unintentional oversight.
>> 
>> ...
>> 
>>

---

From: jouni korhonen <[email-masked]>
Date: Thu, 25 Jun 2009 19:18:47 +0300

Hi Dan,

The following text in the proposed charter:

"The IETF has completed work on the Diameter Base protocol and is
working on revising the base protocol specification. There is on-going
work on defining RADIUS extensions and the DIME WG will ensure
that work done in RADEXT is also available for Diameter."

In my opinion it is not Dime's responsibility to follow what RADEXT  
does and try to align with them. Especially the line "the DIME WG will  
ensure that work done in RADEXT is also available for Diameter" is  
scary. If RADEXT is in a process of upgrading RADIUS with all Diameter  
functionality, why should we care about aligning with them?

I would just write that RADEXT and Dime will work together for the  
general good of AAA. There are topics that concern both.. like  
internationalization etc.

CHeers,
	Jouni

---

From: Mark Jones <[email-masked]>
Date: Thu, 25 Jun 2009 14:29:34 -0400

Hi Dan,

I agree with Jouni and Glen. I see no motivation for a general commitment that "work done in RADEXT is also available for Diameter". Following Jouni's suggestion, I propose updating the charter text to read:

"The IETF has completed work on the Diameter Base protocol and is
working on revising the base protocol specification. There is also 
on-going work in the RADEXT WG on defining RADIUS extensions. 
The DIME WG will work with the RADEXT WG to harmonize approaches on
new AAA topics that concern both groups."

Regards
Mark

> Behalf Of jouni korhonen
> Sent: June 25, 2009 9:19 AM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; Glen Zorn; [email-masked]

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 26 Jun 2009 06:22:45 +0700

> consider problematic and how you propose to change it?

Certainly: delete the sentence "There is on-going work on defining RADIUS
extensions and the DIME WG will ensure that work done in RADEXT is also
available for Diameter."

...

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 26 Jun 2009 06:25:15 +0700

Romascanu, Dan (Dan) [mailto:[email-masked]] writes:

> Tom,
> 
> This is my understanding. 

Thanks!

> I would add the fact that there should be

I think that that has been amply demonstrated on the list.

...

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 26 Jun 2009 06:43:30 +0700

Mark Jones [mailto:[email-masked]] writes:

> Hi Dan,
> 
> I agree with Jouni and Glen. I see no motivation for a general
> commitment that "work done in RADEXT is also available for Diameter".
> Following Jouni's suggestion, I propose updating the charter text to
> read:
> 

I actually don't see any reason to even mention RADIUS or radext in the
charter...

...

---

From: Alan DeKok <[email-masked]>
Date: Fri, 26 Jun 2009 02:09:19 +0200

> I actually don't see any reason to even mention RADIUS or radext in the

  If the groups don't need to coordinate, does this mean that the RADEXT
documents can remove all "Diameter considerations" sections?

  If there aren't any RADIUS <-> Diameter gateways in production
environments, this would seem to be a reasonable thing to do.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 26 Jun 2009 07:27:54 +0700

> documents can remove all "Diameter considerations" sections?

I had thought that that was pretty much the consensus reached during the
radext "virtual interim" (bowing to the radext Chairs, of course).