Subject: [Dime] clearer draft-tsou-dime-routing-problem-statement-01 for the DT meeting on Jan 15th, Thu

From: Tina TSOU <[email-masked]>
Date: Wed, 14 Jan 2009 09:23:38 +0800

Dear all,
The .txt and .xml file could be found in 
http://groups.google.com/group/diameter-routing
http://groups.google.com/group/diameter-routing/browse_thread/thread/899e7568e09634b0

Wish you a prosperous and healthy New Year:D

B. R.
Tina

----- Original Message ----- 
From: Tina TSOU 
To: [email-masked] 
Sent: Wednesday, January 14, 2009 9:15 AM
Subject: clearer draft-tsou-dime-routing-problem-statement-01 for the DT meeting on Jan 15th, Thu

Dear all,
As promised, attached please find a clearer draft-tsou-dime-routing-problem-statement-01 for the DT meeting on Jan 15th, Thu.
Problem 3 has been deleted, and more explanation to problem 2 use case has been added.

Comments are very welcome before and in the DT meeting.

Wish you a prosperous and healthy New Year:D

B. R.
Tina

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "diameter-routing" group. 
To post to this group, send email to [email-masked] 
To unsubscribe from this group, send email to [email-masked] 
For more options, visit this group at http://groups.google.com/group/diameter-routing?hl=en
-~----------~----~----~----~------~----~------~--~---

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

Internet Engineering Task Force                             T. Tsou, Ed.
Internet-Draft                                       Huawei Technologies
Intended status: Informational                          January 14, 2009
Expires: July 18, 2009

                   Diameter Routing Problem Statement
              draft-tsou-dime-routing-problem-statement-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 18, 2009.

Abstract

   This document describes use cases that suggest requirements to be
   able to add constraints to the existing Diameter routing mechanisms.

1.  Introduction

   In [RFC3588], routing of request messages from source to the
   destination is based solely on the routing decision made by each node
   along the path.  This document presents three different cases where
   the basic Diameter routing behaviour is not sufficient to meet the
   requirements.  It then provides three problem statements
   corresponding to the three cases.  Further analysis is required to

Tsou                      Expires July 18, 2009                 [Page 1]

Internet-Draft     Diameter Routing Problem Statement       January 2009

   determine if the number of problems to be solved can be reduced.

2.  Requirements Language

   This document contains no requirements language.

3.  Use Cases

3.1.  3GPP Wireless LAN (WLAN) Access Architecture

   One example of a stateful proxy is in the 3GPP WLAN IP access
   architecture [TS23.234].  The 3GPP WLAN interworking architecture
   extends 3GPP services to the WLAN access side.  It enables a 3GPP
   subscriber to use a WLAN to access 3GPP services.

   WLAN AAA provides access to the WLAN to be authenticated and
   authorised through the 3GPP system.  This access control can permit
   or deny a subscriber the access to the WLAN system and/or the
   interworking with the 3GPP system.

   There are two WLAN interworking reference models:

   1.  In the non-roaming case, the model includes the WLAN access
       network and the 3GPP AAA server in the home network.  The 3GPP
       AAA server is responsible for access control as well as charging.

   2.  In the roaming case, the model includes the WLAN access network,
       the 3GPP AAA proxy in the visited network and the 3GPP AAA server
       in the home network.  The 3GPP AAA server is responsible for
       access control.  Charging records may be generated by the AAA
       proxy and/or the AAA server.  The AAA proxy relays access control
       and charging messages to the AAA server.  The AAA proxy will also
       do offline charging, if required.

   The roaming case presents two problems for which the Diameter routing
   mechanism described in [RFC3588] does not offer any unambiguous and
   standard solution.

   1.  Network selection: Selecting an initial message path for the
       Diameter session through (possibly many) alternative visited
       network(s) to the home network.

   2.  Explicit Routing: Maintaining the selected message path for all
       messages in the Diameter session.

   These problems are discussed in detail in the following sections.

Tsou                      Expires July 18, 2009                 [Page 2]

Internet-Draft     Diameter Routing Problem Statement       January 2009

3.1.1.  Initial Selection of Routing Path

   In the 3GPP model we are considering, the WLAN access network is
   simply a substitute for the radio access network of a cellular
   operator.  Two other operating entities are involved in providing IP
   service to the roaming user: a visited mobile network to which the
   WLAN access network is directly connected, and the user's home mobile
   network.

   Consider the realistic model where the WLAN access network is
   connected to multiple mobile networks with which the user's home
   network has roaming agreements.  A particular visited network has to
   be selected for authentication.  There are three possibilities:

   o  the WLAN access network automatically selects a preferred routing;

   o  the WLAN access network advertises the available networks to the
      UE, which makes an automatic selection based on pre-configured
      policy;

   o  the WLAN access network advertises the available networks to the
      UE, which presents the choices to the user and asks the user to
      make a selection.

   Once the visited network has been selected, Diameter currently does
   not fully standardize the means by which the Diameter client in the
   WLAN access network ensures that its initial request passes through
   the 3GPP AAA proxy in the chosen network.

3.1.2.  Maintaining the Routing Path

   After a successful authentication, a Diameter session is established
   involving (at least) the following stateful entities:

   o  The Diameter client in the WLAN AN

   o  a Diameter proxy (the 3GPP AAA proxy) in the selected visited
      mobile network, and

   o  a Diameter server in the UE's home realm.

   The functions assigned to the 3GPP AAA proxy include:

   o  reporting charging information to the offline charging system in
      the visited network;

   o  enforcing policies based on roaming agreements;

Tsou                      Expires July 18, 2009                 [Page 3]

Internet-Draft     Diameter Routing Problem Statement       January 2009

   o  service termination initiated by the visited network operator.

   These functions all require that state be maintained within the
   visited network.  The 3GPP choice is to maintain that state at the
   3GPP AAA proxy.  This means that the latter must remain in the
   messaging path for all subsequent messages relating to the same
   session.

   The network model with the client, the proxy and the server as
   described above is simplistic.  Operators would usually deploy more
   than one proxy in the visited network and more than one server in the
   home network for better availability and load sharing.  Relays are
   also used at the edges of these networks for topology hiding and load
   balancing.  Thus a realistic network model would typically involve
   some stateless agents also in the session path.

3.2.  Redirect Indication based on realm

   Consider an Operator; say Operator_A offering some service to
   Diameter client in its Realm; say Realm_A. For business/maintenance
   reasons, the operator wants to discontinue the service.  However the
   operator has asked another Operator; say Operator_B (serving Realm_B)
   to provide the service to the clients.  In this case, all the clients
   should be configured to contact Realm_B instead of Realm_A for the
   service.

   For smooth transition, agents may be employed in Realm_A which could
   answer with a redirect indication suggesting that the service
   requests may be sent to another realm; Realm_B in this case, so as to
   be served

4.  Problem Statements

   This section provides problem statements for the three use cases
   described above.

4.1.  Initial Network Selection

   Note: this problem statement is here for completeness.  There is
   agremeent that work on decorated NAI will go forward to remedy this
   specific problem.

   This is the statement of the problem posed by the case presented in
   Section 3.1.1.

   1.  Existing Diameter message routing behaviour: it is possible to
       direct a message through a specific intermediate realm using the

Tsou                      Expires July 18, 2009                 [Page 4]

Internet-Draft     Diameter Routing Problem Statement       January 2009

       decorated NAI mechanism within the User Name AVP.  However,
       [RFC3588] does not unambiguously specify how to handle the
       decorated NAI i.e. how the Diameter client and agents
       participating in request routing may use the decorated NAI to
       update the Destination-Realm AVP.

   2.  Undesirable behaviour in the existing method: unpredictable
       results since the required mechanism has not been fully
       standardized.

   3.  Desired behaviour: the intermediate realm specified in the
       decorated NAI is traversed first, followed by the home user
       realm.  This is required whenever a decorated NAI is presented.
       Section 3.1.1 describes the sort of environment where this
       requirement could arise.

4.2.  Path Maintenance

   This is the statement of the problem posed by the case presented in
   Section 3.1.2.

   1.  Existing Diameter message routing behaviour: each host along the
       path makes its own independent routing decisions.

   2.  Undesirable behaviour in the existing method: routing of all
       messages for a given session through the selected 3GPP AAA proxy
       is not guaranteed if the visited mobile network has multiple
       proxies or if there are other Diameter entities between the WLAN
       client and the target 3GPP proxy.

   3.  Desired behaviour: regardless of the intervening set of Diameter
       elements, all messages for a given session pass through the proxy
       initially selected.  This is required for stateful proxies only.
       Section 3.1.2 describes the sort of environment where this
       requirement could arise.

4.3.  Redirect Indication based on realm

   This is the statement of the problem posed by the case presented in
   Section 3.2.

   1.  Existing Diameter message routing behaviour: Redirect indication
       is provided at host level.  It provides a list of servers that
       may be contacted for the request to be served.

   2.  Undesirable behaviour in the existing method: Redirect indication
       is not provided at the realm level.  There is no option to
       provide a (list of) realm(s) that may be contacted for the

Tsou                      Expires July 18, 2009                 [Page 5]

Internet-Draft     Diameter Routing Problem Statement       January 2009

       request to be served.

   3.  Desired behaviour: Redirect indication could be provided at the
       realm level also.  The indication may specify a (list of)
       realm(s) which could be contacted for the request to be served.

5.  Acknowledgements

   Text on the 3GPP WLAN use cases was provided by Rajith R. Glen Zorn
   provided the problem statement template used in Section 4.

6.  IANA Considerations

   This memo includes no request to IANA.

7.  Security Considerations

   It is possible that there are security issues with the problems
   stated above, but they are not immediately evident.

8.  References

8.1.  Normative References

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

8.2.  Informative References

   [TS23.234]
              3GPP, "TS23.234v7.7.0, 3GPP system to Wireless Local Area
              Network (WLAN) interworking; System description",
              June 2008.

Tsou                      Expires July 18, 2009                 [Page 6]

Internet-Draft     Diameter Routing Problem Statement       January 2009

Author's Address

   Tina Tsou (editor)
   Huawei Technologies
   Section F, Huawei Industrial Base
   Bantian Longgang, Shenzhen  518129
   P.R. China

   Phone: +86 755 28972912
   Email: [email-masked]

Tsou                      Expires July 18, 2009                 [Page 7]

Internet-Draft     Diameter Routing Problem Statement       January 2009

Full Copyright Statement

   Copyright (C) The IETF Trust (2009).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Tsou                      Expires July 18, 2009                 [Page 8]

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

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC3588 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="no"?>
<!-- generate a ToC -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-tsou-dime-routing-problem-statement-01" ipr="full3978">

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title>Diameter Routing Problem Statement</title>

    <author fullname="Tina Tsou" initials="T." role="editor"
            surname="Tsou">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>Section F, Huawei Industrial Base</street>

          <!-- Reorder these if your country does things differently -->

          <city>Bantian Longgang</city>

          <region>Shenzhen</region>

          <code>518129</code>

          <country>P.R. China</country>
        </postal>

        <phone>+86 755 28972912</phone>

        <email>[email-masked]</email>
      </address>
    </author>

    <date month="January" year="2009" />

    <!-- Meta-data Declarations -->

    <area>Operations and Management</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <abstract>
      <t>This document describes use cases that suggest requirements to be able to add constraints to the existing Diameter routing mechanisms. </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>In <xref target="RFC3588"/>, routing of request messages from source to the destination is based solely on the routing decision made by each node along the path.  This document presents three different cases where the basic Diameter routing behaviour is not sufficient to meet the requirements. It then provides three problem statements corresponding to the three cases. Further analysis is required to determine if the number of problems to be solved can be reduced.
</t>
    </section>

      <section title="Requirements Language">
        <t>This document contains no requirements language.</t>      </section>

<section anchor="usecas" title="Use Cases">

<section anchor="wlan" title="3GPP Wireless LAN (WLAN) Access Architecture">

<t>One example of a stateful proxy is in the 3GPP WLAN IP access architecture <xref target="TS23.234"/>.  The 3GPP WLAN interworking architecture extends 3GPP services to the WLAN access side.  It enables a 3GPP subscriber to use a WLAN to access 3GPP services.</t>

<t>   WLAN AAA provides access to the WLAN to be authenticated and authorised through the 3GPP system.  This access control can permit or deny a subscriber the access to the WLAN system and/or the interworking with the 3GPP system.</t>

<t>   There are two WLAN interworking reference models:

<list style="numbers">
<t>   In the non-roaming case, the model includes the WLAN access network and the 3GPP AAA server in the home network.  The 3GPP AAA server is responsible for access control as well as charging.</t>

<t>   In the roaming case, the model includes the WLAN access network, the 3GPP AAA proxy in the visited network and the 3GPP AAA server in the home network.  The 3GPP AAA server is responsible for access control.  Charging records may be generated by the AAA proxy and/or the AAA server.  The AAA proxy relays access control and charging messages to the AAA server.  The AAA proxy will also do offline charging, if required.</t>

</list>

</t>

<t>   The roaming case presents two problems for which the Diameter routing mechanism described in <xref target="RFC3588"/> does not offer any unambiguous and standard solution.

<list style="numbers">
<t>   Network selection: Selecting an initial message path for the Diameter session through (possibly many) alternative visited network(s) to the home network.</t>

<t>   Explicit Routing: Maintaining the selected message path for all messages in the Diameter session.</t>

</list>
</t>

<t>These problems are discussed in detail in the following sections.
</t>

<section anchor="netsel" title="Initial Selection of Routing Path">

<t>In the 3GPP model we are considering, the WLAN access network is simply a substitute for the radio access network of a cellular operator. Two other operating entities are involved in providing IP service to the roaming user: a visited mobile network to which the WLAN access network is directly connected, and the user's home mobile network.</t>

<t>Consider the realistic model where the WLAN access network is connected to multiple mobile networks with which the user's home network has roaming agreements.  A particular visited network has to be selected for authentication. There are three possibilities:
<list style="symbols">
<t>the WLAN access network automatically selects a preferred routing;</t>

<t>the WLAN access network advertises the available networks to the UE, which makes an automatic selection based on pre-configured policy;</t>

<t>the WLAN access network advertises the available networks to the UE, which presents the choices to the user and asks the user to make a selection.</t>

</list>
 
</t>

<t>Once the visited network has been selected, Diameter currently does not fully standardize the means by which the Diameter client in the WLAN access network ensures that its initial request passes through the 3GPP AAA proxy in the chosen network. </t>

</section><!-- netsel -->

<section anchor="keepPath" title="Maintaining the Routing Path">

<t>   After a successful authentication, a Diameter session is established involving (at least) the following stateful entities:

<list style="symbols">
<t>   The Diameter client in the WLAN AN</t>

<t>   a Diameter proxy (the 3GPP AAA proxy) in the selected visited mobile network, and</t>

<t>   a Diameter server in the UE's home realm.</t>

</list>
</t>

<t>   The functions assigned to the 3GPP AAA proxy include:

<list style="symbols">
<t>   reporting charging information to the offline charging system in the visited network;</t>

<t>   enforcing policies based on roaming agreements;</t>

<t>   service termination initiated by the visited network operator.</t>

</list>
</t>

<t>These functions all require that state be maintained within the visited network. The 3GPP choice is to maintain that state at the 3GPP AAA proxy. This means that the latter must remain in the messaging path for all subsequent messages relating to the same session.</t>

<t>The network model with the client, the proxy and the server as described above is simplistic. Operators would usually 
deploy more than one proxy in the visited network and more than one server in the home network for better availability 
and load sharing. Relays are also used at the edges of these networks for topology hiding and load balancing. Thus a 
realistic network model would typically involve some stateless agents also in the session path.</t>

</section><!-- keepPath -->

</section><!-- wlan -->

<section anchor="relmRedir" title="Redirect Indication based on realm">

<!-- Tina and Rajiv add your use case here -->
<t>Consider an Operator; say Operator_A offering some service to Diameter client in its Realm; say Realm_A. For business/maintenance reasons, the operator wants to discontinue the service. However the operator has asked another Operator; say Operator_B (serving Realm_B) to provide the service to the clients. In this case, all the clients should be configured to contact Realm_B instead of Realm_A for the service.</t>
<t>For smooth transition, agents may be employed in Realm_A which could answer with a redirect indication suggesting that the  service requests may be sent to another realm; Realm_B in this case, so as to be served</t>

</section><!-- relmRedir -->

</section><!-- usecas -->

<section anchor="problems" title="Problem Statements">

<t>This section provides problem statements for the three use cases described above.</t>

<section anchor="netselprob" title="Initial Network Selection ">

<t>Note: this problem statement is here for completeness. There is agremeent that work on decorated NAI will go forward to remedy this specific problem. </t>

<t>This is the statement of the problem posed by the case presented in <xref target="netsel"/>.
<list style="numbers">
<t>Existing Diameter message routing behaviour: it is possible to direct a message through a specific intermediate realm using the decorated NAI mechanism within the User Name AVP. However, <xref target="RFC3588"/> does not unambiguously specify how to handle the decorated NAI i.e. how the Diameter client and agents participating in request routing may use the decorated NAI to update the Destination-Realm AVP. </t>

<t>Undesirable behaviour in the existing method: unpredictable results since the required mechanism has not been fully standardized.</t>

<t>Desired behaviour: the intermediate realm specified in the decorated NAI is traversed first, followed by the home user realm. This is required whenever a decorated NAI is presented. <xref target="netsel"/> describes the sort of environment where this requirement could arise. </t>

</list>
</t>

</section><!-- netselprob -->

<section anchor="maintprob" title="Path Maintenance">

<t>This is the statement of the problem posed by the case presented in <xref target="keepPath"/>.
<list style="numbers">
<t>Existing Diameter message routing behaviour: each host along the path makes its own independent routing decisions. </t>

<t>Undesirable behaviour in the existing method: routing of all messages for a given session through the selected 3GPP AAA proxy is not guaranteed if the visited mobile network has multiple proxies or if there are other Diameter entities between the WLAN client and the target 3GPP proxy.</t>

<t>Desired behaviour: regardless of the intervening set of Diameter elements, all messages for a given session pass through the proxy initially selected. This is required for stateful proxies only. <xref target="keepPath"/> describes the sort of environment where this requirement could arise. </t>

</list>
</t>
</section><!-- maintprob -->

<section anchor="redrelmprob" title="Redirect Indication based on realm">

<!-- Tina and Rajiv, put the problem statement here -->
<t>This is the statement of the problem posed by the case presented in <xref target="relmRedir"/>.

<list style="numbers">
<t>Existing Diameter message routing behaviour: Redirect indication is provided at host level. It provides a list of servers that may be contacted for the request to be served.
</t>

<t>Undesirable behaviour in the existing method: Redirect indication is not provided at the realm level. There is no option to provide a (list of) realm(s) that may be contacted for the request to be served.</t>

<t>Desired behaviour: Redirect indication could be provided at the realm level also. The indication may specify a (list of) realm(s) which could be contacted for the request to be served.</t>

</list>
</t>

</section><!-- redrelmprob -->

</section><!-- problems -->

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Text on the 3GPP WLAN use cases was provided by Rajith R. Glen Zorn provided the problem statement template used in <xref target="problems"/>.</t>

    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>

    </section>

    <section anchor="Security" title="Security Considerations">
      <t>It is possible that there are security issues with the problems stated above, but they are not immediately evident.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>

    <references title="Normative References">
      &RFC3588;
    </references>

   <references title="Informative References">

      <reference anchor="TS23.234">
        <front>
          <title>TS23.234v7.7.0, 3GPP system to Wireless Local Area Network (WLAN) interworking; System description</title>

          <author>
            <organization>3GPP</organization>
          </author>

          <date year="2008" month="June" day="9" />
        </front>
      </reference>
    </references>

    <!-- Change Log

v00 2008-10-20  TS    Initial version  -->

<!-- v00 2008-12-05  TS    Added fourth problem  -->
<!-- v01 2009-01-13  RR    Deleted third problem, added more details to second problem  -->

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