Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc7001bis-05

Good point. Thanks. 

That still doesn't match the current text. 

Scott

On April 8, 2015 12:06:57 PM EDT, "t.petch" <ietfc@btconnect.com> wrote:
>----- Original Message -----
>From: "Scott Kitterman" <scott@kitterman.com>
>To: <apps-discuss@ietf.org>
>Sent: Wednesday, April 08, 2015 3:29 PM
>> On Sunday, March 29, 2015 02:43:54 PM Alexey Melnikov wrote:
>> > This message is starting 3 weeks (*) Working Group Last Calls on
>> > draft-ietf-appsawg-rfc7001bis-05 (Message Header Field for
>Indicating
>> > Message Authentication Status). The WGLC ends on
>> > April 19th.
>> >
>>
>> I've reviewed the document and believe it's essentially ready for
>publication.
>> I think there is a bit of editorial adjustment needed in the prose
>about
>> different a-r methods.
>>
>> Here's my list of A-R related RFCs:
>>
>> RFC 5451/7001 Message Header Field for Indicating Message
>Authentication
>> Status
>> RFC 5617 DKIM/ADSP
>> RFC 6008 DKIM signature identification (header.b)
>> RFC 6212 Vouch By Reference (VBR)
>> RFC 6577 Sender Policy Framework (SPF)
>> RFC 7281 Authentication-Results Registration for S/MIME
>> RFC 7293 The Require-Recipient-Valid-Since Header Field
>> RFC7489 DMARC
>>
>> Here's what the draft currently says about different methods:
>>
>>   At the time of publication of this document, the following are
>>   published, domain-level email authentication methods in common use:
>>
>>   o  Author Domain Signing Practices ([ADSP])
>>   o  SMTP Service Extension for Authentication ([AUTH])
>>   o  DomainKeys Identified Mail Signatures ([DKIM])
>>   o  Sender Policy Framework ([SPF])
>>   o  Vouch By Reference ([VBR])
>>   o  reverse IP address name validation ("iprev", defined in Section
>3)
>>
>>    In addition, the following are non-standard methods recognized by
>>    this specification that are no longer common:
>>
>>   o  DomainKeys ([DOMAINKEYS]) (Historic)
>>   o  Sender ID ([SENDERID]) (Experimental)
>>
>> I think the list misses DMARC, S/MIME and RRVS.  I also question the
>> description of ADSP and VBR as "common".  Additionally, ADSP is
>historic.
>>
>> Instead of getting into a bike shed discussion about what's common
>and
>how can
>> we tell, what about something like this:
>>
>>   At the time of publication of this document, the following are
>>   published, authentication methods:
>>
>>   o  Author Domain Signing Practices ([ADSP]) (Historic)
>>   o  Domain-based Message Authentication,  Reporting and Conformance
>([DMARC])
>>   o  DomainKeys ([DOMAINKEYS]) (Historic)
>>   o  DomainKeys Identified Mail Signatures ([DKIM])
>>   o  reverse IP address name validation ("iprev", defined in Section
>3)
>>   o  Require-Recipient-Valid-Since Header Field and SMTP Service
>Extension
>>        ([RRVS])
>>   o  SMTP Service Extension for Authentication ([AUTH])
>>   o  Sender ID ([SENDERID]) (Experimental)
>>   o  Sender Policy Framework ([SPF])
>>   o  S/MIME Signature Verification [SMIME-REG]
>>   o  Vouch By Reference ([VBR])
>>
>> None of these are marked deprecated in the registry:
>>
>> http://www.iana.org/assignments/email-auth/email-auth.xhtml
>
>Scott
>
>but if you were to look at the updated registry, as for example in the
>one I have prepared by hand (but which the IETF mailing system refuses
>to post - perhaps I  have upset the Privacy Police:-) then you will
>find
>that domainkeys and DKIM-ADSP are deprecated in the registry.
>
>Tom Petch
>
>> As a result, I don't think we should treat them differently in the
>text beyond
>> noting the status of the relevant RFC.
>>
>> Scott K
>>
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss