Subject: [MEXT] RE: Minutes of MEXT sessions at IETF-70

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 13 Dec 2007 07:59:23 -0600

Hi Chairs/All,

Please find some comments below.

Regards,
Ahmad

- Multiple Care-of Addresses Registration
  Ryuji Wakikawa - 20 min
  draft-ietf-monami6-multiplecoa-04

Ryuji: George commented that maybe we should add IPv4 CoA support for
DSMIPv6 support
Alex: Disagree, why add new features
George: DSMIP is now being adopted by SDOs, and there is no rush for
this, so lets do it correctly
Ryuji: Other comment from George is why bulk registrations with CNs are
excluded. There was consensous against this before.
George, unlike last issue I am not convinced this is necessary to
support. It was just not clear why this is not supported while reading
the draft.
Ryuji: yes so it was to keep the protocol simple.
Ryuji: Last issue is about simultaneous home/foreign links. This has
been discussed for some time now. There is now consensus to support this
but no yet agreement on how to do it. (two options summarized)

Various: some discussion regarding whether we need to support this in
this draft or not. Seems that the answer is yes

[Ahmad]
I am not sure about the above conclusion at this point of the meeting.
Under various, I assume that my comments should have been listed which
were as follows:

1. I think that addressing this scenario is probably not required at
this point and options look messy. I also raised the issue if supporting
this scenario, will that be a violation of RFC3775 which requires the MN
to send a de-registration BU as soon as it realizes that it is on a home
link. {I do not recall Ryuji answering that point but some other folks
mentioned that it is not which was not clear to me}

2. I also made a comment regarding the status code when multiple care of
address registration fails. I suggested that whenever any of the BID
fails registration, the BA should use a new status code less than 128 to
indicate to the MN that registration was successful but some BID failed
registration in order for the MN to check which BID has failed. If all
registered correctly, HA should always use status zero. {Ryuji agreed
with that comment}

3. Also, I do not think the conclusion of that "various" was YES.

Cheers! 

> -----Original Message-----
> From: Julien Laganier [mailto:[email-masked]]
> Sent: Wednesday, December 12, 2007 9:15 AM
> To: [email-masked]
> Subject: [MEXT] Minutes of MEXT sessions at IETF-70
> 
> Folks,
> 
> Minutes of the meeting are available there:
> 
> <http://www3.ietf.org/proceedings/07dec/minutes/mext.txt>
> 
> Please send to chairs corrections and/or add-ons, if any.
> 
> Thanks.
> 
> --julien
> 
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mext
> 

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

---

From: Julien Laganier <[email-masked]>
Date: Thu, 13 Dec 2007 16:47:12 +0100

Hello Ahmad and others,

Thanks Ahmad for reviewing the minutes, this is certainly helpful to 
ensure they accurately reflect the meeting discussions. Thanks also to 
our notes takers, this is a difficult task and it is unavoidable that 
sometimes mistakes are made.

I listened carefully to the recorded audio from our 1st session:

<http://www3.ietf.org/proceedings/07dec/minutes/btns.txt>

and I agree the excerpt of the minutes Ahmad sent do not reflect 
accurately the discussion that took place (between 1:23 and 1:46 in the 
record). I am proposing the updated text below (I condensed your 
comments Ahmad, hope I got them right).

Now a question to people that were in the meeting or listened to the 
recorded audio: Do you agree with the proposed change?

Thanks.

--julien

-----------------------------
Ryuji: George commented that maybe we should add IPv4 CoA support for
DSMIPv6 support
Alex: Disagree, why add new features
George: DSMIP is now being adopted by SDOs, and there is no rush for
this, so lets do it correctly
Ryuji: Other comment from George is why bulk registrations with CNs
are excluded. There was consensous against this before.
George, unlike last issue I am not convinced this is necessary to
support. It was just not clear why this is not supported while
reading the draft.
Ryuji: yes so it was to keep the protocol simple.
Ryuji: Last issue is about simultaneous home/foreign links. This has
been discussed for some time now. There is now consensus to support
this but no yet agreement on how to do it. (two options summarized)
Ahmad: Addressing this scenario is probably not required at this point 
and options look messy. Also, supporting this scenario would be a 
violation of RFC3775 which requires the MN to send a de-registration BU 
as soon as it realizes that it is on a home link. Can we limit the 
draft to multiple care-of address registration for now.
Ahmad: Also, regarding the status code when multiple care of address 
registration fails, I suggest that whenever any of the BID fails 
registration, the BA should use a new status code less than 128 to 
indicate to the MN that registration was successful but some
BID failed registration in order for the MN to check which BID has
failed. If all registered correctly, HA should always use status
zero.
Ryuji: Ok.
Various people: some discussion regarding whether we need to support 
this in this draft or not. 
-----------------------------

On Thursday 13 December 2007, Ahmad Muhanna wrote:
> Ryuji: Other comment from George is why bulk registrations with CNs
> are excluded. There was consensous against this before.
> support. It was just not clear why this is not supported while
> reading the draft.
> been discussed for some time now. There is now consensus to support
> this but no yet agreement on how to do it. (two options summarized)
>
> I am not sure about the above conclusion at this point of the
> meeting. Under various, I assume that my comments should have been
> listed which were as follows:
>
> this point and options look messy. I also raised the issue if
> supporting this scenario, will that be a violation of RFC3775 which
> requires the MN to send a de-registration BU as soon as it realizes
> that it is on a home link. {I do not recall Ryuji answering that
> point but some other folks mentioned that it is not which was not
> clear to me}
>
> 2. I also made a comment regarding the status code when multiple care
> of address registration fails. I suggested that whenever any of the
> BID fails registration, the BA should use a new status code less than
> 128 to indicate to the MN that registration was successful but some
> BID failed registration in order for the MN to check which BID has
> failed. If all registered correctly, HA should always use status
> zero. {Ryuji agreed with that comment}
>

---

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 13 Dec 2007 15:54:21 +0000

inline...

> mentioned that it is not which was not clear to me}

GT> Ahmad, it would be very strange for the specification that allows
MNs to utilize multiple links, to not allow one of these links to be
the home link. I disagree that the solution to this is in any way
messy. It is only messy if we do not do anything (i.,e., if we do not
address the issue in MCoA specification). Also, there is no issue with
violating RFC3775 since whatever we define in the MCoA draft will only
work and can only by used by MNs IF and ONLY IF the HA supports the
MCoA specification.

Regards
George

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 13 Dec 2007 07:54:41 -0800 (PST)

> 3. Also, I do not think the conclusion of that "various" was YES.

I agree. I do not think this should be addressed in this draft.
It requires some detailed analysis and none of the solutions
are simple enough to be adopted and we have not studied the
implications of any of those proposals, including CoA derivation on
the home link etc. There is no clear interest/consensus either for
the usecase or for a specific solution. Given that, I suggest we
defer this and get this draft out soon. Also, I'm repeating my
view on this, probably posted in the MIP6 ML, to ensure the
new chairs do not miss this.

Thanks
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 13 Dec 2007 11:39:13 -0600

> > that it is on a home link. {I do not recall Ryuji answering 
> that point 
> > but some other folks mentioned that it is not which was not 
> clear to 
> > me}
> >
> 
> MNs to utilize multiple links, to not allow one of these 
> links to be the home link. I disagree that the solution to 
> this is in any way messy. It is only messy if we do not do 
> anything (i.,e., if we do not address the issue in MCoA 
> specification). Also, there is no issue with violating 
> RFC3775 since whatever we define in the MCoA draft will only 
> work and can only by used by MNs IF and ONLY IF the HA 
> supports the MCoA specification.
> 
> Regards
> George

[Ahmad]
George,
Since the meeting minutes needs to capture what happened in the meeting,
I believe that you do not disagree with my correction of the meeting
minutes, but you disagree with the issue itself and would like to
discuss it further.
Is that a fair understanding?

Regards,
Ahmad

> > failed. If all registered correctly, HA should always use 
> status zero. 
> > {Ryuji agreed with that comment}
> >

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 13 Dec 2007 11:48:28 -0800

Julien,

I believe Ryuji was trying to get folks to pick one solution for
the scenario where the mobile node is attached to the home link
and visited link at the same time. We have a few options.

I don't understand Sri's and Ahmad's concerns about complexity.
We do have an issue here, so it needs to be addressed. I agree
with George, if there is a home link to which the MN can attach
to, then this scenario is bound to happen.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 13 Dec 2007 15:42:07 -0600

Hi Julien,

Your updated text looks good to me.
Thanks.

Regards,
Ahmad

> From: julien laganier [mailto:[email-masked]] On 
> Behalf Of Julien Laganier
> Sent: Thursday, December 13, 2007 9:47 AM
> To: [email-masked]
> Cc: Muhanna, Ahmad (RICH1:2H10); marcelo bagnulo braun
> Subject: Re: [MEXT] RE: Minutes of MEXT sessions at IETF-70
> 
> Hello Ahmad and others,
> 
> Thanks Ahmad for reviewing the minutes, this is certainly 
> helpful to ensure they accurately reflect the meeting 
> discussions. Thanks also to our notes takers, this is a 
> difficult task and it is unavoidable that sometimes mistakes are made.
> 
> and I agree the excerpt of the minutes Ahmad sent do not 
> reflect accurately the discussion that took place (between 
> 1:23 and 1:46 in the record). I am proposing the updated text 
> below (I condensed your comments Ahmad, hope I got them right).
> 
> Now a question to people that were in the meeting or listened 
> to the recorded audio: Do you agree with the proposed change?
> 
> Thanks.
> 
> --julien
> 
> George: DSMIP is now being adopted by SDOs, and there is no 
> rush for this, so lets do it correctly
> Ryuji: Other comment from George is why bulk registrations 
> with CNs are excluded. There was consensous against this before.
> George, unlike last issue I am not convinced this is 
> necessary to support. It was just not clear why this is not 
> supported while reading the draft.
> Ryuji: Last issue is about simultaneous home/foreign links. 
> This has been discussed for some time now. There is now 
> consensus to support this but no yet agreement on how to do 
> it. (two options summarized)
> Ahmad: Addressing this scenario is probably not required at 
> this point and options look messy. Also, supporting this 
> scenario would be a violation of RFC3775 which requires the 
> MN to send a de-registration BU as soon as it realizes that 
> it is on a home link. Can we limit the draft to multiple 
> care-of address registration for now.
> Ahmad: Also, regarding the status code when multiple care of 
> address registration fails, I suggest that whenever any of 
> the BID fails registration, the BA should use a new status 
> code less than 128 to indicate to the MN that registration 
> was successful but some BID failed registration in order for 
> the MN to check which BID has failed. If all registered 
> correctly, HA should always use status zero.
> Ryuji: Ok.
> Various people: some discussion regarding whether we need to 
> support this in this draft or not.

---

From: Julien Laganier <[email-masked]>
Date: Fri, 14 Dec 2007 08:29:55 +0100

Vijay,

I'm not arguing for or against solving the issue (yet :).

For now only fixing the minutes so that they reflect what was said 
during the meeting.

--julien

On Thursday 13 December 2007, Vijay Devarapalli wrote:
> > Thanks Ahmad for reviewing the minutes, this is certainly helpful
> > to ensure they accurately reflect the meeting discussions. Thanks
> > also to our notes takers, this is a difficult task and it is
> > unavoidable that sometimes mistakes are made.
> >
> > accurately the discussion that took place (between 1:23 and 1:46 in
> > the record). I am proposing the updated text below (I condensed
> > your comments Ahmad, hope I got them right).
> >
> > Now a question to people that were in the meeting or listened to
> > the recorded audio: Do you agree with the proposed change?
> >
> > Thanks.
> >
> > --julien
> >
> > Ryuji: George commented that maybe we should add IPv4 CoA support
> > for DSMIPv6 support
> > George: DSMIP is now being adopted by SDOs, and there is no rush
> > for this, so lets do it correctly
> > Ryuji: Last issue is about simultaneous home/foreign links. This
> > has been discussed for some time now. There is now consensus to
> > support this but no yet agreement on how to do it. (two options
> > summarized) Ahmad: Addressing this scenario is probably not
> > required at this point and options look messy. Also, supporting
> > this scenario would be a violation of RFC3775 which requires the MN
> > to send a de-registration BU as soon as it realizes that it is on a
> > home link. Can we limit the draft to multiple care-of address
> > registration for now.
> > address registration fails, I suggest that whenever any of the BID
> > fails registration, the BA should use a new status code less than
> >> Ryuji: George commented that maybe we should add IPv4 CoA support
> >> for DSMIPv6 support
> >> George: DSMIP is now being adopted by SDOs, and there is no rush
> >> for this, so lets do it correctly
> >> Ryuji: Other comment from George is why bulk registrations with
> >> CNs are excluded. There was consensous against this before.
> >> Ryuji: Last issue is about simultaneous home/foreign links. This
> >> has been discussed for some time now. There is now consensus to
> >> support this but no yet agreement on how to do it. (two options
> >> summarized)
> >>
> >> Various: some discussion regarding whether we need to support this
> >> in this draft or not. Seems that the answer is yes
> >>
> >> [Ahmad]
> >> 1. I think that addressing this scenario is probably not required
> >> at this point and options look messy. I also raised the issue if
> >> supporting this scenario, will that be a violation of RFC3775
> >> which requires the MN to send a de-registration BU as soon as it
> >> realizes that it is on a home link. {I do not recall Ryuji
> >> answering that point but some other folks mentioned that it is not
> >> which was not clear to me}
> >>
> >> 2. I also made a comment regarding the status code when multiple
> >> care of address registration fails. I suggested that whenever any
> >> of the BID fails registration, the BA should use a new status code
> >> less than 128 to indicate to the MN that registration was
> >> successful but some BID failed registration in order for the MN to
> >> check which BID has failed. If all registered correctly, HA should
> >> always use status zero. {Ryuji agreed with that comment}
> >>

---

From: Keigo Aso <[email-masked]>
Date: Fri, 14 Dec 2007 18:02:27 +0900

Hello,

In the last meeting, actually the author mentioned that there was
concensus to support for the simultaneous usage of the home and foreign
attached interfaces, and then there were apparently more supports 
for this scenario during the session also.
The chair(Marcelo) also said in his email that he had reached the same
conclusion based on the session and ML review, and clearly indicated the next
step as the WG. So, I think there is no need to go back to before again
even though the minutes is updated.

I agree with George and Vijay. Supporting this scenario is very important for
practical MCoA specification because MCoA MN can connect to the network 
which is defined in RFC3775.

Regards,
Keigo

On Thu, 13 Dec 2007 11:48:28 -0800

---

From: Julien Laganier <[email-masked]>
Date: Fri, 14 Dec 2007 11:27:08 +0100

On Friday 14 December 2007, Keigo Aso wrote:
> So, I think there is no need to go back to before again

Just to make sure: we WG chairs are not suggesting that. Just correcting 
the meeting minutes.

--julien

---

From: "George Tsirtsis" <[email-masked]>
Date: Fri, 14 Dec 2007 11:04:40 +0000

On Dec 13, 2007 5:39 PM, Ahmad Muhanna <[email-masked]> wrote:
...
> Is that a fair understanding?

GT> Yes, naturally.

---

From: "George Tsirtsis" <[email-masked]>
Date: Fri, 14 Dec 2007 11:22:54 +0000

Julien,

I am not entirly happy with your updated text. Now it appears as if
only Ryuji and Ahmad talked about this issue on the mike. It also
appears that Ryuji agreed with Ahmad which I do not think it is true
(he just agreed with Ahmad's 2nd comment). My reccolection is that I
disagreed with Ahmad on the mike while at least some of Sri, Vijay,
and Hesham also talked on the issue (you listened again to the audio,
so you maybe remember better?).

In any case, one way to correct the minutes without all of us loosing
too much time on it, is to remove the entire discussion following
Ryuji's comment and replace it with "Various people: some discussion
regarding whether we need to support this in this draft or not."

In any case the minutes are not supposed to be a transcript of the
actual conversation but they just suppose to capture the essence of
the meeting. Here are then how the minutes would look:

"Ryuji: Last issue is about simultaneous home/foreign links. This has
been discussed for some time now. There is now consensus to support
this but no yet agreement on how to do it. (two options summarized)

Ryuji: Ok."

---

From: Julien Laganier <[email-masked]>
Date: Fri, 14 Dec 2007 13:06:25 +0100

Hi George,

> so you maybe remember better?).

Yes, others talked on the issue, some of their comments are captured in 
what follows the excerpt Ahmad wanted to modify (I did not posted the 
follow-up originally since nobody asked to modify it):

Suresh: the issue is simple and the solution is simple if we do not
try to be too clever. If the HNP is not on-link then the issue goes
away
Gerardo Giaretta: This is useful scenario. It is actually very likely 
that if you are multihoming, one of the links is likely to be your home 
link
Kaigo: I also support this to be included in the draft. Prefer the
home CoA option
Suresh: It is not always easy to generate a home-CoA
Sri: Not sure if this should be solved in this draft.
Marcelo: There seems to be agreement to support DSMIP, not to support
Bulk Registrations, and not clear agreement on the multihoming with
home link issue. Will review discussion on the list to determine how
to proceed.

> regarding whether we need to support this in this draft or not."

That would be fine with me. Let's see what others (Ahmad?) think.

--julien

> > > Various: some discussion regarding whether we need to support
> > > this in this draft or not. Seems that the answer is yes
> > >
> > > [Ahmad]
> > > meeting. Under various, I assume that my comments should have
> > > been listed which were as follows:
> > >
> > > answering that point but some other folks mentioned that it is
> > > not which was not clear to me}
> > >
> > > of the BID fails registration, the BA should use a new status
> > > code less than 128 to indicate to the MN that registration was
> > > successful but some BID failed registration in order for the MN
> > > to check which BID has failed. If all registered correctly, HA
> > > should always use status zero. {Ryuji agreed with that comment}
> > >

---

From: "George Tsirtsis" <[email-masked]>
Date: Fri, 14 Dec 2007 15:25:05 +0000

Hmmm, ok I missed that.
Then I am ok with your suggested change since the complete thread
actually presents a more balanced view than I thought from the subset
of the minutes discussed earlier.

Thanks
George

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 14 Dec 2007 09:31:25 -0600

> 
> Yes, others talked on the issue, some of their comments are 
> captured in what follows the excerpt Ahmad wanted to modify 
> (I did not posted the follow-up originally since nobody asked 
> to modify it):
> 
> Suresh: the issue is simple and the solution is simple if we 
> do not try to be too clever. If the HNP is not on-link then 
> the issue goes away Gerardo Giaretta: This is useful 
> scenario. It is actually very likely that if you are 
> multihoming, one of the links is likely to be your home link
> Kaigo: I also support this to be included in the draft. 
> Prefer the home CoA option
> Marcelo: There seems to be agreement to support DSMIP, not to 
> support Bulk Registrations, and not clear agreement on the 
> multihoming with home link issue. Will review discussion on 
> the list to determine how to proceed.
> 

[Ahmad]
Hi Julien,

Since George agreed in his latest response to your original proposed
change, I do not think I need to add anything here.

Regards,
Ahmad

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 15 Dec 2007 16:50:07 +0100

Hi Keigo,

El 14/12/2007, a las 10:02, Keigo Aso escribió:

> step as the WG.

I think i need to clarify this. I think there was more support for  
supporting this case, but there was not clear consesus for it and we  
need more discussion. Since one of the arguments for this is the  
complexity of the approach needed, i think we can understand more the  
complexity of the solution if we have a text describing the solution,  
hence why i have requested to provide some concrete text to describe  
this.

So, it is not that i think we have agreed on this issue, is just that  
i think that such text would help us to move forward with the discussion

Just for completeness, i attach both of my comments below

In the minutes it is clearly stated:

to proceed

In addition, in the mail that i sent to move forward with this issue,  
i wrote:

- With respect to the case of multihoming with a visited network and  
the home network, there was no clear consesus on the meeting but it  
seemed that there was more support for supporting this case. I have  
reached the same conclusion after reading the mailing list. So the  
next steps for this are that the author or other partis to provide  
text for this and propose it to the ml.

Regards, marcelo

>>> for
>>>> has
>>>> this in
>>>> care

---

From: "Benjamin Lim" <[email-masked]>
Date: Mon, 17 Dec 2007 10:03:07 +0800

Hi,

One small comment. 

=8==8<=8==
> the list to determine how to proceed
[Ben] Just caught this from Marcelo's reply. If I'm not wrong, the consensus
was not to support bulk registration to CN right? I believe that bulk
registration to HA is still supported. If so, I propose modifying this text
in the minutes to "..., not to support Bulk Registration to CN, ..."

Regards,
Benjamin Lim

> 
> In addition, in the mail that i sent to move forward with 
> this issue, i wrote:
> 
> - With respect to the case of multihoming with a visited 
> network and the home network, there was no clear consesus on 
> the meeting but it seemed that there was more support for 
> supporting this case. I have reached the same conclusion 
> after reading the mailing list. So the next steps for this 
> are that the author or other partis to provide text for this 
> and propose it to the ml.
> 
> Regards, marcelo

=8==8<=8==

---

From: Julien Laganier <[email-masked]>
Date: Mon, 17 Dec 2007 09:56:39 +0100

Ahmad, George,

I modified the minutes as we agreed. Thanks.

--julien

On Friday 14 December 2007, Ahmad Muhanna wrote:
> > > In any case, one way to correct the minutes without all of
> >
> > us loosing
> >
> > > Ryuji's comment and replace it with "Various people: some
> >
> > discussion
> >

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 17 Dec 2007 09:06:07 +0100

right, i will update the minutes
thanks, marcelo

---

From: Keigo Aso <[email-masked]>
Date: Mon, 17 Dec 2007 19:25:37 +0900

Hi Marcelo,

On Sat, 15 Dec 2007 16:50:07 +0100
marcelo bagnulo braun <[email-masked]> wrote:

> Hi Keigo,
> 
> El 14/12/2007, a las 10:02, Keigo Aso escribis:
> 
> > Hello,
> >
Thank you for your clarification. Certainly there were some people who has the
impression of complexity at that time, and also there were still several
solutions listed which might cause some confusion.
IMHO, as mentioned in ML from some people, I also could not find any complexity.
Hopefully we would be able to remove such confusion by having a text describing
the solution clearly.

Regards,
Keigo

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 17 Dec 2007 08:21:20 -0600

Thanks Julien.

Regards,
Ahmad

> Sent: Monday, December 17, 2007 2:57 AM
> To: [email-masked]
> Cc: Muhanna, Ahmad (RICH1:2H10); George Tsirtsis
> > > Yes, others talked on the issue, some of their comments 
> are captured 
> > > in what follows the excerpt Ahmad wanted to modify (I did 
> not posted 
> > > the follow-up originally since nobody asked to modify it):
> > >
> > > away Gerardo Giaretta: This is useful scenario. It is 
> actually very 
> > > likely that if you are multihoming, one of the links is 
> likely to be 
> > > your home link
> > > multihoming with home link issue. Will review discussion 
> on the list 
> > > to determine how to proceed.
> > >