Last Modified: 2004-02-12
- Documenting deployment of multicast routing in the global Internet.
- Receive regular reports on the current state of the deployment of multicast technology. Create "practice and experience" documents that capture the experience of those who have deployed and are deploying various multicast technologies.
- Based on reports and other information, provide feedback to other relevant working groups.
- Develop mechanisms and procedures for sharing operational information to aid in operation of the multicast backbones and interconnects.
- Update RFC 3171/BCP 51 based on experience.
- Develop a roadmap informational RFC that describes the current IPv4 and IPv6 IETF multicast architectures, including references to the relevant IETF documents and guidance for implementers and network operators.
- Complete the MSDP MIB
This is not meant to be a protocol development Working Group.
|Done||Submit I-D on inter-provider coordination of the deployment of pruning mrouteds.|
|Done||Establish initial charter, goals, and long-term group agenda.|
|Done||Submit I-D outlining requirements for the existing MBONE infrastructure.|
|Done||Submit I-D specifying the use of administratively scoped multicast addresses (RFC 2365)|
|Done||Submit I-D specifying the use of native multicast where appropriate (e.g. exchange points).|
|Done||Submit I-D on IP Multicast and Firewalls (RFC 2588)|
|Done||Submit I-D specifying static allocations in 233/87 (RFC 3180)|
|Done||Submit I-D on debugging multicast problems.|
|Done||Submit final version of scope zone announcement protocol (MZAP RFC 2776)|
|Done||Submit final version of scoped address discovery protocol (SADP)|
|Done||Submit I-D describing ISP multicast deployment practices|
|Done||Submit I-D, with RPS WG, on extensions to RPSL to describe multicast routing policy|
|Done||Submit I-D describing extended allocations in 233/8 (RFC 3138)|
|Done||Submit I-D describing IANA Guidelines for IPv4 Multicast Address Assignments (RFC 3171)|
|Done||Submit I-D describing IP Multicast Applications issues (RFC 3170)|
|Done||Submit I-D describing Anycast (RP) mechanism (RFC 3446)|
|Done||Submit I-D describing Source-Specific Protocol Independent Multicast in 232/8|
|Done||Submit I-D describing MSDP Deployment Scenarios|
|Done||Submit I-D describing IPv4 Multicast Unusable Group And Source Addresses|
|Done||Submit I-D describing Embedded RP for IPv6 Multicast Address|
|Apr 04||Submit I-D on PIM-SM Multicast Routing Security Issues|
|May 04||Submit I-D on IPv4/IPv6 multicast co-existence issues and strategies for IPv4 multicast and IPv6 multicast|
|Jun 04||Update IANA Guidelines for IPv4 Multicast Address Assignments (RFC 3171/BCP 51)|
|Jun 04||Submit PIM-SM Multicast Routing Security Issues to IESG for Informational|
|Jun 04||Submit MSDP MIB to IESG for Experimental|
|Aug 04||Submit IPv4 multicast address allocation procedures IESG for BCP|
|Aug 04||Submit IPv4/v6 co-existence strategies to IESG for Informational|
|Aug 04||Submit multicast roadmap/reference architecture document to IESG for Informational|
|RFC2365||BCP||Administratively Scoped IP Multicast|
|RFC2588||I||IP Multicast and Firewalls|
|RFC2770||E||GLOP Addressing in 233/8|
|RFC2776||PS||Multicast-Scope Zone Announcement Protocol (MZAP)|
|RFC3138||I||Extended Allocations in 233/8|
|RFC3171||BCP||IANA Guidelines for IPv4 Multicast Address Assignments|
|RFC3170||I||IP Multicast Applications: Challenges and Solutions|
|RFC3180||BCP||GLOP Addressing in 233/8|
|RFC3446||I||Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)|
MBONE Deployment (mboned) Minutes for IETF 59 Notes on Draft Minutes ====================== Bert Wijnen <firstname.lastname@example.org>: "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 <email@example.com> Minutes recorded by Simon Leinen <firstname.lastname@example.org> Agenda ====== o Administriva 5 minutes - Mailing list: email@example.com 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 (firstname.lastname@example.org) and David Meyer (email@example.com) 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. 22.214.171.124-126.96.36.199 (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 188.8.131.52/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 (firstname.lastname@example.org) and David Meyer (email@example.com) - Adjourn