Re: [dmarc-ietf] Additional review of draft-ietf-dmarc-arc-protocol-16

[Seth Blank <[e-mail]>]

As stated previously, I've made all stated changes, with the exception of
the below, for further discussion:

On Thu, Aug 2, 2018 at 6:43 AM, Dave Crocker <[e-mail]> wrote:

> 4.  Protocol Elements
>>
>
>
> I keep thinking that it would help to have some summary text, possibly
> with a figure, that shows the role of individual header fields and sets of
> them.
>
> My first inclination is to suggest putting it here, but perhaps it would
> actually be better to have it at the /end/ of this section, after each
> component has been defined.
>
> (I'd offer some candidate text/figure, but I am not sure I have a solid
> enough sense of the details.)
>


This is a good suggestion, but form is unclear. Any guidance from the
working group would be appreciated.



>    To preserve the ability to verify the integrity of a message, the
>>
>    signature of the AMS header field SHOULD include any DKIM-Signature
>>    header fields already present in the message.
>>
>
> Arguably, including it/them does NOT alter integrity validation. i suspect
> /ever/.  At the least, be explicit about /what/ integrity is being maintain.
>
> That is, the dkim signature provides a specific kind of integrity.  If it
> validates, that integrity is proved.  If it doesn't, it isn't. covering it
> by ARC doesn't affect either outcome.
>

This feels more like guidance than a requirement for interoperability.
Should it be moved into ARC-USAGE, or further clarified the way suggested?



>    _INFORMATIONAL:_ The upper limit of 50 was picked based on some
>
>    initial observations reported by early working group members with a
>>    safety margin multiple added on top to support the vast majority of
>>    all intermediary mail flows.
>>
>
> Rather than citing a wg process, document the technical, administrative
> and/or operation concerns, benefits, etc. that justify the choice.
>

I think this is OK for an Experimental draft, especially with the callout
in 11.3.2. For standards track clarification will be essential.



>    Valid ARC Sets MUST have exactly one instance of each ARC Header
>>    field (AAR, AMS, and AS) for a given instance value and signing
>>    algorithm.
>>
>>    _INFORMATIONAL:_ Initial development of ARC is only being done with a
>>    single allowed signing algorithm, but parallel work in the DCRUP
>>    working group is expanding that.  For handling multiple signing
>>    algorithms, see [ARC-MULTI].
>>
>
> As a rule, RFCs should not refer to parallel activities, since the
> reference is soon to become stale and wrong.
>
> If additional signing algorithms are anticipated -- and of course they
> should be -- then define a means for extending what is permitted, noting
> that the initial algorithm is provided to ensure basic, initial
> interoperability.
>

Understood. Earlier consensus was that this is fine for the experiment (as
algorithm rotation is irrelevant if the experiment fails), and that
requirements for rotation would be part of a final standards track document.

Should these INFORMATIONAL items just be ripped out in the meantime?