Re: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01

Yes its FCFS. 

There may be junk in the new proposed registry but so what. 

-----Original Message-----
From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of DRAGE,
Keith (Keith)
Sent: Monday, September 26, 2011 11:39 AM
To: Hadriel Kaplan; PFAUTZ, PENN L
Cc: rai@ietf.org
Subject: Re: [RAI] Global Service Provider ID -
draft-pfautz-service-provider-identifier-urn-01

One distinction between IANA tables is the level of review of qualification
required before a new entry is made in the table.

Which does raise the question of why the new proposal is FCFS. It is expert
review that prevents registries being populated with junk. (It becomes
expertly reviewed junk instead :-))

So ITAD is FCFS and the new proposed registry is FCFS.

Keith

> -----Original Message-----
> From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of
> Hadriel Kaplan
> Sent: 23 September 2011 23:55
> To: PFAUTZ, PENN L
> Cc: rai@ietf.org
> Subject: Re: [RAI] Global Service Provider ID - draft-pfautz-service-
> provider-identifier-urn-01
> 
> 
> On Sep 23, 2011, at 11:02 AM, PFAUTZ, PENN L wrote:
> > The outstanding issues seemed to be
> > 1. Is a new resource assignment necessary for the URN or could an
> existing one, Private Enterprise Numbers or ITADs be used with a URN
> defined to provide a fixed length parameter as requested in the I-D?
> >
> > The I-D proposed a new resource, partly because the existing ones were
> intended for other purposes and already had many registrations. I'd also
> note that PENs suggest a sub-delegation approach to assigning multiple
> SPIDs to an entity (an entity gets one PEN assignment and can assign
> values hierarchically below that (e.g. AT&T has PEN 74, and would assign
> 74.1, 74.2, etc). Because at least some of the service providers wanted to
> use SPID to prefix E.164 numbers and others want to incorporate SPID in a
> domain name, this would present issues.
> 
> I don't personally care whether a new registry space is created for SPID
> or not - it's not like IANA is running out of numbering spaces. :)  And
> although it takes IANA a bit of work to create a new one, I don't believe
> it's hard.
> 
> The thing that confuses me, though, is every characteristic described in
> the draft is exactly provided by ITADs, and although the ITAD space was
> created from RFC 3219 (the TRIP protocol spec), its semantic meaning was a
> Service Provider ID.  So when the draft says this in section 1:
>    Although preference was also expressed for
>    reuse of some existing identifier, if possible, as requirements have
>    been elaborated no current identifier seems appropriate.
> 
> ... it's befuddling.
> 
> So I asked some people about why ITAD wasn't what they wanted to use for
> SPIDs, and they said exactly what you said above:
> > because the existing ones were intended for other purposes and already
> had many registrations
> 
> 
> The former part isn't really important - PENs for example were created by
> SNMP but are now used in RADIUS VSAs, DIAMETER AVPs, IPFIX IEs, and
> others.  It's the number's semantics that matter, not what protocols
> encode it.
> 
> It's the latter part (that they already have many registrations) that I
> think is really why people don't want to use ITADs, and that's what
> worries me in a weird way... because it implies they think some new SPID
> registry won't be populated with junk.  It will be.  Random people
> register for these things, because it's free and simple to do so.  Some
> people will get them for labs or test equipment, some for start-ups which
> go belly-up, some people get them just because.  For example there's a PEN
> for an enterprise called KRAP (Kaplan Research and Application
> Prototyping).  I registered it so I could use a PEN for some prototype
> code I wrote.  It will never be seen in SNMP, RADIUS, etc.  That's the
> kind of junk that will appear even if we start a new registry.  So my
> concern is that people *want* a clean registry, but don't realize that
> making it free+open virtually guarantees it won't be.
> 
> -hadriel
> 
> _______________________________________________
> RAI mailing list
> RAI@ietf.org
> https://www.ietf.org/mailman/listinfo/rai
_______________________________________________
RAI mailing list
RAI@ietf.org
https://www.ietf.org/mailman/listinfo/rai