Subject: [MBONED] I-D Action: draft-ietf-mboned-mcast-arpa-03.txt

From: [email-masked]
Date: Tue, 05 Jul 2011 10:15:59 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MBONE Deployment Working Group of the IETF.

	Title           : Moving MCAST.NET into the ARPA infrastructure top level domain
	Author(s)       : Peter Koch
                          Leo Vegoda
	Filename        : draft-ietf-mboned-mcast-arpa-03.txt
	Pages           : 9
	Date            : 2011-07-05

   This document proposes to migrate the MCAST.NET domain into the ARPA
   top level domain, which is dedicated to infrastructure support.  It
   also provides a maintenance policy for the new MCAST.ARPA domain,
   related registrations in IN-ADDR.ARPA and describes the migration
   process.  This document updates RFC 5771 and forms part of BCP 51.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mboned-mcast-arpa-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mboned-mcast-arpa-03.txt

---

From: Peter Koch <[email-masked]>
Date: Tue, 5 Jul 2011 20:50:09 +0200

Dear mboned WG,

> 	Filename        : draft-ietf-mboned-mcast-arpa-03.txt

after roughly a year Leo and myself revived this document to get BCP51
amended by at least this missing piece.  Most of the DNS administrative preparation
work at IANA is either in late preparation stages or done.  Please find the full
detail of changes between the -02 and -03 versions at

	<http://tools.ietf.org/rfcdiff?url2=draft-ietf-mboned-mcast-arpa-03.txt>

To get the ball rolling for v4 multicast, our suggestion (see section 5.3.2)
for the reverse mapping of v6 multicast space is to defer this to a
separate document.  Our impression was that due to the scoping and
structure the v6 case is more complex than v4 and nees further study (with
my apologies to Stig).

Open Issues:

o Is the approach to defer ff00::/8 reverse mapping to a separate document OK
  for the working group?

o Section 5.3.1 generates an action item for IANA to develop a reverse mapping
  system for GLOP space. Does the WG feel that's the right way to do it?
  GLOP space involves (16 bit) AS numbers, assignment of which is usually
  traceable through RIR whois/registry data (or NIRs, where applicable),
  so IANA seemed like a natural starting point.  Comments appreciated.

o Section 6.1 gives two (was: three) alternative options for the future of
  the MCAST.NET domain.  The WG needs to make a decision.

On the NITS side, we're aware of the triple reference to RFC 6308 and its draft
as well as to its now obsolete predecessor. That will be fixed in -04.

I'll be in Quebec, and Leo migt be available via remote participation. Should
there be a need (and time), we could discuss the open issues during the
session (at the discretion of the chairs), but let's first see how far we can
get by email.

Thanks,
  Peter

---

From: Stig Venaas <[email-masked]>
Date: Tue, 05 Jul 2011 14:49:02 -0700

> structure the v6 case is more complex than v4 and nees further study (with

Probably the right decision. It is a bit different :)

> o Is the approach to defer ff00::/8 reverse mapping to a separate document OK

I'm OK with it at least.

>    so IANA seemed like a natural starting point.  Comments appreciated.

If we think having reverse mappings for GLOP is useful (I think it could
be, but not sure how much it would be used), then that seems to be a
good way to go.

>    the MCAST.NET domain.  The WG needs to make a decision.

In a way, 6.1.2 seems the easiest to me, at least operationally. But
6.1.1 might be better as it is an incentive as you say.

I don't quite understand 6.1.2.

    MCAST.NET will only see deletions but even after the last record has
    been deleted, the domain MUST be kept registered by the IANA. and
    should be operated in parallel using a DNAME RR, as described in
    [RFC2672].

If you make it a DNAME RR, how can mcast.net see deletions? Are you
saying first delete stuff from mcast.net and later make it a DNAME?
Wouldn't you just immediately make mcast.arpa a copy of the current
mcast.net and make mcast.net a dname?

Or I'm probably missing something.

Stig

> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned