Subject: [ietf-dkim] New IANA considerations: standards track or just RFC?

From: Paul Hoffman <[email-masked]>
Date: Fri, 19 Jan 2007 13:39:09 -0800

Greetings again. One significant change in the new draft is the 
addition in Section 7 of "In all cases, new values are assigned only 
for Standards Track RFCs approved by the IESG." This change came at 
the request of Cullen Jennings, an AD. In that request, he says "Glad 
to talk about pros and cons of this", so I am Cc'ing him on this 
thread.

This change precludes IANA from registering values for IESG-approved 
Experimental RFCs, or IESG-approved independently-submitted 
Informational RFCs. Normally, "standards track only" is used in 
protocols where there is a limited-size namespace, and "RFC only" is 
used in places where namespace size is not a concern but there is a 
desire for a stable, long-lived reference for every entry in the 
namespace.

Maybe we want "RFC only", not "standards track only", particularly so 
that people can create Experimental RFCs and have them be used in an 
interoperable fashion as a way of determining whether they should 
later be elevated to standards track.

--Paul Hoffman, Director
--Domain Assurance Council
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 20 Jan 2007 09:35:10 -0800

Just as one other tidbit in this thread, this argument is somewhat  
intertwined with the argument of if this document should be PS or  
experimental. I've been arguing for PS.

On Jan 19, 2007, at 1:39 PM, Paul Hoffman wrote:

> addition in Section 7 of "In all cases, new values are assigned  
> only for Standards Track RFCs approved by the IESG." This change  
> came at the request of Cullen Jennings, an AD. In that request, he  
> says "Glad to talk about pros and cons of this", so I am Cc'ing him  
> on this thread.
>
> This change precludes IANA from registering values for IESG- 
> approved Experimental RFCs, or IESG-approved independently- 
> submitted Informational RFCs. Normally, "standards track only" is  
> used in protocols where there is a limited-size namespace, and "RFC  
> only" is used in places where namespace size is not a concern but  
> there is a desire for a stable, long-lived reference for every  
> entry in the namespace.
>
> Maybe we want "RFC only", not "standards track only", particularly  
> so that people can create Experimental RFCs and have them be used  
> in an interoperable fashion as a way of determining whether they  
> should later be elevated to standards track.
>
> --Paul Hoffman, Director

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 20 Jan 2007 16:22:03 -0500

> later be elevated to standards track.
+1  I think this would be much better.

Scott K

---

From: Arvel Hathcock <[email-masked]>
Date: Tue, 23 Jan 2007 12:22:30 -0600

> Maybe we want "RFC only", not "standards track only",

+1.  I would support this change.

-- 
Arvel

---

From: Jim Fenton <[email-masked]>
Date: Tue, 23 Jan 2007 16:21:24 -0800

Paul Hoffman wrote:
> to talk about pros and cons of this", so I am Cc'ing him on this thread.
>

I generally agree with "RFC only", but haven't thought about all eight 
of the registries that -base asks to have created.  It's not clear that 
we want to do this with all of them.  For example, we might want to set 
a higher bar for the signature or hash algorithm than for creation of a 
new signature tag.

-Jim

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 Jan 2007 16:33:25 -0800

At 4:21 PM -0800 1/23/07, Jim Fenton wrote:
>>This change precludes IANA from registering values for 
>>IESG-approved Experimental RFCs, or IESG-approved 
>>independently-submitted Informational RFCs. Normally, "standards 
>>track only" is used in protocols where there is a limited-size 
>>namespace, and "RFC only" is used in places where namespace size is 
>>not a concern but there is a desire for a stable, long-lived 
>>reference for every entry in the namespace.
>>
>I generally agree with "RFC only", but haven't thought about all 
>eight of the registries that -base asks to have created.  It's not 
>clear that we want to do this with all of them.  For example, we 
>might want to set a higher bar for the signature or hash algorithm 
>than for creation of a new signature tag.

Why? These are just registrations. No one has to follow them if they 
don't want. If they see something in the IANA registry that has an 
RFC number different than the dkim-base RFC number, they will clearly 
go read the spec before doing anything. If someone has done the work 
to get something through the IETF process, or the RFC Editor process, 
that indicates enough effort.

 From our experience in IKEv2, having different levels of requirements 
for different registries is just a headache.

--Paul Hoffman, Director

---

From: John Levine <[email-masked]>
Date: 24 Jan 2007 00:39:20 -0000

>a higher bar for the signature or hash algorithm than for creation of a 

Remember that the point of the registry is primarily to prevent
namespace collisions.  Registering a name for a new algorithm doesn't
change the DKIM spec, it just tells people that if they want to fool
around with that particular algorithm, that's the name to use to be
compatible with other people doing the same.  It'd take another
standards track RFC to promote a particular algorithm into the spec.

The main reason to limit registration is to avoid namespace
exhaustion, but since these are all variable length text
strings. that's not a problem.  In general, the bar to IANA
registration has been set too high, which is why there's way too many
protocol parameters documented only in the folklore.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 24 Jan 2007 00:07:13 -0500

> protocol parameters documented only in the folklore.
+1

Scott K

---

From: Jon Callas <[email-masked]>
Date: Wed, 24 Jan 2007 13:30:21 -0800

> should later be elevated to standards track.

Good reasoning. I also concur.

	Jon

---

From: Jon Callas <[email-masked]>
Date: Wed, 24 Jan 2007 13:33:09 -0800

> than for creation of a new signature tag.

To be something of a devil's advocate on this, why? A nice property  
of signatures is that there is pressure on the verifier either to  
create them maximally interoperably, or accept that some people won't  
be able to verify them.

As a verifier, if I start seeing signatures with a hash that I don't  
speak (or think is not secure), I just consider the message to be  
unsigned or bogusly signed. No problem.

	Jon

---

From: Jim Fenton <[email-masked]>
Date: Wed, 24 Jan 2007 18:29:29 -0800

Jon Callas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

Thanks, Paul, John, Scott, Arvel, Jon, and Phill (did I miss anyone?).  
I have to agree with the logic that you presented, that the namespace 
isn't constrained, and even for such things as hash and signature 
algorithms the registry isn't the place to make sure people make good 
choices.  Let's use "RFC only" for everything.  It was worthwhile (for 
me, anyway) to have talked that through.

-Jim

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 27 Jan 2007 09:32:39 -0800

On Jan 23, 2007, at 4:39 PM, John Levine wrote:

> namespace collisions.

I don't really agree with this - if this is the only point, you don't  
need a registry - you only need to have people do something like  
prepend the name with a domain name that the author of specification  
controls. Or use a GUID. Or any number of things.

The reason we are using registries here is to define what the  
standardization process is to make significant changes and update to  
this protocol.

One other note -  The IESG does not approve the RFC editor RFCs but  
only checks for conflicts with the IETF process - it's complicated to  
explain but you can read about it in RFC 3932.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 27 Jan 2007 12:01:10 -0800

Cullen Jennings wrote:
> need a registry - you only need to have people do something like prepend 
> the name with a domain name that the author of specification controls. 
> Or use a GUID. Or any number of things.

Cullen,

Registries come in many forms.  Having a rule-based scheme, rather than a 
registration-based scheme, is still a registry.  There is nothing wrong a 
rule-based scheme, if it does the job adequately.  For most or all of the things 
people define new IANA registries for, a rule-based scheme is not really 
practical.  To the extent that you disagree, try to apply your view to the 
variety of existing registries that do not require standards status for new 
entries.  There are quite a few.

John's description of the function being served is exactly correct.

I believe you are conflating the administrative job of a registry with the 
approval mechanism of a standards group.  They need to be kept separate.

> standardization process is to make significant changes and update to 

As I said, you are confusing things.  The standardization process is for 
standardizing things.  A registry is for registering things.  The latter has two 
basic functions:  1) avoid collisions, 2) provide a means of finding the 
registered entity.

The core question that we ought to be asking is the one that John raised:  Is 
there a fundamental damage in registering component mechanisms that are not 
standardized?  I believe the answer is not, and that the further answer is that 
industry will provide ad-hoc mechanisms if we fail to provide an official one.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 27 Jan 2007 23:30:48 +0100

Cullen Jennings wrote:

> The IESG does not approve the RFC editor RFCs but only checks
> for conflicts with the IETF process - it's complicated to

Thanks, yes, I knew RFC 3932, and there's also a draft under
discussion about these "independent" submissions:
I-D.draft-klensin-independent-05.txt

draft-narten-iana-considerations-rfc2434bis-05.txt lists all
relevant possibilities for the creation of IANA registries:

- ...
- expert review (that requires an expert and a mailing list)
  It's a pain if the expert is MIA, and/or the IESG forgot
  to appoint one, or if there's no volunteer.
- specification required (not necessarily an RFC)
- RFC required (that's what the WG DKIM apparently wants)
- IETF review (that might be what you really want)
- standards action (maybe you want this, but the WG doesn't)
- IESG approval, that's an oddity, there might be no document,
  only a registration template, it's discouraged in the I-D.

"Standards action" is what the name says, only a PS will do.

"IETF review" would exclude independent submissions, and it
would guarantee an IETF last call with IESG approval.  It
would still allow any IETF RFC (incl. experiments).

As far as I'm concerned "IETF review" instead of only "RFC"
is also fine - I don't see the point of excluding independent
submissions, but if you insist on excluding this... <shrug />

Somebody would have to check that RFC 2434 is compatible
with draft-narten-iana-considerations-rfc2434bis-05.txt :-)
Maybe the 2434 name for "IETF review" is "IETF consensus".

Frank

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 28 Jan 2007 00:46:50 +0000

Hi Cullen,

I think Frank summarised things nicely when he said:

> - RFC required (that's what the WG DKIM apparently wants)
...
> - standards action (maybe you want this, but the WG doesn't)

In your original discuss text [1], you mention pros and cons
and you also say you'd be happy to talk about those.

What are they? And how can they help us square this circle
where the WG wants thing-A and your discuss calls for
thing-B?

Thanks,
Stephen.

[1] 
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=60908

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 27 Jan 2007 20:19:54 -0800

Defintely yes - I think the phone call last time was very productive  
so I will work with the chairs to see if we can set up something  
similar.

On Jan 27, 2007, at 4:46 PM, Stephen Farrell wrote:

> [1] https://datatracker.ietf.org/public/pidtracker.cgi? 
> command=view_comment&id=60908