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

From: Pekka Savola <[email-masked]>
Date: Thu, 3 Jan 2008 08:08:09 +0200 (EET)

The meeting minutes from Vancouver say:

"-  draft-ietf-mboned-addrarch-05
     - Marshall: waiting for the uni-based-macast-04 to be finished 
(dependency)"

To me it seems that there is also a dependency on RFC3180ter and/or 
eGLOP assignment debates at RIRs, or if not, can you suggest how I 
(wearing the editor hat) should proceed after uni-based-mcast is 
finished?

On Tue, 31 Jul 2007, Pekka Savola wrote:
> 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:
>> 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).
>
> 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.
>
>> 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.
>
> 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

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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 3 Jan 2008 08:08:09 +0200 (EET)

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 3 Jan 2008 10:10:57 -0500

> (wearing the editor hat) should proceed after uni-based-mcast is  

There is a draft to update this in the works. Whether or not you want  
to wait for it is another question.

Regards
Marshall

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

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 3 Jan 2008 10:10:57 -0500

Regards
Marshall