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

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

At 14:01 -0700 6/14/05, Allison Mankin wrote:
>Ed,
>
>>  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.
>
>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.

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

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

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.

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

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

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

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

--
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/>