Subject: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 23 Nov 2007 15:10:05 +0100

Folks,

We have been discussing with our AD the way forward w.r.t. WG drafts
inherited from the previous WGs (MIP6, NEMO and MONAMI6).

We have grouped drafts into five categories and decided about the
actions to be taken for drafts of each category:

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

Cat. I: former WG drafts submitted to IESG already

Action: Address possible IESG Comments/Discusses as they surface.

I-Ds:	draft-ietf-mip6-bootstrapping-integrated-dhc-05
	draft-ietf-mip6-cn-ipsec-06
	draft-ietf-mip6-ha-switch-05
	draft-ietf-mip6-hiopt-08
	draft-ietf-mip6-whyauthdataoption-04
	draft-ietf-mip6-experimental-messages-03
	draft-ietf-mip6-vsm-03

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

Cat. II: former WG drafts corresponding to MEXT charter work items

Action: - MEXT to adopt drafts as WG drafts
         - authors to submit new versions if/when needed as draft- 
ietf-mext-...

I-Ds (MEXT work item):	draft-ietf-nemo-mib-03 work item (B.3)
			draft-ietf-nemo-prefix-delegation-02 (B.3)
			draft-ietf-monami6-mipv6-analysis-04 (A.3)
			draft-ietf-monami6-multihoming-motivation-scenario-02 (A.3)
			draft-ietf-monami6-multiplecoa-04 (A.3)
			draft-ietf-mip6-hareliability-03 (A.2)
			draft-ietf-mip6-nemo-v4traversal-05 (A.1)
			draft-ietf-mip6-radius-02 (A.6)

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

Cat. III: individual drafts corresponding to MEXT charter work items
	  that were accepted as former WG drafts but never submitted as such.

Action: - MEXT to adopt drafts as WG drafts as long as the authors  
follow the
           conditions requested by the respective WG at the moment of  
acceptancy
         - authors to submit new versions if/when needed as draft- 
ietf-mext-...

I-Ds (MEXT work item):	draft-eddy-nemo-aero-reqs-01 (A.5)
			draft-soliman-monami6-flow-binding-04 (A.3)

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

Cat. IV: individual drafts corresponding to MEXT charter work items
	 that were *conditionally* accepted as former WG drafts.

Action: - authors to update drafts so that they fullfills conditions.

I-Ds (MEXT work item):	draft-baldessari-c2ccc-nemo-req-01 (A.5)

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

Cat. V: former WG drafts without corresponding MEXT charter work item

Action: - MEXT to include this drafts as part of the rechartering
           discussion.

I-Ds:	draft-ietf-mip6-rfc4285bis-01
	draft-ietf-mip6-generic-notification-message-00

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

Comments?

Cheers,

--
Julien and Marcelo, MEXT chairs

_______________________________________________
MEXT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mext

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 23 Nov 2007 15:23:11 +0100

marcelo bagnulo braun wrote:
>         - authors to submit new versions if/when needed as 
> draft-ietf-mext-...
> 

In addition, I'd like to request inclusion of draft-ietf-nemo-dhcpv6-pd 
which although expired I find it relevant 
(http://tools.ietf.org/id/draft-ietf-nemo-dhcpv6-pd-02.txt) .  On and 
off it's been forgotten expired and re-activated.  I'd suggest a 
deadline in the MEXT timeline as well.

We're currently discussing publicly on the MEXT list about how to 
progress the two NEMO documents of prefix allocation.

What do you think?

Thanks,

Alex

>         - authors to submit new versions if/when needed as 
> draft-ietf-mext-...
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Sat, 24 Nov 2007 09:08:57 -0800

> In addition, I'd like to request inclusion of 
> draft-ietf-nemo-dhcpv6-pd which although expired I find it relevant
> (http://tools.ietf.org/id/draft-ietf-nemo-dhcpv6-pd-02.txt) . 
>  On and off it's been forgotten expired and re-activated.  
> I'd suggest a deadline in the MEXT timeline as well.

Right. This is a NEMO WG document currently expired. A WG last
call on this due about 2 years ago, but got delayed because
there are two solution documents for prefix delegation.

Vijay

> 
> We're currently discussing publicly on the MEXT list about 
> how to progress the two NEMO documents of prefix allocation.
> 
> What do you think?
> 
> Thanks,
> 
> Alex
>

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Sat, 24 Nov 2007 09:12:08 -0800

High level question. Is there a need to rename all the drafts
as draft-ietf-mext...? This always causes confusion when you are
trying to go back through the revisions and try to find something
that was added/deleted. Can't the drafts retain the names 
(mip6/nemo/monami6) and progress as MEXT WG documents?

Of course, new WG documents should be named draft-ietf-mext...

Vijay

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Friday, November 23, 2007 6:10 AM
> To: [email-masked]
> Subject: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps 
> 
> Folks,
> 
> We have been discussing with our AD the way forward w.r.t. WG 
> drafts inherited from the previous WGs (MIP6, NEMO and MONAMI6).
> 
> We have grouped drafts into five categories and decided about 
> the actions to be taken for drafts of each category:
> 
> draft- ietf-mext-...
> Action: - MEXT to adopt drafts as WG drafts as long as the 
> authors follow the
>            conditions requested by the respective WG at the 
> moment of acceptancy
> draft- ietf-mext-...

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Sat, 24 Nov 2007 09:24:23 -0800

Marcelo,

The following drafts are missing. 

draft-ietf-mip6-aaa-ha-goals - I think this document completed 
MIP6 WG last call. It is currently expired.

draft-devarapalli-mip6-authprotocol-bootstrap - There is an
ongoing consensus(?) call to make this a WG document. Not sure
if it is actually a consensus call. Something about gauging
interest. :)

4283bis - There is no draft on this yet, but a need to update
4283 was identified on the NETLMM mailing list and then 
discussed later on the mext mailing list. The update is to
mainly include other subtypes for MN identifier. For example,
the MAC address would be the new subtype. Currently the 
document only defines NAI.

Finally, what happened to 
draft-mitsuya-monami6-flow-distribution-policy-04.txt. I 
thought this was also going to be adopted as a MONAMI6 WG 
document. I might have missed some emails.

Vijay

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Sun, 25 Nov 2007 03:02:16 +0900

Hi Vijay

> document. I might have missed some emails.

There are two documents about flow distribution languages documents.
- draft-mitsuya-monami6-flow-distribution-policy-04.txt
- draft-larsson-monami6-filter-rules-02.txt

We agreed to merge the two documents and
published draft-larsson-mext-flow-distribution-rules-00.txt

regards,
ryuji

---

From: Jari Arkko <[email-masked]>
Date: Sat, 24 Nov 2007 23:05:24 +0200

Vijay,

> (mip6/nemo/monami6) and progress as MEXT WG documents?

I think this is no longer strictly speaking needed for drafts to
show up in the right WG pages. However, having the name
and WG match helps people to understand where drafts
belong, recognize announcements, etc. As Marcelo wrote,
there is no need for anyone to rush to submit a draft just
because of the name change. However, when you have a
need to change the draft for other reasons, I would
actually like to see them use a new name as well.

By the way, nothing passed to the AD or IESG should be
renamed.

Jari

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 24 Nov 2007 22:47:38 +0100

Hi Vijay,

> if it is actually a consensus call. Something about gauging

this should be included in the rechartering discussion, what other  
people feel about including this item in the recharter?

> document only defines NAI.

same thing here, this should be included in the rechartering  
discussion, what other people feel about including this item in the  
recharter?

Regards, marcelo

---

From: "T.J. Kniveton" <[email-masked]>
Date: Sat, 24 Nov 2007 19:32:43 -0800

> By the way, nothing passed to the AD or IESG should be

As Behcet pointed out, renaming the draft will reset the draft counter 
to -00. We experienced this when renaming some of the "monet" drafts to 
"nemo" drafts. However, it's usually not a big deal. Drafts that are 
ready to go to IESG could probably keep their current names (since they 
will just end up as RFCs anyway), but drafts that will be around for a 
while should probably be renamed.

TJ

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 25 Nov 2007 13:52:46 +0100

Vijay Devarapalli wrote:
[...]
> document only defines NAI.

I mainly agree with that need.  I'm not sure however on the interactions 
with netlmm and pmipv6.  The idea about 4283 potential extension (extend 
MN-ID option to include something else than a NAI) that was developped 
in the netlmm pmipv6 discussion made a lot of sense to me there.  But 
I'm not following anylonger where is the pmipv6 overall mechanism/vision 
impacting this.  Maybe 4283bissing discussion should be done there?  I 
don't know?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 25 Nov 2007 14:02:56 +0100

> while should probably be renamed.

I agree it resets the draft counter and a "00" looks fresh new idea 
although it's been refined already many times.  We experienced this with 
NEMOv4 draft going from individual proposal to NEMO then MIP4 WGs each 
time resetting the counter.

But a good ChangeLog in the draft can be a solution to that problem.

Alex

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Sun, 25 Nov 2007 17:20:21 -0800

Hi Marcelo and Vijay,

draft-ietf-mip6-aaa-ha-goals needs an update after the WGLC in MIP6. A
revision will be available after the Vancouver IETF meeting.

Thanks
Gerardo

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]] 
Sent: Saturday, November 24, 2007 9:24 AM
To: marcelo bagnulo braun; [email-masked]
Cc: Julien Laganier
Subject: RE: [MEXT] MIP6/NEMO/MONAMI6 WG drafts - Next steps 

Marcelo,

Vijay

---

From: "George Tsirtsis" <[email-masked]>
Date: Mon, 26 Nov 2007 08:32:59 +0000

Hi Marcelo/Vijay,

I would prefer not to take this up as a WG document. The draft adds
functionality to a mechanism that is known to be problematic, while a better
alternative exists and is already specified. If someone needs this to be
documented then maybe it can be progressed as an AD sponsored RFC, but IMO
it is not worth the full attention of the WG.

Note that the above is not critisism on the quality of the specific draft,
but rather based on the simple fact that we have already defined an overal
mechanism with better security for bootstrapping and securing MIPv6, and it
would be good for the IETF to be providing the market with clear signals
once in a while ;-)

Regards
George

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 26 Nov 2007 10:00:57 +0100

> published draft-larsson-mext-flow-distribution-rules-00.txt

I suggested to check using RSVP TSPEC for flow-distribution-rules before.
This has similar functionality and integration with upper layers could be
more straightforward.
I'm afraid I don't have time to work out this idea. I would appreciate
someone picks up.

Teco.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 26 Nov 2007 10:12:07 +0100

Hi Teco,

> I'm afraid I don't have time to work out this idea. I would appreciate
Are you suggesting to use RSVP for signaling the packet filters?
Or: Are you suggesting to look at the packet formats for describing the 
traffic filters?

Ciao
Hannes

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 26 Nov 2007 10:38:08 +0100

Hi Gerardo,

thanks for taking care of this. Please submit the new draft right  
after vancouver meeting. We are requested to submit the document to  
the IESG for february and i guess we should allow people to comment  
on the new version.

Regards, marcelo

El 26/11/2007, a las 2:20, Giaretta, Gerardo escribió:

>> -
>> -
>> -
>> -

---

From: "Roberto Baldessari" <[email-masked]>
Date: Mon, 26 Nov 2007 11:01:14 +0100

Hi Marcelo,

For automotive requirements, we did not make it in time to submit a joint C2C-CC/CALM ID for Vancouver. Anyway, Thierry and I are working on it. Thierry will also be in Vancouver. 
As suggested from the feedback in Chicago, we are moving from draft-baldessari-c2ccc-nemo-req-01 to something like draft-mext-nemo-ro-automotive-req-00, which will represent both C2C-CC and ISO CALM. 

Thanks,

Roberto

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 26 Nov 2007 11:15:20 +0100

good, the only difference is that it should be draft-ietf-mext-ro- 
automotive-req-00

El 26/11/2007, a las 11:01, Roberto Baldessari escribió:

> For automotive requirements, we did not make it in time to submit a  
> joint C2C-CC/CALM ID for Vancouver. Anyway, Thierry and I are  
> working on it. Thierry will also be in Vancouver.
> As suggested from the feedback in Chicago, we are moving from draft- 
> baldessari-c2ccc-nemo-req-01 to something like draft-mext-nemo-ro- 
> automotive-req-00, which will represent both C2C-CC and ISO CALM.
>
> Thanks,
>
> Roberto
>

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 26 Nov 2007 14:42:49 +0100

Hi Hannes,
I suggest reusing what we already have.
Maybe RSVP is already in place, in that case RSVP packets are sent over the
tunnel.
In the MONAMI6 context; I think we need a protocol for signaling traffic
flow policy. This is related to MIP.
Within this protocol, we need some kind of traffic specification, here we
could reuse RSVP TSPEC.
Cheers, Teco.

> -----Oorspronkelijk bericht-----
> Van: Hannes Tschofenig [mailto:[email-masked]]
> Verzonden: maandag 26 november 2007 10:12
> Aan: Teco Boot
> CC: [email-masked]
> Onderwerp: Re: [MEXT] RSVP TSPEC for flow-distribution-rules
> 
> Hi Teco,
> 
> Teco Boot wrote:

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Nov 2007 09:42:13 +0100

Hi Teco,

> Maybe RSVP is already in place, in that case RSVP packets are sent over the

Two observations from my limited RSVP experience:

* Deployment of RSVP does not really exist (for this type of 
environment). Please note that I talk about RSVP and not RSVP-TE.

* RSVP for packet filter installation does not exist either as an IETF 
document. There was only some work in the 3GPP2.

The 3GPP2 has also specified the NSIS NATFW NSLP to perform packet 
filter installation. Unlike RSVP for packet filter installation the NSIS 
NATFW NSLP is actually an IETF document.

Ciao
Hannes

>>> I suggested to check using RSVP TSPEC for flow-distribution-rules
>>>       
>> before.
>>     
>>> This has similar functionality and integration with upper layers
>>>       
>> could be
>>     
>>> more straightforward.
>>> I'm afraid I don't have time to work out this idea. I would
>>>       
>> appreciate
>>     
>>> someone picks up.
>>>
>>>

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 27 Nov 2007 10:26:04 +0100

Hi Hannes,

Thanks for the hint checking NSIS.

What I found is:
RFC4080 (NSIS Framework): 4.6.1.  Flow Identification
draft-ietf-nsis-qos-nslp-15 (QoS NSLP): 5.1.3.5.  Packet Classifier
(PACKET_CLASSIFIER)

I think NSIS produced specifications on packet classification should be
verified for using for MIP flow distribution / handover also.
Maybe RSVP TSPEC is past and NSIS FlowID is future.

Teco.

> Verzonden: dinsdag 27 november 2007 9:42
> Aan: Teco Boot
> CC: [email-masked]

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Nov 2007 10:36:10 +0100

Hi Teco,

here is the respective NSIS document:
http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-16.txt

It is currently in WGLC.

Ciao
Hannes

PS: The requirements from the 3GPP2 have been documented here and will 
be published as informational RFC (at least that's the latest status I 
have):
http://tools.ietf.org/wg/nsis/draft-bajko-nsis-fw-reqs-08.txt

Teco Boot wrote:
>>> Maybe RSVP is already in place, in that case RSVP packets are sent
>>>       
>> over the
>>     
>>> tunnel.
>>>
>>>       
>>> In the MONAMI6 context; I think we need a protocol for signaling
>>>       
>> traffic
>>     
>>> Within this protocol, we need some kind of traffic specification,
>>>       
>> here we
>>     
>>> could reuse RSVP TSPEC.
>>> Cheers, Teco.
>>>
>>>       
>> Ciao
>> Hannes
>>
>>     
>>>>>> There are two documents about flow distribution languages
>>>>>>             
>> documents.
>>     
>>>> Or: Are you suggesting to look at the packet formats for describing
>>>>         
>> the
>>     
>>>> traffic filters?
>>>>
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>>
>>>>         
>>>>> Teco.
>>>>>
>>>>>
>>>>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 27 Nov 2007 10:41:59 +0100

Btw, there are a couple of NSIS implementations and you can play around 
with the NATFW NSLP. I suggest to look at the following page:
http://user.informatik.uni-goettingen.de/~nsis/

In an EU funded project, called ENABLE, the NATFW NSLP has been used for 
firewall signaling in Mobile IP environments. Papers are available, see 
http://user.informatik.uni-goettingen.de/~fu/#publication
and a separate draft for dealing with the firewall traversal problems 
outlined in RFC 4487 can be found here: 
http://tools.ietf.org/id/draft-thiruvengadam-nsis-mip6-fw-08.txt

Ciao
Hannes