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

On 7/5/2011 11:50 AM, Peter Koch wrote:
> Dear mboned WG,
>
>> 	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
>
> 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).

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

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

I'm OK with it at least.

> 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.

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.

> 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.

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

> 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
> _______________________________________________
> MBONED mailing list
> MBONED@ietf.org
> https://www.ietf.org/mailman/listinfo/mboned