Subject: [Dime] Diameter MIPv6 Split Document: Feedback needed

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 06 Jul 2008 10:36:24 +0300

Hi all,

we have recently received an IPR disclosure for 
http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-10.txt
See http://www.ietf.org/mail-archive/web/dime/current/msg02573.html

So, now we have two options:

a) Ignore the IPR disclosure and go forward with the publication procedure
b) Think about the document a bit and potentiallly change some parts.

I thought a little bit about the document and the concepts of most parts 
of the document dates back already many, many years and is not really 
suprising in any way when you have read the related documents (such as 
Diameter Mobile IPv4, Diameter EAP, or MIPv6 bootstrapping).

In the process of working on the document there was, however, one part 
that surprised me, namely the excitement for getting some of the 
MIP6-Feature-Vectors flags put into the document even though they do not 
really constitute a core part of the protocol.

I would therefore suggest to move these flags/codes into a separate 
document.

Thoughts?

Ciao
Hannes

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

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 8 Jul 2008 14:42:33 +0300

I was asked what specific content would actually be separated from the
current document. So, here is my guess: 

The following text from Section 6.15: 

   RO_SUPPORTED (0x0000000200000000)

      Route optimization is supported.  When the HA sets this bit, it
      indicates support for the route optimization.  If this bit is
      unset in the returned Mobility-Capability AVP, the AAAH does not
      authorize route optimization for the MN.

      In a case the HA or the AAAH cannot authorize the use of route
      optimization then the HA SHOULD send a Binding Acknowledgement
      with a Status Code set to ACCEPTED_BUT_NO_ROUTE_OPTIMIZATION
      (status code TBD).  This Status Code indicates that the binding
      registration succeeded but the HA will fail all possible
      subsequent route optimization attempts because of subscription or
      operator policy.

   USER_TRAFFIC_ENCRYPTION (0x0000000400000000)

      User plane traffic encryption is supported.  When the HA sets this
      bit, it indicates support for the user plane traffic encryption
      between the MN and the HA.  If this bit is unset in the returned
      Mobility-Capability AVP, the AAAH does not authorize user plane
      traffic encryption because of subscription or operator policy.

      In the case the AAAH cannot authorize the use of user plane
      traffic encryption then the HA SHOULD send a Binding
      Acknowledgement with a Status Code set to
      ACCEPTED_BUT_NO_TRAFFIC_ENCRYPTION (status code TBD).  This Status
      Code indicates that the binding registration succeeded but the HA
      will silently discard all encrypted user plane packets sent by the
      MN to the HA.

   VPN_GW_MODE (0x0000000800000000)

      The HA is supposed to act as a IPSec VPN gateway for the user.
      When the HA sets this bit, it indicates support for acting as a
      standalone IPSec VPN gateway.  If this bit is unset in the
      returned Mobility-Capability AVP, the AAAH does not authorize the
      HA to act as a standalone IPSec VPN gateway for the MN because of
      subscription or operator policy.

   MCOA_SUPPORTED (0x0000001000000000)

      Multiple Care-of Addresses (MCoA) [21] are supported.  When the HA
      sets this bit, it indicates support for the MCoA.  If this bit is
      unset in the returned Mobility-Capability AVP, the AAAH does not
      authorize the use of MCoA for the MN.

      In a case the HA or the AAAH cannot authorize the use of the MCoA
      then the HA SHOULD send a Binding Acknowledgement with a Status
      Code set to ACCEPTED_BUT_NO_MCOA (status code TBD).  This Status
      Code indicates that the binding registration succeeded but the HA
      will fail all possible subsequent attempts to use MCoA because of
      subscription or operator policy.

>From Section 9.5: 

   Token                            | Value                | Description
   ---------------------------------+----------------------+------------
   RO_SUPPORTED                     | 0x0000000200000000   | RFC TBD
   USER_TRAFFIC_ENCRYPTION          | 0x0000000400000000   | RFC TBD
   VPN_GW_MODE                      | 0x0000000800000000   | RFC TBD
   MCOA_SUPPORTED                   | 0x0000001000000000   | RFC TBD

And Section 9.6

   This specification defines new Mobile IPv6 [1] Status Code values.
   The Status Code must be allocated from the range 0-127:

   Status Code                             | Value         | Description
   ----------------------------------------+---------------+------------
   ACCEPTED_BUT_NO_ROUTE_OPTIMIZATION      | is set to TBD | RFC TBD
   ACCEPTED_BUT_NO_TRAFFIC_ENCRYPTION      | is set to TBD | RFC TBD
   ACCEPTED_BUT_NO_MCOA                    | is set to TBD | RFC TBD 

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Hannes Tschofenig
>Sent: 06 July, 2008 10:36
>To: [email-masked]
>Subject: [Dime] Diameter MIPv6 Split Document: Feedback needed
>
>Hi all,
>
>I thought a little bit about the document and the concepts of 
>most parts of the document dates back already many, many years 
>and is not really suprising in any way when you have read the 
>related documents (such as Diameter Mobile IPv4, Diameter EAP, 
>or MIPv6 bootstrapping).
>
>In the process of working on the document there was, however, 
>one part that surprised me, namely the excitement for getting 
>some of the MIP6-Feature-Vectors flags put into the document 
>even though they do not really constitute a core part of the protocol.
>
>I would therefore suggest to move these flags/codes into a 
>separate document.
>
>Thoughts?
>
>Ciao
>Hannes
>

---

From: "Julien Bournelle" <[email-masked]>
Date: Tue, 8 Jul 2008 18:05:51 +0200

Hi hannes,

 I understand your view but what bothers me is that we can't know for
sure that the
patent is on this MIP6-Feature-Flag AVP since the patent is
unfortunatly unpublished.

 Maybe we have a third option:

 c/ wait publication of this patent.

 My 2 cents,

 Julien

On Sun, Jul 6, 2008 at 9:36 AM, Hannes Tschofenig
<[email-masked]> wrote:
> I thought a little bit about the document and the concepts of most parts of
> the document dates back already many, many years and is not really suprising
> in any way when you have read the related documents (such as Diameter Mobile
> IPv4, Diameter EAP, or MIPv6 bootstrapping).
>
> In the process of working on the document there was, however, one part that
> surprised me, namely the excitement for getting some of the