Re: [Gen-art] Gen-ART last call review of draft-ietf-marf-authfailure-report-07

[Alexey Melnikov <[e-mail]>]

On 01/01/2012 20:57, Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: Alexey Melnikov [mailto:[e-mail]]
>> Sent: Sunday, January 01, 2012 12:30 PM
>> To: Hilda L. Fontana; Murray S. Kucherawy; Pete Resnick
>> Cc: [e-mail]; The IESG
>> Subject: Gen-ART last call review of draft-ietf-marf-authfailure-
>> report-07
> Hi Alexey,
Hi Murray,
>
>> Major issues:
>>
>> I understand that this is a bit pedantic, but ID-nits reports the
>> following:
>>
>>     ** Downref: Normative reference to an Experimental RFC: RFC 4408
>> (ref.
>>        'SPF')
>>
>> and this was not called out during the IETF LC announcement.
>> This reference is truly Normative, so just making it Informative
>> wouldn't work.
> Yep, this was pointed out by someone else too.  I missed it during my shepherd write-up.  It's been moved to the 1/19 telechat, partly because we'll probably need a second LC to handle this properly.
Yep.
>> Minor issues:
>>
>> 1. Introduction
>>
>> [ARF] defines a message format for sending reports of abuse in the
>> messaging infrastructure, with an eye towards automating both the
>> generation and consumption of those reports. There is now also a desire
>> to extend the ARF format to include reporting of messages that fail to
>> authenticate using known authentication methods, as these are sometimes
>> evidence of abuse that can be detected and reported through automated
>> means. The same mechanism can be used to convey forensic information
>> about the specific reason the authentication method failed. Thus, this
>> memo presents such extensions to the Abuse Reporting Format to allow
>> for detailed reporting of message authentication method failures.
>>
>> Maybe that is just me, but when I read "message authentication" I don't
>> really have a clue what you are talking about. I needed to read the
>> rest of the document in order to understand its scope.
> Rather than adding a paragraph or two about what message authentication is, would it be sufficient to add references to the SPF and DKIM specifications, and perhaps the DKIM Threats document, to the second sentence above (a la "such as...")?
That would be fine.
(I originally was asking myself if TLS and SASL authentication was in 
scope, but it is clearly isn't.)
> I'm weary of adding text that repeats what's stated elsewhere and would prefer we just add some references to appropriate reading.
>
>> 2.2. Base 64
>>
>> base64 is defined in [MIME].
I forgot to mention: It might be worth referencing the base64 RFC instead.

  [...]