Subject: [netlmm] WGLC: draft-ietf-netlmm-proxymip6-07

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Wed, 07 Nov 2007 19:27:54 +0200

<Chair hat on>
Hello everybody,

As discussed earlier, the Working Group Last Call for
draft-ietf-netlmm-proxymip6 is hereby started.

To make sure all the time zones are covered, and everybody has at least two
weeks to to comment, the last call will end on Friday Nov 23rd end of
business time in PST.

Yours truly,

Vidya and Jonne - the chairs.
 
-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

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

---

From: "Ryoji Kato" <[email-masked]>
Date: Fri, 9 Nov 2007 15:27:08 +0900

Hi,

Thank you for the new version of the draft.

The last bullet of P.26 says ...

	If there does not exist a Binding Cache entry and ...,
	the local mobility anchor SHOULD wait till the existing Binding
Cache entry is de-registered ...

I guess this sentence should start with "If there exists a Binding Cache
entry and ..." .

Best Regards,
Ryoji Kato

> -----Original Message-----
> From: Soininen Jonne (NSN FI/Espoo) [mailto:[email-masked]] 
> Sent: Thursday, November 08, 2007 2:28 AM
> To: [email-masked]
> Subject: [netlmm] WGLC: draft-ietf-netlmm-proxymip6-07
> 
> <Chair hat on>
> Hello everybody,
> 
> To make sure all the time zones are covered, and everybody 
> has at least two weeks to to comment, the last call will end 
> on Friday Nov 23rd end of business time in PST.
> 
> Yours truly,
>

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 8 Nov 2007 22:31:22 -0800 (PST)

Hi Ryoji,

You are right. Noted !

Thanks
Sri

---

From: Jun AWANO <[email-masked]>
Date: Fri, 09 Nov 2007 18:44:48 +0900

Hi Sri,

Thanks for your effort to edit the new version draft.

I think that Access Technology Type of Access Technology Type Option 
isn't used for LMA processing but only HI(Handoff Indicator) is used to 
handle multi-homing case.

I remember Access Technology Type was used during discussion of 
multi-homing.
But now it seems to be not needed.

I'm sorry if I'm overlooking something.

Best regards,
Jun

---

From: <[email-masked]>
Date: Fri, 9 Nov 2007 10:45:51 +0100

Hi,

Two initial comments.

First, section 8.4 defines the Access Technology Type Option.
There was a draft some time ago that defined similar MIP6 option
(draft-daniel-mip-link-characteristic) that didn't receive too much
acceptance. With a respect to this I would like to see some text in
draft-*-proxymip6 that makes it clear the option is also available for
CMIP6. There are usecases for CMIP6. Reading the current text it is not
clear to me whether this option is also available for CMIP6 and what
a HA/CN should with HI field. Obviously the Access Technology Type
Option would be option for CMIP6.

Second, regarding "Access Technology Type" the division of access
technologies should either be in greater detail or by grouping "family".
For example grouping by family:

        0: Reserved
        1: 802.3
        2: 802.11 (any present and future .11 variant)
        3: 802.16 (any present and future .16 variant)
        4: PPP

I guess PPP means CDMA..? What about other PP2 types?

        5: GPRS (includes 2G/3G/LTE)
        6: Virtual (MAG has no idea of tech type, typically some tunnel,
           take example of EPC S2b interface)

Or then in more detail:

        0:  reserved
        1:  Virtual (the physical link type is irrelevant)
        0:  LAN  (802.3)
        1:  WLAN (802.11b)
        2:  WLAN (802.11a)
        3:  WLAN (802.11g)
        4:  WLAN (802.11n)
        5:  CDMA (meaning ?)
        6:  GPRS (meaning 3GPP 2G)
        7:  UMTS (meaning 3GPP 3G)
        8:  LTE
        9:  802.16e
        ...

Cheers,
	Jouni

> Sent: 7. marraskuuta 2007 19:28
> To: [email-masked]

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 9 Nov 2007 06:49:25 -0800 (PST)

Hi Jun,

On Fri, 9 Nov 2007, Jun AWANO wrote:

> I think that Access Technology Type of Access Technology Type Option isn't 
> used for LMA processing but only HI(Handoff Indicator) is used to handle 
> multi-homing case.
>
> I remember Access Technology Type was used during discussion of multi-homing.

I think, we are missing one case when the Access Tech in the
BCE does not match the Access Tech in PBU, I realized this
after we posted the doc. Will add this.

Thanks
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 9 Nov 2007 06:52:12 -0800 (PST)

Hi Jouni,

> Option would be option for CMIP6.

This draft cant say much about the applicability of this option
in CMIP6.

> For example grouping by family:

Sure. We were looking for some existing registry/definitions for
this, instead of we creating a new registry. Any case, this can
go as granular as it can be.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 09 Nov 2007 07:55:40 -0800

Hello Jouni,

We want to avoid listing all kinds of access technology types in
the Proxy MIPv6 specification. It can't/won't be exhaustive.
Instead we have relaxed the IANA considerations for this option.
It just requires IANA approval for reserving a new value for the
access technology type. For this you just need to send an email
to IANA. No need for writing a new internet draft or revise the
PMIPv6 specification.

In the IANA Considerations section we have the following text

>    The Mobility Header Option, Access Technology Type option defined in
>    Section 8.4 of this document introduces a new Access Technology type
>    numbering space, where the values from 0 to 5 have been reserved by
>    this document.  Approval of new Access Technology type numbers is
>    subject to IANA Approval.

Chairs, Jari, please let us know if you guys are fine with this.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Fri, 09 Nov 2007 18:11:44 +0200

> Chairs, Jari, please let us know if you guys are fine with this. 

Personally, I think it would be better to list either nothing or a
very small number now and then have an open IANA rule for
allocating more when people need them. That way you would
also get exactly the numbers that you need.

By the way "IANA Approval" is not a known IANA keyword. See
draft-narten-iana-considerations-rfc2434bis. Expert Review
or FCFS would seem more appropriate, IMHO.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 09 Nov 2007 08:38:38 -0800

> also get exactly the numbers that you need.

This is what we have tried to do in version 07.

> or FCFS would seem more appropriate, IMHO.

I am fine with either.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 9 Nov 2007 10:02:32 -0800

> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Friday, November 09, 2007 8:12 AM
> To: Vijay Devarapalli
> Cc: [email-masked]; Narayanan, Vidya; 
> Soininen Jonne (NSN FI/Espoo); [email-masked]
> Subject: Re: Access Technology Types (was re: [netlmm] WGLC: 
> draft-ietf-netlmm-proxymip6-07)
> 
> > We want to avoid listing all kinds of access technology 
> types in the 
> > Proxy MIPv6 specification. It can't/won't be exhaustive.
> > access technology type. For this you just need to send an email to 
> > IANA. No need for writing a new internet draft or revise the
> > PMIPv6 specification.
> >
> Personally, I think it would be better to list either nothing 
> or a very small number now and then have an open IANA rule 
> for allocating more when people need them. That way you would 
> draft-narten-iana-considerations-rfc2434bis. Expert Review or 
> FCFS would seem more appropriate, IMHO.
> 

Sounds reasonable to me. 

Vidya

---

From: <[email-masked]>
Date: Sat, 10 Nov 2007 15:40:51 +0100

[snip]

> allocating 
> > more when people need them. That way you would also get exactly the 
> > numbers that you need.
> 
> > draft-narten-iana-considerations-rfc2434bis. Expert Review or FCFS 
> > would seem more appropriate, IMHO.
> 
> I am fine with either.

Sounds OK. Anyway, "Access Technology Type" imho still needs to define
type of 'Virtual' (or similar) for cases where a MAG is not directly
attached to any access technology, rather e.g. terminates VPNs. This
is similar to PPP case.

Jouni

---

From: "Soininen Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Sat, 10 Nov 2007 20:16:06 +0200

I agree.

-Jonne.
ext Narayanan, Vidya wrote:
>>>>    The Mobility Header Option, Access Technology Type 
>>>>         
>> option defined in
>>     
>>>>    Section 8.4 of this document introduces a new Access 
>>>>         
>> Technology type
>>     
>>>>    numbering space, where the values from 0 to 5 have been 
>>>>         
>> reserved by
>>     
>>>>    this document.  Approval of new Access Technology type 
>>>>         
>> numbers is
>>

---

From: "Ryoji Kato" <[email-masked]>
Date: Mon, 12 Nov 2007 16:24:33 +0900

Dear wg draft authors, 

Thank you for your efforts.

In section 8.4, 2 bits are allocated for 'Handoff Indicator (HI)'
but 5 values are defined for HI. I guess HI needs one more bit...

Best Regards,
Ryoji Kato

---

From: "Ryoji Kato" <[email-masked]>
Date: Mon, 12 Nov 2007 16:24:33 +0900

Dear wg draft authors, 

Best Regards,
Ryoji Kato

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 12 Nov 2007 06:45:31 -0800

Hi Ryoji,

> From: Ryoji Kato [mailto:[email-masked]] 
> Sent: Sunday, November 11, 2007 11:25 PM
> To: [email-masked]
> Subject: RE: [netlmm] WGLC: draft-ietf-netlmm-proxymip6-07
> 
> Dear wg draft authors, 
> 

Thanks for catching this. When we added the additional case, we
missed the part of extending the bits. 

Thanks
Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 12 Nov 2007 15:27:42 -0800

> attached to any access technology, rather e.g. terminates VPNs. This

I wonder if we should be more specific and say what that virtual
tunnel is. For example if it is an IPsec based tunnel, why not
call it "IPsec tunnel interface".

Vijay

---

From: "Sri Gundavelli" <[email-masked]>
Date: Sat, 24 Nov 2007 10:46:19 -0800

Thanks every one for the LC comments. We will review the
comments and will update the document with those that we
agree and post the updated document soon.

Regards
Sri

> Sent: Wednesday, November 07, 2007 9:28 AM
> To: [email-masked]
> has at least two

---

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

Hi Sri,

Can you please handle the comments one by one in a detailed way? It is
very difficult to track changes and progress of the document if you go
offline with your co-authors and come out with another version in two
weeks without explicitly proposing anything in the mailing list.

I suggest you try to get consensus on the new text via the mailing list,
tracking each issue, instead of simply saying "we will fix it in the
next version".

Thanks
Gerardo

-----Original Message-----
From: Sri Gundavelli [mailto:[email-masked]] 
Sent: Saturday, November 24, 2007 10:46 AM
To: 'Soininen Jonne (NSN FI/Espoo)'; [email-masked]
Subject: RE: [netlmm] WGLC: draft-ietf-netlmm-proxymip6-07

Regards
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Sun, 25 Nov 2007 18:07:31 -0800 (PST)

Hi Gerardo,

> tracking each issue, instead of simply saying "we will fix it in the

I'm not sure, what your concern is and why it is difficult to
track changes. If we agreed to a given comment, the authors will
discuss and fix it. It does not make sense to have extensive
debates on every single and minor comment. You will always
have the opportunity to review the new text and see how we resolved
a given issue. If you dont like the text, you can always speakup
and keep the issue open.

As part of this LC, we received comments from 4 people, out of
those 4 reviews, two of them are minor nits. The other two review
comments from you and George are over 100+. You expect me to
create 100 issues in the issue tracker for this and discuss each
of them in the mailing list ? You think, we will be to converge
any time soon ? Please trust the authors on how they resolve a
minor nit or a comment, if there is major issue like multihoming,
we always proposed text and resolved it to every ones satisfaction.

I did not respond to your review comments yet. So far most of the
comments that I've seen from George are minor textual suggestions..
etc and I did not see a need to propose text for those comments,
prior to publishing the draft. But, if there is a specific text that
you are seriously concerned about, let us know and we will propose
text in the mailing list. But, please dont ask for every comment
you make to be discussed in the mailing list and give LC note for
that text before we take it. Also, I will appreciate if you can help
us close this work faster. Again, please trust the authors.

Sri

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Sun, 25 Nov 2007 18:27:50 -0800

Hi Sri,

Not sure why you took this personally as if I don't trust the authors.
Sorry if my comment was giving this impression, that was not the
impression at all.

> a given issue. If you dont like the text, you can always speakup

Isn't better to close the issue before a new version is submitted??? 

In my review I proposed many changes, some of them are editorial and
some are not. I think it would be easier if before you work on a new
version, we agree on the text we should include in that new version.
Note that this is now a WG draft and not a draft own by the authors. I
think the common practice (at least in the mobility area) has always
been to discuss the LC comments in the mailing list (comment by comment)
in order to understand if all issues are closed and if another LC round
is needed. I hope we can keep this good practice for this draft.

> us close this work faster. Again, please trust the authors.

Indeed my comment was intended to close the work faster. If you think
that discussing the comments in the mailing list is a waste of time, you
are free of producing another version of the draft discussing the issues
on your own, but I'm not sure this will help the progress of the work.
Another LC may be needed in that case. 

Again, it's not a trust issue, it's just how IETF and WGLC work.

Gerardo

---

From: Sri Gundavelli <[email-masked]>
Date: Sun, 25 Nov 2007 18:54:24 -0800 (PST)

Hi Gerardo,

> Sorry if my comment was giving this impression, that was not the

We are only trying to work here objectively, while still following
the IETF process. We always have and we will respond to each and
every comment. But, if you want text for every minor change as
supposed to major issues and I'm not sure which draft in mobility
group followed that convention. But, in your mind, if you think we
need to do that, we will certainly do that.

Also, we have not responded to your review comments yet and we did
not start working on a new draft either. Any case, we will respond to
your comments before we post the revision.

Sri

---

From: "Soininen Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 26 Nov 2007 10:44:49 +0200

Sri,

this was the WGLC and the document is a WG document. If you don't (or 
somebody else doesn't) agree on comments, those have to be debated. You 
also have to indicate if you don't agree on comments.

I know that this was what you meant. However, I just wanted to make sure 
that everybody understands the process correctly.

Cheers,

Jonne.

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 26 Nov 2007 09:30:47 -0800 (PST)

Hi Jonne,

On Mon, 26 Nov 2007, Soininen Jonne (NSN - FI/Espoo) wrote:

> somebody else doesn't) agree on comments, those have to be debated. You also 
> have to indicate if you don't agree on comments.
>
> I know that this was what you meant. However, I just wanted to make sure that 
> everybody understands the process correctly.
>

Yes. We will respond to all comments and also identify those
that we dont agree.

Thanks
Sri