However, this group's output will be reviewed by the wider IETF
community as part of the standardization process, and there are many
people in the IETF community who feel reuse of an existing RR is an
architectural violation.
There are four factors here:
1: Can a query be generated that only returns MARID records?
2: Can a MARID record be confused with any other record type?
3: Compactness of the representation.
4; Aesthetics, we have always done it this way etc.
The SPF proposal addresses 2, CallerID with the _ep extension addresses 1 &
2.
3 appears to me to be affected more by the architecture of the proposal than
the syntax of the record.
I think that the term 'architectural violation' in this case refers mostly
to issue 4.
They also may be of the opinion that MARID
lacks the urgency or necessity to require such an architectural
violation.
That would be a politically tone deaf move. The external preception
is that the spam problem has been known about for ten years, has
been unacceptable for at least five and has only received attention
from the IETF when two competing solutions with strong external
support bases are proposed.
So, there are a couple of things this group can do:
1) Go head-to-head with DNS experts and debate their wisdom and
technical conclusions, such as the validity of the DNSSec
specification
or RFC 3597. (I strongly recommend against this!)
You can call yourself a DNSSEC expert when you get the major
registries to deploy support for DNSSEC.
At this point I don't think that anyone can call themselves a
DNSSEC expert. I think we should understand the consequences
of DNSSEC and that MARID should be compatible with DNSSEC.
But I would not accept arguments of the form 'we can rely on
features that would be required for deployment of DNSSEC,
IPv6' these have no more credibility at this point than
'this problem will be solved by X.500 deployment'.
2) Reuse an existing RR without addressing the stated
concerns and take our chances.
3) Reuse an existing RR and rationally explain our decision
against the stated concerns.
4) Define a new RR.
I hope that most find either 3 or 4 to be the proper path forward.
I agree that 3 or 4 is the best route forward.
The purpose of standards groups is not to write specs. We can
all write specs and most of us can probably get them mostly right.
The only reason I am here is to arrive at a spec that has buy in
from as many parties that can drive deployment as is possible.
There are two tactical deployment issues here:
1) Would option 3 lead to a delay due to IETF objections?
2) Would option 4 lead to a delay due to operational constraints?
Since these are both true I think the issue is whether the delay for 3 is
longer than the delay for 4?
Phill