[Mip4] Draft minutes from IETF58

Hi,

Attached are the draft minutes from IETF58.  Please send any comments
to the list.  Especially welcome would be for the people whose
comments are marked as "???" to identify themselves.

These will get mailed to the minutes archives in a week or so.

-Pete

<html>
<head>
</head>
<body>
<pre>

IETF58 mip4 Working Group Minutes
=================================

Monday, November 10, 2003
1300 to 1500
Chairs: Henrik Levkowetz, Pete McCann

Thanks to Sami Vaarala and Eva Gustafsson for taking great notes.

- unclear things marked with XXX

- '???' refers to one and the same person who commented
  on the mike but whose name i did not get

mobile ipv4 agenda (henrik levkowetz and pete mccann)
-----------------------------------------------------

introductions and agenda (pete)

preliminaries (henrik)
	- work status web page http://www.mip4.org/

	- draft status

		draft-ietf-mip4-aaa-nai-00
			- reviewed by iesg, comments addressed in new text
			- one new issue by Bjorn Andersson
			- not re-submitted yet

		draft-ietf-mip4-vpn-problem-statement-00
			- pretty much done, needs writeup by chairs, will send to iesg

		draft-ietf-mobileip-lowlatency-handoffs-07
			- waiting for writeup, then to iesg

		draft-ietf-mip4-rfc2006bis-01
			- waiting for mivp4 specific mib review
			- after that, mib doctor review, finally iesg

		draft-ietf-mobileip-vpn-problem-solution-03
			- all comments addressed in latest version
			- but document needs peer review to go forward
			- wg chair review to be done soon

	- charlie perkins
		- what happened to the regional registration draft?
		- seems that since it is done, should be sent to iesg?
        - Defer this question a bit while chairs confer with ADs

aaa key draft (pete mccann)
----------------------------
    draft-ietf-mip4-aaa-key-01

	- editorial mistake corrected in -01

	- revisions from draft-ietf-mobileip-aaa-key-13
		- clarify: for ipv4, not ipv6
		- terminology cleanup
		- clarified what happens if reg. reply fails
		- iana considerations clarified
		- explicit security requirements for aaa key
			distribution infratstructure

	- next steps
		- one more ietf last call, then to iesg

	- charlie perkins
		- thought review was a response to iesg comments?

	- pete mccan
		- these were informal comments from iesg

	- alpesh patel
		- any work to support radius attributes?

	- pete mccann
        - There is ongoing work on the Diameter MIP4 application in aaa WG
		- mip4 not the place for RADIUS extensions, perhaps radiusext
          could take that work on

experimental messages (alpesh patel)
-----------------------------------------------
    draft-patel-mobileip-experimental-messages-02

	- problem statement
		- defines an experimental message, extensions and error code
		- used to aid interoperability before standardization
		- avoids overlap with reserved numbers

	- status -- -02 published
		- experimenteral message, extensions and error codes for mipv4

	- where do we go from here?

	- henrik levkowetz
		- this problem has been added to charter, question is whether
			this is the proper solution for the problem
		- hum vote on whether this should be a work item
			=> no hums in either direction
		- hand voting
			=> no hands for or against

	- thomas narten
		- is there interest in this work, do people know the issue?

	- alpesh patel
		- recap of motivation for the draft
		- this is a problem, practical feedback from partners

	- charlie perkins
		- could not personally vote either way because had not read
			the draft
		- is this experimental?  sometimes you want to experiment with
			two things, does the draft have subextensions

	- alpesh patel
		- yes, experimental

	- thomas narten
		- need to be able to experiment with protocols;
			chicken-and-egg problem, need codepoints but iana
			won't give you experimental allocations

	- alpesh patel
		- what if we need multiple numbers (e.g. two or three
			message types?)

	- thomas narten
		- you could need requests and responses to be experimental

	- alpesh patel
		- you can also use experimental extensions etc

	- henrik levkowetz
		- we already have subtypes for extensions
		- actually good to not reserve too many experimental numbers,
			because you want to limit the number of extension
			numbers you take for one single application

	- thomas narten
		- balance, you don't want to reserve too many, so that
			numbers don't become permanent.  if number is
			small enough, numbers cannot become permanent
		- mobile ip has a history of having allocated without
			talking to iana, sometimes problems in standardization
			because numbers already iana
		- idea here is that for experimentation and testing you
			can do it the right way

	- henrik levkowetz
		- who's read the draft? ==> same hands that had an opinion
		- we'll need more feedback on this
		- please read the draft, chairs will post the question on
			the list in a couple of weeks

issues with rfc 3344 (charlie perkins)
--------------------------------------

	- tracker for issues

	- issue 9: fa should not reject rrq with error code 136
		- conflicts with language describring the use of code 136
		- straightforward solution: new error code
		- this also provides the solution for issue 18?

		(no discussion)

	- issue 17: enhanced registration request processing at the home agent
		- what is the motivation for the proposed text?
		- error #129 is non-specific, #132 would do
		- idea: what the ha is allowed to do if it gets a rrq to
		  a unicast address the ha does not own?
		- can't remember discussion why this would be interesting

		- pete mccann
			- some deployments where rrq might arrive at the ha
			  maybe after being forwarded from another home agent,
			  so the home agent address may not be set to any
			  unicast address of the (final) home agent

		 	- in those case, proposal was to allow ha to process
			  that request and return a success indication but
			  fill in its own address in the reply

			- propose that we reject the issue

		- charlie perkins
			- agree, lot of recent discussion about ha failover
			  in mipv6 context, starts to look like
			  some sort of failover operation

			-  also propose reject it

		- rejected

	- issue 18: the fa is rejecting with error code 137 which is
			meant for the home agent

		- proposal:  create a new error code in range 64-127, which
			will then be a valid fa error code

		(no discussion -- accepted?)

	- issue 19: multiple authorization-enabling extensions should
			be permitted

		- suggestion: relax current restriction, we have multiple types
			of authorization-enabling extensions now
		- problem: what if one fails but other does not?
			- possiblity: the ha checks until it finds one that
			is verifiable?
		- proposal: table the issue unless motivation increases or
			problem is solved

		- what is the motivation?
			- which scenario is this a solution to?
			- not personally favoring changes to do this,
				introduces problems
			- no strong feeling about this

		- pete mccann
			- there are cases where mn has both mn-ha and aaa
			  extensions out in the field today, should be ok to
			  append more than one extension, might be to
			  authenticate yourself to two different nodes in the
			  network

		- charlie perkins
			- aaa authenticates use of charge card, and mn-ha
			  authenticates mobility, for instance

		- pete mccann
			- reasonable use case

		- charlie perkings
			- can we require that all need to be verified, and
			  must be rejected if any extension does not verify,
			  different codes for different authentication failures

		- charlie perkins:
			- any other comments? (=> no)

		- will take to the list

	- issue 20: missing description - fa rejection code when
		mn-ha auth ext invalid

		- proposal: fa does not requre the existence of mn-ha
			extension, nor reject the reg req if it is absent
		- for this reason, related to issue 21
		- is there a need for the fa to check "formatting" of the rrq?
			- the packet will be rejected anyway by the ha
			- rare case, imposing new requirements on the fa
			- suggest fa does not need to check the mn-ha extension (XXX)

		(no discussion)

	- issue 21: mn-aaa ext. not considered in fa-to-ha forwarding rules
		- proposal. reword to use "authentication-enabling" language
			instead
		- observation: if, in future, more such authentication-enabling
			extensions are defined, the fa may not be able to
			identify those extensions as enabling
		- suggestion: make sure that draft allows forwarding even
			when fa does not understand some new auth extension
		- want to avoid the situation where future authentication
			extensions would not work in the specified model

		(no discussion)

challenge extensions (revised) (jayshree bharatia)
--------------------------------------------------
	draft-ietf-mip4-rfc3012bis-00

	- changes from mobileip-rfc2013bis-06
		- terminology changes, error codes renamed
		- defined/clarified order of mn-aaa auth ext when coexists
			with mn-ha existing in rfc 3344
		- handling of solicited agent adv. at the fa is clarified
		- suggestions are added to security considerations to
			prevent invalidation of challenges caused by large
			number of agent soliciations pr bogus registration
			requests
		- editorial changes based on feedback from list

	- issue 1: potential deadlock for slow reg. replies associated with
			small (re)transmit rate at mn
		- occurs when mn is busy downloading some large file and
			trying to re-reg at the same time
		- first identification field is old when first rrp arrives
			(mn already sent a new rrq with new identification
			field)
		- proposals:
			1. introduce retransmitted challenge whose value
				equal the challenge value used in the last
				req reg + some constant value, and let fa
				accept this retransmitted challenge as valid
				=> potential security issues

			2. reconfigure timer value at mn

		- pete mccann
			- this has been discussed on the mailing list
			- root cause is link buffer that is getting full
			- probably forward direction link towards the mn
			- timer X has been set too short; rfc 3344 says,
			  rexmit should be longer than roundtrip time
			- proposal 2 used in the field, seems lower cost
			  solution, least impact on standards
			- one implementation trick: keep context around
			  for the old request; if you get a response to
			  an old request, you can accept it if this is
			  valid;  this would also not affect the standards
			- should consider lower cost alternatives

		- charlie perkins
			- consider handheld device case, chances of
			  (end user) reconfiguring the timer in a mn
			  are slim; most people would not do that even if
			  option offered
			- would like to see fa oriented solution

		- pete mccann
			- just increasing challenge window does not solve
				the problem; same challenge would not work?

		- charlie perkins
			- it makes sense, does not seem like a big
			  security problem  (XXX did not quite catch this)

		- jayshree bharatia
			- (XXX jayshree commented about the challenge
			  being retransmitted, did not catch this)

		- pete mccann
			- because identifier changes it looks like a
			  different request
			- maybe we want to relax fa so that even if
			  challenge previously used, it would still be ok
			- we need to be careful with security considerations
			- don't think this is a matter of user configuration
			  of the timer, more manufacturer problem so that the
		 	  manufacturer configures the proper timer (e.g. 4
			  seconds), don't think that manufacturers are doing
			  that correctly

		- jayshree bharatia
			- trade-off situation, rare scenario, the mn will
			  most likely recover even without changes

		- henrik levkowetz
			- option 2 as a way to go?

		- charlie perkins
			- comment was just made that this is a fatal error
			  and is recoverable
			- thrust of pete's argument is that depending on
			  traffic, the timer should be done by the manufacturer
			  to antipicate these problems
			- charlie agrees

	- issue 2: processing of the invalid challenge at the fa upon receipt
		of a registration reply from the ha
		- MN => FA: reg req, chal = x
		- FA => HA: reg req, chal = x
		- HA => FA: reg rep, chal = z
		- FA => MN: reg rep, chal = y 

		- proposals
			1. add text in sec. cons. regarding invalidation of
		 	   the data supplied by the ha
			2. discard received reg rep and send the reg rep with
			   an appropriate error code once the time waiting for
			   the valid response expires

		- charlie perkins
			- just wanted to expand on what the fa might do if
			  it has bad format
			- for a long time we had problem that if fa messes
			  with code in reg rep, so was wondering whether we
			  might have an extension where the fa could say
			  "dont want to change reg rep code, but here's the
			  code i would like to use")
			- could have the original authentication data still
			  verifiable, but still get the same data

		- henrik levkowetz
			- seems like the cleanest solution I heard so far
            - in favor of charlie's proposal

		- jayshree bharatia
			- (XXX take on the list?)

vendor specific round up (henrik levkowetz)
-------------------------------------------

	- new possible charter item, currently a number of vendor specific
		extensions for mipv4, which is good

	- purposes of round-up
		- catalogue v-s extensions found in the wild
		- document purpoases and details of the messages
			- understand why necessary
			- see if there are commnon needs which new standard
			  mipv4 extensions should be defined

	- not work on
		- v-s extensions that vendor does not want to share
		- link specific v-s extensions

	- is this a wortwhile effort for the wg to take on?
		- espen klovning
			- catalog would be nice, not aware of any
			  actual vendor specific extensions

		- thomas narten
            - I initiated this
			- long time in ppp there was a similar situation, 
			  having a document that listed the extensions useful
			  in debugging
			- simply provide information to people, but not
			  necessarily take the work on

		- henrik levkowetz
			- we should add the debugging aspect

		- charlie perkins
			- might interact with iana work?  Individuals might get assignments
              that they would not have gotten otherwise

		- thomas narten:
			- good question, if people are using same numbers
			  improperly

		- charlie perkins: (XXX: did not get this)

		- pete mccann
			- clarification: charlie, are you talking about people who didn't use
			  v-s extensions, but used the standards-track extension space without
              asking?

		- charlie perkins
			- yes

		- henrik levkowetz
			- since these are vendor specific, they are orthogonal
			  to each other, no collisions, are and will continue
			  to be owned by the respective vendors;  if we
			  standardize, we need to go through the normal
			  routine and iana process

		- pete mccann
			- should not be a problem with iana

		- thomas narten
			- theory is that having more information is better
			  than not having information

		- ???
			- practically every protocol has vendor specific
			  options, not sure if this is useful

		- thomas narten
			- not necessarily, if its useful they do it, if not,
			  they don't

		- ???
			- not ietf's job to find variations from vendors

		- pete mccann
			- will take cooperation of vendors, not a polling
			  exercise to get extensions, vendors will need to
			  volunteer

		- ???
			- how we actually do this?

		- pete mccann
			- will need to use our contacts in the industry

		- ???
			- the effort will be incomplete

		- pete mccann
			- some items are specificallty excluded, there is no
			  intention to get a comprehensive list

		- alpesh patel
			- vendors can add proprietary information to messages
			- why would vendors tell that information?

		- henrik levkowetz
			- maybe they wont

		- alpesh patel
			- if vendors think extensions add value, vendor should
			  try to standardize the extensions themselves, the
			  working group should not do it

		- pete mccann
			- this effort could be best seen as a way to facilitate
			  the process

		- thomas narten
			- are there interoperabilty issues here, e.g. people
			  need to implement vendor specific stuff to make
			  things work, sometimes vendor specific extension
			  becomes de facto standard, so vendors just need to
			  implement
			- not useful to have "the definitive list", but still
			  might be a useful effort

		- henrik levkowetz
			- does the wg feel this is a wortwhile exercise?
			- for: a few, opposed: a few
			- no clear consensus
			=> won't go into this at this time

		- pete mccann
			- if more interest in the list, might pick up later

		- thomas narten
			- do people feel there are issues with vendor
			  specific extensions?

		- pete mccann
			- any examples?

		- ???
			- example with a test suite vendor who has test suites
			  for vendor specific extensions; ietf has nothing
			  to do with it

		- henrik levkowetz
			- at my company, we have only had problems in this
			  area only once, where we came across a v-s ext
			  and could not handle it correctly; the ext was
			  skippable, so the processing was fixed to skip
			- having skippable extensions makes this a non-issue
			  for interoperability

		- pete mccann
			- we'll put this on the shelf for now, unless
			  there is more interst on the mailing list

dynamic ha assignment (alpesh patel)
------------------------------------
	draft-kulkarni-mobileip-dynamic-assignment-02

	- status
		- version 02 published
		- major changes from 01 to 02
		- active interest from vendors
		- at least 2 working implementations

	- resolved issues / changes in 02
		- terminology and editorial
		- loop free routing of rrq
		- load balancing by rejecting the rrq with special code and
			suggesting an ha
		- security consiederations

	- terminology and editorial
		- requested/assigned ha -- denote a single ha, indicates the
			meaning depending on the message type
		- redirected ha -- new ha that is being referred to for load
			balancing, administrative policies etc, when the reply
			message carries a special error code (TBD by IANA)
		- changed text to take care of "outside the scope" as in -01

	- loop free routing of rrq
		- no ha redirection in network (as in version 01), ha could
			forward rrq to another ha
		- ha receiving rrq (assigned ha) may reject the request and
			point to a redirected ha
		- since ha does not forward rrq in network, no chance of same
			rrq looping in the network
		- also fixes a nat traversal problem

	- load balancing
		- requested ha can suggest an alternate ha to use by
			rejecting with special error code and redirected ha
			address in extension
		- if special error code is present, the extension carrying
			redirect ha address must be present

	- security considerations
		- since there is no redirection in network, fa receives rrp
			from the ha it fowraded to rrq (no address mismatch)
		- statement that "mn and all has may share same sa" removed
		- mn and ha can derive dynamic seucrity association

	- open issues
		- in extension carrying redirected ha address, including
			public and pricate ha ip address if available
		- would like to get feedback on this

	- questions ?

	- ???
		- question regarding redirection, how do you redirect without
		  knowing the status of the target ha?  Could be redirecting into
          a black hole

	- alpesh patel
		- this is outside the scope, could be a heartbeat protocol,
		  whatever

	- ???
		- suppose that redirections start "bouncing"

	- alpesh patel
		- not enforcing that, management layer in mn could detect

	- ???
		- protocol should take care of reconfiguration

	- alpesh patel
		- can be built on client side, mn can simply keep state of
		  registration attempts and redirections

	- ???
		- have to build state for each registration in the client,
		  loop can be longer

	- henrik levkowetz
		- sounds like an earlier version of the draft, there is no
		  forwarding of the rrq in the draft

	- pete mccann
		- i think the draft now puts mn in control of every reg
		  retransmits, mn can decide what to do, much more in line
		  with the end-to-end principle, and can detect config errors

	- henrik levkowetz
		- who has read the draft?  (=> a few hands)

	- henrik levkowetz
		- the issue is within the wg charter, sooner or later we
		  need to decide whether this draft is a good solution to
		  the accepted problem in the charter
		- with the few readers who read, will not do this now
		- will solicit a few more people to read, then get
		  feedback from list

ipv6 in mipv4 tunnels (scott corson)
------------------------------------
Representing George Tsirtsis & Hesham Soliman

	draft-tsirtsis-v4v6-mipv4-00
	draft-tsitrsis-v4v6-mipv4-00
	draft-soliman-v4v6-mipv4-00 (incorrect file)

	- the problem - 1
		- mipv4 allows ipv4 node to move in ipv4 networks
		- same for mipv6 (for mipv6 networks)
		- but internet is a micture of ipv4, ipv6, and dual
		  stack networks, interop issues

	- best case scenario today - what works and what doesn't?
		- mipv4 => IPv4 and dual stack
		- mipv6 => IPv6 and dual stack
		- mn supports mipv4 and mipv6 => ipv4, ipv6, dual stack okay
			- but e.g. v4 => to v6 handover does not work
		=> undesirable overhead, unpredictable connectivity

	- the problem - 2
		- double overheads
		- inability maintaining sessions when doing v4/v6 handovers
		- mobility micromanagement impossible

	- solution: ds-mip
		- use mip as a v4/v6 migration tool
			- use the tunneling capaibility of mip to forward
			  both ipv4 and ipv6 traffic over the same mip
			  created tunnel
		- mipv4 extension
			- allow ipv4 and ipv6 hoas to bind to an ipv4 coa
		- mipv6 extensions
			- similarly
		- mn can use either ds-mipv4 only (initially), or ds-mipv6
		  only (future)   (XXX?)

	- scenarios
		- ds-mipv4 scenario - ipv4 dominant
		- ds-mipv6 scenario - ipv6 dominant
		- ds-mipv4 and ds-mipv6 solution works with both ipv4
		  and ipv6 networks

	- james kempf
		- draft looks ugly, but maybe the problem is that the
		  problem is ugly and requires an ugly solution
		- not too common to wander from network to another and
		  change from v4 to v6 or vice versa
		- haven't seen a solution that looks nice

	- pete mccann
		- suggest that we adopt ipv6 everywhere? (:-)

	- james kempf
		- of course
		- would like to see more thought on this, alternative
		  solutions

	- alpesh patel
		- couple of years ago there was a relevant contribution
		- draft from Pat Calhoun & others

	- pete mccann
		- participated in the draft, no interest at the time
		- i think the ds-mip approach solves some problems not
		  in the previous draft

	- pete mccann
		- first exercise: do we want to add this to the charter?

	- henrik levkowetz
		- we will not make any decisions now
		- we'd still like to see who thinks this is an interesting
		  problem to look at?
		- for: ~10 ? against: none  (XXX)

filters for mobile ipv4 bindings (carsten bormann)
--------------------------------------------------
	draft-nomad-mobileip-filters-05

	- motivation
		- simultaneous use of multiple points of attachments on a
		  single mobile device

	- mobile ipv4
		- simultaneous binding, s-bit, duplicates traffic
		- if duplication is unwanted, only one poa can be active
		- one hand-off affects all flows
		- not enough ip addresses for multihoming

	- filtering for mobile ip bindings (nomad)
		- simultanous use of multiple points of attachment with
		  a single home ip addresses without duplicating traffic
		- distribution of multiple flows / single flow
		- flow rejection

	- applications
		- load balancing
		- network management (flow mgmt initiated by core network)
		- enchanged terminal mobility (partial/smoothed handoffs)
		=> better utilization of available network resources

	- idea: send filters from mn to ha, mn can specify which parts of
		data flow should be sent through which interfaces / points
		of attachment

	- mode of operation (slide illustrating modes of operation with
		different filters)
		- may have "competing" filter specifications, e.g. same filter
		  but can specify that 20% to interface 1, 80% to interface 2
		- also weights

	- dynamic format filters
		- nine types of filter modules, OR and AND between predicates

	- conclusions

	- do we want to do this work in this working group?

	- ???
        - good idea, but have fundamental problems
		- how will you stop from requesting a large number of flows?
		- very complex filter policies, will affect traffic to
		  every other device

	- carsten bormann
		- this is between mn and ha

	- ???
		- no, can affect other mns, e.g. huge number of filters

	- carsten bormann
		- you can work around this

	- ???
		- although theory is novel, not practical?

	- james kempf
		- i think this is a really bad idea; home agent is a
		  convenient middle box, so we can do all nice things
		  in the middle box [is often thought]
		- you don't have some of this information in the ip
		  layer to do this, relevant information may be in
		  the transport layer
		- i don't see any real usefulness

	- carsten bormann
		- several things in the question; are you addressing
		  the case where one transport is through multiple
		  connections, or several transports through multiple
		  connections

	- james kempf
		- any case where you use multiple interfaces for
		  other than sending traffic through them
		- don't think this is the right way to deal with the
		  problem

	- pete mccann
		- i see some good motivations for doing this thing,
		  we have many interface types which are suitable
		  for different things; e.g. voice over 3g, data
		  over wlan.  if application can distinguish those
		  things, app could control routing
		- but, not convinced that mobile ipv4 is the right
		  way to do it, what if all interfaces are at home?
          Then there is no home agent to do the filtering, and
          we need another solution.
		- a bit confusing, not sure what is the right solution,
		  should perhaps be independent of mipv4

	- carsten bormann
		- many situations where you want someone in the network
		  to do something for you, addresses james's comments
		  as well.  would be nice to have a general architectural
		  approach for having this, a "friend" in the network
		  to do this for you.

		- rsvp does something similar but is a one connection
		  protocol.  nsis is doing something similar.

		- if you have an identifiable thing in the network
		  where to do this work, it might be a good place
		  to do the changes; you could also have a completely
		  separate protocol for doing this. seems to me that 
		  mobile ipv4 would be a good match for this problem.

	- henrik levkowetz
		- i have a couple of issues; first, basic idea of
		  route appropriate flows over appropriate channels;
		  i think really belongs in the end nodes, the appropriate
		  would be to let applications select which interface to use

		- second, if you want to go down this road, you want to do
		  this for other things than mobile ipv4 (signaling), this
		  is completely  incomplete as long as you don't have a
		  way for applications to signal their needs and then some
		  transport with filtering capability

		- multiple interfaces with multiple capabilities, don't do
		  anything except in end node

	- carsten bormann
		- counter-argument is that much depends on the mobile node
		  actually moving, so the characterization of an interface
		  changes as the mobile node moves; not clear that you want
		  to involve correspondent node architecturally
		- can you put this into one domain and without changing the
		  correspondent node?  from protocol point of view, ha seems
		  like a good choice
		- i think there are good arguments for considering
		  mobility aspects

	- james kempf
		- there are other possibilties in transport area for instance
		- point is that it's not wise to complicate the home agent by
		  putting this functionality in; it's not clear that you get
		  the necessary nformation at the ip layer to do this
		- one could consider another mechanism 	separate from mipv4

	- henrik levkowetz
		- some aspects are enticing, but feel that there are good
		  things but not sure it has "landed" completely yet

	- bof tonight

	- any more comments? (=> no)

-----------------------------

	- henrik levkowetz
		- agenda done, any more issues?

	- charlie perkins
		- loose question about the regional registration draft

	- henrik levkowetz
		- when mobile ip split to three groups, no-one took
		  the draft
		- merit to go forward?

	- charlie perkins
		- several people asked, several requests on the
		  mailing list

	- henrik levkowetz
		- true

	- charlie perkins
		- expectation was this would be published

	- thomas narten
		- should take this off-line, the document was
		  expired and appeared to be dead when documents
		  were divided

	- henrik levkowetz
		- we're done

</pre>
</body>
</html>

-- 
Mip4 mailing list
Mip4@ietf.org
https://www.ietf.org/mailman/listinfo/mip4