On 2017-11-14 09:51, Daniel Margolis wrote:
> Works for me. To sum up the thread:
> 
> 1. Bunch of editorial stuff. I will try to collate the list from Jim's
> original email sometime next week and get it into a new draft. I expect
> we may have some feedback from the UTA session as well. ;)
> 
> 2. Rename "report" to "testing". Not a big deal, I agree, and a bit more
> clear. 
> 
> 3. Jim's suggested language with a SHOULD on proactive policy refresh
> and a MUST NOT on publishers expecting that to happen. 
> 
> I think that's all of it? 
> 

Yeah I think so. I think we can treat these things as WGLC comments.

Barring people speaking up on new things at the meeting tomorrow I
expect to push the IESG button on MTA-STS and TLSRPT sometime next
week or so.

        Cheers Leif

> Thanks everyone. 
> 
> 
> On Tue, Nov 14, 2017 at 6:58 AM 🔥 Nicolas Lidzborski <[email protected]
> <mailto:[email protected]>> wrote:
> 
>     On Tue, Nov 14, 2017 at 11:45 AM, Viktor Dukhovni
>     <[email protected] <mailto:[email protected]>> wrote:
> 
> 
> 
>         > On Nov 13, 2017, at 9:16 PM, Jim Fenton <[email protected] 
> <mailto:[email protected]>> wrote:
>         >
>         > I'm mixed on this. This is at the draft stage so some changes 
> should be expected. The key question that I have, and implementers will need 
> to know, is if there is any semantic difference between "report" and "none".
> 
>         There is a semantic difference:
> 
>         * With "none" no verification of the destination is expected and
>           no reports are generated on verification "failure"
> 
>     I would suggest calling this mode "disabled" for clarity.
>      
> 
>         * With "report", verification is expected, and failure reports
>           may be generated, but delivery proceeds despite failure.
> 
>     As mentioned, I would suggest renaming this mode "testing" for clarity.
>      
> 
>         The request to "report" failures is subject to the usual downgrade
>         protection (except on cold-start, loss of state at the sending MTA,
>         or too little traffic to keep the cache "warm").
> 
>     _______________________________________________
>     Uta mailing list
>     [email protected] <mailto:[email protected]>
>     https://www.ietf.org/mailman/listinfo/uta
> 
> 
> 
> _______________________________________________
> Uta mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/uta
> 

_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta

Reply via email to