Subject: [MBONED] IETF Meeting, draft-ietf-mboned-addrarch and prefix assignments.

From: Marshall Eubanks <[email-masked]>
Date: Mon, 30 Jul 2007 09:32:34 -0400

At the IETF Chicago MBoned meeting, there was consensus in the room to

- go forward with the prefix assignment draft and
- have the draft-ietf-mboned-addrarch document reflect this, which I  
assume will require a rev of the document (but may not, as it is close).

I also gave a report on IANA Multicast address assignments, and my  
conclusion that eGLOP could best
be implemented through IANA, and that RFC 3180 needs an update to  
reflect that. This may also require changes
to draft-ietf-mboned-addrarch.

I am sending this to the list for the benefit of those who could not  
make the meeting, and also to
request that this consensus be confirmed on the list.

So, if you have anything to say about this, positive or negative,  
please speak up.

Regards
Marshall

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

---

From: Leonard Giuliano <[email-masked]>
Date: Mon, 30 Jul 2007 12:07:38 -0700 (PDT)

These sound like positive developments to me.  Prefix assignment is a 
nice, simple way to derive mcast addresses for those who don't own an ASN.  
And eGLOP is a good idea once we can find some registry to administer it.  
I think the more options that are available for address assignment the 
better.

And once all these options are finalized, it will be helpful to have them 
all described in one doc (draft-ietf-mboned-addrarch).

-Lenny

On Mon, 30 Jul 2007, Marshall Eubanks wrote:

-) At the IETF Chicago MBoned meeting, there was consensus in the room to
-) 
-) - go forward with the prefix assignment draft and
-) - have the draft-ietf-mboned-addrarch document reflect this, which I assume
-) will require a rev of the document (but may not, as it is close).
-) 
-) I also gave a report on IANA Multicast address assignments, and my conclusion
-) that eGLOP could best
-) be implemented through IANA, and that RFC 3180 needs an update to reflect
-) that. This may also require changes
-) to draft-ietf-mboned-addrarch.
-) 
-) I am sending this to the list for the benefit of those who could not make the
-) meeting, and also to
-) request that this consensus be confirmed on the list.
-) 
-) So, if you have anything to say about this, positive or negative, please
-) speak up.
-) 
-) Regards
-) Marshall
-) 
-) 
-) _______________________________________________
-) MBONED mailing list
-) [email-masked]
-) https://www1.ietf.org/mailman/listinfo/mboned
-)

---

From: Leonard Giuliano <[email-masked]>
Date: Mon, 30 Jul 2007 12:07:38 -0700 (PDT)

-Lenny

---

From: Pekka Savola <[email-masked]>
Date: Tue, 31 Jul 2007 09:17:17 +0300 (EEST)

Hi,

A couple of clarification requests, speaking as 
draft-ietf-mboned-addrarch editor who wants to know when (and how) to 
edit the document further.  My current take is that 
draft-ietf-mboned-addrarch cannot be revised and as such cannot go 
forward until there is progress with uni-based-multicast and 
RFC3180bis.

On Mon, 30 Jul 2007, Marshall Eubanks wrote:
> - have the draft-ietf-mboned-addrarch document reflect this, which I assume 
> will require a rev of the document (but may not, as it is close).

Clarification: does draft-ietf-mboned-ipv4-uni-based-mcast-xx go out 
to the IESG/IETF-LC first, and we revise addrarch afterwards, or do we 
this as a single bundle?

I.e., do we make sure that draft-ietf-mboned-ipv4-uni-based-mcast 
doesn't get stuck before we ship addrarch doc?

Given that (AFAICS) RFC3180 revision has not (re-)started yet (see 
below), it'd seem to make sense that uni-based-mcast would go forward 
first.

> conclusion that eGLOP could best be implemented through IANA, and 
> that RFC 3180 needs an update to reflect that. This may also require 
> changes to draft-ietf-mboned-addrarch.

Clarification: does draft-ietf-mboned-addrarch wait for this work on 
RFC3180bis (ter?) complete first?  Was there a volunteer to work on 
RFC3180bis (ter?).

Clarification: does "could be best implemented through IANA" mean that 
the current attempt to get eGLOP allocations through RIRs has failed 
due to no interest, or that it has succeeded but IANA instructions 
need to be made explicit?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Tue, 31 Jul 2007 09:17:17 +0300 (EEST)

Hi,

---

From: Tim Chown <[email-masked]>
Date: Tue, 31 Jul 2007 15:43:53 +0100

> So, if you have anything to say about this, positive or negative,  

I would like to support this proposal.

-- 
Tim

---

From: Tim Chown <[email-masked]>
Date: Tue, 31 Jul 2007 15:43:53 +0100

-- 
Tim