Subject: Re: [apps-discuss] Last Call: <draft-ietf-appsawg-nullmx-05.txt> (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 17 Jul 2014 14:38:12 -0700

[dropping dnsop]

On Thu, Jul 17, 2014 at 1:59 PM, Dave Crocker <[email-masked]> wrote:

> > Specifically referring to Section 3 of
> > draft-ietf-appsawg-nullmx-05, there is not such thing as a "NULL
> > MX Resource Record".  There is only an MX Resource Record that
> > this specification proposes to use with a convention involving
> > specific content in the DATA.  One could call that many things,
> > but "NULL MX Resource Record" isn't one of them.
>
> By my reading of that section, it is defining the term, if only by
> virtue of the way it is used in the name of that section.
>
> Perhaps your confusion would be resolved if the term had a comma in it,
> so:  NULL, MX Record?
>
> In other words, NULL is an adjective within the term.
>
> If you would prefer a different term, please suggest one.
>

I mentioned this to one of the co-authors privately, but since you just
reminded me of it, I'll mention it here too:

The use of NULL (i.e., in all-caps) makes me think of it more as either an
acronym or a mnemonic.  For example, in C, the special pointer with address
zero is written in prose as "the null pointer", but in source code simply
as "NULL".  Since this draft is more prose than code, my sensibilities
would prefer it be written as "null" in this document rather than "NULL".
In its current form, I might expect to find a special RR type definition
for NULL MX and/or corresponding definitions in the appropriate C header
files.

This is not a major point since I'm the only one to mention it so far, but
there you have it.

-MSK

---

From: John C Klensin <[email-masked]>
Date: Thu, 17 Jul 2014 18:49:22 -0400

--On Thursday, July 17, 2014 14:38 -0700 "Murray S. Kucherawy"
<[email-masked]> wrote:

>> > draft-ietf-appsawg-nullmx-05, there is not such thing as a
>> > "NULL MX Resource Record".  There is only an MX Resource
>> > Record that this specification proposes to use with a
>> > convention involving specific content in the DATA.  One
>> > could call that many things, but "NULL MX Resource Record"
>> > isn't one of them.
>> 
>> By my reading of that section, it is defining the term, if
>> only by virtue of the way it is used in the name of that
>> section.
>> 
>> Perhaps your confusion would be resolved if the term had a
>> comma in it, so:  NULL, MX Record?
>> 

I don't want to get into grammatical hair-splitting if that can
be avoided, but the current construction names an RR type that
doesn't exist and punctuation doesn't help.  As I said, if we
didn't already have a use problem with DNS terminology, it would
be a non-issue.
 
>> If you would prefer a different term, please suggest one.

That particular problem would be easily solved by saying 

    "MX Resource Record with a null value"

or even 

    "MX Resource Record that, by convention, points at the root"

The latter is a little long for a section title, but it exactly
reflects what is going on.   I would still like a consensus
opinion from DNSOP both generally and for the specific reason
that a reasonable person might assume that a resource record
with a null value would have an empty DATA field, not one with a
value, even a value pointing informally at the root, so the
question of whether the DNS Experts find "null value"
problematic is actually important.   I can't remember whether
resource records with a zero-length DATA field are even allowed,
but we should know for certain before throwing terms like "null
value" around.  And, whether this document can, procedurally,
define "null value" as meaning something different from what it
might mean elsewhere in the DNS (were that the case) that would
be, IMO, a Really Bad Idea.

> I mentioned this to one of the co-authors privately, but since
> you just reminded me of it, I'll mention it here too:
> 
> The use of NULL (i.e., in all-caps) makes me think of it more
> as either an acronym or a mnemonic.  For example, in C, the
> special pointer with address zero is written in prose as "the
> null pointer", but in source code simply as "NULL".  Since
> this draft is more prose than code, my sensibilities would
> prefer it be written as "null" in this document rather than
> "NULL". In its current form, I might expect to find a special
> RR type definition for NULL MX and/or corresponding
> definitions in the appropriate C header files.

Yes, exactly.  That isn't, IMO, the problem, but it certainly
makes it worse (more confusing).  See above.

> This is not a major point since I'm the only one to mention it
> so far, but there you have it.

Consider it as getting an extra mention.  Ultimately, the text
should be clear whether caps are used or not, but the use of the
caps in these contexts doesn't make things any easier.

   john

---

From: Douglas Otis <[email-masked]>
Date: Sat, 19 Jul 2014 07:03:14 -0700

>    "MX Resource Record that, by convention, points at the root"

Agreed.

Null as a term is misleading since these MX record contain an a value that simply won't resolve an address because it points to root.

Although first used in defining SRV RR where:
"A Target of "." means that the service is decidedly not available at this domain."

Perhaps using the term 'nullified' as in Nullified MX record would be closer to what this is attempting to communicate.  It also seems unlikely anyone would feel a need to capitalize Nullified because it looks like a defined language variable.

If only RFC2782 said "A Target of "." means that the service has been nullified and declared not available at this domain."
Regards,
Douglas Otis

---

From: John C Klensin <[email-masked]>
Date: Sat, 19 Jul 2014 12:09:08 -0400

--On Saturday, July 19, 2014 07:03 -0700 Douglas Otis
<[email-masked]> wrote:

> Null as a term is misleading since these MX record contain an
> a value that simply won't resolve an address because it points
> to root.
> 

Trying to do fine editing on the IETF list is rarely productive
so, if this level of tuning is important (I think some of it
is), perhaps the document should be returned to the WG --with
all of the issues on the table that were apparently not raised
before Last Call-- and Last Called again when it is really
ready.  Personally, I find symptoms that choices of string,
choices of response code, details of terminology, DNS impact,
etc., were not sorted out in the WG beyond repetitions of
statements like "this has been done since 2006 and no major
issues have appeared", troubling in and of themselves.  To me,
the IETF adds value when those discussions occur both intra-area
and cross-area.   If that value isn't wanted, or isn't wanted
beyond an editorial check, I'm not sure why we should be
investing the resources.  YMMD, of course.

But, since I'm writing this note anyway, let me suggest that it
would be entirely reasonable (maybe not ideal, but reasonable)
to be very clear in the document about what is going on, perhaps
with the language I suggested and Doug likes, but then to point
out that the mechanism has been known as "null MX" or "nullMX"
for some years and that usage will undoubtedly continue.  Such a
statement could even survive a change of what goes into the DATA
field should that otherwise be desired.  If people want to refer
to this as "nullMX", that is probably no worse than an obscure
acronym or abbreviation.   It is also very different from the
term I objected to that started this because "NULL MX Resource
Record" is rather clearly DNS-incorrect and misleading.

    john