Re: [dmarc-ietf] I-D Action: draft-akagiri-dmarc-virtual-verification-00.txt

[ned+dmarc]

Normally I'm not a stickler for avoiding side discussion of related items 
on working lists. But this case I'm going to have to agree with Dave: This

group is not making sufficient progress on its core work, which currently
is to review and progress the ARC specifications. This needs to happen
sooner rather than later, and we cannot afford to spend time on this
specification at this time.

If and when we get that far, we can discuss whether or not this is a fit for
the third track of this WG (documentation of actual and possible operational
practices).



Ned



On 10/3/2016 9:21 AM, Takehito Akagiri wrote:
> We have updated the draft based on comments on ML when we submitted
> draft 00.  I'll show small comments about that.




I'm confused.



First, this is not a task within the working group charter, as I read
it, and I haven't seen a wg discussion to adopt it.



Second, I've seen a range of specific arguments against this work, with
only a tiny amount of support for it, and no follow-up discussion of
those arguments, nevermind accomplishing reasonable resolution of those
concerns.



All of which tells me that this activity is out of scope for this IETF
mailing list.



I encourage the chairs to chime in and either confirm or correct this
assessment.



d/



--
Dave Crocker
Brandenburg InternetWorking
bbiw.net



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] indeterminisim of ARC-Seal b= value

[ned+dmarc]

> What's the best way to proceed from here for the working group?

That's easy: The way to proceed is by describing the actual interoperability
problem that came up. In detail.

What you have done so far, AFAICT, is propose a change that at most facilities
a type of testing decades of experience have shown to have limited value.
This is a far cry from describing an actual interoperability problem.

This is, or at least is supposed to be, a technical list. Noone here is
going to be put off by complicated technical details. In  fact the absence
of such discussion was and is a major problem with the advancement of this
specification, and unless that changes fairly soon I'm going to put on my
working group chair hat and say some stuff that people are really not going
to like.

Ned



> On Fri, Mar 31, 2017 at 8:55 AM, Dave Crocker  wrote:

> > On 3/30/2017 10:41 PM, Seth Blank wrote:
> >
> >> If the consensus here is that the matter is not worth pursuing further,
> >> that is fine - I just want to make sure we're all talking about the same
> >> thing.
> >>
> >
> >
> >
> > Except that 'the matter is not worth pursuing' isn't what I heard anyone
> > saying and it definitely wasn't what I meant...
> >
> > I'm not sure whether it's been presented here sufficiently, but I believe
> > your underlying concern is based on observed problems with implementation
> > of the current ARC specification.  That is, from interoperability testing,
> > the actual use of ARC is proving far too fragile.
> >
> > If that's true, then there needs to be an effort to a) understand the
> > fragility better, and b) consider ways to make ARC more robust.
> >
> > So while there has been strong push-back against the /solution/ that you
> > proferred, I am not clear whether there is working group understanding of
> > the motivating concern or with the way to resolve it.
> >
> >
> >
> > d/
> >
> > --
> > Dave Crocker
> > Brandenburg InternetWorking
> > bbiw.net
> >
> > ___
> > dmarc mailing list
> > dmarc@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmarc
> >



> --

> [image: logo for sig file.png]

> Bringing Trust to Email

> Seth Blank | Head of Product for Open Source and Protocols
> s...@valimail.com
> +1-415-894-2724 <415-894-2724>

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc