Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-terminology-02.txt

["Joe Abley" <[e-mail]>]

Hi Paul,

On 15 Jun 2015, at 14:49, Paul Hoffman wrote:

> This message, and some of the earlier in this discussion, says in 
> essence "RFC Foo says the definition of X is Y, but that's wrong". At 
> the beginning of this process, we decided that we should use 
> definitions from the RFCs where possible instead of making up our own. 
> That was a good way to get this document out in a reasonable amount of 
> time.
>
> The authors of the WG document have also floated the idea that there 
> should be a -bis RFC to come later to deal with the important terms 
> for which we cannot get consensus. At this point, I think we should 
> also assume that the -bis document will formally update a bunch of 
> RFCs and say "RFC Foo says the definition of X is Y, but this document 
> updates RFC Foo to say that the definition of X is Z".

Quoted entirely to confirm that I have read them. :-)

>> I think that "superordinate" and "subordinate" might be worth 
>> mentioning here, with reference to their definitions in EPP.
>
> These seem limited to the EPP RFCs only, so probably not worth 
> bringing up here.

Well, there's a whole section on registration that also makes sole 
reference to those RFCs, no? If we're at least tipping the hat towards 
the intersection between RRR and DNS, they seem useful (and easy) to 
include.

>> "Name Error" as a synonym for NXDOMAIN seems like it is worth 
>> including, somewhere.
>
> Are you sure that "name error" always refers to NXDOMAIN? If not, this 
> is not a can of worms we should open.

I was sure until you asked that question. I can do some more research 
and justify my opinion or change my mind, but it might be quicker just 
to wait for Mark Andrews to wake up. :-)

>> 4. Resource Records
>>
>> The negative cache TTL is alluded to under SOA field names, but not 
>> under TTL. The former also claims a definition of MINIMUM of "the TTL 
>> to be used for negative responses", when in fact the TTL to be used 
>> for negative responses is the MINIMUM value or the TTL of the SOA RR 
>> returned with the negative response, whichever is the smaller. This 
>> fact may be familiar to Secure64 and Afilias people :-)
>
> If you want to update RFC 2308, you need to do so separately from this 
> document. (Note to Mark and Joe: if you want to argue about this, 
> please change the name of the thread, since we are not going to make 
> that change in this document.)

RFC 2308 section 3 says exactly:

    Name servers authoritative for a zone MUST include the SOA record of
    the zone in the authority section of the response when reporting an
    NXDOMAIN or indicating that no data of the requested type exists.
    This is required so that the response may be cached.  The TTL of 
this
    record is set from the minimum of the MINIMUM field of the SOA 
record
    and the TTL of the SOA itself, and indicates how long a resolver may
    cache the negative answer.

So I don't think I'm asking for a change to 2308, rather that this 
document not contradict 2308.

>> There is no mention of "authority-only servers", which I find to be 
>> in common usage.
>
> That term appears in exactly one RFC, of which you are co-author.

But Paul, I am the voice of the people! The people must be heard!

>> I wonder what the real difference is between "stealth server" and 
>> "hidden master". If they are synonyms (I think they are) it might be 
>> as well to say so; as it stands they both have the appearance of 
>> having different definitions.
>
> The two definitions from the RFCs do not make them seem like synonyms 
> to me. In one, it is a slave, and in the other it is a master.

We ought to note somewhere that servers can easily both slaves and 
masters for the same zone, simultaneously. I often refer to such servers 
as "distribution masters", but only really as a convenience when 
describing a particular platform where the zone distribution graph is 
simple.

In any case, in both cases in this doc they are authoritative servers 
for a set of zones, and do not appear in those zones' NS RRSets (either 
at the zone apex or in the parent). It seems troublesome to me that it's 
trivial to find a production server that could fit either or both of 
those definitions.

But perhaps this is all fine, as you say, and something to be addressed 
in -bis.

>> In zone cut, I'm not sure what "barely an ostensive definition" is 
>> intended to convey. Are you saying that this is not a definition that 
>> is made by way of demonstration, or that it is, or that it should be, 
>> or something else?
>
> The former.

OK. I guess the main reason for the question was rhetorical; if it's not 
obvious what it means, perhaps "ostensive" could be replaced with a 
merely $1 word in the interests of clarity.

>> 7. Registration Model
>>
>> This whole section talks about "registration of names in a zone", 
>> which I think encourages a kind of conflation between database and 
>> DNS operations that keeps cropping up and always causes headaches.
>>
>> The RRR (or RR or RRRR, with a reseller layer, even) structure exists 
>> to maintain uniqueness in a database. Information present in that 
>> database is used to publish one or more zones in the DNS, but the 
>> interactions between the Rs are better characterised in database 
>> terms than DNS terms.
>
> Without specific proposed text, we can't fix this in this round.

I will see what I can do to propose something, then.

>> "NSEC3": whether not NSEC3 is "quite different" from NSEC depends on 
>> your context. Functionally, in the narrow sense of "allows verifiable 
>> denial of existence", they are identical. I think it would be clearer 
>> to focus on their functional similarities, and point out the 
>> additional features of NSEC3 (opt-out and making zone enumeration 
>> harder), observing that any particular signed zone must use exactly 
>> one of these, not both (so, they are alternatives, and one of them is 
>> required).
>
> Disagree. Even in the "allows verifiable denial of existence", they 
> are quite different in that the processing needed is very different. 
> The "fundamental similarities" are only in what is achieve, not in the 
> way of achieving it.

Perhaps we could agree on some text that confirms that they are 
functionally similar, whilst having quite different approaches to 
achieving that functionality? That seems like it would be better than 
declaring them to be "quite different".


Joe