Subject: [spfbis] Obsoleting SPF RRTYPE

From: S Moonesamy <[email-masked]>
Date: Tue, 23 Apr 2013 15:03:45 -0700

Hello,

Section 13.1 of draft-ietf-spfbis-4408bis-14 obsoletes the SPF RRTYPE:

   'IANA is requested to add an annotation to the SPF RRTYPE saying
    "(OBSOLETE - use TXT)" in the DNS Parameters registry.'

Is the annotation in the DNS Parameters registry correct?

Regards,
S. Moonesamy (as document shepherd)

---

From: Stuart Gathman <[email-masked]>
Date: Wed, 24 Apr 2013 12:23:50 -0400

Long ago, Nostradamus foresaw that on 04/23/2013 06:03 PM, S Moonesamy
> Is the annotation in the DNS Parameters registry correct?
And, more importantly (to me anyway), does that still ensure that the RR
is available for any future v=spf3?  The dual publishing as a transition
may have failed, but the separate RR type is still a good idea for the
next version.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 24 Apr 2013 12:34:21 -0400

> may have failed, but the separate RR type is still a good idea for the

That will not work as the "client" will not know the format the SPF record "target" is publishing 
you need to pick one and only one option as much as I hate that SPF is using TXT that boat has sailed 
and forcing the SPF type usage will not work. 

	Olafur

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 24 Apr 2013 12:42:29 -0400

On Wednesday, April 24, 2013 12:34:21 PM Olafur Gudmundsson wrote:
> That will not work as the "client" will not know the format the SPF record
> "target" is publishing you need to pick one and only one option as much as
> I hate that SPF is using TXT that boat has sailed and forcing the SPF type
> usage will not work.

The case Stuart is concerned about is some hypothetical future incompatible 
upgrade to SPF that might use type SPF (and only type SPF) from the beginning.  
The RR type is still assigned and the DNS parameters registry could be changed 
again in the future, so if it comes up, I think the answer to Stuart's 
question is "Yes".

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Apr 2013 10:53:49 -0700

> again in the future, so if it comes up, I think the answer to Stuart's

The issue, however, is that SPFv3 might decide it wants an SPF RR that
isn't formatted like a TXT field.  That part probably can't/shouldn't be
changed.

Andrew, is there any precedent for this kind of recycling of RR types?  Do
you have any advice?

-MSK

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 24 Apr 2013 14:05:13 -0400

> Andrew, is there any precedent for this kind of recycling of RR types?  Do

If it's not formatted the same way as the old record (modulo the
version number, I guess, and any differences that arise as a result),
use a new RRTYPE.  It's just better that way.

Note that over on dnsext@ we're having a somewhat dull discussion
about whether it'd have been better for an expert reviewer to have
insisted on a single RRTYPE instead of two in a recent decision.  The
barriers to new RRTYPE assignment that happened when the SPF TXT
decision was made are not there now.  If there were an SPFv3 that
needed a significantly different format, adding a new RRTYPE would be
easy.  It'd probably be better not to revive TYPE 99 in the future,
also, for that reason.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 24 Apr 2013 14:08:11 -0400

> easy.  It'd probably be better not to revive TYPE 99 in the future,

The barriers to RR type assignment are different, but the barriers to RR type 
deployment (which in my opinion were more important for Type 99/SPF) are still 
real and substantial.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Apr 2013 11:14:51 -0700

> deployment (which in my opinion were more important for Type 99/SPF) are
Sure, but they're unchanged.

I think the only reason not to fully obsolete type 99 would be if we think
SPF3 is:

a) likely to ever appear; and

b) likely to do a TXT clone again; and

c) likely to be able to tolerate finding legacy SPFv1 records, which
undoubtedly will linger.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 24 Apr 2013 14:20:37 -0400

> c) likely to be able to tolerate finding legacy SPFv1 records, which

When we discussed this before, we concluded there was no benefit to fully 
obsoleting it since Type 99 still couldn't be reused for something else.

I've seen lots of "If we could do an incompatible update to SPF ..." 
discussions over the last 9 years and I don't recall changing the record 
structure ever coming up.  If there's a new version, I'm confident it would use 
a text clone.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Apr 2013 11:34:47 -0700

Maybe it's enough to just update the DNS record type registry to point to
the bis document as the defining document, wherein we already say "Don't
use type 99 anymore".

-MSK

On Wed, Apr 24, 2013 at 11:20 AM, Scott Kitterman <[email-masked]>wrote:

> > On Wed, Apr 24, 2013 at 11:08 AM, Scott Kitterman <[email-masked]
> >wrote:
> > > The barriers to RR type assignment are different, but the barriers to
> RR
> > > type
> > > deployment (which in my opinion were more important for Type 99/SPF)
> are
> > > still
> > > real and substantial.
> >
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
>

---

From: Commerco WebMaster <[email-masked]>
Date: Wed, 24 Apr 2013 13:01:42 -0600

> structure ever coming up.  If there's a new version, I'm confident it would use

I agree with Scott.

The TXT RRs (and SPF, until the SPFbis retired the use) for the current 
SPF includes the v=spf1 syntax.

Certainly, if the SPF/99 RR format was substantially changed in a 
future, the one thing we probably could depend upon would have to be the 
use of say, v=spf3, making what whatever follows entirely a design 
choice for the spec designers of SPFv3 at the time.

In other words, the SPF/99 RRs could change substantively or remain 
largely the same without any impact to existing v=spf1 implementations 
(and for SPFbis adopters, SPF/99 RRs should not even be used in v=spf1).

Thus, IMO retiring or depreciating the SPF/99 RR seems wasteful, as it 
certainly could be reused down the road without harm to current (albeit, 
now inappropriate as of SPFbis) implementers.

Alan M

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 24 Apr 2013 15:04:31 -0400

Sounds reasonable. Would you propose modified text please?

Scott K

On Wednesday, April 24, 2013 11:34:47 AM Murray S. Kucherawy wrote:
> > > I think the only reason not to fully obsolete type 99 would be if we
> > 
> > think
> > 
> > > SPF3 is:
> > >

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Apr 2013 12:25:04 -0700

> Sounds reasonable. Would you propose modified text please?

Replace Section 13.1 with:

Per [RFC4408], ... (as you have it now until) ...  [US-ASCII].

Studies have shown that RRTYPE 99 has not seen any substantial use, and in
fact its existence and mechanism defined in [RFC4408] has led to some
interoperability issues.  Accordingly, its use is now obsolete, and new
implementations are not to use it.

IANA is requested to update the Resource Record (RR) TYPEs registry to
indicate that this document is the reference document for that RRTYPE.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 24 Apr 2013 15:44:10 -0400

> indicate that this document is the reference document for that RRTYPE.

Thanks.  Done locally.

Scott K

---

From: Commerco WebMaster <[email-masked]>
Date: Wed, 24 Apr 2013 14:00:38 -0600

On 4/24/2013 1:25 PM, Murray S. Kucherawy wrote:
> On Wed, Apr 24, 2013 at 12:04 PM, Scott Kitterman <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Studies have shown that RRTYPE 99 has not seen any substantial use, and
> in fact its existence and mechanism defined in [RFC4408] has led to some
Could we consider this?

Studies have shown that DNS RRTYPE 99 has not enjoyed the substantial 
use seen by SPF TXT records for "v=spf1" deployment. In fact, its 
existence and mechanism as defined in [RFC4408] have led to some 
interoperability issues.  Accordingly, its use for SPF "v=spf1" records 
is now obsolete, and any new implementations of SPF "v=spf1" are not to 
consider RRTYPE 99 in processing nor use RRTYPE 99 in SPF record deployment.

IANA is requested to update the Resource Record (RR) TYPEs registry to 
indicate that this document is the reference document for that RRTYPE 
until such time any future SPF version may redefine its use.

Alan M.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 24 Apr 2013 16:04:29 -0400

> until such time any future SPF version may redefine its use.

I think that raises more questions than it answers.  I believe it's better as 
msk proposed.

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 24 Apr 2013 16:05:18 -0400

In which case, we're not deprecating the RRTYPE, just deprecating its
use.  That sounds perfectly reasonable to me.  I don't know if the
registry even gets updated.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Commerco WebMaster <[email-masked]>
Date: Wed, 24 Apr 2013 14:20:13 -0600

> I think that raises more questions than it answers.  I believe it's better as

Very well then, looks good as MSK proposed.

Alan

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Apr 2013 13:25:00 -0700

I think we should point the reference in the registry to a document that
makes it clear use is deprecated, since there's not a "status" column in
the registry to do so there.

On Wed, Apr 24, 2013 at 1:05 PM, Andrew Sullivan <[email-masked]>wrote:

> > On Wed, Apr 24, 2013 at 11:20 AM, Scott Kitterman <[email-masked]
> >wrote:
> >

---

From: S Moonesamy <[email-masked]>
Date: Wed, 24 Apr 2013 13:30:49 -0700

Hi Murray,
At 12:25 24-04-2013, Murray S. Kucherawy wrote:
>Studies have shown that RRTYPE 99 has not seen any substantial use, 
>and in fact its existence and mechanism defined in [RFC4408] has led 
>to some interoperability issues.  Accordingly, its use is now 
>obsolete, and new implementations are not to use it.

I'll nit-pick on this.  This is already mentioned in RFC 6686.

>IANA is requested to update the Resource Record (RR) TYPEs registry 
>to indicate that this document is the reference document for that RRTYPE.

draft-ietf-spfbis-4408bis-14 is unfortunately not the document which 
defines the Resource Record Type.  I suggest not doing this 
(process-wise) as I think it is better not to create legacy problems 
(in future).

I suggest removing Section 13.1.  As the process is at the moment 
unknown I suggest that anyone who would like a change to the DNS 
Parameters Registry to explain the process to do that.  Please note 
that I'll defer to advice from Andrew Sullivan or Olafur Gudmundsson 
on this matter.

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 24 Apr 2013 16:35:20 -0400

> that I'll defer to advice from Andrew Sullivan or Olafur Gudmundsson

My intent then is to leave it the way Murray suggested until we get some 
advice then.

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 24 Apr 2013 17:15:39 -0400

No hat.

Thinking about this some more, I don't think that will work.

RFC 4008 actually has a somewhat poor definition of the RRTYPE, in
that there isn't really a formal definition of the type (normally,
you'd require a wire representation).  That was fine in an
experimental document.

If we were to keep the type, then we would have needed to improve this
part of the old document and then change the IANA registry.  But since
we were planning to obsolete the type, the effect was instead that we
just needed the registry to be altered to deprecate the type and point
at the new document.

If we're now not actually going to update the registry to deprecate
the type, then we need 4408bis to contain the actual formal definition
of the SPF RR, and also still to tell people not to use it.  That
seems a little perverse.

So I think this document needs to request IANA to update the
"Reference" field of "Resource Record (RR) TYPEs" subregistry to point
to this document, and to update the "Meaning" field to say "OBSOLETE -
use TXT".  This is roughly what the currend document does.

I am not concerned about the loss of the RRTYPE.  Yes, it would be
nicer if there were an RR for this, but there isn't.

-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Apr 2013 14:17:53 -0700

> I'll nit-pick on this.  This is already mentioned in RFC 6686.

If all we do is point the IANA entry to this draft, the reference is now
ambiguous since the bis draft doesn't talk about type 99 at all except as a
bullet point in Appendix C.  A reader would be right to wonder what's going
on here.  We need to at least explain that it's a legacy allocation.

We could rely on people following the IANA entry to the obsolete document
and realizing what that means, but that seems like an incomplete solution
to me.

> defines the Resource Record Type.  I suggest not doing this (process-wise)
> as I think it is better not to create legacy problems (in future).
>
> I suggest removing Section 13.1.  As the process is at the moment unknown
> I suggest that anyone who would like a change to the DNS Parameters
> Registry to explain the process to do that.  Please note that I'll defer to
> advice from Andrew Sullivan or Olafur Gudmundsson on this matter.
>
>
I disagree.  I suggest also asking Pete or Barry since this is a
particularly strange procedural point, but also not so gnarly that it
couldn't be fixed as late as IESG Evaluation.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Apr 2013 14:19:32 -0700

> nicer if there were an RR for this, but there isn't.
I'm satisfied with that solution as well.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 24 Apr 2013 21:27:00 -0000

>RFC 4408 actually has a somewhat poor definition of the RRTYPE, in

It says in sec 3.1.1 that it's identical to TXT.  Dunno how formal
that is, but it was adequate for people to implement it and
interoperate, give or take the bugs in the query algorithm.

>use TXT".  This is roughly what the currend document does.

Seems reasonable.

R's,
John

---

From: S Moonesamy <[email-masked]>
Date: Wed, 24 Apr 2013 14:49:47 -0700

>use TXT".  This is roughly what the currend document does.

Ok, here's the suggestion after discussing with Andrew and Pete:

The entry in the Resource Record (RR) TYPEs sub-registry for SPF is 
updated; the "Meaning" will say "Obsolete, use TXT" and include a 
reference to RFC 4408 and the document.

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 24 Apr 2013 17:55:14 -0400

> reference to RFC 4408 and the document.

Would you please provide the exact change you want me to apply?

This discussion has had a lot of moving parts and I'd like to make sure I get 
it right.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Wed, 24 Apr 2013 15:29:11 -0700

Hi Scott,
>Would you please provide the exact change you want me to apply?

I suggest having the second paragraph of Section 13.1 as follows:

    IANA is requested to update the DNS Parameters sub-registry entry
    for the SPF RR TYPE with "(OBSOLETE - use TXT)" in the Meaning column
    and with "[RFC 4408][RFC XXXX]" in the References column.

    [Note to RFC Editor: Please update XXXX to this RFC number upon
     publication]

Regards,
S. Moonesamy

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 24 Apr 2013 17:05:41 -0400

No hat.

-- 
Andrew Sullivan
[email-masked]

---

From: David Conrad <[email-masked]>
Date: Wed, 24 Apr 2013 17:12:07 -0700

Hi,

> Is the annotation in the DNS Parameters registry correct?

It is in keeping with past practice, e.g., see the notations for MD, MF, A6, and the MAILA RRtypes at http://www.iana.org/assignments/dns-parameters/dns-parameters.xml.

I personally believe deprecating the SPF RR is the wrong way to go, but I'm guessing that discussion has already been had.

Regards,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Thu, 25 Apr 2013 10:28:47 +1000

In message <[email-masked]>, David Conrad
 writes:
> It is in keeping with past practice, e.g., see the notations for MD, MF, A6, 
> and the MAILA RRtypes at http://www.iana.org/assignments/dns-parameters/dns-p
> arameters.xml.
> 
> I personally believe deprecating the SPF RR is the wrong way to go, but I'm g
> uessing that discussion has already been had.
> 
> Regards,
> -drc

Personally, I agree with you.  TXT to SPF transition was always
going to be a slow transition.  libspf2 took ages to come out but
it is out now and looks for SPF records first.  Waiting less than
is single hardware deprecation cycle before stating that the
transition is not working wasn't a good faith effort.  The introduction
of MX records to 10 or more years before you could reliably have
MX only (no A records) domains.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: S Moonesamy <[email-masked]>
Date: Wed, 24 Apr 2013 21:42:03 -0700

Hi David,
At 17:12 24-04-2013, David Conrad wrote:
>It is in keeping with past practice, e.g., see the notations for MD, 
>MF, A6, and the MAILA RRtypes at 
>http://www.iana.org/assignments/dns-parameters/dns-parameters.xml.

Based on the current discussion a similar approach may be followed 
for the SPF RRTYPE.    Please note that this is in my view a IANA 
Considerations (administrative) issue.

>I personally believe deprecating the SPF RR is the wrong way to go, 
>but I'm guessing that discussion has already been had.

Yes, the thread is at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00426.html 
The results of the discussion is documented in RFC 6686.

Regards,
S. Moonesamy

---

From: Måns Nilsson <[email-masked]>
Date: Thu, 25 Apr 2013 09:51:47 +0200

> I personally believe deprecating the SPF RR is the wrong way to go, but I'm guessing that discussion has already been had.

Overloading the TXT record has always been a Really Bad Idea. I'm with
drc here. While the draft probably is formally proper, it advocates the
worng decision and I cannot support it.

OTOH, mixing up routing layer with application layer and gilding some
IP addresses in favour of others is another Really Bad Idea; I'd rather
throw the entire business of supposedly Good and Bad addresses out the
window and start looking at the in-band data instead; ie. DKIM or similar.

While removing SPF can be seen as in support of above, I'm pretty certain
that it in practice just will continue as usual, in TXT records. Better 
then that we get to keep TXT records for free-form data. 

Regards, 
-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
I want you to organize my PASTRY trays ... my TEA-TINS are gleaming in
formation like a ROW of DRUM MAJORETTES -- please don't be FURIOUS with me --

---

From: Hector Santos <[email-masked]>
Date: Thu, 25 Apr 2013 07:52:35 -0400

Is this going to cause a lost of endorsement by the DNS community folks?

I raised that question last year in SPFBIS and took it to IETF and DNSOP 
[1], and I got a good sense people still expected an RRTYPE rather than 
continue to use TXT for all these new DNS application protocols.

I felt that the migration was occurring, but slow. There was evidence of 
clients using both. I know the folks who pushed other TXT solutions, 
like DKIM, believe that it was probably OK to stick with TXT for SPF as 
well.  But that was the not the general feel I got from key DNS folks it 
was the preferred thing to do as more and more TXT solutions were being 
proposed.

I only changed my own mind about the dedicated SPF type when I found out 
as out last year, Microsoft DNS servers still hadn't supported rfc3597 
"Handling of Unknown DNS Resource Record (RR) Types" and that was the 
hope back in 2003 during MARID, that the passthru nature of servers was 
going to be available for queries.

--
HLS

[1] http://www.ietf.org/mail-archive/web/dnsop/current/msg09440.html

---

From: Douglas Otis <[email-masked]>
Date: Thu, 25 Apr 2013 02:15:23 -0700

> then that we get to keep TXT records for free-form data.

Dear Måns,

Obsoleting SPF RR is not enough.  All macros should be deprecated as well.  tools.ietf.org/html/rfc3123 predates this poorly conceived scheme.

SPF was poorly conceived starting out as 2KB TXT XML encoded resource records in DNS where many expect direct use of TXT resource records permits wildcard replication.  This scheme also expects receivers to combine email-address local-parts with SPF domains to query other resource record sets.  SPF may induce high query overheads flooding caches with up to 100 transactions derived from email-address local-parts that normally vary in spam campaigns to also support DDoS attacks leveraging receiver's attempt to verify service authorizations.
(10 mechanisms x 10 (PTRs or As or AAAAs))  Permitting PTRs can also lead to connection resource exhaustion. The macro expansion can also leverage DNS name compression to further increase network amplifications against some unseen domain while spamming entirely different domains.

The macro scheme was not intended to validate EHLOs or provide NDN authorizations and inappropriately exposes aspects of message handling.  The review of SPF use also neglects whether major providers process these macros, many whom assure they do not.  Verifying the ELHO is seldom supported, where authorization permits by bulk sender's to dodge accountability.  Without genuine domain authentication SMTP is not safe.    

A safe and effective alternative is needed to safely provide a basis for assessing and reacting to abusive behavior.  XMPP offers examples of StartTLS used in a highly scalable fashion that can leverage OCSP and self published DANE Certs needed to support IPv6.  

Regards,
Douglas Otis

---

From: Hector Santos <[email-masked]>
Date: Thu, 25 Apr 2013 11:58:00 -0400

On 4/25/2013 12:42 AM, S Moonesamy wrote:
> Based on the current discussion a similar approach may be followed for
> the SPF RRTYPE.    Please note that this is in my view a IANA
> http://www.ietf.org/mail-archive/web/spfbis/current/msg00426.html The
> results of the discussion is documented in RFC 6686.

FYI, that msg reference was Feb, 2012.  I don't recall it all, but I 
sensed that many in the DNS community believed in a status quo design 
choice - use RR TYPE and give the migration for unknown type processing 
by DNS servers more time.  I don't know if RFC 6686 properly reflected 
that idea or not.

My position was one of surprise when there was reports of clients 
actually doing SPF RRTYPE query as described in 4408. However, the 
problem was still the same one, the DNS servers still did not propagate 
unknown types (follow rfc3597 "Handling of Unknown DNS Resource Record 
(RR) Types").  To my disappointment, now even Microsoft DNS servers v5.0 
did not support rfc3597 10 years later!   That would make it nearly 
impossible to work well.

The solution to this problem was discussed here:

   [DNSOP] Batch Multiple Query Packet
   http://www.ietf.org/mail-archive/web/dnsop/current/msg09440.html

I believe SPFBIS should continue supporting its special "registered" RR 
type and then relax the REQUIREMENT to use it in BIS and keep it open 
ended for developers to watch development of future Multiple Query 
packet designs.  As you will note in the above thread, the MX record was 
a similar introduction.  But the all DNS servers on all platforms 
quickly supported that so it wasn't an WASTE issue.

I still find it surprising Microsoft DNS server v5.0 doesn't support 
RFC3597.  Why not?  What servers out there support it?

--
HLS

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Apr 2013 10:39:38 -0700

On 4/24/2013 11:14 AM, Murray S. Kucherawy wrote:
>     are still
> think SPF3 is:

Even then, retention is a bad idea.  There is no current basis for 
seeing any likelihood of utility for the RR.  None.

In the face of /massive/ market rejection for a feature, the normal and 
reasonable approach during a -bis effort is to deprecate it.

Given both the market reality of SPF deployment and common IETF revision 
practice, retention is unrealistic, counter-productive willfulness.

Worse, retention tells new implementers that they should do extra work 
that won't be useful now or in the foreseeable future.  Useless extra 
work that might create additional software and/or operations hassles.

Should the future decide to grace us with a more friendly environment 
and more significant functional benefit, which makes using an 
SPF-specific RR practical, then it will be appropriate to define it and 
pursue its adoption.

The reality is that that will have nothing to do with the current, 
vestigial SPF RR.  (Even if it winds up looking the same.)

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Apr 2013 10:43:41 -0700

> I'm satisfied with that solution as well.

The proposal seems to be for something that is simple, clear and 
pragmatic to its purpose.  I'm sure that means it is massively 
deficient, but let's do it anyway.

d/

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Apr 2013 13:24:48 -0700

> Is the annotation in the DNS Parameters registry correct?

Dear DNSEXT,

For all of the really interesting side discussions that have developed 
since SM sent this initial query, I believe there have not been any 
responses that answered the question that was asked.

DNSEXT was asked to provide expert review of this specific bit of text. 
  The text is intended to be comparable to the way that some other, 
similar situations have already been handled.

d/

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Apr 2013 13:43:51 -0700

Dear DNSEXT,

d/

---

From: David Conrad <[email-masked]>
Date: Fri, 26 Apr 2013 15:55:01 -0500

Dave,

As I pointed out to Paul Hoffman, the message I sent that I believe started this thread said:

"It is in keeping with past practice, e.g., see the notations for MD, MF, A6, and the MAILA RRtypes at http://www.iana.org/assignments/dns-parameters/dns-parameters.xml."

Regards,
-drc

On Apr 26, 2013, at 3:43 PM, Dave Crocker <[email-masked]> wrote:

> For all of the really interesting side discussions that have developed since SM sent this initial query, I believe there have not been any responses that answered the question that was asked.
> 
> DNSEXT was asked to provide expert review of this specific bit of text.  The text is intended to be comparable to the way that some other, similar situations have already been handled.
> 
> d/
> -- 
> Dave Crocker
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Apr 2013 14:03:52 -0700

On 4/26/2013 1:55 PM, David Conrad wrote:
> "It is in keeping with past practice, e.g., see the notations for MD,

ahh.  right.  thanks!

d/

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 26 Apr 2013 17:58:02 -0400

Thanks.  Having looked at that, I think that the text in the original question 
from sm is OK (modulo we don't redesign things - please keep that in a 
different subthread).

Scott K

On Friday, April 26, 2013 03:55:01 PM David Conrad wrote:
> "It is in keeping with past practice, e.g., see the notations for MD, MF,
> A6, and the MAILA RRtypes at
> http://www.iana.org/assignments/dns-parameters/dns-parameters.xml."
> 
> Regards,
> -drc
> 
> > The text is intended to be comparable to the way that some other, similar
> > situations have already been handled.
> > 
> > d/
>