Subject: Re: [Dime] re-chartering

From: jouni korhonen <[email-masked]>
Date: Mon, 2 Jan 2012 09:31:16 +0200

Fine with me. Thanks for the input.

- Jouni

On Dec 24, 2011, at 1:11 PM, Glen Zorn wrote:

> On 12/23/2011 6:54 PM, Romascanu, Dan (Dan) wrote:
>> Should we also replace signaling by session management in the
>> Description of the Working Group?
> 
> Good idea; it might be good to be more specific that this is _Diameter_
> management as well, since "session" means lots of different things to
> different people, many of those things having nothing to do w/AAA.
> 
>> 
>>  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, charging in network access,
>>  provisioning of configuration information within the network, and for
>>  new session management uses within the extensibility rules of the 
>>  Diameter base protocol. 
>> 
>> Dan
>> 
>> 
>>> -----Original Message-----
>>> From: Jouni [mailto:[email-masked]]
>>> Sent: Friday, December 23, 2011 10:25 AM
>>> To: Glen Zorn
>>> Cc: Romascanu, Dan (Dan); [email-masked]
>>> Subject: Re: [Dime] re-chartering
>>> 
>>> 
>>> 
>>>>> - Protocol extension for bulk and group signaling. The aim of this
>>>>> work is to study and standardize a solution for handling groups of
>>>>> sessions within the Diameter base protocol context. The solution
>>> would
>>>>> define how to identify and handle grouped sessions in commands and
>>>>> operations.
>>>> 
>>>> If you insist upon ignoring such important applications as state
>>>> synchronization between agents, at least please change "signalling"
>>> to
>>>> "session management" since that at least comes within spitting
>>> distance
>>>> of actual AAA while generic "signalling" does not.
>>>> 
>>>> ...
>>> 
>>> - Protocol extension for bulk and group session management. The aim
>> of
>>>   this work is to study and standardize a solution for handling
>> groups
>>>   of sessions within the Diameter base protocol context. The solution
>>>   would define how to identify and handle grouped sessions in
>> commands
>>>   and operations.
>>> 
>>> Ok with me.
>>> 
>>> 
>>> - Jouni
>

---

From: jouni korhonen <[email-masked]>
Date: Mon, 2 Jan 2012 12:40:16 +0200

Just to make a clean post to the list. The below is the revision submitted for the next IESG meeting regarding DIME rechartering.

- Jouni

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

Diameter Maintenance and Extensions (dime)
-----------------------------------------

Current Status: Active

Last Modified: 2011-12-27

 Chairs:
     Lionel Morand <[email-masked]>
     Jouni Korhonen <[email-masked]>

 Operations and Management Area Directors:
     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 DIME working group plans 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.

  - 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.

  - 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.

  - Protocol extension for bulk and group session management. The aim of
  this work is to study and standardize a solution for handling groups of
  sessions within the Diameter base protocol context. The solution would
  define how to identify and handle grouped sessions in commands and
  operations.

  Additionally, Diameter-based 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 be used to ensure this.

Goals and Milestones:
  Done     - Submit the following two Diameter Mobility documents to the IESG for consideration as a Proposed Standards:* 'Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction' * 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction'
  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.
  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
  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
  Done     - Submit 'Diameter NAT Control Application' as DIME working group item
  Done     - Submit 'Diameter Capabilities Update' as DIME working group item
  Done     - Submit 'Diameter Credit Control Application MIB' to the IESG for consideration as an Informational RFC
  Done     - Submit 'Diameter Base Protocol MIB' to the IESG for consideration as an Informational RFC
  Done     - Submit 'Diameter Capabilities Update' to the IESG for consideration as a Proposed Standard
  Done     - Submit 'Diameter Extended NAPTR' as DIME working group item
  Done     - Submit 'Realm-Based Redirection In Diameter' as DIME working group item
  Done     - Submit 'Diameter Support for Proxy Mobile IPv6 Localized Routing' as DIME working group item
  Done     - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' as DIME working group item
  Done     - Submit 'Diameter Priority Attribute Value Pairs' as DIME working group item
  Done     - Submit 'Diameter IKEv2 PSK' as DIME working group item
  Done     - Submit Revision of 'Diameter Base Protocol' to the IESG for consideration as a Proposed Standard
  Done     - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' to the IESG for consideration as a Proposed Standard
  Done     - Submit 'Diameter Priority Attribute Value Pairs' to the IESG for consideration as a Proposed Standard
  Done     - Submit Revision of 'Diameter Network Access Server Application - RFC 4005bis' as DIME working group item
  Done     - Submit 'Diameter NAT Control Application' to the IESG for consideration as a Proposed Standard
  Done     - Submit 'Diameter IKEv2 PSK' to the IESG for consideration as a Proposed Standard
  Done     - Submit 'Diameter Extended NAPTR' to the IESG for consideration as a Proposed Standard
  Done     - Submit 'Diameter Support for Proxy Mobile IPv6 Localized Routing' to the IESG for consideration as a Proposed 
  Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the IESG for consideration as a Proposed Standard
  Mar 2012 - Submit Revision of 'Diameter Network Access Server Application - RFC 4005bis' to the IESG for consideration as a Proposed Standard
  May 2012 - Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document Standard
  Jul 2012 - Submit 'Diameter Support for EAP Re-authentication Protocol' to the IESG for consideration as a Proposed Standard
  Aug 2012 - Submit a document on 'Protocol extension for bulk and group signaling' as a working group item
  Aug 2013 - Submit a document on 'Protocol extension for bulk and group signaling' to the IESG for consideration as a Proposed Standard

---

From: Glen Zorn <[email-masked]>
Date: Thu, 05 Jan 2012 16:11:15 +0700

On 1/2/2012 5:40 PM, jouni korhonen wrote:

>   - Diameter application design guideline. 

s/guideline/guidelines

>   This document will provide

About a month ago there was a brief thread about this draft, in part
containing a promise from one of the authors to "initiate a mail with at
least the points that I would like to see clarified with this document.
And we can use it to set-up after that a confcall. Is it OK?".
Apparently this _was_ OK, but a month has passed and nothing has
happened.  In addition, it has now been nine months since anybody
considered this draft important enough to change the rev number and
resubmit it w/o any other changes (a 2 minute task at worst).  Since
there is clearly zero interest in this work, why is it still in the charter?

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 5 Jan 2012 10:39:14 +0100

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Glen Zorn

[[DR]] I believe that this work is needed for people out of the IETF
(other SDOs, vendors) or people in the IETF with less experience in
Diameter design extensions. Do we care how these extensions are
designed? I believe the answer is yes or should be yes in this WG. Also,
in the OPS area SNMP (SMI), YANG, RADIUS have each similar documents
which provide guidelines for those who design extensions and data
models. 

Dan

---

From: Glen Zorn <[email-masked]>
Date: Fri, 06 Jan 2012 15:24:05 +0700

On 1/5/2012 4:39 PM, Romascanu, Dan (Dan) wrote:

...

> (other SDOs, vendors) 

Other SDOs have made it painfully clear that they will do precisely as
they like with Diameter, regardless of any input from the IETF.  How is
the existence of this document going to change that?

> or people in the IETF with less experience in

I will not presume to comment upon the others, but the RADIUS
"guidelines" are an abomination, the major purpose of which seems to be
to cripple RADIUS implementers while protecting a single vendor's
extremely limited view of how things should be done

---

From: jouni korhonen <[email-masked]>
Date: Fri, 6 Jan 2012 10:28:04 +0200

Glen, 

> the existence of this document going to change that?

And a lot of this originates from their "own interpretations" of RFC3588. Every measure to fix this is for common good.. I hope :) But I sort of agree the train left in some cases.

- Jouni

---

From: Glen Zorn <[email-masked]>
Date: Sat, 07 Jan 2012 14:17:59 +0700

On 1/6/2012 3:28 PM, jouni korhonen wrote:

> And a lot of this originates from their "own interpretations" of RFC3588. 

OK, I'll bite: which part of 3588 can be interpreted to say that
Diameter is a general-purpose signaling protocol?

Every measure to fix this is for common good..

How can any amount of "guidance" fix willful misuse?

 I hope :) But I sort of agree the train left in some cases.

---

From: jouni korhonen <[email-masked]>
Date: Mon, 9 Jan 2012 13:19:19 +0200

Glen,

> Diameter is a general-purpose signaling protocol?

It does not either specifically prohibit that and also gives excellent
tools for such usage. One can easily create a new command that has no
concept of session, does not maintain any auth-session state etc.

> How can any amount of "guidance" fix willful misuse?

My sincere hope is that education could fix stuff and new
breed of developers could do things better ;) Might be
wishful thinking though.

- Jouni