Subject: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-email-auth-codes-06: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 06 Aug 2014 14:50:37 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-appsawg-email-auth-codes-06: 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.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-email-auth-codes/

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

- Since only one code is returned and since the client has to
assume that other failures may have happened in parallel, and
since the X.7.20 code covers two different things (i.e. (a) and
(b) from 3.1), did the wg consider splitting out 3.1's (a) and
(b) into different codes?  That way the 3.1.a code would
conform to 6376 and the 3.1.b code would be "failed my local
DKIM specifics." Seems to me that splitting those out might be
better but I'm fine if this was considered and rejected (i.e.
no need to re-do the reason for rejecting, just tell me it
happened and that'll be fine).

- The intro could make the X.7.nn notation clearer, but it
becomes blatently obvious if one reads 5248 so its ok unless
you want to be extra-nice to the reader.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 6 Aug 2014 16:55:06 -0700

Hi Stephen,

> happened and that'll be fine).

There haven't to my knowledge been any instances of wanting or needing to
report 3.1.a separately from 3.1.b, which is why they're rolled into the
same status code.  To date the only distinction of interest is between
what's covered by x.7.20 and x.7.21, namely the domain name alignment.  In
that sense all we're documenting here is a set of codes that match what the
industry has been doing since DKIM started achieving serious deployment.

-MSK

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 07 Aug 2014 01:12:58 +0100

> industry has been doing since DKIM started achieving serious deployment.

Sure, I get that.

If separating 3.1.a and 3.1.b doesn't resonate with folks, that's
fine, we should just move on. However, if it did, then that'd I
think get rid of some of the odd language about the DKIM spec. But
its a minor point, not worth more mail unless people want to take
that route.

Cheers,
S.

---

From: S Moonesamy <[email-masked]>
Date: Wed, 06 Aug 2014 17:18:53 -0700

Hi Stephen,
>COMMENT:

There was a DISCUSS from Pete ( 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12731.html 
).  Murray suggested some text for Section 3.1, i.e. the (a) and the 
(b) ( 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12732.html ).

The question of whether 3.1 (a) and (b) should be split into two 
different codes did not arise during the working group discussions.

Regards,
S. Moonesamy (as document shepherd)

---

From: Pete Resnick <[email-masked]>
Date: Wed, 6 Aug 2014 21:24:39 -0500

On 8/6/14 7:18 PM, S Moonesamy wrote:
> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12731.html ).  
> Murray suggested some text for Section 3.1, i.e. the (a) and the (b) ( 

And to be clear, my DISCUSS was because I thought the text was not clear 
that 3.1.a and 3.1.b were being combined in X.7.20. Now the text is 
clear that they are, which is why I moved off of my DISCUSS, but that's 
not to say that I think it's good that they're combined. Murray has 
argued that there has been no need to split them and therefore there is 
no likely future need to do so either. The WG should probably decide if 
that's true, because once you put X.7.20 in to mean the combination of 
3.1.a and 3.1.b, there's no going back; if you decide later that they 
ought to be split, you'll be deprecating X.7.20 and making two new 
codes. I'd rather see them split now, but it's not a showstopper, and if 
the WG considers it and decides it's not necessary, like Stephen I will 
be fine with it.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: S Moonesamy <[email-masked]>
Date: Wed, 06 Aug 2014 20:14:28 -0700

Hi Pete,

[removed iesg@ from the working group discussion]

At 19:24 06-08-2014, Pete Resnick wrote:
>And to be clear, my DISCUSS was because I thought the text was not 
>clear that 3.1.a and 3.1.b were being combined in X.7.20. Now the 
>text is clear that they are, which is why I moved off of my DISCUSS, 
>but that's not to say that I think it's good that they're combined. 
>Murray has argued that there has been no need to split them and 
>therefore there is no likely future need to do so either. The WG 
>should probably decide if that's true, because once you put X.7.20 
>in to mean the combination of 3.1.a and 3.1.b, there's no going 
>back; if you decide later that they ought to be split, you'll be 
>deprecating X.7.20 and making two new codes. I'd rather see them 
>split now, but it's not a showstopper, and if the WG considers it 
>and decides it's not necessary, like Stephen I will be fine with it.

I suggest that the working group considers the above points.  I'll 
wait for comments until end of Friday (this week).

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 6 Aug 2014 22:05:07 -0700

On Wed, Aug 6, 2014 at 7:24 PM, Pete Resnick <[email-masked]>
wrote:

> that 3.1.a and 3.1.b were being combined in X.7.20. Now the text is clear
> that they are, which is why I moved off of my DISCUSS, but that's not to
> say that I think it's good that they're combined. Murray has argued that
> there has been no need to split them and therefore there is no likely
> future need to do so either. The WG should probably decide if that's true,
> because once you put X.7.20 in to mean the combination of 3.1.a and 3.1.b,
> there's no going back; if you decide later that they ought to be split,
> you'll be deprecating X.7.20 and making two new codes. I'd rather see them
> split now, but it's not a showstopper, and if the WG considers it and
> decides it's not necessary, like Stephen I will be fine with it.
>

I'll add it if the WG thinks it's needed or is a good idea.  I just haven't
seen any call for separating the two cases in practice so far.

-MSK