Subject: Re: [MBONED] addrarch: MADCAP to historic?

From: Pekka Savola <[email-masked]>
Date: Fri, 19 Jan 2007 09:44:50 +0200 (EET)

Summarizing the MADCAP part here.

On Wed, 20 Dec 2006, Pekka Savola wrote:
> AD review issue: eGLOP and MADCAP to historic?
> 2) Some mechanisms described in the draft haven't been used (at least
>    very much).  Should we do something about them?
...
>    2.2) Since MADCAP implementations are few and in between and it
>    hasn't been significantly deployed, should we do anything about it
>    -- for example, reclassify both RFC2730 and RFC2907 as Historic or
>    Experimental?
>
>    Given that there are at least two implementations (AFAIK, Windows
>    and an open-source project) even though not a lot of deployment,
>    Historic would seem a bit big action.  Personally, I wouldn't have
>    a problem with Experimental if it's worth the effort though.

David Kessens reminded that in this case, we can't really downgrade to 
Experimental.  (It's not obvious what 'expiriment' we'd be running.) 
So, if we'd want to change a category, the options would be Historic 
and Informational.

Lenny seemed to believe MADCAP is useless at present.  John Kristoff 
seemed to be content with the currently used repertoire of mechanisms. 
Toerless would support experimental, but also stated it was the only 
protocol from the "multicast assignment/allocation protocols" suite 
that could be useful in the future.

Offlist, Dave Thaler told that MADCAP client exists in Windows XP, 
2003 and Vista, and server is implemented in 2003 and 'Longhorn', so 
it should be relatively widely deployed.  He also stated that it's 
used in some cases, e.g. Windows Media Server deployments.

As a conclusion, even if it's not clear how useful MADCAP is right now 
in most purposes, it seems to fill a niche of sorts and might become 
more used in the future.  Therefore it seems to me that changing its 
status would be premature given that implementations and minor 
deployments exist, and staying on Proposed Standard track is 
appropriate, and the text in ADDRARCH document needs to be adjusted a 
bit.

Any objections or further comments?

-- 
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: Fri, 19 Jan 2007 09:44:50 +0200 (EET)

...

---

From: Pekka Savola <[email-masked]>
Date: Fri, 19 Jan 2007 10:04:39 +0200 (EET)

I'll try to summarize the discussion that related to IANA assignment 
policies and eGLOP.

DaveM mentioned that RIRs haven't been very interested in taking up 
this assignment task for various reasons.  Marshall said he'd try to 
get this started.  What is the status of this effort?

DaveM seemed to believe that whenever a requestor comes to IANA and 
says (s)he wants X number of addresses, the request cannot (in 
practice) be denied.  Toerless [and yours truly] at least want a 
mechanism to discourage unnecessary use of IANA assignments.  A change 
in IANA policies and/or guidelines could create a backing to also deny 
requests if need be. (In the end, it might be that the requestor would 
just invent an address space to use if denied, but whether that 
matters is an open issue.)

There was some aside discussion about doing assignments inside the 
current SSM address range, but the conclusion seemed to be it's not 
worth it.

Beau suggested that IANA should stop making static assignments for 
[typical, unspecified] protocols, and instead should give a GLOP 
address if applicable or from eGLOP block if not.  Lenny supported 
this and also supported resurrecting the IPv4 unicast-prefix mapping 
draft (separate thread on this).

One point that has been discussed before was that if eGLOP assignments 
were to be made for a fee, there would be no incentive for anyone to 
use that service unless IANA stopped providing multicast addresses for 
those customers.

DaveM preferred to have IANA guidelines and policies in some other 
document [one was started and has died off several times] rather than 
this one.

Questions to the group (first one mainly to Marshall):

  1) Marshall's initiative on getting eGLOP started.  What was it
     exactly and what's the status?

  2) Is it even possible for IANA (if instructed by the IETF) to stop
     making multicast assignments (or tighten the policy) on specific
     ranges?

  3) If we end up using eGLOP, how should that change IANA's
     traditional assignments (if answer is 'yes' to 2)?

  4) Should we try to defer all the questions about IANA policies,
     eGLOP, etc. to some other document in order to get this one
     finished (and this one being vague on the topic)?

---

From: Pekka Savola <[email-masked]>
Date: Fri, 19 Jan 2007 10:04:39 +0200 (EET)

---

From: Thomas Narten <[email-masked]>
Date: Fri, 19 Jan 2007 08:58:20 -0500

> Any objections or further comments?

My view: Standards Track is appropriate for any technology where it is
"the best currently recommended choice", for folk who need to do X.

So, moving something from standards track to anything else really
needs to have a reason along the lines of "current technology is
really not the recommended way to go anymore". 

I don't hear that in this case.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Fri, 19 Jan 2007 08:58:20 -0500

Thomas

---

From: "John Meylor \(jmeylor\)" <[email-masked]>
Date: Fri, 19 Jan 2007 08:02:15 -0800

> -----Original Message-----
> From: Thomas Narten [mailto:[email-masked]] 
> Sent: Friday, January 19, 2007 5:58 AM
> To: Pekka Savola
> Cc: [email-masked]
> Subject: Re: [MBONED] addrarch: MADCAP to historic? 
> 
> My view: Standards Track is appropriate for any technology 
> where it is "the best currently recommended choice", for folk 
> who need to do X.
> 
> So, moving something from standards track to anything else 
> really needs to have a reason along the lines of "current 
> technology is really not the recommended way to go anymore". 
> 

I agree.  If we believe there is better way to handle this function
(which there may or may not be), WG should address it.

Otherwise, this function works, and has commercial implementations
in the field, this latter point certainly raises the bar for
us to degrade status without alternative..

 john

---

From: "John Meylor \(jmeylor\)" <[email-masked]>
Date: Fri, 19 Jan 2007 08:02:15 -0800

john

---

From: David Kessens <[email-masked]>
Date: Fri, 19 Jan 2007 15:21:41 -0800

John,

> us to degrade status without alternative..

There is a little bit more to this:

Are these existing implementations actually being used (anybody on
this list?) ?

If not so, are we not sticking our head in the sand if we keep
recommending a particular solution that apparently doesn't address a
problem in the marketplace?

David Kessens
---

---

From: David Kessens <[email-masked]>
Date: Fri, 19 Jan 2007 15:21:41 -0800

John,

David Kessens
---

---

From: Dave Thaler <[email-masked]>
Date: Fri, 19 Jan 2007 16:03:09 -0800

> From: David Kessens [mailto:[email-masked]]
> Sent: Friday, January 19, 2007 3:22 PM
> To: John Meylor (jmeylor)
> Cc: [email-masked]

Yes.

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Fri, 19 Jan 2007 16:03:09 -0800

Yes.

-Dave

---

From: Thomas Narten <[email-masked]>
Date: Mon, 22 Jan 2007 09:20:07 -0500

> Are these existing implementations actually being used (anybody on

This question (by itself) does not seem particularly relevant to
me. (I'm serious.) If there were an alternative technology that people
preferred, or if there were known shortcomings with this technology,
that would be useful to discuss. But if no one is using it, that could
simply mean that (gasp) multicast has not taken off generally, and
this is just one more example of collatoral damage. It does not
immediately follow that this technology is flawed and needs to be
taken off Standards Track.

> problem in the marketplace?

If no one is using it, and no one seems to be confused by it being on
the Standards Track, what harm is there in leaving well enough alone?

We have plenty of more important things to do IMO, then reclassify
documents when the status quo is not causing any problems.

What problem needs fixing here? Aren't there more pressing things to
do with our precious cycles?

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Mon, 22 Jan 2007 09:20:07 -0500

Thomas

---

From: Leonard Giuliano <[email-masked]>
Date: Mon, 22 Jan 2007 14:18:30 -0800 (PST)

On Fri, 19 Jan 2007, Pekka Savola wrote:

-) 
-) Questions to the group (first one mainly to Marshall):
-) 
-)  1) Marshall's initiative on getting eGLOP started.  What was it
-)     exactly and what's the status?
-) 
-)  2) Is it even possible for IANA (if instructed by the IETF) to stop
-)     making multicast assignments (or tighten the policy) on specific
-)     ranges?
-) 

Why not?  If I went to IANA and requested a Class A network of unicast 
space, I'm pretty sure I know what answer they would give me.  Pointing 
out that Class A blocks were given out in the past would probably not 
change their answer.

-)  3) If we end up using eGLOP, how should that change IANA's
-)     traditional assignments (if answer is 'yes' to 2)?
-) 

IANA should not make static assignments anymore (unless it is for
protocol use- eg, 224.0.0/24 stuff).

-)  4) Should we try to defer all the questions about IANA policies,
-)     eGLOP, etc. to some other document in order to get this one
-)     finished (and this one being vague on the topic)?
-) 

This seems like an eminently solvable problem to me and something that has 
been discussed for years.  I believe it would be worthwhile to finally 
resolve this once and for all now instead of punting and having to resolve 
it later.  We all seem to agree on the solution.  Our goal here is to 
solve problems, not just publish expedient documents.

Must this be taken on by a RIR?  I would happily do this myself if there's 
a fee involved.

---

From: Leonard Giuliano <[email-masked]>
Date: Mon, 22 Jan 2007 14:18:30 -0800 (PST)

-)

---

From: Pekka Savola <[email-masked]>
Date: Wed, 24 Jan 2007 16:08:20 +0200 (EET)

(Lenny's message has not appeared to the archives, I wonder if you 
posed from a different address than the one you've subscribed, or the 
list is hosed..)

> out that Class A blocks were given out in the past would probably not

Personally I agree with you.  Just trying to figure out if any WG 
member disagrees with this.

> protocol use- eg, 224.0.0/24 stuff).

OK, looking at http://www.iana.org/assignments/multicast-addresses. 
More specifically, I suppose your recommendation is (referring to 
IANA guidelines defined in RFC2434):

- IANA policy for 224.0.0.0/24 (Local network control block) should be
   FOO (what would that be? Specification Required?  Is Expert Review
   enough?  Should this range be usable for non-IETF protocols as it
   currently has been used?)

- What about 224.0.1.0/24 (Internetwork control block)?  Specification
   required, expert review, something else?

- I suppose for 224.0.[2-255].0/24 (Adhoc block) you suggest stopping
   altogether or making sufficiently strong requirement (specification
   required, with further qualifiers on the number of available
   addresses per assignee?) that it would not be exercised so much
   anymore.

- What about the rest of 224.0.0.0/8? (e.g., recent allocation to
   london stock exchange)?   Require Standards Action or something very
   strong?

> Must this be taken on by a RIR?  I would happily do this myself if there's

Well, for some reason, the attempts to write new IANA guidelines were 
dropped at least twice, in 2002 and in 2004.  Either there was no 
sufficient interest or time or there were some issues (e.g., about 
what the policy should be) which weren't easily solvable.

Personally, I'd be glad to see us finally properly write down the IANA 
policies, regardless of what those policies would end up being. 
AFAICS, currently there are basically no policies whatsoever.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 24 Jan 2007 16:08:20 +0200 (EET)

---

From: Leonard Giuliano <[email-masked]>
Date: Fri, 26 Jan 2007 06:46:23 -0800 (PST)

Pekka- the suggestions you make here sound reasonable to me.

On Wed, 24 Jan 2007, Pekka Savola wrote:

-) (Lenny's message has not appeared to the archives, I wonder if you posed from
-) a different address than the one you've subscribed, or the list is hosed..)
-) 
-) On Mon, 22 Jan 2007, Leonard Giuliano wrote:
-) > On Fri, 19 Jan 2007, Pekka Savola wrote:
-) > -) Questions to the group (first one mainly to Marshall):
-) > -)
-) > -)  1) Marshall's initiative on getting eGLOP started.  What was it
-) > -)     exactly and what's the status?
-) > -)
-) > -)  2) Is it even possible for IANA (if instructed by the IETF) to stop
-) > -)     making multicast assignments (or tighten the policy) on specific
-) > -)     ranges?
-) > -)
-) > 
-) > Why not?  If I went to IANA and requested a Class A network of unicast
-) > space, I'm pretty sure I know what answer they would give me.  Pointing
-) > out that Class A blocks were given out in the past would probably not
-) > change their answer.
-) 
-) Personally I agree with you.  Just trying to figure out if any WG member
-) disagrees with this.
-) 
-) > -)  3) If we end up using eGLOP, how should that change IANA's
-) > -)     traditional assignments (if answer is 'yes' to 2)?
-) > -)
-) > 
-) > IANA should not make static assignments anymore (unless it is for
-) > protocol use- eg, 224.0.0/24 stuff).
-) 
-) OK, looking at http://www.iana.org/assignments/multicast-addresses. More
-) specifically, I suppose your recommendation is (referring to IANA guidelines
-) defined in RFC2434):
-) 
-) - IANA policy for 224.0.0.0/24 (Local network control block) should be
-)   FOO (what would that be? Specification Required?  Is Expert Review
-)   enough?  Should this range be usable for non-IETF protocols as it
-)   currently has been used?)
-) 
-) - What about 224.0.1.0/24 (Internetwork control block)?  Specification
-)   required, expert review, something else?
-) 
-) - I suppose for 224.0.[2-255].0/24 (Adhoc block) you suggest stopping
-)   altogether or making sufficiently strong requirement (specification
-)   required, with further qualifiers on the number of available
-)   addresses per assignee?) that it would not be exercised so much
-)   anymore.
-) 
-) - What about the rest of 224.0.0.0/8? (e.g., recent allocation to
-)   london stock exchange)?   Require Standards Action or something very
-)   strong?
-) 
-) > -)  4) Should we try to defer all the questions about IANA policies,
-) > -)     eGLOP, etc. to some other document in order to get this one
-) > -)     finished (and this one being vague on the topic)?
-) > -)
-) > 
-) > This seems like an eminently solvable problem to me and something that has
-) > been discussed for years.  I believe it would be worthwhile to finally
-) > resolve this once and for all now instead of punting and having to resolve
-) > it later.  We all seem to agree on the solution.  Our goal here is to
-) > solve problems, not just publish expedient documents.
-) > 
-) > Must this be taken on by a RIR?  I would happily do this myself if there's
-) > a fee involved.
-) 
-) Well, for some reason, the attempts to write new IANA guidelines were dropped
-) at least twice, in 2002 and in 2004.  Either there was no sufficient interest
-) or time or there were some issues (e.g., about what the policy should be)
-) which weren't easily solvable.
-) 
-) Personally, I'd be glad to see us finally properly write down the IANA
-) policies, regardless of what those policies would end up being. AFAICS,
-) currently there are basically no policies whatsoever.
-) 
-) -- 
-) 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: Leonard Giuliano <[email-masked]>
Date: Fri, 26 Jan 2007 06:46:23 -0800 (PST)

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 26 Jan 2007 10:51:19 -0500

Hello;

> -) > -)     exactly and what's the status?

I am preparing to submit a proposal to APNIC to instantiate eGLOP  
before the deadline (one week from today)
and, since I am attending the Apricot meeting, will attend the Apnic  
meeting to discuss it. (I believe that Dave Meyer will be there as  
well.)

Assuming that this meets a positive response, I would send the same  
to ARIN and RIPE.

For whatever reason, there is now substantial interest in eGlop and I  
see no reason to instantiate it along
the lines of the RFC.

> -)   currently has been used?)

I agree.

> -)   addresses per assignee?) that it would not be exercised so much

I agree.

> -) which weren't easily solvable.

I think it was really both.

> -) currently there are basically no policies whatsoever.

I agree, and will forward the Apnic draft to the list as soon as I  
have it done.

Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 26 Jan 2007 10:51:19 -0500

Hello;

I agree.

I agree.

Marshall

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 26 Jan 2007 09:46:26 -0800

> see no reason to instantiate it along

I would bet:
The interest comes from deployment that have SSM-type applications where
they want to distribute market data or IPTV type content to receivers
interdomain but want to continue to ignore SSM, and the fixes necessary
in their environment to enable it, like they did for the last 6 years.

Not the best of reason to go to eGLOB, *sob*

Would be lovely if folks requesting those addresses would at least engage
in discussions on Mboned at all, but there's a total disconnect here. And
that disconnect is why the problems don't get resolved.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 26 Jan 2007 09:46:26 -0800

I would bet:

Cheers
    Toerless

---

From: David Meyer <[email-masked]>
Date: Fri, 26 Jan 2007 10:04:58 -0800

> meeting to discuss it. (I believe that Dave Meyer will be there as  

	I'll be there. Please let me know if/how I can help.

	--dmm

---

From: David Meyer <[email-masked]>
Date: Fri, 26 Jan 2007 10:04:58 -0800

--dmm

---

From: Leonard Giuliano <[email-masked]>
Date: Fri, 26 Jan 2007 10:28:06 -0800 (PST)

On Fri, 26 Jan 2007, Toerless Eckert wrote:

-) I would bet:
-) The interest comes from deployment that have SSM-type applications where
-) they want to distribute market data or IPTV type content to receivers
-) interdomain but want to continue to ignore SSM, and the fixes necessary

I would argue that ALL current (and foreseeable) deployments and content 
have SSM-type data or content.  I have yet to see an app that couldn't be 
done with SSM-only.  Unfortunately, the SSM-only decree was tried (for 
IPv6) and rejected.  That ship has sailed.  We are stuck with ASM, so we 
might as well manage it in the easiest and least harmful ways we can.

---

From: Leonard Giuliano <[email-masked]>
Date: Fri, 26 Jan 2007 10:28:06 -0800 (PST)

-) I would bet:

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 26 Jan 2007 10:31:16 -0800

On Fri, Jan 26, 2007 at 10:28:06AM -0800, Leonard Giuliano wrote:
> done with SSM-only.

> Unfortunately, the SSM-only decree was tried (for 
> IPv6) and rejected.

Not sure what you mean  with that... Care to explain ?

> That ship has sailed.  We are stuck with ASM, so we 

-- 
Thanks
   Toerless Eckert

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 26 Jan 2007 10:31:16 -0800

-- 
Thanks
   Toerless Eckert

---

From: Leonard Giuliano <[email-masked]>
Date: Fri, 26 Jan 2007 10:41:14 -0800 (PST)

-) > Unfortunately, the SSM-only decree was tried (for 
-) > IPv6) and rejected.
-) 
-) Not sure what you mean  with that... Care to explain ?
-) 

draft-giuliano-mboned-v6mcast-framework, which was proposed for all the 
reasons you state.  A suggestion that the WG start clubbing baby seals 
probably would have been received more warmly than this proposal 
experienced in Vienna.

---

From: Leonard Giuliano <[email-masked]>
Date: Fri, 26 Jan 2007 10:41:14 -0800 (PST)

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 31 Jan 2007 19:06:00 -0500

Hello;

On Jan 19, 2007, at 3:04 AM, Pekka Savola wrote:

> I'll try to summarize the discussion that related to IANA  
> assignment policies and eGLOP.
>
> this assignment task for various reasons.  Marshall said he'd try  
> to get this started.  What is the status of this effort?
>

Here is a draft of a submission for Apnic. Comments, tomatoes, etc.,  
welcomed. This is based on the form at

http://www.apnic.net/cgi-bin/policy_proposal.pl

which is why it is a little choppy.

Marshall

SIG for discussion:
Nominate the SIG you think is most appropriate for discussing this  
proposal.

Policy

Title of proposal:

eGLOP Multicast Address Assignments

Introduction:

RFC 2770 [now replaced by RFC 3180 / BCP 53] set up an automatic  
"GLOP" multicast address assignment in 233/8 based on Autonomous  
System Numbers (ASNs). The mechanism that was set up in RFC 318 for  
extending GLOP assignments, known as eGLOP, envisioned the assignment  
of multicast addresses by RIRs from the portion of the 233/8 space  
corresponding to the RFC 1930 private address space. This mechanism  
has never been used, but its use is now imperative due to both an  
increased interest in multicast address assignments to support IPTV  
and the adopted proposals to assign 4-octet ASNs, which do not have  
GLOP assignments. This proposal is for the assignment of Multicast  
addesses by the APNIC RIR; equivalent proposals will be sent to the  
other RIRs for consideration in due course.

Summary of the current problem:

RFC 2770 and RFC 3180 describe a policy for use of the class D  
address space
by mapping 16 bits of Autonomous System number (AS) into the middle two
octets of 233/8 to yield a /24, which is automatically assigned to  
that ASN.  While this technique has been
successful, the assignments are inefficient in those cases in which a
/24 is too small or the user doesn't have its own AS, and it does not  
work for 4-octet AS number
extension scheme.

RFC 3138 expanded on RFC 2770 to allow routing registries to assign  
multicast addresses from the GLOP space corresponding to the RFC 1930  
private AS space; referred to as the EGLOP (Extended GLOP) address  
space.

The failure to instantiate RFC 3138 assignments had lead to a  
situation where some multicast users feel like they cannot obtain  
addresses, while others apply directly to IANA, with there being at  
least 24 IANA approved applications in 2006. The current situations  
in inequitable and inefficient and there is no reason not to apply  
the mechanism set up in RFC 3138.

Situation in other RIRs:

We intend to make comparable proposals to the ARIN, LACNIC, and RIPE  
NCCs in due course. This submission was motivated by the date of the  
next APNIC meeting.

Details of your proposal:

RFC 3138 allocated 233.252/14 to eGLOP. The RFC further says that

    Globally scoped IPv4 multicast addresses in the EGLOP space are
    assigned by a Regional Registry (RIR).  An applicant MUST, as per
    [IANA], show that the request cannot be satisfied using
    Administratively Scoped addressing [RFC2365], GLOP addressing
    [RFC2770], or SSM.  The fine-grained assignment policy is left to  
the
    assigning RIR.

[IANA] is http://www.iana.org/assignments/multicast-addresses

We propose that each RIR be allocated an initial /20 from this  
address range, and allocate by default /28's to proposers (16  
addresses as Multicast address are not subject to CIDR default  
restrictions), subject to the above criteria, and that the RIR assign  
more addresses based on demonstrated need.

Note that Multicast addresses are not subject to classless  
aggregation and address blocks as small as a /32 can be usefully  
assigned.

Advantages and disadvantages of adopting the proposed policy:

The proposed policy should facilitate multicast deployment. The  
current mechanism for non-GLOP multicast deployment involves  
requesting an assignment from IANA, which has no ability to evaluate  
these requests and relies on the IANA Multicast Expert appointed by  
the IESG (currently David Meyer). This process is inefficient,  
inequitable (as this policy route is not widely known), encourages  
the use of "rouge" self-assignments, and discourages application  
developers and service providers from developing and deploying  
multicast.

The only disadvantage that we can see from the proposed policy is  
that the RIR's will have to set up and execute mechanisms to  
implement it.

Effect on APNIC members:

We feel that adoption of this proposal will help to make multicast  
deployment more widespread, and should be of benefit to APNIC members  
adopting Multicast for video distribution on the Internet. It will  
have no effect on APNIC members who do not deploy Multicast.

Effect on NIRs:

> mechanism to discourage unnecessary use of IANA assignments.  A  
> change in IANA policies and/or guidelines could create a backing to  
> also deny requests if need be. (In the end, it might be that the  
> requestor would just invent an address space to use if denied, but  
> whether that matters is an open issue.)
>
> this and also supported resurrecting the IPv4 unicast-prefix  
> mapping draft (separate thread on this).
>
> One point that has been discussed before was that if eGLOP  
> assignments were to be made for a fee, there would be no incentive  
> for anyone to use that service unless IANA stopped providing  
> multicast addresses for those customers.
>
> document [one was started and has died off several times] rather  
> than this one.
>

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 31 Jan 2007 19:06:00 -0500

Hello;

Marshall

SIG for discussion:

Policy

Title of proposal:

Introduction:

Situation in other RIRs:

Effect on APNIC members: