Subject: Re: [Dime] re-chartering

From: jouni korhonen <[email-masked]>
Date: Thu, 1 Dec 2011 22:41:05 +0200

Frank,

hanks for the comments. See some stuff inline.

On Nov 30, 2011, at 12:39 PM, Frank Brockners (fbrockne) wrote:

> Thanks for the updated version. Two minor comments:
> 
> - typo: s/for a bulk/for bulk/

Ack.

> 
> - On "and an appropriate use of the Diameter protocol".
>  Do we have a clear description of what "an appropriate
>  use of the Diameter protocol" is? Unless we have this,

Appropriate being what fits under RFC3588(bis) umbrella.

>  wouldn't the "require verification that the proposed
>  extension is needed" provide the justification
>  and evaluation that the extension would make sense?
>  In which case wouldn't it make sense to drop
>  "and an appropriate use of the Diameter protocol"?
> 
> Thoughts?

Hmm.. good point. I don't myself have a firm opinion. 

- Jouni

> 
> Thanks, Frank
> 
> 
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
>> jouni korhonen
>> Sent: Wednesday, November 30, 2011 10:40 AM
>> To: [email-masked]
>> Subject: Re: [Dime] re-chartering
>> 
>> Folks,
>> 
>> The next revision of the new charter proposal. I added Mark's &
>> Lothar's comments. I recall someone had concerns on the intended
>> "extension for a bulk and group signaling" solution space the current
>> text directs to. If so, just propose changes to the text.
>> 
>> - Jouni
>> 
>> 
>> 
>> 2011-xx-yy charter
>> Diameter Maintenance and Extensions (dime)
>> ------------------------------------------
>> 
>> Charter
>> 
>> Current Status: Active
>> 
>> 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 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 configuration information within the network, and other
>>  signaling purposes.
>> 
>>  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 a bulk and group signaling. The aim of this
>>  work is to study and standardize a solution for handling a group of
>>  sessions within the Diameter base protocol context. The solution
>> would
>>  define how to identify and handle grouped sessions as a one combined
>>  entity for 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 and an appropriate use of the Diameter protocol.
>>  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
>>  Sep 201x - Submit 'Diameter Application Design Guidelines' to the
>> IESG for consideration as a BCP document
>>  Done     - Submit 'Diameter NAT Control Application' to the IESG for
>> consideration as a Proposed Standard
>>  Sep 201x - Submit 'Realm-Based Redirection In Diameter' 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
>>  Nov 2011 - Submit 'Diameter Support for Proxy Mobile IPv6 Localized
>> Routing' to the IESG for consideration as a Proposed Standard
>>  Jul 201x - Submit 'Diameter Support for EAP Re-authentication
>> Protocol' to the IESG for consideration as a Proposed Standard
>>  Sep 201x - Submit Revision of 'Diameter Network Access Server
>> Application - RFC 4005bis' to the IESG for consideration as a Proposed
>> Standard
>> 
>> 
>> _______________________________________________
>> DiME mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dime

---

From: jouni korhonen <[email-masked]>
Date: Thu, 1 Dec 2011 22:49:37 +0200

Hi Marco,

Thanks for the input. See inline.

On Nov 30, 2011, at 1:33 PM, Marco Liebsch wrote:

> Hi Jouni,
> thanks for the updated charter proposal. Please find some minor comments
> and proposals inline.
> 
>  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 other
>  signaling purposes.

Ack.

> 
> ..
> 
> Original text about the bulk operations work item: 
>  sessions within the Diameter base protocol context. The solution would
> If we plan to look at bulk operation use cases also for NASREQ and Credit Control applications,
> we may not refer to '..Diameter base protocol context', which I understand as RFC3588.
> 
> Also, the last sentence about '..as a one combined entity' is not so clear to me.

Right. Bad wording. What I meant by "handle grouped sessions as a one combined entity" is merely like being able to name a group of session with a single name/identity and use that in signaling. In that sense one message would be targeted to one combine set (=entity) of session.

> 
> What about the following:
> 
>  - Protocol extension for /- a -/ bulk and group signaling. The aim of this
>  work is to study and standardize a solution for handling /-a-/ group/+s+/ of

So multiple groups..?

>  sessions within /-the Diameter base protocol -/ /+ Diameter  applications' +/ context.

So you would not extend the base protocol, rather each application separately using some well-defined rule? Would this them imply that a new application need explicitly stated & described support for bulk/group signaling?

>  The solution would define how to identify and handle grouped sessions 
>  /-as a one combined entity for commands and operations-/
>  /+and how to signal and perform Diameter operations on these groups+/. 

- Jouni

> Thanks,
> marco
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> jouni korhonen
>> Sent: Mittwoch, 30. November 2011 10:40
>> To: [email-masked]
>> The next revision of the new charter proposal. I added Mark's & Lothar's
>> comments. I recall someone had concerns on the intended "extension for a
>> bulk and group signaling" solution space the current text directs to. If so, just
>> propose changes to the text.
>> 
>> - Jouni
>> 
>> 
>> 
>> 2011-xx-yy charter
>>  and extensions to the Diameter protocol required to enable its use for
>>  authentication, authorization, accounting, charging in network access,
>>  extensions to Diameter Base protocol that can be considered as enhanced
>>  features or bug fixes.
>> 
>>  - 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.
>> 
>>  sessions within the Diameter base protocol context. The solution would
>>  Additionally, Diameter-based systems require interoperability in order
>>  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 '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
>>  Done     - Submit 'Diameter Proxy Mobile IPv6' as DIME working group item
>>  Done     - Submit 'Quality of Service Attributes for Diameter' to the IESG for
>>  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
>>  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
>>  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 Revision of 'Diameter Base Protocol' to the IESG for
>>  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
>>  Done     - Submit Revision of 'Diameter Network Access Server Application -
>> RFC 4005bis' as DIME working group item
>>  Sep 201x - Submit 'Diameter Application Design Guidelines' to the IESG for
>> consideration as a BCP document
>>  Sep 201x - Submit 'Realm-Based Redirection In Diameter' to the IESG for
>>  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
>>  Jul 201x - Submit 'Diameter Support for EAP Re-authentication Protocol' to
>> the IESG for consideration as a Proposed Standard
>>  Sep 201x - Submit Revision of 'Diameter Network Access Server Application -
>> RFC 4005bis' to the IESG for consideration as a Proposed Standard
>> 
>>

---

From: jouni korhonen <[email-masked]>
Date: Thu, 1 Dec 2011 22:51:52 +0200

Hi Qin,

Regarding your question, see my latest reply to Marco. The "combined entity" being a signle name/identification for a group of sessions. I admit the wording is not the best one ;)

- Jouni

On Dec 1, 2011, at 4:28 AM, Qin Wu wrote:

> This version looks good to me. One minor comment:
> It is not clear to what "one combined entity" is in the bulk and group sigaling item? functinality entity or physical entity?
> How about change it into "one single association"?
> 
> Regards!
> -Qin
> ----- Original Message ----- 
> From: "jouni korhonen" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, November 30, 2011 5:39 PM
>> The next revision of the new charter proposal. I added Mark's & Lothar's comments. I recall someone had concerns on the intended "extension for a bulk and group signaling" solution space the current text directs to. If so, just propose changes to the text.
>> 
>> - Jouni
>> 
>> 
>> 
>> 2011-xx-yy charter
>>    Archive:            http://www.ietf.org/mail-archive/web/dime/current/maillist.html
>> 
>> 
>> 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 '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 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 '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 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
>> Sep 201x - Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document
>> Done     - Submit 'Diameter NAT Control Application' to the IESG for consideration as a Proposed Standard
>> Sep 201x - Submit 'Realm-Based Redirection In Diameter' 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
>> Nov 2011 - Submit 'Diameter Support for Proxy Mobile IPv6 Localized Routing' to the IESG for consideration as a Proposed Standard
>> Jul 201x - Submit 'Diameter Support for EAP Re-authentication Protocol' to the IESG for consideration as a Proposed Standard
>> Sep 201x - Submit Revision of 'Diameter Network Access Server Application - RFC 4005bis' to the IESG for consideration as a Proposed Standard
>> 
>>

---

From: Qin Wu <[email-masked]>
Date: Fri, 02 Dec 2011 09:06:34 +0800

That address my concern. Thanks.

-Qin
----- Original Message ----- 
From: "jouni korhonen" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 02, 2011 4:51 AM
Subject: Re: [Dime] re-chartering

Hi Qin,

- Jouni

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 2 Dec 2011 08:40:47 +0000

Hi Jouni,

please see my feedback inline.

> From: jouni korhonen [mailto:[email-masked]]
> Sent: Donnerstag, 1. Dezember 2011 21:50
> To: Marco Liebsch
> Cc: [email-masked]
> > thanks for the updated charter proposal. Please find some minor
> > comments and proposals inline.
> >
> > provisioning /+ of +/ configuration information within the network,
> > and other  signaling purposes.
> 
> Ack.
> 
> >
> > ..
> >
> > If we plan to look at bulk operation use cases also for NASREQ and
> > Credit Control applications, we may not refer to '..Diameter base protocol
> context', which I understand as RFC3588.
> >
> Right. Bad wording. What I meant by "handle grouped sessions as a one
> combined entity" is merely like being able to name a group of session with a
> single name/identity and use that in signaling. In that sense one message
> would be targeted to one combine set (=entity) of session.

Sure, that's the optimal case. But does the charter text need to comprise this
as requirement? Why not opt for group operation by identifying the group
of users with a list of Session-IDs? No strong opinion here, so if you think the
text is clear, fine.

> >  - Protocol extension for /- a -/ bulk and group signaling. The aim of
> > this  work is to study and standardize a solution for handling /-a-/
> > group/+s+/ of
> 
> So multiple groups..?

Not within the same operation. But separate bulk operations could be done
in the context of different groups. So, multiple groups. If the text points to a single
bulk operation, then it's one group.

> So you would not extend the base protocol, rather each application
> separately using some well-defined rule? Would this them imply that a new
> application need explicitly stated & described support for bulk/group
> signaling?

If we can extend the base with a mechanism for bulk operation that can
be applied by individual applications, that would be a good choice. My only
concerns with the written text was to limit bulk operation to messages
of the base protocol (3588) and to exclude other applications' messages from
being bulk-operation enabled.

marco

> > /-as a one combined entity for commands and operations-/  /+and how to
> > signal and perform Diameter operations on these groups+/.
> 
> 
> - Jouni
> 
> >
> > Thanks,
> > marco
> >
> >
> >
> >
> >
> >> Of jouni korhonen
> >> for  authentication, authorization, accounting, charging in network
> >> access,  provisioning configuration information within the network,
> >> and other  signaling purposes.
> >>
> >> enhanced  features or bug fixes.
> >>
> >> 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.
> >>
> >> would  define how to identify and handle grouped sessions as a one
> >> combined  entity for commands and operations.
> >>
> >> 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 and an appropriate use of the Diameter
> protocol.
> group
> >> RFC 4005bis' as DIME working group item  Sep 201x - Submit 'Diameter
> >> Application Design Guidelines' to the IESG for consideration as a BCP
> >> document
> >> Routing' to the IESG for consideration as a Proposed Standard  Jul
> >> 201x - Submit 'Diameter Support for EAP Re-authentication Protocol'
> >> to the IESG for consideration as a Proposed Standard  Sep 201x -
> >> Submit Revision of 'Diameter Network Access Server Application - RFC
> >> 4005bis' to the IESG for consideration as a Proposed Standard
> >>
> >>

---

From: jouni korhonen <[email-masked]>
Date: Wed, 7 Dec 2011 13:15:59 +0200

Marco,

> of users with a list of Session-IDs? No strong opinion here, so if you think the

How about "The solution would define how to identify and handle grouped
           sessions in commands and operations."

> being bulk-operation enabled.

If the base protocol has support, then each new application can make use of it. I think we have not decided yet whether bulk signaling support means new base protocol messages or something else. At the moment I would like to keep it in this way.

- Jouni

---

From: jouni korhonen <[email-masked]>
Date: Wed, 7 Dec 2011 13:16:57 +0200

Folks,

Yet another revision. 

- Jouni

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

2011-xx-yy charter

 Charter

 Current Status: Active

 Chairs:

 Mailing Lists:

  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 other
  signaling purposes.

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

  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:

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 7 Dec 2011 11:25:05 +0000

Jouni,

I am fine with both of your proposals below.

Thanks,
marco

> Sent: Mittwoch, 7. Dezember 2011 12:16
> To: Marco Liebsch
> Cc: [email-masked]
> >>> access, provisioning /+ of +/ configuration information within the
> >>> network, and other  signaling purposes.
> >>
> >> Ack.
> >>
> >>>
> >>> ..
> >>>
> >>> Also, the last sentence about '..as a one combined entity' is not so
> >>> clear to
> >> me.
> >>
> >> combined entity" is merely like being able to name a group of session
> >> with a single name/identity and use that in signaling. In that sense
> >> one message would be targeted to one combine set (=entity) of session.
> >
> > Sure, that's the optimal case. But does the charter text need to
> > comprise this as requirement? Why not opt for group operation by
> > identifying the group of users with a list of Session-IDs? No strong
> > opinion here, so if you think the text is clear, fine.
> 
> >>> - Protocol extension for /- a -/ bulk and group signaling. The aim
> >>> of this  work is to study and standardize a solution for handling
> >>> /-a-/ group/+s+/ of
> >>
> >> So multiple groups..?
> >
> > Not within the same operation. But separate bulk operations could be
> > done in the context of different groups. So, multiple groups. If the
> > text points to a single bulk operation, then it's one group.
> >
> >>
> >>> sessions within /-the Diameter base protocol -/ /+ Diameter
> applications'
> >> +/ context.
> >>
> >> separately using some well-defined rule? Would this them imply that a
> >> new application need explicitly stated & described support for
> >> bulk/group signaling?
> >
> > be applied by individual applications, that would be a good choice. My
> > only concerns with the written text was to limit bulk operation to
> > messages of the base protocol (3588) and to exclude other
> > applications' messages from being bulk-operation enabled.
> 
> If the base protocol has support, then each new application can make use of
> it. I think we have not decided yet whether bulk signaling support means
> new base protocol messages or something else. At the moment I would like
> to keep it in this way.
> 
> - Jouni
> 
> 
> 
> >
> > marco
> >
> >>
> >>
> >>> The solution would define how to identify and handle grouped
> >>> sessions /-as a one combined entity for commands and operations-/
> >>>> From: [email-masked] [mailto:[email-masked]] On
> >>>> Behalf Of jouni korhonen
> >>>> "extension for a bulk and group signaling" solution space the
> >>>> current text directs to. If so, just propose changes to the text.
> >>>>
> >>>> - Jouni
> >>>>
> >>>>
> >>>>
> >>>> 2011-xx-yy charter
> >>>> guidelines for design of Diameter extensions. It will detail when
> >>>> to consider reusing an existing application and when to develop a
> >>>> new application.
> >>>>
> >>>> - Protocol extension for a bulk and group signaling. The aim of
> >>>> this work is to study and standardize a solution for handling a
> >>>> group of sessions within the Diameter base protocol context. The
> >>>> solution would  define how to identify and handle grouped sessions
> >>>> as a one combined  entity for commands and operations.
> >>>>
> >>>> evaluate  any potential extensions and require verification that
> >>>> the proposed  extension is needed and an appropriate use of the
> >>>> Diameter
> >> protocol.
> Diameter'
> >> to
> consideration
> >> as
> working
> working
> Application
> >> -
> >>>> RFC 4005bis' as DIME working group item  Sep 201x - Submit
> >>>> 'Diameter Application Design Guidelines' to the IESG for
> >>>> consideration as a Proposed Standard Sep 201x - Submit 'Realm-Based
> >>>> Redirection In Diameter' to the IESG for consideration as a
> >>>> Proposed Standard
> >>>> Submit Revision of 'Diameter Network Access Server Application -

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 7 Dec 2011 12:36:07 +0100

Hi,

What is the answer to the question that can be asked (and will be asked)
- what does 'other signaling purposes' mean in the first paragraph? 

Thanks and Regards,

Dan

Of
> jouni korhonen
> Sent: Wednesday, December 07, 2011 1:17 PM
> To: [email-masked]
(MIBs)
or
Routing
the
Routing

---

From: jouni korhonen <[email-masked]>
Date: Thu, 8 Dec 2011 21:55:34 +0200

Dan,

> - what does 'other signaling purposes' mean in the first paragraph? 

Right. Good point. Here we refer to the text in Section 1.1 about new uses of Diameter. Maybe following rewording helps:

  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 signaling uses within the extensibility rules of Diameter.

I.e. within a new application we are rightfully allowed to use Diameter beyond authentication and accounting applications. At least that is my understanding of the Section 1.1 "tone":

   ...
   network access [NASREQ].  It is also possible for the base protocol
   to be extended for use in new applications, via the addition of new
   commands or AVPs.  At this time the focus of Diameter is network
   access and accounting applications.  A truly generic AAA protocol
   ...

- Jouni

---

From: jouni korhonen <[email-masked]>
Date: Tue, 13 Dec 2011 23:18:29 +0200

Folks, 

Yet another revision. Any further comments on the charter text? I also updated the goal & milestones.

- Jouni & Lionel

2011-xx-yy charter

 Charter

 Current Status: Active

 Chairs:

 Mailing Lists:

  new signaling uses within the extensibility rules of the Diameter base
  protocol.

Goals and Milestones:
  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

---

From: Mark Jones <[email-masked]>
Date: Thu, 15 Dec 2011 11:23:27 -0500

> updated the goal & milestones.
Looks good, Jouni. Assuming Dan accepts the clarification on "new signaling
uses", when does this proposal go before the IESG?

/Mark

>     Archive:
> http://www.ietf.org/mail-archive/web/dime/current/maillist.html
>
>
>  Done     - Submit 'Quality of Service Parameters for Usage with Diameter'
> to the IESG for consideration as a Proposed Standard.
>  Done     - Submit 'Quality of Service Attributes for Diameter' to the
>  Done     - Submit ' Diameter Credit Control Application MIB' to the IESG
> for consideration as an Informational RFC
>  Done     - Submit Revision of 'Diameter Network Access Server Application
> - RFC 4005bis' as DIME working group item
> Routing' to the IESG for consideration as a Proposed
>  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
>
>

---

From: jouni korhonen <[email-masked]>
Date: Thu, 22 Dec 2011 09:15:12 +0200

Dan,

On Dec 20, 2011, at 7:51 PM, Romascanu, Dan (Dan) wrote:

> Yes.
>  
> Can you send me a clean and final version, so that I can ask the Secretariat to send it for internal review?
>  
> Thanks and Regards,
>  
> Dan
>  
>  
>  

Here is the latest revision. NOTE. I actually added a milestone for the new bulk & group signaling work we wanted to do:

o Aug 2012 - Submit a document on 'Protocol extension for bulk and group signaling' as a working group item
o Aug 2013 - Submit a document on 'Protocol extension for bulk and group signaling' to the IESG for consideration as a Proposed Standard

I wanted to give it two meeting cycles.. 

- JOuni

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

2011-xx-yy charter

Charter

 Current Status: Active

 Chairs:

 Mailing Lists:

Goals and Milestones:
  Done     - Submit 'Diameter Credit Control Application MIB' to the IESG for consideration as an Informational RFC
  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: Fri, 23 Dec 2011 12:10:14 +0700

> I wanted to give it two meeting cycles.. 

One more time, AAA & in particular Diameter is NOT a generic signalling
protocol, no matter how much other SDOs might want to twist it into such
a thing.

>   define how to identify and handle grouped sessions in commands and

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.

...

---

From: Jouni <[email-masked]>
Date: Fri, 23 Dec 2011 10:25:02 +0200

> 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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 23 Dec 2011 12:54:57 +0100

Should we also replace signaling by session management in the
Description of the Working Group?

  new session management uses within the extensibility rules of the 
  Diameter base protocol. 

Dan

> From: Jouni [mailto:[email-masked]]
> Sent: Friday, December 23, 2011 10:25 AM
> To: Glen Zorn
> Cc: Romascanu, Dan (Dan); [email-masked]

---

From: Glen Zorn <[email-masked]>
Date: Sat, 24 Dec 2011 18:11:46 +0700

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