ietf-mxcomp
[Top] [All Lists]

RE: consensus call of RR prefix

2004-09-03 21:24:06

-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Andrew 
Newton
Sent: Friday, September 03, 2004 5:32 PM
To: IETF MARID WG
Subject: consensus call of RR prefix



 From the discussion on prefixes for the DNS record, there seems to have
been no discernible outcome regarding the use of prefixes for the
purposes of avoiding collisions with other DNS records (thus avoiding
fallback to DNS over TCP).

Naturally, this issue wraps itself into both the versioning/scoping
issue and the wildcard issue.  Based on the comments received so far,
it is the opinion of the co-chairs that there is no consensus on how to
handle wildcards and that most participants seem to agree that
wildcards present a problem no matter the solution.  Based on the
comments received so far, it is the opinion of the co-chairs that there
is consensus on placing the "scope" in the RDATA of the record and no
consensus on the scope being in the prefix.

Therefore, that leaves one under-discussed question: should a prefix be
used to avoid collision with other records as one measure of preventing
the requirement of DNS over TCP?

Incidentally, the co-chairs note that many examples of the prefix have
used "-marid".  We would note that "MARID" is the name of this working
group and likely not meaningful beyond the context of discussions and
process of this working group.  Therefore we recommend a more
meaningful label such as "_rmx": the deduction of its meaning is easier
and it references the genesis of the MARID idea.

-your co-chairs

One possibly small point with respect to deployment in this area...

At least some (and I understand it to be many) DNS providers do not
currently allow underscore characters.  Even if other issues that might
prevent my deployment of Sender-ID records are resolved, I would currently
be unable to publish records if they are prefixed with an underscore due to
such limitations.

Scott Kitterman