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
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
