While John Levine cited the benefits of the "experimental" approach
taken for EAI
(https://mailarchive.ietf.org/arch/msg/dmarc/gvUecJuYLT9GIh5zbcZ_U9CgNkw),
I'm also biased by the "let's all just play nice" mess that came from
designating incompatible "versions" of SPF as competing experiments (see
https://tools.ietf.org/html/rfc6686 for the eventual outcome of that six
year long experiment).
I think that any protocol which has not already been widely implemented
is, in some sense, experimental - if you are looking at it from the
perspective of hind-sight, you might have done some things
differently/more efficiently/etc. One might not have called IPv6
"IP"-anything or may have chosen a longer address space for IPv4 for
instance.
Both of the above examples demonstrate a corrupted use of the term,
pretty much rendering it useless. Such a rendering does not seem very
helpful to the community, not does it reflect the intent of the label.
Here's some text that I think points in a more constructive direction:
https://www.ietf.org/iesg/informational-vs-experimental.html
"If the IETF may publish something based on this on the standards
track once we know how well this one works, it's Experimental."
There have been some very specific descriptions of focused concern for
fragility and interactions about ARC. Those are what justify
Experimental. There needs to be explicit documentation of those
concerns and suggestions for measuring ARC performance to assess the
field experiences with regard to those concerns.
I offered examples of these earlier:
ARC Experimental goals
https://www.ietf.org/mail-archive/web/dmarc/current/msg03812.html
In an earlier note, I also noted:
ARC RFC status to target
https://www.ietf.org/mail-archive/web/dmarc/current/msg03707.html
"Having intermediaries signing thing and having receivers base
delivery and labeling decisions on those signatures is new and, I think,
significantly different that doing that for SPF or DKIM. Who should sign
and when isn't yet well understood. How those signatures should get
evaluated by receiving filtering engines also is not yet well-understood."
Re: [dmarc-ietf] ARC RFC status to target
"From that perspective, I suspect a good target for marking
readiness for standardization is the ability of the community to produce
an experience-based BCP about ARC Use."
ARC RFC status to target
https://www.ietf.org/mail-archive/web/dmarc/current/msg03730.html
Re: [dmarc-ietf] Question for Thursday's meeting consideration:
extending DMARC DNS record to cover ARC
https://www.ietf.org/mail-archive/web/dmarc/current/msg03789.html
"ARC is an underlying authentication mechanism that calls for a
new assessment mechanism, since the role of the authenticated entity is
different than the entities currently being assessed by filtering engines. "
So...
These were offered to explain the significant reasons this specification
is not likely to be well-understood at initial deployment but is likely
to raise significant operational challenges. And they offered a basis
for evaluating initial use, to determine efficacy.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
