MBONE Deployment (mboned) Minutes for IETF 59



Notes on Draft Minutes
======================
Bert Wijnen <bwijnen@lucent.com>: "W.r.t. the MIB issue... the minutes of 
course need to state what was discussed. But....In SMIv2 (the language in 
which we define MIB modules these days, it is NOT allowed to use 
IPAddress anymore. One MUST use 
InetAddressType/InetAddress. If you only want to require support for IPv4, 
then you can do so in the MODULE-COMPLIANCE statement."



Monday 03.01.2004 (0900-1100)
=============================


CHAIR: David Meyer <dmm@1-4-5.net>


Minutes recorded by Simon Leinen 
<simon@limmat.switch.ch>


Agenda
======


 o Administriva                                         5 minutes


   - Mailing list: majordomo@lists.uoregon.edu
     subscribe mboned


   - Scribe?


   - Blue Sheets


 o Agenda Bashing                                       5 minutes
   Meyer                                           


 o Charter Update/Review                                20 minutes
   Meyer 


 o Review and status of work items                      30 minutes
   Active Drafts
   -------------
   draft-ietf-mboned-ssm232-07.txt                      5 minutes   
     Shepherd, et al
   draft-ietf-mboned-embeddedrp-00.txt                  5 minutes
     Savola/Haberman
   
draft-ietf-mboned-ipv4-mcast-unusable-01.txt         5 minutes
     Nickless
   
draft-ietf-mboned-ipv4-uni-based-mcast-01.txt        5 minutes
     Thaler
   draft-ietf-mboned-msdp-deploy-05.txt                 5 minutes
     McBride, et al
   draft-ietf-mboned-rfc3171bis-01.txt                  5 minutes
     Albanna, et al


   Expired Drafts
   -------------
   
draft-ietf-mboned-iesg-gap-analysis-01.txt


 o  PIM-SM Multicast Routing Security Issues and Enhancements
    draft-savola-mboned-mroutesec-00.txt
    Savola, et. al                                      10 minutes


 o Multicast Address Allocation Issues
   draft-ietf-mboned-rfc3171bis-01.txt
   All                                                  15 minutes


 o MSDP MIB                                              5 minutes
   Fenner


 o Update on the IMDOC Initiative/charter issues        30 minutes
   Meylor/Meyer



Minutes
=======


Blue sheets


Agenda


  Bashing 5 minutes
  Status of active drafts 30'
  MSDP MIB update 5'
  Charter update/review 10'
  IMDOC initiative 30'
  multicast address alloc 15'
  PIM-SM Multicast Routing Security Issues 10' (added)


Status of active drafts


draft-ietf-mboned-ssm232-07.txt for BCP
  Shepherd et al. 5'
  at the IESG
  basically finished
  normative reference to SSM, we figured out how to remove that
  normative reference to MSDP and PIM
    BCPs are treated the same as standard-track documents
    wrt normative references...
  Written up some text to ask for a variance in the procedures to
  loosen the reference conditions.
    Dependency on the acceptance of the variant text
    Expect >6 months for anything to happen.
  We don't want to advance MSDP
  PIM spec should be ready by San Diego


draft-ietf-mboned-msdp-deploy-05.txt -> BCP
  McBride et al., 5'
  at the IESG
  Hard to do a BCP on an Experimental protocol



draft-savola-mboned-mrutesec-00.txt
  Savola, et al., 10'


  Embedded-RP triggered discussion of security
  This document tries to analyze PIM-SM/MSDP/Embedded-RP security in 
general
    excluding Bidir-PIM (text contributions welcome if you think this is 
relevant)
    excluding host issues (IGMP/MLD)
    excluding other protocols (DVMRP etc.)


  threats:
    receiver-based
      Joins to different groups
    source-based
      sending multicast to empty groups
        encapsulated to the RP
        generates MSDP state
      disturb an existing group
    "aggravating factors" (catch-all)
      distant RP/source problem
        what if the addresses in PIM messages are invalid?
      RPF considers interface, not neighbor
        a problem with Ethernet-based IX'es;
        PIM should be modified
      No receiver information in PIM joins
        only DR knows the addresses joining to a group
        can't be used in policy etc.


Toerless Eckert:
  One useful differentiation
    Whether or not you can create intra- or inter-domain DoS
    E.g. where IGMPv3 joins can be immediately transformed into PIM
    (S,G) joins, this opens up an inter-domain DoS threat]


  Threat summary table (see draft)


  Enhancements for Threat Mitigation
    retire MSDP for inter-domain
    implement some form of PIM rate-limiting or similar
    implement some "return routability" checks
        [before creating state]
      probably quite challenging to do properly
    fix new PIM-SM spec to use RPF neighbor not interface


  Going forward
    Rate-limiting difficulties
      a lot of different threats
      ...and different kinds of deployment
      should not harm legit traffic
      finding the right kind of parameters is very difficult!
        help appreciated
      one could even omit trying to find the optimal solutions
 
Toerless Eckert: attacks against state in multicast are not 
PIM-specific.


Bill Fenner: Can you expand on the PIM RPF problem?


Pekka Savola: If I understand David Meyer correctly, the PIM spec 
specifies that an RPF check returns an interface rather than a next-hop 
address. 


David Meyer: RPF is a very weak policy mechanism.


Bill Fenner: Just trying to understand which of the 
exchange-point deployment issues we are talking about.


Stig Venaas: This is only a problem for data packets, where one would have to 
look at source MAC addresses - the source IP address would just be the 
remote sender address.


Take as WG item for Informational?


Weak humming in favor of taking this up as a WG item.


Will be taken to the list.


Embedded-RP update
  Pekka Savola


  Changes since -00


  Many text changes
  [Lots of good comments received from Hugh Holbrook]
    "just a group-to-RP mapping mechanism" which cannot be 
precomputed
    more text on RP redundancy and deployment tradeoffs
    clarify usability/scalability/security issues and refer to 
draft-savola-mboned-mroutesec-00
    add that the embedded RP mappings MUST be honored


  What didn't change?
    the group-id 32-bit -> 24 bits not done
      no proposals, no consensus => no change


  Ready for WG Last Call?
    IMHO, yes!


Toerless Eckert:
  Did you move all the security concerns out to the mroutesec 
document?
Pekka Savola: No, not all of them but the text in embed-rp got 
shortened.
Toerless Eckert: In any case you should mention that the security issues of 
Embedded-RP are similar to SSM (concerning creation of inter-domain 
state)



draft-ietf-mboned-ipv4-mcast-unusable-01
  Bill Nickless, 5'
  presented by David Meyer


  Draft seems to be losing its focus


  Basic question on whether these kinds of ACLs should be documented in 
this form.  


Toerless Eckert: Not sure to which degree a draft is needed or useful for 
this.


John Meylor: We started out with a pretty clear set of addresses that 
shouldn't be used.  Then we started adding more and more other 
addresses that are likely to cause problems.  By now, a Web page is 
probably a better way to publish this.


IPv4 Automatic Multicast Without Explicit TUnnels (AMT)
draft-ietf-mboned-auto-multicast-02.txt
  Dave Thaler


  Was recently discussed on the mailing list.


  Goal: solve last-mile problems for three situations
    receive SSM traffic even behind a NAT
    receive ASM traffic even behind a NAT
    source SSM traffic from public IPv4 address
  without requiring any state on infrastructure for idle hosts


  NON-Goals:
    sourcing SSM traffic from a private IPv4 address
    sourcing ASM traffic


  Terminology: similar to 6to4/Teredo...


    native multicast - AMT gateway - AMT NBMA subnet


                       - AMT relay - AMT subnet prefix 


  Protocol overview
    use IP-in-UDP encaps (to traverse NATs)
    AMT single-host site just uses IGMP
    AMT site gw acts as an IGMP proxy
    IGMP joins and leaves are periodic since no query can be multicast 
draft mentions multiple ways to implement
    site-site multicast goes direct, not via a relay
      (gateway-to-gateway/host-to-host)


  After discussions with Dino Farinacci and Tom Pusateri(?):


  Protocol (latest thinking)
    3-way handshake for Reports
      Ensures return routability and mitigates DOS


      Gateway                          Relay


      Generate Noyce (e.g. seq#)
                AMT Request(Noyce) -> Rnonce = 
Hash(Secret,Gaddr,Gnonce)


                 <- AMT (Gnonce, Rnonce)
                    IGMP Query


                    AMT (Gnonce, Rnonce)
                    IGMP Report ->     No state created on relay until here


  Something for Pekka Savola and others who look at security issues to look 
at further.  Handshake seems sufficient.


  Deployment Considerations
    Relays may be public (open) or private
      restricted to specific prefxies, etc.
    Clients are zero-config if use public,
      for private need to config relay name or addr.
    Can scale to more sites/traffic by adding more relays
      scales much better than tunnel brokers, however.
    AMT *sourcing* scales like replicated unicast over the AMT link
      Better than replicated unicast to all receivers
      Worse than tunnel broker solution 
        popular sources should get a configured tunnel instead.


  Open Issues


    Sourcing SSM from AMT site:
        [How does a relay communicate Join back to source?]
      IGMP Report or MSNIP from interested relay/site?
    Packet format optimizations suggested by Tom Pusateri


Toerless Eckert: Why develop new tunneling protocol? Couldn't this has been 
built modularity on top of existing tunnel mechanisms such as IPsec or GRE? 
Don't see much additional value in a new mechanism except perhaps the 
automatic discovery mechanism.


Dave Thaler: 2nd question: Interest in deploying relays - relay to 


Dave Thaler: Why a new protocol: In general, solutions you mention don't go 
through NATs well (GRE, L2TP/IPsec).  Those that require a handshake 
require state at the relay; thus they fall into what I classify as the 
"tunnel broker" category.  There is no other solution that fulfills all the 
requirements.


Pekka Savola: Question about state: Do you consider as state when 
something wants to join and the relay caches some information?


Dave Thaler: Yes.  But this only happens after the 3-way handshake, so you at 
least ensure return routability.


Pekka Savola: The diagrams talk about relays, but it could be 
relay/gateway.


Dave Thaler: Right.


Pekka Savola: Doubts whether this will really work over NATs because of 
keep-alive issues.


Dave Thaler: Sourcing SSM traffic (site-to-site) from a private address is 
out of scope.  You're right that this doesn't work if you source from 
behind a NAT.


Haixiang He: How do you protect the IGMP leave message?


Dave Thaler: Same 3-way handshake


Haixiang He: So you have the same overhead here


Dave Thaler: Right, but you have to do this 


Mark Handley: Do you *mandate* use of a cryptographic hash? I'd like to 
leave this decision open as a deployment choice.


Mark Handley: What happens if the request is lost?


Dave Thaler: It will be retransmitted like in normal IGMP.


Haixiang He: Report messages should be authenticated too.


Dave Thaler: Authenticating IGMP is a separate issue, not really 
specific to this proposal.


Haixiang He points out possibility of spoofing Reports once the 3-way 
handshake has succeeded.


Dave Thaler: Yes, this is the same security characteristic as for other 
return routability checks such as in TCP, Mobile IP etc.


Mark Handley: This suggests that this hash doesn't have to be 
cryptographic.


...


Dino Farinacci: AMT request goes to a public address (Dave Thaler: If it's a
    public relay)
  In the draft, you do this (?) about once a day
  I think it should be done more frequently
  Should be better specified in the draft


IPv4 Unicast-Based Multicast Addresses
  
draft-ietf-mboned-ipv4-uni-based-mcast-01.txt
    Dave Thaler


  David Meyer: THis is the first of a bunch of addr allocation drafts


  1/19 Mboned draft-01 submitted and posted on a Web site
  1/20-1/21 pseudo Last Call started and then canceled because it
  hadn't appeared in the repository yet.
    Thanks to Greg, Dave, and Toerless Eckert for reviewing anyway!


  David Meyer apologizes for slight procedural problem


  Non-editorial 
  Issues
    What category? (GLOP is BCP)
      Should /8 expire? (GLOP doesn't)
    "What problems does this solve?"
      4-byte ASes
      Multiple organizations within an AS
        [Example: Merit AS is used by all Michigan universities]
        Easier delegation within an AS
        Provides space to customer when AS owner is not 
multicast-savvy
        Easier debugging
          [for large sites such as MERIT]
    If developers hard-code addresses, bad stuff can happen
      [Example: you change ISPs after writing an application]
      No different from GLOP!
        Should say these mechanisms are for deployment not 
developers.


Toerless Eckert: Big operational difference in that GLOP is limited to AS 
owners (operators) who should make sure that this doesn't happen.  If you 
give this possibility to any address owner, this type of abuse is much more 
likely;


Peter Lothberg: If you ship an application that includes a hard coded 
address, this address should be reserved by IANA and not by some 
ISP/other registry.


Dave Thaler: Yes.


Toerless Eckert: Should the draft spell out which kinds of addresses 
should (not) be used here.


Dave Thaler: General issue: Should address allocation be implicit (as in 
GLOP) or explicit (where you can reserve addresses e.g. through a Web 
page)?


draft-ietf-mboned-rfc3171bis-01.txt
  Albanna et al.
  briefly presented by David Meyer
  Going through allocated addresses in the IANA tables
  Try to reclaim for IANA:
    ST-Transient Block
    DIS Block


MSDP MIB Status
Bill Fenner
  Moved from MSDP WG to mboned because we wanted to close down the MSDP WG.


  Assumption: existing implementations based on -03 (IPv4-only
    version)
  Task (what we thought the task was):
    update -07 to back down to -03
    remove InetAddress*, etc.
  Make it as compatible as possible with the only known 
implementation


  Assumption was wrong: There are implementations based on -07
  New task: update MIB based upon -07 (republished as -08)
    Look at implementations
    Look at updated spec.


  Soliciting help with this


  David Meyer: What exactly is the requirement for publishing a MIB for an 
Experimental protocol?


  Bill Fenner: It would be a useful thing, but yes, Procedurally we're not 
obliged to doing this.


  Toerless Eckert: Why base on the -07 version of the spec?
  Bill: Seems to be more widely implemented than -08.


  Toerless Eckert: Differences?
  Bill: Address types were changed to InetAddress (to allow for 
extension to IPv6).  We shouldn't do MIBs that are IPv4-only.


  Dave Thaler explains the official IETF policy on this.


  Bill Fenner: If we use IPAddress, we have to explain why.


  Toerless Eckert: Dislike anything that makes people think we could do 
MSDP for IPv6.  MSDP has been an Experimental protocol for six years.


  David Meyer: Really only six years? Feels like at least ten.


  Toerless Eckert: Would prefer the effort to go into the important 
multicast MIBs


      Conversion to InetAddress happened in March 2001
      Added Discontinuity Timers


  Charter update: What's New?


    Goal: Make sure we could admit IMDOC into mboned
    Discussion (where?) whether this was a directorate or not
    Triggered rechartering more or less by accident in the confusion after 
Randy left.  But changes are benign/sensible:


      Update RFC 3171/BCP51 based on experience (June 04)
        IANA considerations
      Develop a roadmap of information RFCs describing the current IETF 
muylticast architecture... (IMDOC stuff)
      Complete the IPv4 MSDP MIB by June 04


  IMDOC Update
  John Meylor


    Few comments on scope
    Summarize 
    Topics


    Scope
      A general framework/architecture for guiding forward progress on 
multicast issues in the IETF


      includes:
        v4 and v6 for each component
        service models
          ASM
          SSM


    Architecture Components (Rough List)
[the things in CAPS are actually in red and identify problematic areas.]
      Routing (congruent and divergent)
      Forwarding
        RP/BSR Management
      Group Management
      L2 issues
      Transport Layer
      Reliable Transport
      ADDRESS ALLOCATION
      Source Discovery/Session Control


Dino Farinacci: Nothing on security?
John Meylor: And on the next page...


  If you were to design and end-to-end service, would you find all the 
components here.


Haixiang He: What do you mean by session control?


John Meylor: Not exactly admission and access control.  More how we can 
identifies the sources and receivers of a group.  E.g. issue of dynamic 
multi-source groups in SSM


Colin Perkins: Concern about overlapping with the applications (and 
transport) area if we include session control.  E.g. this group telling the 
SIP group how to write SIP.


David Meyer: We only want to provide a framework for talking about these 
issues.


John Meylor: We're not trying to solve this within the source-group of 
mboned.


Mark Handley: [on Colin's question] There's a sliding scale of things that 
are firmly in-scope for this, maybe in scope, out of scope...


We have to be aware whether we want to describe where we want to be, or the 
history, or the current mess.


David Meyer: Effort draws on experience when trying to convince people to 
deploy multicast.  Where is it that multicast isn't being considered where it 
should? Document where the holes in the current architecture are.


Mark Handley: Sounds more like a requirements document, rather than an 
architecture document.


Dave Thaler: Second what Colin and Mark said.  Can see 
justification for at least two documents.  1: Document roadmap for things 
that exist.  Probably the best focus for this ("IMDOC").  2: 
Gap-analysis... more rat hole potential here.


Toerless Eckert Eckert: What is the value if we don't identify gaps?


John Meylor: Start by documenting the basic components.


    Components continued


      QoS
      TE
      Tunneling/VPNs
        transit and access
        IP and MPLS
      Mobility
      Security
      Management
      Stack and End-User-Device Issus
      Application Issues


Dino Farinacci: There are customer requirements for some form of 
multicast fast-reroute.  Should there be a bullet item for 
"convergence" or "join-latency issues".


David Meyer: Mark, Colin etc. where should that be addressed?


Toerless Eckert: Path selection, fast reroute, resource allocation are all 
subsumed under Traffic Engineering (according to some marketing 
people).


Mark Handley: Gut feeling that "fast rerouting" is not 
"architectural" enough to go here.  This is not to say that this isn't 
*important*, but maybe not for this document.


  Proposed next steps:
    1. Identify most important topics to address first
      Focus is on analysis and clarification of the problem space.
    Today:
      Address Allocation
    IETF60: ??


    2. Interested in contributing to various sections:
       contact John Meylor (jmeylor@cisco.com) and David Meyer 
(dmm@1-4-5.net)


    URL: http://www.1-4-5.net/MBONED/IMDOC


Introduction to IPv4 Multicast Address Allocation Issues
David Meyer


  We don't have a viable strategy to conserving the IPv4 address space.  
Even is this is considered as IANA's responsibility, IANA only has the 
tools that we give them.


  IPv4 multicast address space is a scarce resource
    People are starting to grasp this
  However, IANA is being besieged by requests for IPv4 multicast address 
space.  This problem has been brought about by the fact that:
      There were previous "bad" allocations, e.g. 
224.3.0.0-224.3.0.63 (Nasdaqmdfeeds)
      Other people come and say "why can't I"
      
http://www.iana.org/cgi-bin/multicast.pl (flowchart-type tool to 
classify address needs) and/or RFC 3171/BCP 51 clearly aren't enough 
(read: aren't effective)


Peter Lothberg: Didn't we solve this problem with SSM?
David Meyer: No.  I'll get to it.


Toerless Eckert: Problem statement (that this space is a scarce 
resource) is a little bit too compressed.  For example, global 
addresses are often not desired but IANA doesn't seem to have 
authority over 239.0.0.0/8. Also we don't have allocation methods for 
dynamic/temporary assignments. 


David Meyer: Points well taken.


Dave Thaler: Who are these requests (that besiege IANA) coming from? 
Application developers, or deployers of existing applications?


David Meyer: Both. No statistics on how this is distributed between this.


Dave Thaler: Large number of application developers asking for a few 
addresses each, and small number of deployers asking for larger spaces?


David Meyer: Something like that.


    In practice, we're experiencing ...


    Basic Problems
      We thought dynamic address allocation was the answer
        SDR
        later MALLOC
        both failed (in practice)!
          Those aren't solutions that people can field in their 
scenarios


      So what's the problem
        No global dynamic address allocation (workable?)
        No lightweight Service Location Protocol (SLP?)
          Not a solution, too heavyweight
        Many applications with no definable scope (==global scope)
          Impossible to use admin space in complex administrative 
environments
        SSM seeing limited deployment
        Oh, and bad precedent for many allocations
          Problem of IANA liability because this touches on business
          issues [Toerless Eckert remarks that this is the same for 
unicast addresses - they also managed to change policies in the face of 
scarcity.]


Dino Farinacci: Just because it's not deployed... John Meylor: Should be 
more descriptive breaking out the problem, so that 


Mark Handley: MALLOC was intended as a replacement, but it failed among 
others because it was linked to BGMP (thesis: BGMP was squashed by SSM). It 
doesn't seem worth to solve the address allocation problem in the 
absence of a routing protocol that routes this stuff. 


Toerless Eckert: Enterprise-scope address space for discovery (with other 
traffic using SSM).  1. Figure out better scopes; 2. Start taking money for 
them. 


David Meyer: The economics of how IANA and the RIRs work are out of scope 
here.


Dave Thaler: What failed was not MALLOC but MASC (the inter-domain 
layer). Failure of the top layer doesn't necessarily mean a failure of the 
bottom layer. 


David Meyer: We don't have a functional global address allocation 
mechanism in the Internet today, right?


Dave Thaler: Correct.  The closest thing we have today is GLOP. 


John Meylor: Are you saying that we believe that there will be embedded 
applications on the global scope?


David Meyer: In the sense that you aren't able to define a non-global 
scope.


David Meyer: SSM can often not be used because the node's IP address isn't 
known a priori.


Peter Lothberg: Why don't we write a lightweight protocol to resolve 
addresses between nodes in locally scoped environments.


David Meyer: Something like a lightweight service location protocol, 
perhaps?


Dave Thaler: Do you think that the same questions apply to IPv6? My 
answer: Yes AND no.  For deployers, no (no scarcity issue).  For 
developers, the problem is the same between IPv4 and IPv6.  If you agree 
that there is a difference, then the problem could be split 
accordingly.


Toerless Eckert: The big issue is not that you have more addresses, but 
that we have a clear, static, and well-known scoping model.


Mark Handley to Peter Lothberg: In how far do you think MADCAP would solve 
this problem?


Peter Lothberg: If it was deployed and understood, then it might solve it.


David Meyer: The whole point of this discussion is to find out what are the 
open issues.  The basic problem is that the target audience for a lot of 
these protocols didn't consider these applications developers.


John Meylor: Whatever we do there's going to be some period where we 
cannot solve the application developers' problems.  Maybe there should be an 
address lease mechanism for those periods where we don't have an 
effective address allocation or service discovery mechanism.


David Meyer: See Alex Zinin's draft on such an approach to register 
temporary pre-IANA code points.


Mark Handley: SLP and MADCAP should solve many of these problems.  1. 
People just aren't aware of them or 2. The protocols themselves have 
problems.


Dino: The problem is that the IETF has too many solutions and not enough 
clear directions on what to use.  That argues for e.g. mandating SSM as the 
single way to go in the future.


Dave Thaler: Probably lack of knowledge.  The places with access to the 
MADCAP server code would be enterprises.  Those usually aren't the ones who 
turn on multicast first.  Not aware of any issues with the protocol as 
such.


Peter Lothberg: The problems are locally scoped; not a real 
Internet/inter-domain problem.


David Meyer: I didn't say that.  There is no definable scope in these 
cases.


John Meylor: Even if you could use a scoped range, there is lack of 
knowledge in the application domain.  When David Meyer tells them you 
could use this, they don't see enough evidence for this from the IETF.


Peter Lothberg: I don't see an Internet-wide problem here.  There's no 
multicast traffic to speak of in my little network (about 10% of the 
Internet).  There's just a land grab issue, not an operational one.


John Meylor: The problem is that you can never construct a service when you 
cannot be sure that others won't collide with your addresses.


Peter Lothberg: Should make dynamic address allocation very 
lightweight in scopes where nodes can see each other.


David Meyer: This process has really expanded my view on what people 
understand as "the Internet" ["internet"?].  Being connected to a 
transit provider is low on the scale of this.


Toerless Eckert: Want public record of the exchanges between IANA and the 
requesters.


David Meyer: I personally don't have problems with that.  Writing a 
document seems necessary to get anything going though.


Stig Venaas: A protocol such as MADCAP alone isn't sufficient.  A 
lightweight SLP would be very helpful for "zeroconf" applications.


David Meyer: Yes but you don't have anything to point at right now.


Mark Handley: What we need is a big disclaimer "You don't get what you 
expect" (Multicast addresses assigned to them 
personally+permanently).


Dave Thaler: To John Meylor: Indefinite-scope problem mainly a problem with 
application developers.  As opposed to deployers e.g. NASDAQ 


David Meyer: Even the NASDAQ deployment doesn't have a well-defined 
scope: one island... and then a bunch of other islands.


Dave Thaler: Missing on IMDOC list: What we used to call "Session 
advertisements" (as in: SDP was supposed to be split into address 
assignment and session advertisements).  The mechanism to allow 
everybody who is interested in <something> to learn about it.


Those protocols are good for finding things that exist, but cannot prove 
that something doesn't exist (address allocation does this).


Jon Crowcroft: What you're missing is part of normal protocol 
evolution: You need an enforced address reclamation protocol.  "We're 
going to take those back once we have figured out how to do this 
better."


Toerless Eckert: This goes back to how we manage unallocated 
addresses.


Jon Crowcroft: There was a day when we could enforce these things by 
building protocols... now there are commercial issues involved, and I'm not 
sure who can solve this - IANA/ICANN etc.
We have a stewardship responsibility. 


I wish we could have these discussions on the list by the way!!


    So what to do?
      Goal/Milestone
        Update RFC3171/BCP51 based on experience
        EGLOP (RFC 3137)?
        A few folks looking at lightweight service location
      In general, fit into the IMDOC framework
      Is anyone interested in working on this problem?


If you're interested, send mail to John Meylor 
(jmeylor@cisco.com) and David Meyer (dmm@1-4-5.net)


- Adjourn