Subject: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-rfc5451bis-09: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 09 Jul 2013 09:53:40 -0700

Stephen Farrell 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:
----------------------------------------------------------------------

- note to RFC editor in the abstract I guess needs changing 
now that this is going for PS

- intro: Are ADSP and VBR really in common use?

- 1.6: you say valid use "requires removing" this when the
message first arrives in the ADMD. I think that'd be better
as a "MUST remove" but is clear enough. (Section 5 has a MUST
btw, though also allows for not removing messages you
get *directly* from a "trusted" peer. Is "directly" there
really verifiable in general?)

- 1.7: I guess this is changed by the new PS target.

- 2.3: You say MUAs SHOULD use the authserv-id field to
determine whether to use or ignore the header field. That's
unchanged since 5451 but I wonder if it'd be better to say that
MUAs need to have a whitelist or similar of values that are ok
for this? What's actually done here? (This isn't a discuss since
its the same in 5451.)

- 2.4 and 2.5.7: I think I agree that adding these means that
cycling at PS is correct.

- section 4, 2nd last para: has a new SHOULD NOT that seems
sensible - but I wondered why this was a SHOULD NOT and not a
MUST NOT? I can't think of a case where an AR is better
containing stuff that the MUA can't see. If there are such
cases, maybe mention one. Or maybe I've misinterpreted the
text? (It is a bit hard to get.)

- section 7: Thanks!

---

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

> now that this is going for PS

Fixed.

> - intro: Are ADSP and VBR really in common use?

There's support for both in OpenDKIM which is definitely in common use.  I
don't have any data about how many people have actually turned them on, nor
do I have any publication survey data.

> really verifiable in general?)

Section 1.6 is part of an overall introduction section, so I avoided using
RFC2119 language in it.  As you point out, the requirement is actually
established elsewhere.

> - 1.7: I guess this is changed by the new PS target.

Removed.

> for this? What's actually done here? (This isn't a discuss since

The whitelist solution is the most common one (and the only one I know
of).  There might be some way other than a whitelist to determine whether
to trust the field, but it didn't seem appropriate to name a specific way
to do that in case that's taken as proscribing other methods.

> cycling at PS is correct.

Right.

> text? (It is a bit hard to get.)

Pete brought up the same point in a different spot.  MUST NOT is fine with
me.

Any suggestions to de-confuse it?

> - section 7: Thanks!
A question to the IESG: Should I take that out since this is falling back
to PS, or leave it in?  It won't be there when the request comes to advance
this to IS in 6-12 months.

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Tue, 9 Jul 2013 16:32:21 -0400

> A question to the IESG: Should I take that out since this is falling back
to PS, or leave it
> in?  It won't be there when the request comes to advance this to IS in
6-12 months.

Leave it.  It already asks the RFC Editor to remove it, and when it comes
back around again later we can refer to the section in the archived draft.

Barry