Re: [dnsext] draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission...

[joel jaeggli <[e-mail]>]

On 4/18/13 11:41 AM, Thierry Moreau wrote:
> Donald Eastlake wrote:
>> Hi Thierry,
>>
>> Calling anything but April 1st RFCs a "submarine RFC" is pretty silly.
>> (April 1st RFCs really do appear with no warning.)
>>
>
> I stand corrected on this one, with the following nuance: while IETF 
> processes are eminently transparent and public, they remain obscure 
> and complex, at least at the detailed level, for anyone not directly 
> involved.
>
> I stand corrected because IANA web pages indeed refers to the I-D once 
> approved and until the RFC is published (but still, once the RFC is 
> published, the date of I-D approval disappears from the IANA web pages 
> ... so a hindsight understanding of IANA motivation for a protocol 
> assignment between I-D approval and RFC publication is harder).
Were this AD sponsored, which in fact it isn't  yet the responsible AD 
would be looking for reviewers, and at a minimum it would be subject to 
an IETF last call.

the ISG processing rules say:

AD Sponsored documents to Standards Track require review in the IETF, 
IETF Last Call, and IESG approval. AD Sponsored documents to 
Experimental/Informational require some form of review in the IETF and 
IESG approval. While RFC 2026 does not require the latter type of 
documents to go through an IETF Last Call, this statement suggests that 
it is always performed. It is needed to ensure adequate review and 
transparency in a situation where the pending publication of the 
document may not be known by any Working Group or the IETF community at 
large.
>> They are all internet-drafts first and publicly available there even
>> before they are listed in the RFC Edtior's queue for, usually, a
>> couple of months, while going through the editing process. And, in the
>> case of a WG document like rfc6195bis, there is notice and discussion
>> in the working group, the IETF Last Call, the IESG process tracked in
>> the datatracker, etc.
>>
>> The IESG has the standards setting and BCP approval authority in the
>> IETF. It has always been the case that, unless perhaps there is some
>> special provision in the document, drafts take effect on the final
>> approval by the IESG, that is, at the time they are transferred to the
>> RFC Editor, not when the RFC issues.
>>
>
> I never figured out how to train myself about BCP. I got bored of IETF 
> process before I could. So what about others not directly involved?
>
>> RFC Editor's queue is here, which is linked off the RFC Editor home 
>> page:
>> http://www.rfc-editor.org/queue2.html
>> RFC publication can be held up for a variety of reasons. The oldest
>> document currently in the queue was placed there 2012-02-21, almost 14
>> months ago.
>>
>> Thanks,
>> Donald
>> =============================
>>  Donald E. Eastlake 3rd   [phone] (cell)
>>  155 Beaver Street, Milford, MA 01757 USA
>>  [e-mail]
>>
>>
>> On Thu, Apr 18, 2013 at 10:16 AM, Joe Abley <[e-mail]> wrote:
>>> On 2013-04-18, at 09:46, Thierry Moreau 
>>> <[e-mail]> wrote:
>>>
>>>> Joe Abley wrote:
>>>>> On 2013-04-15, at 12:10, Doug Barton <[e-mail]> wrote:
>>>>>> It's also not clear why IANA has already assigned code points for 
>>>>>> this (as described in your text).
>>>>> Because the expert review passed, and IANA was following the 
>>>>> required procedure, I think.
>>>> [reviewing the discussion from a process perspective -- what is the 
>>>> root cause of the controversy?]
>>>>
>>>> It appears that the bar for RR type allocation is lower than for an 
>>>> informational RFC.
>>> The RRType application registry's bar is "expert review". The bar 
>>> for publication of an informational RFC depends on what stream you 
>>> follow, whether it's a working group document, etc. It's not clear 
>>> to me that one bar is obviously lower; they're just different.
>>>
>>>> To which extent should the IESG lower the bar for a specific I-D on 
>>>> the ground that it acquired an RR type?
>>> I'm not sure that it should (nor that anybody has suggested it 
>>> should, or would).
>>>
>>>> Incidentally:
>>>>
>>>> Process-wise, we could be in front of a "submarine RFC" case: IANA 
>>>> (or the expert?) would have followed the RFC6895 procedures before 
>>>> it was published.
>>> As I understand it, the directions in 
>>> draft-ietf-dnsext-rfc6195bis-05 were followed by the IANA once that 
>>> document was approved by the IESG. It looks like that happened in 
>>> December last year. The document emerged from the RFC editor queue 
>>> as RFC6895 two days ago.
>>>
>>> It doesn't seem unreasonable that "IESG approval" is the trigger 
>>> here, rather than "RFC published".
>>>
>>>> It bugs me that the IANA allocation process uses a mailing list a) 
>>>> not listed in the IANA web pages, and b) (I guess) subject to the 
>>>> IETF IPR disclosure policy by virtue of being run under the 
>>>> ietf.org domain.
>>> I'm not sure what mailing list you're talking about. Applications 
>>> for RRTYPE code point assignments are sent to 
>>> [e-mail], which seems to forward to a ticket 
>>> system at the IANA.
>>>
>>>> I am not particularly expert in those details, but somehow I care that
>>>> 1) stakeholders are created equal, but some are more equal than 
>>>> others (e.g. those aware in advance of the submarine RFC), and
>>> I had no particular awareness of the process when I applied for code 
>>> points for EUI48 and EUI64 -- I just found the relevant registry at 
>>> www.iana.org and clicked the link above the table. That took me to 
>>> draft-ietf-dnsext-rfc6195bis-05 which contained instructions; I 
>>> followed them.
>>>
>>>> 2) who controls the process controls the outcome.
>>> My experience with this application was that the process was 
>>> efficient, easy to find and easy to understand.
>>>
>>>
>>> Joe
>>> _______________________________________________
>>> dnsext mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dnsext
>>
>
>