Subject: Re: FW: [IANA] Your request for a Private Enterprise Number has been closed - need to appeal this

From: Alan DeKok <[email-masked]>
Date: Wed, 04 Aug 2010 12:50:07 +0200

(original was sent to requestor && IANA)

Cindy Arens wrote:
> I am writing to appeal this denial of an additional PEN for Acme Packet, Inc.  This is directly related to our enterprise wanting to comply with the Internet-Draft (BCP) - RADIUS Design Guidelines (draft-ietf-radext-design-17).
> 
> Over the last almost 10 years, our enterprise has defined well over 200 unique RADIUS VSAs for the various products that we have.  We are now developing some new products that require even more unique RADIUS VSAs for our customers to use.  
> 
> In order to comply with the appendix section, A.3. Vendor-Specific formats, in the RADIUS Design Guidelines, we can see no solution other than getting a new PEN to implement a new set of vendor-specific attributes.  

  The guidelines document has not been published.  As such, it does not
(yet) affect IANAs allocation methods.

  I've brought your message to the attention of the IETF RADEXT working
group, and CC'd the group on this message.  We will discuss it, and see
what can be done.

  I also suggest joining the mailing list, by sending an email to
[email-masked].  You can follow the discussion, and
contribute any additional details that may be needed.

> If you need any more information about our products, how we have implemented our existing VSAs, or how we intend to implement future VSAs, please don't hesitate to inquire.  I would be happy to provide any information necessary to allow a new PEN to be issued for Acme Packet.

  The existing Acme VSAs look to have been allocated "freely".  For
example, the RADIUS dictionary I see has 30 attributes marked as "custom
string content based on system config".  This practice is not common in
RADIUS dictionaries, and uses up a lot of the attribute space.

  The RADEXT working group is developing an "Extended Attributes"
document.  It is intended to solve Attribute Type space exhaustion for
both IETF attributes, and for vendors.  If the document is published in
a timely manner, you may be able to leverage it before your current VSA
space is exhausted.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Alan DeKok <[email-masked]>
Date: Wed, 04 Aug 2010 12:55:55 +0200

OK... this would seem to be another issue that the guidelines document
needs to resolve.

  If allocating multiple Enterprise IDs for one vendor is not something
IANA will do, the document needs to be updated to specifically request
this.  The current IANA section doesn't specify this.

  If we don't want to allocate multiple Enterprise IDs for one vendor,
then the Extended Attributes document becomes more time-critical.

  Any suggestions?

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 4 Aug 2010 09:50:15 -0700

Allocating multiple Enterprise IDs to one vendor is probably not a very good idea, although it can easily happen due to mergers.  

I do agree that Design Guidelines needs to provide a recommendation that is consistent with the IANA allocation policy. 

> Date: Wed, 4 Aug 2010 12:55:55 +0200
> From: [email-masked]
> To: [email-masked]
> Subject: Duplicate PEN from IANA
>

---

From: Alan DeKok <[email-masked]>
Date: Thu, 05 Aug 2010 09:57:54 +0200

Bernard Aboba wrote:
> Allocating multiple Enterprise IDs to one vendor is probably not a very
> good idea, although it can easily happen due to mergers. 

 I think that's why many large vendors haven't had an issue.  They buy a
company, and get more VSA space.

> I do agree that Design Guidelines needs to provide a recommendation that
> is consistent with the IANA allocation policy.

  If we can get the extended attributes document done quickly, the
guidelines document doesn't have to make any recommendations. :)

  But right now, I'm not sure what recommendation to make.  One
short-term suggestion would be to tell vendors to uses nested
attributes.  3GPP does it, WiMAX does it, so most RADIUS servers support
it.  Using nested attributes would relieve a lot of pressure on the
vendor space.

  Alan DeKok.