IDMR met in one session at the Minneapolis IETF. These minutes were collected by Bill Fenner. Administrivia: Bill Fenner's new email address is Jennifer Hou presented some QoS extensions to CBT. These extensions provide the capability to ensure a certain QoS along a CBT-built tree. The desired QoS can be specified as an upper or lower bound on some parameter (such as delay, loss, available bandwidth) or as a bound on the inter-receiver difference (e.g. inter-receiver delay jitter bound). When a QoS-aware member joins, the on-tree router performs an eligibility test, based upon information that was collected as the join traveled towards the tree and information that the on-tree router has, and only replies with a Join-Ack if the test succeeds. On-tree routers need only keep state about the maximum (or minimum) value of a parameter within the subtree rooted at that router. In simulation, the worst case message overhead was twice unmodified CBT. Bill Fenner talked about rechartering IDMR. IDMR has been an unfocused "catch-all" working group for all multicast-related issues for years. Previous attempts to get the working group interested in fixing the charter have more or less failed, and the current charter has very little applicability to what the working group has been doing. Bill proposed rechartering IDMR to finish work on the existing "catch-all" documents: IGMPv3, Multicast Router Discovery, Domain-Wide Reports, IGMP Proxying, Multicast Traceroute, the Multicast Interoperability draft, and any others that may have been forgotten. New working groups would be chartered for any other work (such as BGMP); minor issues could be handled in the Routing Area meetings or MADDOGS. Bill proposed renaming the working group to Internet-Draft Multicast Remnants, and set a firm latest acceptable work item due date of April 2000. The only two comments were positive ones. Bill will send a proposed revised charter to the IDMR mailing list. Following in the same vein, Bill talked about chartering a BGMP working group. Its charter would effectively be to complete the BGMP protocol specification (and related MIBs) and follow them through the standards track. Goals and Milestones include security, interoperability, monitoring and measurement. Developing a transition plan was added to the goals by suggestion. Bill will send a proposed charter to the BGMP mailing list. Dave Thaler talked about BGP Path attributes for multicast tree construction. These help provide policies on how routes may be used to construct multicast trees; they are independent of the multicast routing protocol but provide information which "policy-clueful" protocols like BGMP could use. The two proposed attributes are a forwarder preference and a directional policy attribute. The forwarder preference is a non-transitive attribute which allows the election of a designated forwarder per prefix. Electing the designated forwarder at the time of route exchange eliminates the need for a mechanism like PIM's "Assert" process to resolve multiple forwarders. This procedure is already present in BGMP, but if it were in BGP it could be used by other multicast routing protocols. In addition, there is a race condition when using BGMP to elect a forwarder; if the route is learned via BGP, then data arrives before BGMP has noticed the new route and elected a forwarder, then there is not yet a designated forwarder. The directional policy attribute allows the annotation of a route as "come-from", "go-to", or "both". "both" is the default, and are the only routes that may be used by bidirectional tree protocols. "Go-to" routes may be useful for non-member senders, especially in a UDLR environment. Come-From routes can be of two types. A Come-From route for a source may be used to perform reverse-path forwarding. A Come-From route for a group indicates that that group requires a unidirectional tree. Come-From routes may optionally be annotated with an encapsulation destination for sending to the root of the bidirectional tree (like PIM's Registers). One use for the directional policy attribute is that an ISP which only supports unidirectional trees may annotate all routes with the Come-From attribute. This allows the tree to be bidirectional in the parts of the network that support it but unidirectional in the parts that don't. It can also potentially create a debugging nightmare. "Lots of rope". In discussion, it was mentioned that BGP is not necessarily the right place for these options. In fact, BGP was originally considered but discarded for the Forwarder Preference attribute and that attribute was added to BGMP (introducing the synchronization problem mentioned earlier). The desire for a directional attribute raises the same kind of problem. Since these attributes are (or are considered to be) protocol independent, perhaps they belong in BGP.