Subject: Re: draft-ietf-dnsext-apl-rr-01.txt

From: Peter Koch <[email-masked]>
Date: Sat, 11 Nov 2000 17:59:59 +0100

Thank you, Thomas, for the comments and apologies for the late response. I
must have missed the original posting.

> >    The specification of particular application scenarios is out of the
> >    scope of this document.
> 
> I.e, this ID defines an RR for which no usage has been specified, and
> for which in the future, multiple incompatable usages might be
> specified.

This ID defines an RR which is a syntactic framework for multiple uses, some
of which are outlined in the document. Of course `incompatible usages' *might*
be specified, but that is of course not intended and could as well happen to
any other of the already existing RR types. The A and PTR RR types already bear
different meanings in different contexts (RFC 1101) without leading to
significant trouble.

> It seems to me that the semantics of an RR should be well-defined and
> uniformly interpreted by clients. If they are not, one runs the risk
> that different clients will query for the same RR (but for different
> reasons) and get unexpected results. This is particularly true if two

I agree with you if 'client' in your statement means what is called
'application scenario' in the document, but I do not yet see this principle
violated by the ID.

> result. Thus, even in cases where the raw format of an RR might be
> correct for multiple different uses, it might be better to define
> multiple different RRs each having the same syntax, but (possibly)
> different semantics and (possibly) different uses.

Another example of a multi-usage RR type is the SRV RR. It has a fixed syntax
but different meanings depending on the service name which is made part of
the owner name queried for. 

> I note that semantics/usage of the Negation Flag is explicitely not
> defined in this document, so the RR seems underspecified.

Section 7, Applicability Statement, explicitly calls for a specification
of the exact semantics of the "!" character, so this part of the specification
is intentionally deferred. The in-zone and on-the-wire representation of this
flag should be clear from the ID and I'd appreciate any hint should something
still be wrong with that.

> As an example, consider TXT records. You can put lots of things in
> them, but many consider it bad form to do so precisely because the TXT
> RR one gets back may have nothing to do with the usage the client is
> expecting.

No DNS zone file maintainer is expected to start using APL RRs based on
this ID alone. Maybe the document should emphasize this, although the text
you quoted should exactly do that. The TXT RR case is different, because
the specification more or less said "do with it whatever you like", while
the ID doesn't.

> 1) This document should be published at all, without a specific usage
>    associated with it for the reasons discussed above.

The intent was to decouple the RR application specification from the syntax
specification (somehow similar to SRV), because different applications
(e.g. AXFR control and CIDR block documentation, see section 8) may or may
not evolve differently and I still think it eases the process if they are
not tied together more than necessary.
You cannot build any application with this ID alone, but support for the
APL RR can be built into DNS software with this specification, which is
a base requirement for those applications to work.

> 2) Even if the document is published, making it a PS seems wrong,
>    without a specific usage documented along with it that clearly
>    defines the semantics and intended usage.

The standards track was chosen to give any application scenario making use of
the APL RR to be standards track itself - having the SRV experience in mind.
Does the IESG prefer 'experimental'?

> >    The RDATA section consists of zero or more strings (<apstring>) of
> >    the form
> 
> Is the "string" description correct? The RDATA actually consists if
> fixed length fields such as a prefix, a bit, etc.

The word "string" here originates from the textual representation, which
consists of multiple strings of the form e.g. "1:127.0.0.1/32". It may not
be the best choice in the RDATA context, but the I tried to avoid the
word "record", which is probably more appropriate. Comments?

> >   ftp://ftp.iana.org/in-notes/iana/assignments/address-family-numbers.
> 
> The IANA requests that all references to numbers be via:
> 
> http://www.iana.org/numbers.html

Thanks for that URL. This particular part of the document already has some
history, including IANA contact, so I'll again change this ``moving target''.

-Peter

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Paul Vixie <[email-masked]>
Date: 11 Nov 2000 20:36:45 -0800

>> for which in the future, multiple incompatable usages might be

well, i'll say that i have a widely deployed application which depends on
being able to enforce AXFR access control in slaves, using an access control
list which can be dynamically changed by the zone owner.  speaking as an
implementor (bind8 isn't YET fully irrelevant, i think), i can say that i'll
be adding this functionality in the near term, and i'd much rather do it
using APL RR's than TXT RR's.  (either way i'll try to get it to be an
approved standard rather than a local hack, of course.  but APL is cleaner.)

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 12 Nov 2000 23:04:22 +0100

>Does the IESG prefer 'experimental'?

I am not on the IESG now, so can't speak authoritatively, but the IESG of 
my day preferred to have experiments labelled "experimental".

The SRV experience (apart from the problem of the delay) actually proved 
benefical in this case - the spec was changed based on experience.

Of course, if there is an application ready to go standards track that 
depends on this spec, standards track is the only way to go.

           Harald

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]