Subject: New type code assignments (was: Re: draft-iab-dns-choices-02.txt comments)

From: Samuel Weiler <[email-masked]>
Date: Tue, 14 Jun 2005 12:22:44 -0400 (EDT)

On Mon, 13 Jun 2005, Olaf M. Kolkman wrote:

> One of the arguments that is currently being used against trying to
> "design"  a new RR for use with ones application, is that it is
> apparently difficult to get one's specification reviewed, processed
> and the typecode assigned.
>
> This should not be an argument.
...
>          o Reviewing and providing recommendations about the
>            specification, by other working groups, of RR types that do not
>            require any special processing and that do not require any
>            special naming conventions.

Note that this charter item only applied to RRs requested "by other
working groups".  Presumably those looking for assignments in the
"specification required" part of the number space wouldn't even need
DNSEXT review.

-- Sam

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

---

From: Allison Mankin <[email-masked]>
Date: Tue, 14 Jun 2005 12:51:59 -0700

To Sam's point:
RFC 2434 and RFC 2929 (and the IETF IANA practice) cause the allocation
to appear in the registry when the document is approved, and then IANA 
updates the registry reference to the RFC number when the RFC is published.

To Ed's point:
There is a BCP providing for an early allocation practice for
cases where the working group makes a careful justification (it also
explains revocation if anything goes wrong).  It has conditions; 
it can only be used for Standards Action policy codepoints (this
woudl work for the kind of type code assignments being
discussed here) and there are documentation requirements.
Take a look at RFC 4020 (BCP 100).

Allison

---

From: Edward Lewis <[email-masked]>
Date: Tue, 14 Jun 2005 16:35:52 -0400

>Take a look at RFC 4020 (BCP 100).

I agree with the premise of the document - especially that 
interoperability of implementations is the goal, and this is helped 
by number assignments.  But I don't see the process in the document 
as a solution.

Setting aside a segment of space for "early assignment" is not 
operationally tenable.  E.g., what if one assignment from that space 
becomes a Full Standard - the space is now "polluted" by a real 
assignment.

I've seen similar ideas in network address assignments.  Segmenting 
number space (whether for addressing or coding) isn't that beneficial 
once you have "cross overs."  By a cross-over, I mean a successful 
early assignment and a failed late assignment.

I also think that requiring "standards track" is too high of a bar, 
or even getting WG consensus.  What about things like the DNS A6 RR, 
which started as a standards track item and then slipped to 
experimental?

For non-WG activities, i.e., those that sometimes lead to a BoF and 
then a WG, counting on finding a sympathetic ear of an Area Director 
sounds like a subjective process.  Bureaucracies that rely on 
subjective processes don't scale well.

Finally, a lot of us have thrown RFC 2929 around as the definition of 
the process IANA is to follow.  How would I have navigated from RFC 
2929 to RFC 4020 to see these new "rules?"

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.

---

From: Allison Mankin <[email-masked]>
Date: Tue, 14 Jun 2005 14:01:21 -0700

Ed,

> becomes a Full Standard - the space is now "polluted" by a real 

Perhaps you read a little fast.  The space just becomes
eligible for Early Assignment - it is not set aside en bloc
foro early assignment.  The normal Standards Track space is "amended
to permit Early Allocation" so it has both early and normal 
allocations out of it.  

> which started as a standards track item and then slipped to 

The point about making these assignments before the document is
finished by the working group is make sure that the codepoint is
for something stable and expected to need the acceleration of
the deployment of the early allocation.  The working
group judges that.  Did the A6 RR need that?  If the working
group and Chair had figured out a case for that, they'd ask the
AD for that, and it would get the type early.  We're only talking
about time here, after all.  It would get the codepoint later
if not.

> 2929 to RFC 4020 to see these new "rules?"

They're not yet new "rules" that update 2929 unless a given WG
goes through the process of updating its space.  At that point,
the WG needs to have the knowledge, but also, we probably need to
mark the RFC Index to say that RFC 4020 updates some other document
(I'm not sure of this - I haven't brought this up with others).
I brought up RFC 4020 because I guessed it hadn't crossed most WGs'
paths, and because the IANA process interests me.

Allison

---

From: Edward Lewis <[email-masked]>
Date: Tue, 14 Jun 2005 17:17:04 -0400

>to permit Early Allocation" so it has both early and normal

"   This memo only addresses the early allocation of code points from
    spaces whose allocation policy is "Standards Action" [2434] AND that
    have been amended to permit early allocation.  This permission must"

I interpreted "spaces whose policy" "have been amended to permit 
early allocation" to mean that only some of the "Standards Action" 
space is so designated.

>about time here, after all.  It would get the codepoint later

I don't recall the how A6 got it's type code assignment.  I'd also be 
curious of the case studies of SINK and OPT - as cases of a mature 
proposal that was ultimately killed and a successful proposal that 
got a wrong number.

My interest isn't in trying to find blame, guilt, etc., but in 
finding out how we can do better in the future.  I.e., why don't we 
have a document that says "don't try to use the SINK record because 
it proved to be an arguably bad idea and oh, by the way, here was the 
definition it had when it sunk (no pun intended)."  By this I mean no 
disrespect to the people behind the effort to make the SINK record 
work, but I also wish we wouldn't mind documenting bad ideas as 
signposts for the future.

>paths, and because the IANA process interests me.

It sounds then like 4020 is an invitation to revisit 2929, to 
consider loosening our recommendations to IANA.