Re: [apps-discuss] APPSDIR review of draft-ietf-marf-authfailure-report-05

[S Moonesamy <[e-mail]>]

Hi Murray,
At 12:39 02-12-2011, Murray S. Kucherawy wrote:
>There will probably be a few people concerned about the 
>"authentication vs. authorization" matter, but I think RFC5451 dealt 
>with this reasonably well, and the field

Agreed.

>If it would help, we could add a reference to RFC5451 Section 1.5.2, 
>which talks about the differences and their effective union in this area.

That may help if you want to avoid getting into a discussion about 
authentication v/s authorization.  The draft already references RFC 
5451 normatively.  A reference could be added in the Introduction Section.

>I suppose it's worded that way because we created a new report type 
>but had to make a number of changes to IANA registries to do so, 
>hence the plural.  But it really is one omnibus extension action.  I 
>don't have a preference as to wording; if the plural is confusing, 
>we can change it.

It can be argued either way.  The Abstract Section mentions "an 
extension report type to ARF".


>The point of saying this is that RFC5965 allows for the absence or 
>presence of the field, but proscribes multiple instances of it.  We 
>want to say, for this report type, that Original-Envelope-ID should 
>be there, further limiting the "absence" case.
>
>Perhaps changing the SHOULD to a MUST above is better?

Yes.

As an editorial comment, Section 3.2 of RFC 5965 uses two key words 
for the six header fields.  Section 3.1 of this draft uses ten key 
words for six header fields.  Imperatives should not only be used 
with care and sparingly; it also helps if the reader can easily 
identify what is required versus what is recommended.

>The Source-IP is a key piece of information for reconstructing why 
>an SPF evaluation failed.  It needs to be there if it's available, 
>or the failure report is basically incomplete.

Your reply clarifies when the "SHOULD" does not apply.  If it is a 
key piece of information which is necessary for interoperability, 
specify it as a requirement.

>It is the same, except that RFC5965 makes it entirely optional.  For 
>this report type, we want to see it at least once.

There could be an explanation about that in the draft.

>I agree with the reference change, however the "contrary" part is 
>correct because [REPORT] says the third MIME part in a report is 
>optional, while for this specific instance of it, we want it to be 
>there.  If it would help for illustration, we could say "(contrary 
>to [REPORT], which makes it optional)".

Ok.

>We actually had it the other way (as you suggest), and then changed 
>it to this because we thought this description was more effective, 
>i.e., having the strongest requirement first.

Ok.

>How about:
>
>         DKIM-ADSP-DNS: Includes the ADSP policy used to obtain the 
> verifier's ADSP result.
>
>("record" suggests an RRTYPE, and there isn't one specific to ADSP)

I used "record" as that is the term I found in RFC 5617.  The above sounds Ok.

>SHOULD [NOT] and MUST [NOT] don't apply... :-)
>
>Is there a problem with "MAY" there?

No. :-)

>I disagree, since one could also in theory use PGP or S/MIME for 
>similar effect.  DKIM is just the most common example, and is 
>actually in practical use in ARF terms.

Ok.

>Right, it should be removed.  And given some other comments made 
>within the WG, we'll be revisiting the example before it goes to the IESG.

Please note that the review is semi-formal.  The Application Area 
Directors may or may not agree with me about the issues identified in 
the review.

Regards,
S. Moonesamy