Subject: Re: [Dime] Fwd: New Version Notification fordraft-korhonen-dime-mip6-feature-bits-01

From: Jinwei Xia <[email-masked]>
Date: Tue, 07 Jul 2009 14:09:46 +0800

Hi Jouni,

	Do you think it is better to mark this ID as updates of 5447?  With
the stability of MCoA and DSMIP, both feature will be added in MIP Diameter
Application. 

	However if you take PMIP feature into account, I support this ID is
independent from RFC5447 and Dime-PMIPv6. In such case, IMHO
"Bulk_Termination" and "Bulk_Re_Registration" should be involved in as PMIP
feature.

BR

	Jinwei

> 
> Hi all,
> 
> I have updated the additional feature bits draft. I did 
> remove some stuff so that the draft now only reserves 
> MIP6-Feature-Vector flag bits and nothing more. I'll forward 
> the draft soon to RFC editor so if anyone has comments, 
> please be quick :)
> 
> Cheers,
> 	Jouni
> 
> Begin forwarded message:
> 
> > From: IETF I-D Submission Tool <[email-masked]>
> > Date: June 10, 2009 12:26:53 PM GMT+03:00
> > To: [email-masked]
> > Subject: New Version Notification for  draft-korhonen-dime-mip6-
> > feature-bits-01
> >
> >
> > A new version of I-D, draft-korhonen-dime-mip6-feature-bits-01.txt
> > has been successfuly submitted by Jouni Korhonen and posted to the 
> > IETF repository.
> >
> > Filename:	 draft-korhonen-dime-mip6-feature-bits
> > Revision:	 01
> > Title:		 Diameter MIP6 Feature Vector 
> Additional Bit Allocations
> > Creation_date:	 2009-06-10
> > WG ID:		 Independent Submission
> > Number_of_pages: 5
> >
> > Abstract:
> > During the Mobile IPv6 Split Scenario bootstrapping the Mobile IPv6 
> > Home Agent and the Authentication, Authorization, and Accounting 
> > server may exchange a set of authorized mobility 
> capabilities.  This 
> > document defines new mobility capability flags that are used to 
> > authorize per Mobile Node route optimization, Multiple 
> Care-of Address 
> > and user plane traffic encryption support.  Furthermore, 
> this document 
> > also defines a capability flag of indicating whether the 
> Home Agent is 
> > authorized to act as a stand alone Virtual Private Network gateway.
> >
> >
> >
> > The IETF Secretariat.
> >
> >
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: jouni korhonen <[email-masked]>
Date: Tue, 7 Jul 2009 14:26:57 +0300

Hi Jinwei,

> the stability of MCoA and DSMIP, both feature will be added in MIP  

I don't think the draft would update RFC5447. It just uses the IANA  
procedures defined there. If something would be updated that is the  
dime-mip6-split draft. However, that is the draft we purposely removed  
these flags and spun off the feature-bits draft.

> independent from RFC5447 and Dime-PMIPv6. In such case, IMHO

dime-pmip6 draft already defines its own feature bits.

> "Bulk_Termination" and "Bulk_Re_Registration" should be involved in  

Do you suggest adding feature bits for bulk operations (the recent  
work in netext)?

Cheers,
	Jouni

---

From: Jinwei Xia <[email-masked]>
Date: Tue, 07 Jul 2009 20:37:59 +0800

Hi Jouni,

Thank your feedback, please see inline.

> > the stability of MCoA and DSMIP, both feature will be added in MIP 
> > Diameter Application.
> 
> I don't think the draft would update RFC5447. It just uses 
> the IANA procedures defined there. If something would be 
> updated that is the dime-mip6-split draft. However, that is 
> the draft we purposely removed these flags and spun off the 
> feature-bits draft.
> 

Sure. It makes sense to spin off one feature-bits ID to maintain Dime-MIP
base protocol stability .

> dime-pmip6 draft already defines its own feature bits.

OK

> 
> 
> >
> > "Bulk_Termination" and "Bulk_Re_Registration" should be 
> involved in as 
> > PMIP feature.
> 
> 
> Do you suggest adding feature bits for bulk operations (the 
> recent work in netext)?

Yeah, since Dime-PMIP ID has entered IESG Processing stage, the remain
feature bits (e.g. Bulk operations which do not standardized yet) sponsored
in netext WG maybe should be added in a specific feature bits ID, make
sense? 

BR

	Jinwei

> remove some 
> >> stuff so that the draft now only reserves MIP6-Feature-Vector flag 
> >> bits and nothing more. I'll forward the draft soon to RFC 
> editor so 
> >> if anyone has comments, please be quick :)
> >>
> >> Cheers,
> >> 	Jouni
> >>
> >> Begin forwarded message:
> >>

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 7 Jul 2009 07:39:36 -0700 (PDT)

Hi Jouni,
  Can you please add
IP4_IN_IP6_TUNNELING_SUPPORTED flag (which could be defined as:
IP4_IN_IP6_TUNNELING_SUPPORTED (0x0000000000000100)
)
 
The need for this came out in a contribution we made to WiMAX NWG's IPv4/v6 Transition subteam on the scenarios for DSMIP.
 
Regards,
 
Behcet

----- Original Message ----
> From: jouni korhonen <[email-masked]>
> To: [email-masked]
> Sent: Wednesday, June 10, 2009 4:55:36 AM
> Subject: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01
> 
> Hi all,
> 
> I have updated the additional feature bits draft. I did remove some stuff so 
> that the draft now only reserves MIP6-Feature-Vector flag bits and nothing more. 
> I'll forward the draft soon to RFC editor so if anyone has comments, please be 
> quick :)
> 
> Cheers,
>     Jouni
> 
> Begin forwarded message:
> 
> > From: IETF I-D Submission Tool 
> > Subject: New Version Notification for  
> draft-korhonen-dime-mip6-feature-bits-01
> > 
> > 
> > A new version of I-D, draft-korhonen-dime-mip6-feature-bits-01.txt has been 
> successfuly submitted by Jouni Korhonen and posted to the IETF repository.
> > 
> > Title:        Diameter MIP6 Feature Vector Additional Bit Allocations
> > server may exchange a set of authorized mobility capabilities.  This
> > authorize per Mobile Node route optimization, Multiple Care-of
> > Address and user plane traffic encryption support.  Furthermore, this
> > document also defines a capability flag of indicating whether the
> > Home Agent is authorized to act as a stand alone Virtual Private
> > Network gateway.
> > 
> > 
> > 
> > The IETF Secretariat.
> > 
> > 
>

---

From: jouni korhonen <[email-masked]>
Date: Wed, 8 Jul 2009 09:05:25 +0300

Could you point me at the relevant Wimax documents regarding the flags  
below?

Cheers,
	Jouni

On Jul 7, 2009, at 5:39 PM, Behcet Sarikaya wrote:

> The need for this came out in a contribution we made to WiMAX NWG's  
> IPv4/v6 Transition subteam on the scenarios for DSMIP.
>
> Regards,
>
> Behcet
>
>
>
>>> has been

---

From: Julien Bournelle <[email-masked]>
Date: Wed, 8 Jul 2009 09:53:06 +0200

Hello,

 one question maybe is if it is the IETF or IANA which will be used to
register specifc SDO flags ?

 Maybe we could have a specific range for such allocation ?

 Any comments ?

 Julien

---

From: jouni korhonen <[email-masked]>
Date: Wed, 8 Jul 2009 11:24:58 +0300

Hi Julien,

Well, the IANA allocation rules were crafted so that other SDOs could  
easily allocate their own flags once they document flag usage (the  
document can be any publicly available proper spec/document, not just  
RFC). Having said that, allocating flags "ahead" without relevant  
documentation which properly describe the use and need is not really  
what we want. And having said that, I basically self-conclude most  
flags the current I-D proposes are not needed ;)

Cheers,
	Jouni

On Jul 8, 2009, at 10:53 AM, Julien Bournelle wrote:

> Hello,
>
>  one question maybe is if it is the IETF or IANA which will be used  
> to register specifc SDO flags ?
>
> On Wed, Jul 8, 2009 at 8:05 AM, jouni korhonen  
> <[email-masked]> wrote:
>
> Could you point me at the relevant Wimax documents regarding the  
> flags below?
>
> Cheers,
>        Jouni
>
>

---

From: Julien Bournelle <[email-masked]>
Date: Wed, 8 Jul 2009 14:03:16 +0200

Hi jouni,

On Wed, Jul 8, 2009 at 10:24 AM, jouni korhonen <[email-masked]>wrote:

> easily allocate their own flags once they document flag usage (the document
> can be any publicly available proper spec/document, not just RFC). Having
> said that, allocating flags "ahead" without relevant documentation which
> properly describe the use and need is not really what we want. And having
> said that, I basically self-conclude most flags the current I-D proposes are
> not needed ;)

 not sure to catch your conclusion ! :)

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 8 Jul 2009 07:58:19 -0700 (PDT)

----- Original Message ----
> To: Julien Bournelle <[email-masked]>
> Cc: Behcet Sarikaya <[email-masked]>; [email-masked]
> Sent: Wednesday, July 8, 2009 3:24:58 AM
> Subject: Re: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01
> 
> Hi Julien,
> 
> Well, the IANA allocation rules were crafted so that other SDOs could easily 
> allocate their own flags once they document flag usage (the document can be any 
> publicly available proper spec/document, not just RFC). Having said that, 
> allocating flags "ahead" without relevant documentation which properly describe 
> the use and need is not really what we want.. And having said that, I basically 
> self-conclude most flags the current I-D proposes are not needed ;)

This is a good point.
In the document I mentioned one of them:
 IP4_HOA_SUPPORTED (0x0000020000000000)
 
is being used though.
 
Regards,
 
Behcet

> > On Wed, Jul 8, 2009 at 8:05 AM, jouni korhonen wrote:
> > 
> > Could you point me at the relevant Wimax documents regarding the flags below?
> > 
> > Cheers,
> >        Jouni
> > 
> > 
> > The need for this came out in a contribution we made to WiMAX NWG's IPv4/v6 
> Transition subteam on the scenarios for DSMIP.
> > 
> > Regards,
> > 
> > Behcet
> > 
> > 
> > 
> > From: jouni korhonen

---

From: jouni <[email-masked]>
Date: Wed, 8 Jul 2009 22:03:39 +0300

Hi Julien,

On Jul 8, 2009, at 3:03 PM, Julien Bournelle wrote:

> Hi jouni,
>
> On Wed, Jul 8, 2009 at 10:24 AM, jouni korhonen <[email-masked] 
> > wrote:
> Hi Julien,
>
> Well, the IANA allocation rules were crafted so that other SDOs  
> could easily allocate their own flags once they document flag usage  
> (the document can be any publicly available proper spec/document,  
> not just RFC). Having said that, allocating flags "ahead" without  
> relevant documentation which properly describe the use and need is  
> not really what we want. And having said that, I basically self- 
> conclude most flags the current I-D proposes are not needed ;)
>
>

;)  Meaning.. SDOs could (should) go and allocate feature vector flag  
bits on their own directly from IANA, once they have appropriate  
documentation.. without getting involved in IETF WG level process.

Regarding the proper documentation, I realize that draft-korhonen-dime- 
mip6-feature-bits does not really do a good job at explaining "use &  
need" for some flags it aims to allocate.

JOuni

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 9 Jul 2009 09:28:57 +0200

Hello,

On Wed, Jul 8, 2009 at 9:03 PM, jouni <[email-masked]> wrote:

> ;)  Meaning.. SDOs could (should) go and allocate feature vector flag bits
> on their own directly from IANA, once they have appropriate documentation..
> without getting involved in IETF WG level process.

 ok, I see. Maybe we could add a little section explaining this.

>
> Regarding the proper documentation, I realize that
> draft-korhonen-dime-mip6-feature-bits does not really do a good job at
> explaining "use & need" for some flags it aims to allocate.

i'll re-read the current draft and provide comments ASAP.

regards,

 Julien