IETF56 Network Mobility (NEMO) Working Group Minutes - March 18, 2003


Scribes: W. Ivancic, Alexandru Petrescu, TJ Kniveton

Note: the complete jabber log is available at:

http://www.jabber.com/chatbot/logs/confe
rence.ietf.jabber.com/nemo/

Wednesday, March 18 at 0900-1130
=================================

CHAIR:	Thierry Ernst  
	TJ Kniveton  

Reading list: 
  all drafts available on 
http://www.nal.motlabs.com/nemo
      draft-ernst-nemo-terminology-01.txt
      draft-ietf-nemo-requirements-00.txt  
      
draft-ng-nemo-multihoming-issues-00.txt 
      draft-wakikawa-nemo-basic-00.txt
      draft-petrescu-nemo-mrha-02.txt
      
draft-thubert-nemo-ipv4-traversal-00.txt

AGENDA:
Charter Update and Milestones   - TJ Kniveton 
NEMO Support Requirements - Thierry Ernst
Multi-Homing Issues in Bi-Directional Tunneling - Chan Wah, Takeshi 
Tanaka 
AAA discussion
IPv4 traversal for MIPv6 based Mobile Routers - Pascal Thurbet       
Basic NEMO Support solutions

NEMO Support Requirements - Thierry Ernst
  Draft Update
  draft-ietf-nemo-requirements-00.txt
  
draft-ng-nemo-multihoming-issues-00.txt 
  Basic NEMO Support solutions
  draft-wakikawa-nemo-basic-00.txt
    


========================================
==============================
Agenda Bashing - TJ Kniveton

========================================
==============================
New agenda item "Basic NEMO support starting point - TJ Kniveton"
No concerns


Charter Update and Milestones   - TJ Kniveton

========================================
============================= 
Charter updated Jan 03. This change was to update some typos.  
Milestones were also adjusted by a few months to match formation of 
working group.

March 03  Terminology document is supposed to be delivered to IESG May 03 
Submit threat analysis and security requirements. This is not clear yet; we 
need more activity on the list.

Aug 03 Submit solution for basic support to IESG - this is the current 
focus of nemo.


Route optimization is not currently on the plate, more discussing the 
issues at this point.



========================================================
Basic Support Requirements - Thierry Ernst

========================================================

There was a discussion held on whether or not to merge the 
terminology and requirements draft. Thierry is in favor of combining them. 
Group members made comments on various points why keeping them separate 
might be advantageous. Consensus was reached to keep these documents 
separate. However, we will follow up on the list to validate this.

Also, we should look at merging the appropriate terminology to seamoby and 
then simply reference the seamoby document when appropriate.  Part of the 
goal of the seamoby terminology document was to be a useful document for 
various mobile protocols thereby reducing size of individual mobility 
protocol's requirements documents.


Comments on this topic in Appendix A.1

Thierry described multi-homing cases -- multi-addressed, 
multi-interfaced, multi-linked, multi-sited. 
General comments on multihoming:
- If mr's need multiple prefixes, we might need a new word for it.
- maybe we can define the most specific terms like multi-address, so we - 
need to clarify if m.h. means that interfaces are to be available 
simultaneously or not.
- need to clarify if multihoming means you have multiple addresses on the 
same interface.  If you have multi address, you have several tunnels, each 
one being a different interfaces.
- Text should be added that addresses benefits / use of 
multihoming?
- The degree of layering cannot be enforce, thus it should not be 
specified.  Rather, the text should simply state the multihoming should be 
supported. The preferred approach will result from evaluations, not 
requirements.


Comments on this topic in Appendix A.2

General comments.  For many instances the concept of "design goals" would 
serve nemo better than "requirements".  This pertains to issues such as NAT 
and PAT transversal, fault tolerance, and location privacy.

R14 requirement - signaling messages between the HA and the MR MUST be 
secured.  Consensus is R14.4 requirement for encryption should be 
removed from basic support.  Will be move to the mailing list.

Some discussion on location privacy.  Since headers contain 
addresses, people can always see your home and care-of address, so it's 
always visible. Somebody in the middle of the network can track your 
movement, which is a location privacy concern.  No consensus as to 
whether or not this should be a basic requirement.

Appears to be consensus to remove R16, impact of protocol on the routing 
fabric.

R17: The solution MUST ensure backward compatibility with other 
standards defined by the IETF. What is the list of protocols that must be 
backward compatible? We can discuss this on the list.


For more discussion, see Appendix A.3


=====================================================
AAA - Chan-Wah

=====================================================
Issues - Migration transparency, AAA policy transparency, nested MRs and 
nested AAA relationships.

Consensus is that we need to understand AAA and what AAA models may be.  
However, it may be necessary to allow AAA to evolve regarding nemo as 
traditional AAA models may not apply and it is very unclear as to what the 
AAA models may be at this time.

- In the case of mobile networks, we want to have transparency of the 
network.


For more discussion, see Appendix A.4


======================================================
IPv4 traversal - pascal

======================================================
Idea described is to be able to traverse IPv6, IPv4 public and IPv4 
private as well as PATs and NATs.

Issues - Satellites, GPRS and many other systems use PATs and NATS. 
Public Access (DSL, etc...).  Also, most of today's 
infrastructure is IPv4

Consensus appears to be that having a "goal" of working over various PATs 
and NATs is fine.  However making this a requirement may not be wise as 
NATs and PATs are very unpredictable and constantly evolving.



========================================
==============================
Multi-Homing Issues in Bi-Dir. Tunneling - Chan Wah and Takeshi Tanaka

========================================
==============================
Consensus that pictures in the draft are very useful to discuss 
multihoming and understand the scenarios.

Question: If mult-egress links have active open paths, then should the MR 
actively switch to different route instead of waiting for MNNs to 
discover?

Having multiple address on single interface does not appear to be an issue to 
be addressed by nemo.

Having multiple MRs with different home agents requires 
coordination between HAs.  This is a fancy feature that we shouldn't have to 
worry about at this time.  The suggestion is that this not be required as 
part of the basic draft.  However, this could be considered for future 
development.

It is possible to have two mobile routers can serve the same prefix. we may 
ask the MR to tell the HA which prefix it's serving. in that case, it may 
have to tell multiple HAs, or have a single registration, etc.  Some 
advantages of having multilple HA's with a advertising the same MR prefix is 
that it can be used for geographically diverse locations of HA and fault 
tolerance.


For more discussion, see Appendix A.5


========================================
==========================
Basic Network Mobility Support - 
draft-wakikawa-nemo-basic-00.txt

========================================
==========================
The draft was presented by Thierry Ernst as Ryuji Wakikawa could not be 
present.  All technical questions should be directed to Ryuji via email or on 
the mailing list.

This draft has been tested and implemented under 
FreeBSD-Release.  They still need to do multiple home agents.

Some general issues/questions:

How does this implementation hand more than one prefix for your mobile 
network?

There appears to be a restriction to using only one prefix.  Thus, how do 
you create routes at the home agent for both prefixes? instead of having a 
prefix suboption?

Question - Does one always have to maintain a binding cache entry on the 
home agent, even when you're at home?

There was a comment that deregistration is easy with 
implementation. However it is unclear as to why this would be.

For more discussion, see Appendix A.6


========================================
=======================
Basic NEMO Support starting point

========================================
=======================
Delivery date for Base Document is August 03.

Requirements will be finalized by end of this month.

Consensus was reached that the group should use 
"draft-kniveton-mobrtr" as the starting document and insert material from 
the other drafts into this document.
 
Also, there was suggestion that 
draft-petrescu-nemo-mrha-02 should updated to included analysis of any new 
proposals to ease use by group.


========================================
==========================
Appendix A - Supporting Discussions

========================================
==========================
These were some (somewhat rough) notes on what individual speakers said. 
Also see the realtime Jabber logs, which provide an alternate log of these 
discussion items.

A.0 - Name abbreviations

TD: Terry Davis
TJ: T.J. Kniveton
TE: Thierry Ernst
PT: Pascal Thubert
SC: Samita Chakrabarti
JK: James Kempf
EN: Erik Nordmark
KM: Keith Moore
CW: ChanWah Ng
VD: Vijay Devarapalli
HYL: Hong-Yon Lach
WK: Woojune Kim
WI: Will Ivancic
AY: Alper Yegin
FW: S. Felix Wu
MT: Michael Thomas


A.1 - Terminology Document
--------------------------
PT: we already have these documents.
TE: doesn't mean it should be changed, just merged together.  Because 
terminology and requirements should be merged.  They should, could be 
merged with the seamoby document.  I need more feedback.
SC: first comment: I like the idea of merging terminology and reqs. I'm not 
sure, how can you then combine with seamoby terminology.
TE: I think there are a few words that are already in the seamoby 
terminology (AR, mobile node, mobile network).  For some reason they use 
them, so we should make sure we just use them the same way.  They should be 
combined or alt least, the consistence.
SC: as long as it makes sense to have them in the same doc, should not 
confuse.
TJ: can you clarify?  Seems you want to keep them in same doc?
SC: yes, I would like them in same doc.
JK: I think mobility transition, how can you.  If you have specific terms 
that are mobile network doc, you can keep them.  To the extent that you 
could reference doc, reduce the size of the terminology doc, reduces the 
size, attractive
TJ: suggestions you have how to merge?
JK: anything in addition for network mobility, keep them in this 
document.
PT: did you expect someone looking for terms will look them in the reqs 
doc?
TE:
PT: terminology is actualy to be found in... terminol. is to be evolved 
with reqs.  I don't see why we have to merge.
TE: one single document is easier to track.  There's a relation reqs and 
terminology.  For instance, multihoming, if you read the reqs doc and you 
don't have the terminology, you don't understand.  Reqs may look very 
lighter.
TJ (no hat): I would think conceptually makes sense to have them 
separate.  It's because what pascal said.  It might be hard to keep 
terminology and reqs up-to-date in the same doc.  Specifically if we do RO, 
where would the terminology be then?  A new terminology for RO?
TE: for RO we have new documents.  The idea is to submit terminology and 
reqs as RFC.  New terms for RO will have to be separate docs.
TJ: ok.
TE:vote: one doc, who?  two doc who? Conclusion: one doc.
TJ: please make more comments
TE: no it's ok
TJ: we'll have more discussion on this.  It seems like consensus right now is 
one doc, but we'll have more discussion.

Appendix A.2
------------
KM: multi-homing and source address solution doesn't work.  If you want to 
define a term describing something, I'm not against.  I'm not sure 
there's a point on this.
TE: we must be sure we know what it means.
KM: why that word?
TE: because it is from definition of multihoming for hosts.
KM: I object to, I don't think it is useful here, it doesn't apply here to 
this situation.  If you find that mr needs to deal with many 
interfaces then you might need it.
TE:
KM: i think it still to be confusing.  For people
EN: the doc must have to be specific on this.  multi-homing must catch all 
names for all thise doifferent things.  Draw pictures.  I think in 
general, if you look at rfc, it treats multhimong.  The term is 
actually consistent.  Whether it works or not is ok.  You'll be able to 
talk more accurate.
CW: define the most specific terms in terms of more specific like, 
multi-egress interface, so we know which scenario...
PT: I do agree what CW, we miss some terms.  What if one MR is linked to one 
HA, we should have more words.
TE: explicit text.
EN: finish the discussion and put drawings, figure out. it might be 
premature to add more terms to this.  You might discover later down
the rd that you might need more, I'm not sure you need more .
TE: mh means, read slide.
VD: the last one, just because a monet has two separate interfaces 
doesn't make it multhoming.
TE: what about the case you have multiple address.  Yo can not have both 
addresses at the same time.
VD: you mean?
TE: I mean.
VD: I mean that is vague, in my oppinion.
PT: several CoA, several tunnels, each tunnel can be an interface, you're 
actually multihomed.
HYL: definition speak loose.  Simultaneously active is different,
VD: you don't have to uplinks active, one tunnel is up only.  Two 
tunnels to different HA.  Source selction address.
PT: I don't want to address that discussion now, the detail is


Appendix A.3
------------
KM: basic problem.  This word reqs got attached to this.  Change from 
title from reqs to "design goals".  It is premature to define reqs at this 
point.  Strong consensus, it is fundamental.  Others are 
implications.  Misleading.  Suggest: change the title.  Label the goals as 
strength and importance.
TE: change the title of this section
KM: not, the whole document.  Not everything is requirements in that 
document.
TJ: solution must fit reqs.
KM: things will be compromised.  Goals indicate a sense of direction.  
You'll find compromises.  Casting thins in a rock, find easier 
solution.
TE: ok, other requests.  Location privacy.  I'll clarify what it means.  
Design goal. I need to clarify that.  There was request to add more text for 
the benfit of multihoming.  Do you agree we should more text in the 
section.
TJ: anyone has additional comments regarding km suggestions with respect to 
change in title?  Location privacy?
WK: regarding the reqs doc, it can be avoided.  Distinguish what we try to do 
with respect .  Change
Fault tolerance: is multihoming.  What is the intent to do?  More 
specific.  Why we need to have multiple interfaces.
TE: so you suggest to put more text
WK: yes..
PT: location privacy: there are actually 2 things: one for the visitor, one 
for the visitor network.  OTOH, if the monet proposes a global 
prefix...
TE: section 5 of reqs... go on through this.  Question: how many layers of 
nestedness.  At least two?  More than one?
MT: how can you prevent arbitrary layers of nesting?
TJ: by specifying in the draft that it doesn't have to happen.
MT: when it happens?
KM: it strikes me, that TCP is there?  There are performance 
limitations.  What do you try to work well?
HS: personally I dont think he can make it, if you have proxy RA?  be nice of 
solutions it just works, it naturally collapses.  I don't think 
solution should require x levels of nesting.
TE: what text should be there?
HS: I don't see a problem with text.  Naturally, protocol becomes. 
multiple nevels of tunnels, ugly, but slow.
TJ: question is: if there's a solution that allows max 0 levels of 
nesting, is it acceptable? 1, acceptable? n, acceptable?
WI: I think the text, we can not specify the levels of enforcing. 
Especially because VMN below doesn't see mobility.
HS: 0 levels of nesting, no.  1 levels.  If pick number, I'd say 2.
TE: at least 2, fine?
TE: a first
KM: The intent is ok.  Performance limitations might be apparent.  It 
would b
PT: first point is that we already have cases where the nesting occurs.  
Later on in the evaluation of proposals.  Scales better then 
preferred.
TE: <back on multi-homing>  DO you agree to remove the 3rd 
requirements and just keep the first line?
VD: as k said, multi-homing means diffs things.  E.g..   I think we 
should keep them.
PT: I don't think we should enter into multiple CoA registration.  This req 
is not clear whether you have one regi or two regi.  Maybe.., maybe then we
TJ: I have a question about what exactlly it means in this req.  Says 
solution must support these things.  Implementation details.  What 
exactly does "support" mean here?
TE: maybe word is not fine, maybe "function" is better.
TJ: i think implemntation details.
HS: depends on the solution itself.  There is at least 12.1 is much 
trickier, lots of sub-cases.
TE: another issue, use case of multi-homing.  Do we need to adapt this req?
TJ: this says "SHOULD".  You mean?
TE: I mean. because it was discussed.  I mean 13, not 12.
TJ: I'm talking about original question.
TE: ..?..
EN: so the document says R12.  Under says R13. Slide is not consisted with 
the numbering.
TE: yes, there was a mistake.  The req is 12 in the draft and 13
in. There's a new req which is proposed.
TD: links of aircraft are not all available.  Commercial ISP.  
Some of them are voice.  Very different combinations ponts on the 
ground.  You probably cant maintain a commercial internet session 
through a low speed digital linl.
KM: question, this is somehow not stated right.  I suspect that level of 
fault tolerance is something you want to provide for.  Seems like needs 
reworking.
TJ: I would make a comment, I'd like to avoid doing a lot of fault 
tolerance work for basic solution.  Like link failure should work is 
implementation.  Not part of basic spec.
HS: are thes reqs for basic rolusiton?  A document?  Basic support, 
multiple documents.   I mean , there's a need for this, WG produces.  
Nothing in reqs draft talks about that.  Basic solution.
TE: what people think about that?  Different docs for base support?
CW: wording is strange here.  Fault tolerance, we don't need it in the reqs 
doc.  It would be a very complicated undertaking, it shouldn't fall on us.  
Relate to terminology comment, if we do make that change, we have to 
clearly clarify here wha.
KM: minor comment: is it useful to distinguish between reqs on support and on 
implementation.  Clears things up.
TE: security requirements: payload messages may be encrypted.  Q:Does it 
make sense?
EN: a bit of hardplace.  This falls out.  Tunneling can be used IPsec 
secured, this falls out.
TE: so you suggest we don't need to add a text for encrypt payload.
Keith said that some of these things are protocol, others are external of 
the protocol.  Writing these types of docs is hard.  right level of 
description is a bit difficult.
VD: which nemo signalling message needs to be encrypted and why?
TE: and in which case?
VD: give me one example?
TE: I don't know.
VD: there are none.  Explanation is this.  BU/Back don't need 
encryption, but authentication.  R14.4 should go.
MT: one thing you loose, somebody in the middle, location privacy.
HS: you wouldn't get much privacy.
MT: 27 levels of obfuscation?
TJ: I think suggestion is to remove R14.4 and have more discussion.
MT: reqs document then it should not say that message is encrptyed.
But that should have.
TJ: how many more slides.
TE: one more.
TE: I need a list of protocols that need to be backward compatible.  
Maybe on the list, we can discuss.
MT: R16, how do you test for that?
TE: this is form the list discussions.  We have a clear idea of the basic 
solution.
MT: I would remove R16.
TE: a few issues.  Read slide.  Question, do we need to have reqs from this 
organizations.  It is too early maybe.  Reqs with specific use case.
PT: Signaling: it's not really we can place as req, but use as an 
evaluation criterion.
TE: minimize: keep vague.  Between two solutions choose one.
PT: point out which criterion.
TE: tricky to do it.
PT: you can't precise and
WI: I don't think you should have a separate req for different 
applications.  You should take into consideration what their needs are.  I 
strongly beleive you should have cross-boundaries between 
administrative domains.
TE: what do you think about preventing a mr in different domains?
VD: makes more sense to have it in the req document.
TE: last two req is the other speakers.
MT: redundant with the multihoming req?  How access control is done is 
related to.
TE: kind of falling on that.


Appendix A.4
------------
MT: does this WG actually needs to consider this?
TE: question is where we should discuss that.
CW: a possible approach is to id problems.  Problem statement draft reqs to 
other WGs.
EN: go back one slide.  Number 1 there I think there is another way of 
describing that at a hoghe lrevel of abstraction.  Would monets might end up 
doing nesting AAA relationships.  There are sort of boundaries AAA 
domains.  Nesting.  You want this nesting transparent as much as 
possible.  Number 2. Reflect nesting.  It's another way of thinking of 
this. Figure out what is the reasonable model fo thinking about AAA 
issues.  People can actually understand how we plan to fit this up in the 
AAA.  Samepicture.
TJ: based on that idea, layering of AAA associations, do you think there are 
reqs that should be communicatied to AAA, or it is just a matter of 
understanding.
EN: number 1 yes, number 2.  Req or not, business issue.
TD: migration transparency.  You should realize we handoff between 
different cells, you don't necessarily the same bandwidth.
Aircraft. Something you wanna think about.
MT: skeptical about being there _a_ AAA model.  There is a downside of 
concocting one at this point.  My preference would be to allow this to 
evolve more.  It may not even have much to do with traditional AAA 
altogether.  Single model might be premature at this point.
AY: id between mobile ip mobile nodes and monets.  Coupled.  Tightly 
coupled in a signel transaction.  In the monet case there is 
transparency.  Billing aspects might be different.
PT: IPv4 traversal slides.  read slides.  I'm asking for a 
requirement here.  The requirement of v4 traversal.
TJ: question is: what is the business of this WG for dealing with this 
issue? Do we need to have an additional req?  Do we need to just say we 
support this?
KM: nats are not predictable.  they don't ensure intergrity of payload.  if 
you're trying, you're constraining .  NATs are not stable, keep 
evolving.
PT: ALG?(Application Level Gateways)
KM: no, about advanced NAT.  basically you make your lives very very 
difficult.
PT: maybe you would place boundaries of which types of NATs.
KM: defining nat acceptable behaviour is a rathole.  Putting it as a 
requirement is difficult.
PT: how would you formulate the req to put this.
KM: i think it is too specific.  This derives from operational need.
PT: gprs is deployed.
KM: rathole.  It is not going to support mobile ip and mobile 
networks.  PT-KM argument.
People lining up.
TD: for whatever reason aircraft industry chose to assign private 
addresses to cabin.
TJ: using a NAT?
TD: sort of assume nat.
CW: sort of agree with K.  I'm not comfortable with making it a req.  
Because if we design that into the base, we've been grabbed down by 
history when we need clean.  Not as a req.  As an informational.  people can 
work with GPRS.  Go for it.  Basic solution should not have this req.
MT: seems WG group.  NAT free world. later decide what to do about 
reality.  Has the advantage of allowing progress.  horrible ratholes to 
happen.  reasonable protocol might actually happen, rfc number before next 
millenium.
KM: You impose a burden on the group.  Goal and not req.
TJ: couple of different viewpoints.  Please vote on: req for working on 
this, design the spec for a nat free world and leave req later, 
3-design for a nat free workd and come Comment?
EN: consider is also there mgith be a reasonale path forward.  
Composing things.  v6ops.  Basic Mobile IPv6 solution.  Headers get 
bigger, but might be less complex.  Not many cycles on.  Simplifying 
assumptions.  Compose existing stuff together.
PT: I did not actually give here.  We've being doing some work. Mobile IPv6 
can be used as a vector to pass nat or path.  Actually the midflows fits 
very well the picture, store the states.  ALG things. PAT/NAT.  It's easy 
but limited to mip, why.
TD: go with the "goal" rather than "requirement" for NAT traversal. Will 
make it easier for the spec to move forward.  Common techniques for 
traversing nats.

TJ: we can't prevent people to be interested in using nemo protocol to 
traverse nats. Please vote on adding a req? People raise hands.  In favor of 
not adding a req?  Consensus: not having a req for that.

Appendix A.5
------------
HS: question, bullet, undesidered.  why?
CW: because it takes time for mnodes to actually discover home.
HS: why is it ok for ipv6 but undesired for nemo?
CW: for nemo it is multiple egress links.  mr should actively, instead of 
waiting for mn's to discover.
HS: I don't disgaree there it would be nice to have something faster. It 
might be a genereic problem.
CW: it is a generic problem, but.
HS: I'm not sure I have
EN: the first bullet lead to believe IGP leads to imply to recover. It 
would be interesting to notice that ...  My model is assuming one 
organization runs a ha and runs mr and assign one prefix to monet, run IGP 
between the mr and ha. what are issues that are mobility, wireless 
flakiness, will pop up?  What do we need to do different?  Pictures are 
very useful, good for group to do.
WI: one thing to consider: multihimoing on wireless links, fast 
handovers, think about radio techs, thin.  Change two things is a 
problem. Kep radio in mind when developping seolutions.
AY: what is the purpose of different HAs sending different prefixes?
This is not basic requirements.
TE: you mean no reqs, but wg item we can think of.
AY: fancy features
TE: too early.
AY: at least too early.
WI: not in the basic draft..  Geopgraphically different locations for your HA
HA: have different HA for the same mobile router at the same time.
CW: diff mr, multiple mr, each time, distinctions..
TJ: comment, under mip, when mn walks away from home.  It will be served by 
any ha on the mobile link.  ha can advertise, multiple prefixes served by 
other HAs on the link, but the binding for a prefix will be served by 
whatever HA is serving it.
HS: multiple has with same prefix is no problem.  I thought that would 
work, do we need anything else?  Am I missing something?  Unless there are 
two home addresses.
TJ: yes, it should work.
FW: requirements on fault tolerance.  Should be considered seriously.  
Multiple HA.
TJ: do you think there should be any functionality?
FW: right, currently Mobile IP base solution is very close to what .
TJ: you suggest any specific functionality in the nemo spec that is not in 
Mobile IPv6.
FW: define coordination between different HA for supporting the same 
prefix.
HS: which problem are you trying to solve.
FW: both cases.
HS: two ha defending same home address.
FW: should not exclude the possibility.
AY: requires coordination between HAs.  Why?
AY: different mobile networks.  They are disjoint, traffic just follows 
prefix.  I don't see any integration that would require 
coordination between has.
CW: what if the mn chooses the other ha.
AY: the mobile node will first choose a prefix and then configure an IPv6 
address.
CW: must choose a default router.
AY: is not necessarily on the same.  theres no mn . i don't see .  just 
picks a prefix.
PT: prefix sees and, same prefix. basically with nemo we don't have a 
clear req.  Same prefix several times on ...  redundancy used it better.


Appendix A.6
------------ 
VD: what if the mobile network has more than one prefix?  How do you 
create routes in the HA for both prefixes?
TE: you send a different BU, you send one BU but with different.
VD: but you said you're not going
TE: I don't know in this case.
PT: if the mobile prefix is actually behind .  Why you want , I don't 
think it is necessary.
TE: ok.
TE: Changes to mobile ipv6. read slides.
MT: not clear to me that HA ipsec draft works directly.  I'm not sure that is 
a given.
TE: say that again.
MT: it ....
TE: there are changes of course.  Not exactly the same.
VD: basically Ryuji does provide an example.  You're missing something you 
have to always maintain a binding cache, even when you're at home.  Since 
there is no home.  What you meant by "de-registration"?
TE: I can not really give you the motivation.
VD: something is wrong in the drraft.
TJ: return home link, not home network.
VD: you have.
PT: scalability problem not addressed in the draft: there is no home 
network in the network, you'll have to do coordination, routing 
protocols.  Reminds me of what we talked about before about 
multi-homing.  Same kind.
TE: no more needed.  Show that there is different ways to solve the basic 
support issue.  It needs to be considered. Questions?  Please ask 
questions on the ml, ryuji will answer.


Appendix A.7
------------
JK: recommend right away, don't get caught with requirements.  Minor 
things, go for it.
VD: no need of threat analysis document.
TJ: security review.  Sanity check on that.  Any opinions on starting 
point for text?
PT: I'm missing the step here.  Should figure out what are the problems 
that are left to be solved.  NEMO seems to have a basic kernel, mn on the 
egress interface and the mobile ip router, no RO, that's kind of .  We want 
to add a few things.  Which exactly are those.  Try to say take 
everything from the draft and then we amend it.
TJ: what we have right now.  There's work to id exactly.  That's 
probably part of the process.  The discussion on the mailing list.  It is 
not really possible to do that ahead of time before .  Are there 
additional issues before we can start making a solution?  Or using one of 
the existing solutions?
MT: which draft has the fewest tweaks from Mobile IPv6 basic solution.
TJ: my answer is b (MRTP).
MT: what is the distance between these drafts?
TJ: answer, my personal impression, there isn't too much 
controversial.  Creative ways to do, exist.  Interesting points. There are 
limitations, obviously.  I would say, my personal, not too much 
controversies.  I think it is possible to proceed now.
MT: a real bare bones initial standard and then as things become more 
apparent, add optimization.
TJ: Yes, and the RO is split off as a separate task.
SC: suggestion, I was wondering if you one of you could put together a list 
that contains the common things.  Basic solution, and then can have some 
analysis on different aspects of the draft.  It would be easy for the WG to 
decide which one to pick.
TJ: the analysis is in Petrescu's document.  Basically looking at the 
different reverse-tunneling solutions.  Any suggestion beyond that?
SC: include Ryuji's draft and more email discussion in that draft.
TJ: ok.
PT: bare bone approach. PSBU thing.  What is the exactly the bare bone?  Do 
we have a clear requirement of having to update dynamically the HA?  Can we 
have a basic basic?
TJ: there is no specific req.  You really have the choice to do either one.  
The way that the solution will address the agreement.
PT: not have to do it?
TJ: it is implicit that HA must know what the prefix, otherwise it could not 
run packets.  AM i missing the point
PT: I have in mind that the stated definition will be there anyway. 
Exchange that, seems to me that it is , not needed in the bare bone 
approach.  It will come, but later.  Which of those that will come. 
Example, Ryuji draft is all about this.
TJ: ok, I have a question.  Does the WG feel comofrtable to choose a text 
starting with now?  Raise hands, 2 to 1.
MT: what would be the possibliity.  If there are subtle 
differences, that will probably good exercise.
TJ: authors of these drafts collaborate and choose some texts.  Bring 
controversial topics to the list.
PT: I prefer the initial draft: take your draft (MRTP) and take the best of 
the other ones.  Your draft has two sides: simple and complex.  Keep the 
simple.
TJ: draft explanation: has two cases.
HYL: team should be formed, not all authors.  Some other people who are 
interested should be able to participate.
TJ: other people who are interested that other authors should get 
involved?
TJ: OK, from these suggestions, how about this? We start with MRTP as the 
text, and have the draft authors collaborate on editing.
Vote: unanimous in favor (about half the room or so).