[no subject]

------
Paging Assessment Update

Four volunteers, each assigned a different protocol proposal.
There was an effort to calibrate the results across assessments.

All protocols had good points; all had problems.
Security was a particular problem.
- Some recommend IPSEC, some new, details lacking.

draft-ohba-seamoby-last-hop-dmha-02.txt
+ Good ...
- Ties paging agent directly to last hop subnet, so no
subnet-independent 

Q: The second item is not correct because we don't mention
subnet-dependent PA.  The PA in our protocol can go anywhere.
A: OK.

draft-koodli-paging-00.txt
+ c

draft-sarikaya-seamoby-mipv6hp-00.txt
+ Good layer 2 integration
- No v4 support

Q: Was combining these a good idea?  These were completely different
proposals.
A: That is a fair statement.  We'll cover it later.

draft-renker-paging-ipv6-01.txt
+ Lots of details.
...

Next Step recommendations
1) another round of assessments or
2) Start work toward common protocol -- Allison et al

Marco Leibsch will be the draft editor.


Q: How should contributors put in recommendations. 
A: If it is short, send it to the list.  If it is lengthy, contribute
as an ID.
Pat Calhoun: Rather than having folks submit draft, people should submit
proposed text to the list.

Q: How will we incorporate material from the other drafts?
James Kempf: Look at the assessment draft and see what is missing from the
Renker draft and submit the relevant pieces of the other drafts as
changes to specific sections.
Pat Calhoun:Assessment draft going to last call.
Jari Malnin: Last call will be a good idea for reviewing the assessment
draft.  Especially the security area needs a lot of attention.

ACTION ITEM: WG chairs will find somebody to do security assessment.

Q: Question about unifying ideas and
the feedback of the assessment.  Are the comments going into the
2nd version of the assessment?
A: The assessment draft is complete as it is.  People can submit
proposals during last call for changes.

-----------
CT Problem Statement

There were MAJOR comments from the IESG.  It is going back to the
IESG after WG Last Call completes.

------------
General Requirements for Context Transfer

There were a LOT of comments which we did NOT accept.  Some changes
were substantial so this doc will go through ANOTHER WG last call.

...
Section 4.13 expanded greatly.

Q: Is WILL NOT part of the standard terms?
A: No, is SHOULD be a MUST NOT.
Q: So if the CT solution verifies the CT info prior to transfer it is NOT
acceptable?
A: We'll take that up on the mailing list.

New requirement
4.16 The CT solution MUST include methods for interworking w/any IETF IP
handover solution.

4.17 The CT solution MUST be scalable.  

Pat Calhoun: That's kind of hard to quantify...
Scott Bradner: 3.5lbs of scalability.

------------
CT Next Steps

Follow the same process as DMHA
Due date for protocols is Feb 1st/

These dates give time to submit an ID in time for IETF-53.

Pat Calhoun: Are there things we should change about the DMHA process?
James Kempf: We REALLY encourage people to volunteer.  We really appreciate the
volunteers who worked through the assessment process.

---------
CAR Discovery Issues update
dis-cardiscovery-issues-01.txt 

What's CAR discovery?
- Discover AR's that an MN can hand over to.

Changes from 00.txt
PAAR -> GAAR
New section to to illustrate GAARs separated by several domains
Example scenarios to justify CAR
New section demonstrating that existing protocols don't do this

Requirements:
MUST: L2 id -> L3 id.
MUST L2 devices of different technologies.
MUST: L2 devices in private/site-local spaces.
MUST: Capability communication between GAARs.
MUST&TBD: Standard format for capabilities.
SHOULD: Protocol applicability -- Interdomain as well as Intra-domain scope.
MUST NOT: Introduce new network elements for CAR discovery.
SHOULD: Minimize involvement of ARs which are not GAARs in CAR discovery.
MUST NOT: Depend on particular mobility protocol.

Q: Support for L2 devices in private/site-local spaces makes no sense
at all.
A: We think it can be done.

Phil Neumiller: You might consider a new requirements.  We have MANET and 
MIP and there is very little bridging.  This could fill this gap.
A: So you want to support mobile routers also?
PN: We don't want to preclude mobile ARs.
A: I don't think we preclude that now, but if you want to add a SHOULD
for that we could do that.

Pat Calhoun: Looking at requirements I see something that's not on there.
The mobile provides its view of the network.  There
are some DoS attacks possible from this.
A: I don't see why we need to preclude that.  If the MN's are suitably
authenticated, it should not be a problem.
PC: Authentication is not the issue.  An MN can still inject erroneous
information about what the network looks like.
Scott Bradner: It is a long policy in the IETF for nodes not to know about
network topology.  It would have to be a REALLY GOOD idea to take
advantage of MN knowledge of network topology.

James Kempf: Are you talking about Localized Mobility Mangement?
James Kempf: It sounds like there may be some overlap w/MANET.
Phil Neumiller: MIP and MANETs are going to collide.  This is an ideal place to
deal with these requirements.
Pat Calhoun: Is Scott Corsen (co-chair of MANET) here?  Do you know anything 
about this work?
Scott Corsen: Right now there is no specific item for this work.  There have
been submissions but none have been accepted.
PC: Any work that people try to submit there should be redirected to
here.

Concensus call:
SHOULD to MUST for Inter domain as well as Intra-domain scope?
[plenty of hands in support, none in dissent]

Slide discussion on issue involving MN detection of
network topologies:



Pat Calhoun: (Draws diagram with overlapping circles to represent
service areas).
A malicious dot (representing the MN) tells local cells about far away 
cells.  This could "confuse" the local cells.

Some discussion about how critical the problem is, and
discussion on possible solutions.

James Kempf: There is clearly a problem to be solved.

Scott Bradner: Once you start down the path of letting the MN know about
topology, it gets you into the problem of what path to take and you
don't want to go there.

Comments about whether or not MNs do
continuous scanning.

Comment from an author: Neither proposal has this problem.

Security association discussion...

George Tsirtsis: What is the usefulness of know somebody is a neighbor other
than to create an SA?
Hesham Soliman: I am very concerned that the direction to go is to have
routers discover for each other, but we've found this doesn't scale.
Why doesn't each router just advertise for itself?

Pat Calhoun: It sounds like there are a lot of people who need to read and
comment on the problem statement.  We appear to be trying to discuss
multiple problems.

Ajoy Singh: I don't see that we have a strong scaling requirement.  
This is how CDMA and GSM work today.


------------
CAR Next Steps

We wanted avoid a lengthy requirements phase, but that's sounding like
it might be a problem.

Is everybody comfortable with the requirements discussed?
Comment: If we add the MANET issues we should be OK.

Discussion about inter- v.s. intradomain discovery.

George Tsertsis: Automatic discovery of AR's from separate domains is not a
GOOD THING.

The discussion ended with moving this issue to the list.


-------
Following stuff has to happen before IETF-53

DMHA Protocol Design First Draft
CT Protocol Submission Complete and base Protocol Selected
CAR Problem Statement and Requirements Complete

</PRE>

<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<hr>
<ul><li><strong>Follow-Ups</strong>:
<ul>
<li><strong><a name="00080" href="msg00080.html">Re: [Seamoby] Minutes of Meeting at IETF 52</a></strong>
<ul><li><em>From:</em> Behcet Sarikaya <behcet.sarikaya@alcatel.com></li></ul></li>
</ul></li></ul>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<ul>
<li>Prev by Date:
<strong><a href="msg00076.html">Re: [Seamoby] IP Paging ]Framework discussion</a></strong>
</li>
<li>Next by Date:
<strong><a href="msg00078.html">Re: [Seamoby] Minutes of Meeting at IETF 52</a></strong>
</li>
<li>Previous by thread:
<strong><a href="msg00065.html">[Seamoby] IP Paging ]Framework discussion</a></strong>
</li>
<li>Next by thread:
<strong><a href="msg00080.html">Re: [Seamoby] Minutes of Meeting at IETF 52</a></strong>
</li>
<li>Index(es):
<ul>
<li><a href="mail76.html#00077"><strong>Date</strong></a></li>
<li><a href="thrd74.html#00077"><strong>Thread</strong></a></li>
</ul>
</li>
</ul>

<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
</body>
</html>
</pre>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<hr>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<ul>
<li>Prev by Date:
<strong><a href="msg00075.html">[no subject]</a></strong>
</li>
<li>Next by Date:
<strong><a href="msg00077.html">[no subject]</a></strong>
</li>
<li>Previous by thread:
<strong><a href="msg00075.html">[no subject]</a></strong>
</li>
<li>Next by thread:
<strong><a href="msg00077.html">[no subject]</a></strong>
</li>
<li>Index(es):
<ul>
<li><a href="maillist.html#00076"><strong>Date</strong></a></li>
<li><a href="threads.html#00076"><strong>Thread</strong></a></li>
</ul>
</li>
</ul>

<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
</body>
</html>
</pre>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<hr>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<ul>
<li>Prev by Date:
<strong><a href="msg00075.html">[no subject]</a></strong>
</li>
<li>Next by Date:
<strong><a href="msg00077.html">[no subject]</a></strong>
</li>
<li>Previous by thread:
<strong><a href="msg00075.html">[no subject]</a></strong>
</li>
<li>Next by thread:
<strong><a href="msg00077.html">[no subject]</a></strong>
</li>
<li>Index(es):
<ul>
<li><a href="maillist.html#00076"><strong>Date</strong></a></li>
<li><a href="threads.html#00076"><strong>Thread</strong></a></li>
</ul>
</li>
</ul>

<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
</body>
</html>