Subject: Re: [apps-discuss] Spencer Dawkins' No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT)

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 9 Jul 2013 11:23:53 -0700

On Mon, Jul 8, 2013 at 5:37 PM, Spencer Dawkins <
[email-masked]> wrote:

>
> I found this specification clear and especially appreciated the context
> in sections like Operational Guidance.
>

Thanks!

>
> I had some non-blocking comments that I'd ask you to consider along with
> other comments you might receive.
>
> In 1.1.  Purpose
>
>    In particular, the mere presence of this header field SHOULD NOT be
>    construed as meaning that its data is valid, but, rather, that it is
>    reporting assertions made by one or more authentication schemes
>    applied somewhere upstream.
>
> This doesn't look like a 2119 SHOULD NOT to me ... are you saying
> something like "the mere presence of this header field doesn't mean that
> its data is valid"?
>

Yes, I'll calm the language down.  I actually violated my own rule about
having normative language in an introduction section.

>
> In 1.5.2.  Security
>
>    By contrast, DKIM is agnostic as to the routing
>    of a message but uses cryptographic signatures to authenticate agents
>    claim (some) responsibility for the message (which implies
>    authorization) and ensures that the listed portions of the message
>    were not modified in transit.
>
> This sentence isn't parsing for me. Missing word, perhaps?
>

Yep, already fixed in my copy.

>
> In 2.5.1.  DKIM and DomainKeys
>
>    neutral:  The message was signed but the signature or signatures
>       contained syntax errors or were not otherwise able to be
>       processed.  This result SHOULD also be used for other failures not
>       covered elsewhere in this list.
>
> I don't think this is an RFC 2119 SHOULD, but my larger point is, if you
> encounter a failure that's not covered in this list, what other choice is
> there? (Return no result? return the wrong result?)
>

It was "should" in the last one, upgraded on the grounds that "should" and
"SHOULD" are actually the same thing.  It's a little excessive since the
listed values constitute the complete list, so we can just say this is the
catch-all without the SHOULD (or even a MUST).

> In 6.2.  Email Authentication Method Name Registry
>
>    Each method must register a name, the specification that defines it,
>    a version number associated with the method being registered
>    (preferably starting at "1"),
>
> this "preferably" is Mostly Harmless, but I'd think if the intent was to
> avoiding confusing the reader, you'd be better off mandating that.
> "Preferably" seems to say "you could *probably* trust that version 5
> isn't the first version, but you can't know that for certain".
>

Being a C coder, I was trying to allow for cases where someone wants to
start versioning at 0.  :-)

>
> A couple of paragraphs down,
>
>    IANA is also requested to add a "version" field to all existing
>    registry entries.  All current methods are to be recorded as version
>    "1".
>
> seems to mandate starting at "1" for existing methods, so I'm confused
> why new methods might not begin with version '1'.
>

The methods currently in the registry all either don't have a version, or
are explicitly version 1 anyway, so I believe this was a safe move.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 9 Jul 2013 15:27:49 -0700

On Tue, Jul 9, 2013 at 2:36 PM, Spencer Dawkins <
[email-masked]> wrote:

> If we're tracking each other, I agree with what you're doing (setting
> everything that's not explicit to the same origin).
>
> That's why I was more confused when you have what looks like a uniform
> situation now, but people can pick some random integer for the first
> version number on new methods.
>
> If you tell me that the mismatch doesn't matter, because no one will
> assume anything about version number '1' being the first version without
> checking, I'll believe you, but I'll silently and non-blockingly wonder why
> you preferred starting with "1".
>
> Does that make sense?
>
>
Yep.  And yes, I don't think it matters.  The question in a consumer of
this field will be "Do I understand the specific version I see in the
header field?"  The IANA registry is mainly a mapping of version numbers to
specification documents.  If new method "foobar" appears and wants to start
versioning at 0, there's no reason it can't.  I did the "set the current
things at 1" only because they all actually are 1 (in DKIM keys, it's
"v=DKIM1"; in SPF, it's "v=spf1"; etc.), and I need to populate the new
column in the IANA registry with something.

-MSK

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 08 Jul 2013 17:37:04 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-appsawg-rfc5451bis-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I am sympathetic to Pete's DISCUSS on advancing to full standard while
making incompatible changes, but I'll let you folks hash that out - it
wouldn't affect my ballot position either way.

In 1.1.  Purpose

In 1.5.2.  Security

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 09 Jul 2013 16:36:23 -0500

On 7/9/2013 1:23 PM, Murray S. Kucherawy wrote:
> On Mon, Jul 8, 2013 at 5:37 PM, Spencer Dawkins 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:

Hi, Murry,

Thanks for the quick response! I had one point I should ask more clearly ...

> Being a C coder, I was trying to allow for cases where someone wants 
> to start versioning at 0.  :-)

Having started as an APL coder, I appreciate that :-)

> The methods currently in the registry all either don't have a version, 
> or are explicitly version 1 anyway, so I believe this was a safe move.

If you tell me that the mismatch doesn't matter, because no one will 
assume anything about version number '1' being the first version without 
checking, I'll believe you, but I'll silently and non-blockingly wonder 
why you preferred starting with "1".

Does that make sense?

Spencer

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 09 Jul 2013 17:37:56 -0500

On 7/9/2013 5:27 PM, Murray S. Kucherawy wrote:
> On Tue, Jul 9, 2013 at 2:36 PM, Spencer Dawkins 
>     If you tell me that the mismatch doesn't matter, because no one
>     will assume anything about version number '1' being the first
>     version without checking, I'll believe you, but I'll silently and
>     non-blockingly wonder why you preferred starting with "1".
>
>     Does that make sense?
>
>
> Yep.  And yes, I don't think it matters.  The question in a consumer 
> of this field will be "Do I understand the specific version I see in 
> the header field?"  The IANA registry is mainly a mapping of version 
> numbers to specification documents.  If new method "foobar" appears 
> and wants to start versioning at 0, there's no reason it can't.  I did 
> the "set the current things at 1" only because they all actually are 1 
> (in DKIM keys, it's "v=DKIM1"; in SPF, it's "v=spf1"; etc.), and I 
> need to populate the new column in the IANA registry with something.
>
> -MSK
>

Thanks for the clue!

Spencer