Subject: RE: [Seamoby] Moving forward with paging

From: "Pat R. Calhoun" <[email-masked]>
Date: Wed, 6 Feb 2002 17:33:52 -0800

Thanks for the feedback. However, what would be much more useful is
to provide comments on the assessment draft. If you believe that the
technical assessment of a particular draft is incorrect, please make
that statement. Perhaps the new text could justify the selection of
another draft as the starting point.
 
PatC

- -----Original Message-----
From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Wednesday, February 06, 2002 1:39 PM
To: Pat R. Calhoun
Cc: [email-masked]
Subject: Re: [Seamoby] Moving forward with paging

Pat R. Calhoun wrote:

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

So we are calling a WG last call on the assessment document
(draft-ietf-seamoby-paging-protocol-assessment-01.txt). We encourage
folks to provide their *technical* comments on the draft should they
believe that the findings of the assessment team are incorrect. We do
ask the WG members to kindly refrain from posting any process related
comments, since it detracts us from achieving our milestones. Once
the WG last call is complete, we will collect the comments that have
WG concensus and make any necessary changes to the draft. The WG last
call ends February 25th.

The end result is that the WG will get to decide which document is to
be used as the *starting point*.

Thanks for your patience,

PatC & jak

- -----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <
http://www.pgp.com >

iQA/AwUBPFrawTN1fXKoxmisEQIaWQCfYIis0Nsd52Q0Xv7wA77/RWn4J9IAn0t2
FoREK4Kavht9sSs7VjZIhLlV
=EmAk
- -----END PGP SIGNATURE-----

Dear all,
  Based on the technical evaluation of all the drafts I posted in a
previous mail on this thread, I propose draft-guri as the starting
point. This draft uses all the entities of the requirements
architecture and it does not make any assumptions on the mobility
protocol mapping. This means the text from other drafts (security
from draft-ohba, time-slot based paging from draft-sarikaya, mipv6
mappings from draft-renker and draft-koodli) can be easily
incorporated. Along with its own goodies of the triggers, draft-guri
would make a perfect starting point.
  My 2 euro cents.

- -- 
Behcet

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 07 Feb 2002 12:01:04 +0100

Pat and all,

proposing a protocol as starting point, I think the decision process
described in the assessment-01.txt addresses the right things and the
independence and flexibility of the draft-renker concept has been
understood. Therefore, I support the opinion of many others to keep
draft-renker as a starting point.

With respect to technical feedback on the assessment draft, I would like
to refer to my mail from Dec., 4th, 2001, where I covered feedback on
most of the issues addressed for draft-renker-paging-ipv6-01.txt.
If desired, I can send the mail again to the list.

In addition I would like to add some comments now:
wrt requirement 4.6:
As the assessment-01.txt indicates, multiple dormant modes should
address MTs, that have no explicit L2 paging support. The architecture
and protocol in draft-renker allows to keep access technologies
specifics transparent to the IP paging protocol up to Access Routers,
but allows mapping to any specifics at the Access Routers. This can be a
mapping to L2 wake-up/paging mechanisms, but might be a mapping to
link-local L3 paging (for example a solicited node multicast). This
concept allows easy integration of time-slotted paging from ARs in order
to improve efficiency of dormancy.

wrt requirement 4.19:
I don't think that this issue has been addressed correctly, since we
decribe how to authenticate paging related signaling by IPSec AH, like
other proposals do. Some security issues are addressed in the Security
Consideration section, but not describing threads addressed in RFC 3154
already. We described how our concept integrates into an IPSec
framework, but does not discuss establishment of SAs (as none of the
other drafts does). The deployment of the AAA framework as key
distribution center is described roughly.
In general, as addressed on the list already, the security issue is
obviously one of the issues requiring a lot more study and discussion.

wrt 4.20:
Same as 4.19, the assessment criticizes that the protocol relies on BUs,
which is not correct. It's only the case for MIPv6 optimization, as
described. For the generic (explicit signaling) case, which is the one
to be considered within the Seamoby WG protocol specification, IPSec AH
is deployed for signaling message authentication. The advantage of an
IPSec approach is also to support authentication of signaling messages
independent of UDP or IPv6 Destination Option transport.

wrt 4.21:
true, but advertising PA info from the attendant function located on
each Acces Router allows to authenticate and to keep this info broadcast
away from RtAdv specifics.

Regards,

Marco

"Pat R. Calhoun" wrote:

>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 07 Feb 2002 14:55:53 -0600

Dear All,
  My comments follow. If these changes are incorporated, I am OK with 
this draft going for the last call.
Comments on the assessment draft:
On page 2:
Of these, [6]
   and [7] were from the same team and were treated as one contribution
   for purposes of assessment.
Action: Drop this sentence, since 6 and 7 define different protocols and 
they were evaluated separately in 3.3 and 3.4.
Page 4
draft-renker-paging-ipv6-01.txt
       Unacceptable Requirements Match:
        4.4, 4.6, 4.19, 4.20, 4.21
Action: add 4.7 to the list.
Page 5
Requirement 4.7: Independence of Mobility Protocol
   
   The independence of mobility protocol is valid for "explicit" case
   only. The design specifies two separate protocols, one for Mobile IP
   and one without Mobile IP. 
Even implicit mode requires HA, i.e. Mobile IP, see the figure on page 
22 of draft-renker-paging-ipv6-01.txt.
Action: replace the text above with this: The design basically specifies 
one protocol for Mobile IP home agent based paging. 

Page 13
Draft-sarikaya was ruled out
   because it is based on a protocol that is currently under evaluation
   in another working group, setting up an unacceptable dependency
   between the Seamoby paging protocol design and the other working
   group's process.
Action: add the following to this. Moreover draft-sarikaya is not the 
only draft that has some dependency on HMIPv6. Draft-koodli also has 
included the mapping of their protocol to HMIPv6.

Page 13
While the assessment
   of draft-guri was positive, draft-guri is explicitly concerned with
   utilizing Layer 2 support for paging, and was therefore not
   sufficiently broad enough as a base for IP paging.
Action: Replace by: The assessment of draft-guri was positive.

Page 13 and 14.
Last 4 paragraphs starting with:
Of these, both draft-renker and draft-ohba provided adequate support
   for the first two, independence of mobility protocol and support for
   existing mobility protocols.
Until 5.0 Acknowledgements
Action: Drop completely.
The reasons are the following:
1.    Some comments on the "advantages:" of draft-renker may be taken to 
mean that: IETF is soliciting the draft authors to have a long reference 
list of the published literature including conference/journal  papers, 
otherwise you will be judged out not knowing the field
The fact is that the text and the related references of draft-renker 
fail to identify clearly which is Layer 2 related (there is a very rich 
literature on the paging in cellular networks which is called Layer 2 
paging) and which is Layer 3 related and some key references on Layer 3 
paging are missing.

Action. Add the following text.
As the response to the survey  sent out to the mailing list indicated, 
nobody is doing product in this area in the near future, so we have some 
time to get this right.

The Working Group wants a design that will last, like Internet routing
has, and fit properly into the Internet architecture,
since paging will be a key component of the future
all-IP wireless networks.  This is naturally going to require
some time.

Page 15
The acknowledgements.

This is the first time I see the authors acknowledging themselves. It is 
unheard of.
Action. Drop section 5.0.

Regards,

-- 
Behcet

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 08 Feb 2002 10:14:17 +0100

Behcet and all,

finally, are there some mails with technical content appearing on the
list? Great, this is what we need ;)
Please, be referred to my comments to your comments below.

Behcet Sarikaya wrote:

> Action: Drop this sentence, since 6 and 7 define different protocols
> and they were evaluated separately in 3.3 and 3.4.
> Page 4

Please, be referred to my previous mail, addressing these requirements
(and please comment, if somebody does not agree)

> 22 of draft-renker-paging-ipv6-01.txt.

Why 'even'?. 'Only' implicit mode assumes a HA, since 'implicit' mode
addresses MIPv6 related optimization. 'Explicit' mode is what we
consider in Seamoby, and ths mode is independent of a HA. You only have
to ensure, that initial paging trigger packets are captured by a DMA FE
in order to initiate a paging process. So what? 4.7 addresses
overspecification, which is in this case provision of more than the
generic 'explicit' case. Not considering the 'implicit' case, as
proposed several times for a framework draft, this requirement is
definitely a requirement match.

> Action: replace the text above with this: The design basically
> specifies one protocol for Mobile IP home agent based paging.
>

This is not true, please see my explanation above (and remember SLC
discussion). Although my feedback in the previous mail addressed some
issues probably not correctly interpreted by the assessment team,
assessment of requirement 4.7 is correct.

> included the mapping of their protocol to HMIPv6.

I don' think that one can assume a protocol is 'dependent' on a specific
mobility platform only if the proposal decribes how the paging
architecture integrates into some available mobility management solution
'as an example'. Correct?

> Until 5.0 Acknowledgements

I do not agree to drop this section, since for description of the
selection process, it is reasonable to have it in.

> 1.    Some comments on the “advantages:” of draft-renker may be taken
> to mean that: IETF is soliciting the draft authors to have a long
> reference list of the published literature including
> conference/journal  papers, otherwise you will be judged out not
> knowing the field
> fail to identify clearly which is Layer 2 related (there is a very
> rich literature on the paging in cellular networks which is called
> Layer 2 paging) and which is Layer 3 related and some key references
> on Layer 3 paging are missing.
>

Since some sections in draft-renker refer to advanced paging strategies,
related work has been referenced. You concern is not acceptable for me.

> nobody is doing product in this area in the near future, so we have
> some time to get this right.
>

Since some good work has been done already, why shifting further steps
to later? The importance of having a solution has been recognized,
otherwise there wouldn't be quite a lot of draft-submissions on this.
Better to work relaxed in order to come up with a clever solution in the
near future than working (possibly from scratch?) in the near future
under pressure. Furthermore, if standardization process will start
early, companies have the possibility to orientate their product
development planning early.

Regards,

Marco

> This is the first time I see the authors acknowledging themselves. It
> is unheard of.

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 08 Feb 2002 10:23:59 -0600

Marco and all,
  Some remarks on Marco's email:
1. Issue of Requirement 4.7. You said draft-renker satisfied it and 
mentioned DMA FE. Sorry but I could not find DMA in draft-renker (using 
a simple search). Also none of the figures of draft-renker has this 
entity. Maybe you meant to add this, but then probably there is no need, 
because draft-guri already has it and does the packet capturing using 
DMA. So we seem to agree on this important architectural issue that it 
should be done at DMA. Also let's agree that draft-renker does not 
satisfy 4.7 :)
2. Regarding HMIPv6, I agree with you. The text I suggested added 
regarding draft-koodli may or may not be added, but I stand by all other 
suggested changes. What is important here is that the statements in the 
assessment draft on this are too strong, I think that Seamoby can not 
close its eyes to what is going on in Mobile IP WG. We all know that 
James is an active contributor to MIP WG,
3. Regarding the next steps, the text I suggested was taken from James' 
recent email. Yes we do have some drafts and it does represent some 
progress. Remember that the "front runner" draft-renker is based on home 
agent paging whose disadvantages are well known. Of course the knowledge 
developed so far and is being developed can be utilized in the next 
steps whatever they they will be.

One possible avenue is to reconsider the requirements such as security 
items and even 4.7. The assessment draft can be advanced with the 
modifications if there is desire to have yet another RFC on IP paging or 
DHMA protocol. Remember that in IETF WGs there are many stale WG documents.
So I suggest that we continue to discuss on the mailing list and have a 
session at Minneapolis on
IP Paging solutions.

Regards,

Marco Liebsch wrote:

>>1.    Some comments on the "advantages:" of draft-renker may be taken

-- 
Behcet Sarikaya
Network Strategy Group, Mobile Networking Team
Alcatel USA M/S 026
1000 Coit Road  PB7
Plano, TX 75075 USA
Email: [email-masked]
Phone: (972) 477 2794 Fax: (972) 519 2460

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 08 Feb 2002 18:12:03 +0100

Behcet,

Behcet Sarikaya wrote:

> mentioned DMA FE. Sorry but I could not find DMA in draft-renker
> (using a simple search). Also none of the figures of draft-renker has
> this entity.

Please be referred to section C.1 of the draft.

> Maybe you meant to add this, but then probably there is no need,

Not agreed. Think of having a further section in draft-gury, describing
how your architecture might be integrated in a Mobile IPv6 platform.
Reading the 'entire' draft and understanding the architecture and
protocol ;), nobody would assume that your architecture is MIP / HA
dependent, or?

> regarding draft-koodli may or may not be added, but I stand by all
> other suggested changes. What is important here is that the statements
> in the assessment draft on this are too strong, I think that Seamoby
> can not close its eyes to what is going on in Mobile IP WG. We all
> know that James is an active contributor to MIP WG,
>

It cannot close its eyes, but the specific requirement intends to
de-couple the IP paging solution from the mobility platform.

> 3. Regarding the next steps, the text I suggested was taken from
> James' recent email. Yes we do have some drafts and it does represent
> some progress. Remember that the "front runner" draft-renker is based
> on home agent paging whose disadvantages are well known. Of course the
> knowledge developed so far and is being developed can be utilized in
> the next steps whatever they they will be.
>

Same issue as above, its not dependent on a HA.

Regards,

marco

> modifications if there is desire to have yet another RFC on IP paging
> or DHMA protocol. Remember that in IETF WGs there are many stale WG
> documents.
> So I suggest that we continue to discuss on the mailing list and have
> a session at Minneapolis on
> IP Paging solutions.
>
> Regards,
>
> Marco Liebsch wrote:
>
>> Behcet and all,
>>
>> >    only. The design specifies two separate protocols, one for
>> > Mobile
>> > IP