Re: [dmarc-ietf] ARC RFC status to target

2017-07-11 Thread Murray S. Kucherawy
On Tue, Jul 11, 2017 at 8:39 AM, Kurt Andersen (b) wrote: > Regarding timelines, I think that we can have wishes and hopes, but, since > we will now be holding our seventh(!) interop event during the IETF99 > hackathon, I don't expect that "months" is even the right scale upon which > to base our

Re: [dmarc-ietf] ARC RFC status to target

2017-07-11 Thread Kurt Andersen (b)
On Sat, Jul 8, 2017 at 11:45 AM, Dave Crocker wrote: > On 7/8/2017 11:24 AM, Murray S. Kucherawy wrote: > >> . . . if it's more important to get an RFC published than it is to wait >> for some modicum of deployed maturity -- which will take months, at least, >> I would guess -- then Experimental

Re: [dmarc-ietf] ARC RFC status to target

2017-07-10 Thread John Levine
In article , Murray S. Kucherawy wrote: >I think at the time DKIM went to Proposed Standard, one could've made the >same argument about it as well, especially on your last two points. Sorta kinda. At that point there wasn't any question that people would use it to tie messages to domain names,

Re: [dmarc-ietf] ARC RFC status to target

2017-07-09 Thread Alexey Melnikov
> On 7 Jul 2017, at 20:50, Steven M Jones wrote: > > Perhaps the criteria would be included in the RFC, and the review would > be added to the WG's work items? I'm not sure how it's usually done... > Do Experimental RFCs ever get expiration dates as a forcing function, > the way Internet Drafts

Re: [dmarc-ietf] ARC RFC status to target

2017-07-08 Thread Dave Crocker
On 7/8/2017 11:24 AM, Murray S. Kucherawy wrote: There's interest verging on anxiety to get this deployed, and thus there are both private and public implementations of it that are relatively stable (modulo some open questions about the draft content). It won't be long before we're able to gat

Re: [dmarc-ietf] ARC RFC status to target

2017-07-08 Thread Murray S. Kucherawy
On Sat, Jul 8, 2017 at 10:55 AM, Dave Crocker wrote: > 2. The mechanics of cascading signatures that ARC does /is/ unusual > and possibly unique. I believe the only operationally established exemplar > in this space is the X.509 cert signature hierarchy. However it is an > relatively static,

Re: [dmarc-ietf] ARC RFC status to target

2017-07-08 Thread Dave Crocker
On 7/7/2017 11:05 PM, Murray S. Kucherawy wrote: On Fri, Jul 7, 2017 at 11:09 AM, Dave Crocker > wrote: Having intermediaries signing thing and having receivers base delivery and labeling decisions on those signatures is new and, I think, significantly diffe

Re: [dmarc-ietf] ARC RFC status to target

2017-07-08 Thread Dave Crocker
On 7/7/2017 11:05 PM, Murray S. Kucherawy wrote: On Fri, Jul 7, 2017 at 11:09 AM, Dave Crocker > wrote: Having intermediaries signing thing and having receivers base delivery and labeling decisions on those signatures is new and, I think, significantly diffe

Re: [dmarc-ietf] ARC RFC status to target

2017-07-07 Thread Murray S. Kucherawy
On Fri, Jul 7, 2017 at 11:09 AM, Dave Crocker wrote: > I've come to believe that it makes more sense, at this stage, to seek a > status of Experimental. That's not meant as a criticism of the work, but > rather to accurately reflect the current understanding of ARC dynamics. > > Having intermedi

Re: [dmarc-ietf] ARC RFC status to target

2017-07-07 Thread Murray S. Kucherawy
On Fri, Jul 7, 2017 at 12:50 PM, Steven M Jones wrote: > I may be misreading your response, but I wasn't suggesting a timeline > without criteria. I would hope to see criteria and a provisional > timeline for when to apply them. "A, B, and C will be tracked and > evaluated at IETF 101, next move

Re: [dmarc-ietf] ARC RFC status to target

2017-07-07 Thread Murray S. Kucherawy
On Fri, Jul 7, 2017 at 11:29 AM, Andrew Sullivan wrote: > I always feel like experimental status ought to come with some > description of what success or failure would mean and how that would > be determined. I think that is aligned with (but not entailed by) > https://www.ietf.org/iesg/informat

Re: [dmarc-ietf] ARC RFC status to target

2017-07-07 Thread Scott Kitterman
On Friday, July 07, 2017 03:12:51 PM Andrew Sullivan wrote: > On Fri, Jul 07, 2017 at 11:57:36AM -0700, Steven M Jones wrote: > > Would there be a proposed schedule for that evaluation to take place? I > > don't so much disagree with the description of how Experimental status > > /should/ work, and

Re: [dmarc-ietf] ARC RFC status to target

2017-07-07 Thread Steven M Jones
On 07/07/2017 12:12, Andrew Sullivan wrote: > On Fri, Jul 07, 2017 at 11:57:36AM -0700, Steven M Jones wrote: >> Would there be a proposed schedule for that evaluation to take place? > It's a good question, but I have two responses: > > 1. IETF timelines are worth approximately what one pays for t

Re: [dmarc-ietf] ARC RFC status to target

2017-07-07 Thread Andrew Sullivan
On Fri, Jul 07, 2017 at 11:57:36AM -0700, Steven M Jones wrote: > Would there be a proposed schedule for that evaluation to take place? I > don't so much disagree with the description of how Experimental status > /should/ work, and including evaluation criteria would make sense. But > I'm not thril

Re: [dmarc-ietf] ARC RFC status to target

2017-07-07 Thread Steven M Jones
On 7/7/17 11:29 AM, Andrew Sullivan wrote: > On Fri, Jul 07, 2017 at 11:09:41AM -0700, Dave Crocker wrote: >> Experimental status is exactly for this purpose. > I always feel like experimental status ought to come with some > description of what success or failure would mean and how that would > be

Re: [dmarc-ietf] ARC RFC status to target

2017-07-07 Thread Andrew Sullivan
On Fri, Jul 07, 2017 at 11:09:41AM -0700, Dave Crocker wrote: > > Experimental status is exactly for this purpose. > > Thoughts? I always feel like experimental status ought to come with some description of what success or failure would mean and how that would be determined. I think that is ali

[dmarc-ietf] ARC RFC status to target

2017-07-07 Thread Dave Crocker
G'day. Noting the considerable efforts and progress on ARC specification, implementation and testing, I've given some though to the status that makes sense for the RFC that will result. The obvious assumption is Proposed Standard. I've come to believe that it makes more sense, at this stage