Subject: [Seamoby] Status of WG Last Call

From: "James Kempf" <[email-masked]>
Date: Fri, 11 Jan 2002 09:43:13 -0800

WG Last call has expired on the following drafts:

1) draft-ietf-seamoby-context-transfer-problem-stat-04.txt
2) draft-ietf-seamoby-ct-reqs-02.txt
3) draft-ietf-seamoby-car-discovery-issues-01.txt
4) draft-ietf-seamoby-paging-protocol-assessment-00.txt

No comments were received on 1) and 3), they will now be sent to the
IESG for review.

On 3), one comment was received to remove 4 requirements, but there were
two opinions expressed
that the document should remain unchanged, so this document will be sent
to the IESG as is for
review.

On 4), a desire was expressed for some additional text describing the
decision process. This text
is currently undergoing review by the WG chairs and ADs for inclusion in
the document. An updated
document will be issued when the text is incorporated and another WG
last call will be scheduled.

                    jak

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

---

From: "Hemant Chaskar" <[email-masked]>
Date: Fri, 11 Jan 2002 21:41:15

Hi Hesham,

I also did not see any comment from you on the NSIS list during the first 
last call that has not been attended to. What was the text of your email, is 
it there in list archives? If so, please point me to that and I will take 
care of your concern.

Also, note that this is the "second" WG last call for the same draft. When 
we make multiple last calls, we should try to build upon the text of the 
previous call. Hence, in the second WG calls we should restrict the comments 
to either the new text that is added after the first call or the relation 
between the new text and the previous text. Directly making major changes in 
the old text during second call without its any reletion to the new text 
will just keep us infinitely in the last calls phase. Nonetheless, we can 
"finetune" the old text for better clarity.

Also, please note the difference between the "issues" draft, the 
"requirements" draft and the "solutions" draft.

Hemant

>From: "James Kempf" <[email-masked]>
>To: "Hesham Soliman \(ERA\)" <[email-masked]>,        
><[email-masked]>
>Subject: Re: [Seamoby] Status of WG Last Call
>Date: Fri, 11 Jan 2002 10:19:05 -0800
>
>Hesham,
>
>The usual procedure for comments is that they be sent to the list. Any
>Last
>Call comments must be sent to the list in order that there be a record
>of them. I don't recall any email from you on
>draft-ietf-seamoby-car-discovery-issues-01.txt
>during the last call period, but perhaps I missed it. If you have any
>comments,
>please send them out within the next day.
>
>Also note that we are talking here about the problem statement, not the
>requirements.
>I have noted a thread over the last couple days on requirements, and
>your comments, will
>naturally be taken into account when the requirements draft is done.
>
>                 jak
>
>----- Original Message -----
>From: "Hesham Soliman (ERA)" <[email-masked]>
>To: "'James Kempf'" <[email-masked]>; <[email-masked]>
>Sent: Friday, January 11, 2002 9:59 AM
>Subject: RE: [Seamoby] Status of WG Last Call
>
>
> >   >
> > => Just a minute, we _are_ discussing comments on 3).
> > I've also made these comments in London.
> >
> > Hesham
> >
>
>

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 14 Jan 2002 15:06:23 +0100

James, 

  > during the last call period, but perhaps I missed it. 

=> No you didn't miss it, but I think the last call 
period was a very strange time, that goes over the 
christmas break where a lot of people (especially on
this side of the world) take some holidays. 

If 
  > you have any

=> I've already sent my comments on the draft 
(in this thread), specifically on the assumptions
in chapter 4.1. 

  > Also note that we are talking here about the problem 

=> I commented on both in my email.

Hesham

  > >   > No comments were received on 1) and 3), they will now 
  > be sent to
  > the
  > >   > IESG for review.
  > >

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 14 Jan 2002 16:58:32 +0100

Hi Hemant, 

  > last call that has not been attended to. 

=> I'm not on the NSIS list. This is a seamoby doc.

  > "requirements" draft and the "solutions" draft.

=> I made comments on both. I realise they are 2 different
things.

Hesham

  > > >   > No comments were received on 1) and 3), they will 
  > now be sent to
  > >the
  > > >   > IESG for review.
  > > >

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 14 Jan 2002 14:33:43 -0600

I don't want 4.12 removed, because I don't want to put
the burden of context management (collection and dump)
on the context transfer protocol. Removing 4.12 would
add that extra requirement on CTP. CTP was supposed
to be a mere transport protocol. and that is why
I said you could reword it, if you want to, but not remove.
However, rewording it is up to people that are not happy with
it IMHO :)

I don't care about 4.15, since a MAY is not a requirement
anyway :)

and yes 5.5.2 is a 1000:1 condensation of a lot of reliability discussions,
it should stay. Nobody likes to get garbage instead of actual
context

Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Friday, January 11, 2002 4:34 PM
To: Gary Kenward; George Tsirtsis; Nakhjiri Madjid-MNAKHJI1;
[email-masked]

Sorry, Gary, it wasn't a nonvote.

That you don't care about 4.12 and 4.15 means that you don't care
whether we get rid of them. Since George
wants to get rid of them, unless somebody else complains, they will go.

As for 5.5.2, since you want to keep it, it stays.

Since you didn't say anything about 4.13, it goes unless somebody cares
that it stays.

            jak

----- Original Message -----
From: "Gary Kenward" <[email-masked]>
To: "'James Kempf'" <[email-masked]>; "George Tsirtsis"
<[email-masked]>; "Nakhjiri Madjid-MNAKHJI1"
<[email-masked]>; <[email-masked]>
Sent: Friday, January 11, 2002 2:19 PM
Subject: RE: [Seamoby] Status of WG Last Call

> Since I spoke up before and my name was mentioned in the recent
> exchange....
>
> I do not care about 4.12 or 4.15, one way or another.
>
> I do care about 5.5.2, but these requirements have revisited
> so many times that the rationale behind them are ethereal,
> so I will sit firmly on the fence.
>
> How that for an explicit non-vote?
>
> Gary
>
> > -----Original Message-----
> > From: James Kempf [mailto:[email-masked]]
> > Sent: January 11, 2002 17:10
> > To: George Tsirtsis; Nakhjiri Madjid-MNAKHJI1; [email-masked]
> > > >From what I remember Gary said that he supports the
> > removal of 3 out
> > of the
> > > 4 points....so the 2 opinions against the removal do not
constitute
> > what I
> > > would call....WG consensus do they? In fact only Madjid
> > said that "we
> > could
> > > re-word but not remove"...who was the 2nd person against removal?
> > >
> > > Maybe you should ask "who cares?"
> > >
> >
> > Alright, but this is *the very last time*. We do really need
> > to get this
> > document on the way.
> > This is a concensus call. Is there any opposition to removing the
> > following requirements
> > from draft-ietf-seamoby-ct-reqs-02.txt:
> >
> > 4.12 The context information to be transferred MUST be
> > available at the
> > AR
> > performing the transfer, prior to the initiation of a given
> > phase of the
> > context transfer.
> > 4.13 The context transfer solution WILL NOT verify the context
> > information
> > prior to transfer.
> > 4.15 The context transfer solution MAY include methods for
> > interworking
> > with
> > non-IETF mobility solutions.
> > 5.5.2 A context update MUST preserve the integrity, and thus the
> > meaning, of
> > the context at each receiving AR.
> >
> > Speak until Monday 3 PM Pacific Standard time or forever hold your
> > peace.
> >
> >             jak
> >
> >
> >

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 14 Jan 2002 14:37:15 -0600

Govind, 
 you got it. But lets not get into "how much prior" right now :)

Madjid

-----Original Message-----
From: Govind Krishnamurthi [mailto:[email-masked]]
Sent: Friday, January 11, 2002 6:02 PM
To: [email-masked]
Subject: Re: [Seamoby] Status of WG Last Call

Do we loose much by letting 4.12 stay? I don't see this such a big
problem as the transferring AR much get the context prior to transfer
anyways.. so the only point is how much prior.
Maybe I'm missing something.
-Govind.

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 15 Jan 2002 13:16:06 +0100

Hi Hemant

  > Opps, that was a slip of pen, of course. I meant Seamoby, 
  > and not NSIS. So, 
  > was the concern raised on SEAMOBY list, and what exactly was it?

=> I don't know where the spanish inquisition is going :) but
we've already agreed to the change. Btw, i never claimed to
have sent this comment during last call, I always said
I made the comment in London. London IETF _meeting_

  > 
  > I do not know if it is good to change the name 
  > "anticipated" now as, for 
  > one, it has references at other places in document, as well 
  > as there is no 
  > other better alternative name. I do not think that AR-based 
  > better suited 
  > than anticipated. Anticipated discovery means discovery 
  > before actual 
  > handoff event. It could be AR-based on anyting else based.

=> I don't care what it's called as long as it is meaningful
and consistent. If people want to go with anticipated 
then be it, call them AR-based and MN-based anticipation. 
If this WG has some kind of allergic reaction towards MIP
terminology then replace MN with something else. 
But simply attaching anticipation to AR-based discovery
only is not correct.

  > 
  > However, we can certainly finetune the text to state that 
  > _a set_ of CARs 
  > (_not all_ CARs) are discovered. 

=> Yes this should be done too.

With that, can we close 
  > this tread now and 
  > conclude on the issues draft? Please let us know. Thanks.

=> I was under the impression that we concluded already as per
James' email. My comment is to change both the anticipated 
terminology and the first sentence under 4.1.

Thanks, 
Hesham

  > >To: "'Hemant Chaskar'" <[email-masked]>, 
  > [email-masked],    
  > >     "Hesham Soliman (ERA)" 
  > <[email-masked]>,        
  > >[email-masked]
  > >Date: Mon, 14 Jan 2002 16:58:32 +0100
  > >
  > >Hi Hemant,
  > >
  > >   > > >   > 1) 
  > draft-ietf-seamoby-context-transfer-problem-stat-04.txt
  > >   > > >   > 4) 
  > draft-ietf-seamoby-paging-protocol-assessment-00.txt
  > >   > > >   >

---

From: "Pat R. Calhoun" <[email-masked]>
Date: Tue, 15 Jan 2002 06:24:04 -0800

Hesham, because of the holidays, we provided much more than the
necessary two weeks.

PatC

- -----Original Message-----
From: Hesham Soliman (ERA) [mailto:[email-masked]] 
Sent: Monday, January 14, 2002 6:06 AM
To: 'James Kempf'; Hesham Soliman (ERA); [email-masked]
Subject: RE: [Seamoby] Status of WG Last Call

James, 

If 

Hesham

---

From: "Pat R. Calhoun" <[email-masked]>
Date: Tue, 15 Jan 2002 06:27:33 -0800

=> I don't know where the spanish inquisition is going :) but we've
already agreed to the change. Btw, i never claimed to have sent this
comment during last call, I always said I made the comment in London.
London IETF _meeting_

Hesham, it is necessary to actually send your comments on the mailing
list during the last call period. Otherwise, folks like me forget,
and we have no record of the comment.

PatC

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 15 Jan 2002 15:35:00 +0100

=> Got it, but there should be some record in the meeting
minutes.

Hesham
 
PatC

---

From: "Pat R. Calhoun" <[email-masked]>
Date: Tue, 15 Jan 2002 06:38:23 -0800

I hope you don't seriously expect the document editors to have to
interpret a third party's interpretation of a WG last call comment,
that may, or may not be, in the meeting minutes, right? :)

Anyways... For future reference, it would be best to send the comment
to the list as well.

PatC

- -----Original Message-----
From: Hesham Soliman (ERA) [mailto:[email-masked]] 
Sent: Tuesday, January 15, 2002 6:35 AM
To: Pat R. Calhoun; Hesham Soliman (ERA); 'Hemant Chaskar';
[email-masked]; [email-masked]
Subject: RE: [Seamoby] Status of WG Last Call

=> Got it, but there should be some record in the meeting minutes.

Hesham
 
PatC 
- -----BEGIN PGP SIGNATURE----- 
Version: PGPfreeware 7.0.3 for non-commercial use
<http://www.pgp.com> 
iQA/AwUBPEQ8VTN1fXKoxmisEQJ4hwCcCfeHq486uENYYZ+UxJ9rw3tON5YAnjcc 
QnLZJG6ZzNoWfit71TWCMMh8 
=vVeS 
- -----END PGP SIGNATURE-----

---

From: Scott Bradner <[email-masked]>
Date: Tue, 15 Jan 2002 09:50:11 -0500 (EST)

> Hesham, because of the holidays, we provided much more than the

note that the IETF always wants to know about real problems in specifications
but it is helpful if people who have problems be very clear as to what they
are - so, Hesham, can you please send your comments to the list now -
please be very careful to say 
	1/ exactly what you think is wrong
	2/ exactly what you think should be done to fix it

I understand that you have already sent or said them but please do so again
so that there is no misunderstanding on what you are talking about

note that not all comments may pass working group consensus muster

Scott

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 15 Jan 2002 16:08:06 +0100

Hi Scott and all,

  > 	2/ exactly what you think should be done to fix it

=> I have 2 minor comments really but I thought they were
important enough to make sure we understand the different
ways of solving the problems outlined in the draft. 

1. The title of chapter 4.1 is confusing. It associates
'anticipation' with the case where the AR discovers 
other GAARs. This need not be the case. If anticipation
is in relation to handover, the MN can also discover
GAARs in advance. If anticipation is in relation to some
other event, then I think this 'other event' should be
stated. 

Chapter 4.2, on the other hand, explains the case where 
the MN discovers GAARs and is given a different. 

2. The first sentence of the same chapter (4.1) states
that the AR can discover a set of all GAARs for a 
certain MN. I think this assertion is false and I 
don't see why it should be stated at all. 

I hope this is clear enough. I really thought these 
are quite straight forward comments and we can fix
them quickly. Overall the draft is well written.

  > note that not all comments may pass working group consensus muster

=> Sure.

Hesham

---

From: "Trossen Dirk (NRC/Boston)" <[email-masked]>
Date: Tue, 15 Jan 2002 10:17:23 -0500

Hi Hesham,

As I tried to explain, the terms anticipated as well as dynamic are 
meant as timing-based differentiation criterias regarding the knowledge 
of the CARs in the case of a handoff event. So I don't quite understand 
why the title as such is confusing since what you mentioned is our
example 
in the text that, in your opinion, precludes MN-based anticipated CAR 
discovery.

So why don't we agree on explicit statements that the descriptions
(for both cases) merely outlines examples how (and where) the
anticipation
(or the dynamic request for the second case) could happen so that we
eliminate the impression to preclude other solutions.

The second comment is no problem.

BTW, the focus in Section 4.2 is not on the fact that the MN discovers,
it is the again the TIME when the GAARs are discovered, namely at the
time of handoff in contrast to the example in Section 4.1 !

Regards,

Dirk

> From: ext Hesham Soliman (ERA) [mailto:[email-masked]]
> Sent: Tuesday, January 15, 2002 10:08 AM
> To: Scott Bradner; Hesham Soliman (ERA); [email-masked];
> [email-masked]; [email-masked]

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 15 Jan 2002 18:34:36 +0100

> of the CARs in the case of a handoff event. 

=> And I already tried to explain that this is not reflecting
the text in the draft. I don't think we're making any 
progress, but I suggest you read the draft without 
your author's hat because I get the impression that the 
authors meant somethings that are not obvious to me
in the text. But of course I could also be wrong.

  > eliminate the impression to preclude other solutions.

=> You mean we state that the chapter (e.g. 4.1) only
states one example of achieving anticipation ?
Do you think that this is easier than changing the 
title to reflect the real concepts behind the chapter ? 

  > The second comment is no problem.

=> OK.

  > time of handoff in contrast to the example in Section 4.1 !

=> I might be confused or unable to comprehend your explanation
in the draft, but what you're explaining on email 
does not (entirely) reflect the draft. I'm not saying time 
is not relevant here (although you insist on repeating this), 
I am saying that the differences between 4.1 and 4.2
are TIMING and ENTITIES involved in the discovery. 
If you agree with that, then the text in the draft
does not reflect this. 

I have expressed my opinion several times now and I 
can see we're revisiting the same places, so it's
up to the WG to decide on this. 

Hesham

---

From: "Trossen Dirk (NRC/Boston)" <[email-masked]>
Date: Tue, 15 Jan 2002 13:04:58 -0500

Hi Hesham,

see comments inline.
> title to reflect the real concepts behind the chapter ? 

Yes, it is. The timing issue is the differentiation, reflected by
the title alone. A title 'AR- or router-based' introduces another
concept of differentiation, and the entire text has to reflect that
and has therefore to be changed appropriately. It is simply not done 
with just changing the title. As I suggested in my mail, let's explictly

state that the text only reflects examples to not preclude other 
solutions. 

Let's face it, this is an issue draft that is not intended to reflect 
all possible 'modes' of  operations since the basis issues of CAR
discovery 
is the same for all these 'modes'.

> If you agree with that, then the text in the draft

The differentiation is made based on time, the text are examples
for this mode. These examples indeed involve different entities
but we could have also used an AR-based example for Section 4.2.

> up to the WG to decide on this. 

My problem is that exactly noone else participated in this
discussion. The specific text has been out now for six months
with two WG last calls, and noone came up with that discussion.
This means (maybe I understand the procedures wrong), that
the WG has already decided that this is ok. You are the only
one coming with this issue, and this after the second last call.

If we introduce procedure like this, we will certainly never come
to an end.

Regards,

Dirk

---

From: "Hemant Chaskar" <[email-masked]>
Date: Tue, 15 Jan 2002 18:37:31

Hi Hesham,

---Snip------

>If you agree with that, then the text in the draft

We do not agree with this, and hence, the text does not reflect it either. 
It is only the TIMING that we are proposing for classification as it causes 
first order differentiation among the approaches. The second order 
differentiation based on who takes lead (I do not know how lead will be 
defined) in doing this is solution specific, and it is left as a free 
parameter in the problem statement. If we had to classify using (Timing, 
Entities) tuple, there would have been at least 4 combinations, as each of 
these parameters can take 2 distinct values. Or there would have been 9 
different classifications if each parameter can take "hybrid" as valid value 
as well.

Hemant

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Tue, 15 Jan 2002 13:46:40 -0500

Hello Hesham,
We are working on text which
will detail a temporal classification of CAR discovery protocols.
We will post it on the WG mailing list. We look forward
to your comments then.
Regards,
Govind.

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 16 Jan 2002 11:32:58 +0100

Thanks, 
Hesham

  > Sent: Tuesday, January 15, 2002 7:47 PM
  > To: [email-masked]
  > Join the world's largest e-mail service with MSN Hotmail. 
  > http://www.hotmail.com
  > 
  >