[DNSOP] review of draft-ietf-dnsop-as112-ops-01

[Andrew Sullivan <[e-mail]>]

Dear colleagues,

In Philadelphia, I volunteered to review
draft-ietf-dnsop-as112-ops-01.  This is that review.

General:

I have read the draft.  I think it is a sensible draft that
documents an important part of the DNS infrastructure.  I think it is
well-written and clear.  I have not been personally involved with the
operation of an AS112 node (other than, in a previous position,
saying, "Yes, that seems like a good idea to me," which hardly
qualifies), so I cannot confirm that the document is correct in all
its details.  That said, it looked reasonable to me, and I worked out
what to do to implement this "on paper", and didn't notice any gaps.

I have some particular observations, below.  None of them strikes me
as an important objection.  Other than those remarks, I think this
draft is ready to go.

Abstract:

"Examples are the addresses designated in RFC1918 for private use
within individual sites."  I might change this to, "Examples include."

Section 1:

As in the Abstract.

Also, while I was working on another document, a reviewer pointed out
to me that the term "reverse DNS query" could be misinterpreted to be
referring to IQUERY operations.  That approach is formally deprecated
in RFC3425.  I therefore suggest changing

   Devices in such environments may occasionally originate reverse DNS
   queries [RFC1034] corresponding to those private-use addresses.

to

   Devices in such environments may occasionally originate DNS queries
   forFrom [e-mail]  Mon Mar 31 09:44:25 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id B6B0A28C142;
	Mon, 31 Mar 2008 09:44:25 -0700 (PDT)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id D66B328C142
	for <[e-mail]>; Mon, 31 Mar 2008 09:44:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.735
X-Spam-Level: 
X-Spam-Status: No, score=-1.735 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553,
	HOST_MISMATCH_NET=0.311]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id IJo-S7DO2avb for <[e-mail]>;
	Mon, 31 Mar 2008 09:44:24 -0700 (PDT)
Received: from lists.commandprompt.com (host-159.commandprompt.net
	[207.173.203.159])
	by core3.amsl.com (Postfix) with ESMTP id F3BB528C134
	for <[e-mail]>; Mon, 31 Mar 2008 09:44:23 -0700 (PDT)
Received: from commandprompt.com (227-54-222-209.mycybernet.net
	[209.222.54.227]) (authenticated bits=0)
	by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m2VGipKn022527
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <[e-mail]>; Mon, 31 Mar 2008 09:44:53 -0700
Date: Mon, 31 Mar 2008 12:44:16 -0400
From: Andrew Sullivan <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.17 (2007-11-01)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0
	(lists.commandprompt.com [207.173.203.159]);
	Mon, 31 Mar 2008 09:44:54 -0700 (PDT)
Subject: [DNSOP] review of draft-ietf-dnsop-as112-ops-01
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dnsop>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:[e-mail]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]

Dear colleagues,

In Philadelphia, I volunteered to review
draft-ietf-dnsop-as112-ops-01.  This is that review.

General:

I have read the draft.  I think it is a sensible draft that
documents an important part of the DNS infrastructure.  I think it is
well-written and clear.  I have not been personally involved with the
operation of an AS112 node (other than, in a previous position,
saying, "Yes, that seems like a good idea to me," which hardly
qualifies), so I cannot confirm that the document is correct in all
its details.  That said, it looked reasonable to me, and I worked out
what to do to implement this "on paper", and didn't notice any gaps.

I have some particular observations, below.  None of them strikes me
as an important objection.  Other than those remarks, I think this
draft is ready to go.

Abstract:

"Examples are the addresses designated in RFC1918 for private use
within individual sites."  I might change this to, "Examples include."

Section 1:

As in the Abstract.

Also, while I was working on another document, a reviewer pointed out
to me that the term "reverse DNS query" could be misinterpreted to be
referring to IQUERY operations.  That approach is formally deprecated
in RFC3425.  I therefore suggest changing

   Devices in such environments may occasionally originate reverse DNS
   queries [RFC1034] corresponding to those private-use addresses.

to

   Devices in such environments may occasionally originate DNS queries
   for reverse map entries [RFC1034] corresponding to those
   private-use addresses.

or something similar (I'm sure those better with English prose than I
will be able to make the above more elegant).  I'm not sure whether
that reference to [RFC1034] is needed in this formulation, but it may be.

Section 2.1: 

Would there be any benefit to creating a registry for the zones that
should be covered by AS112?  I assume not, because the reservation of
the address blocks in question is already well-defined; but I thought
I'd ask anyway.

Section 3.3:

   A host which is configured to act as an AS112 anycast node should be
   dedicated to that purpose, and should not be used to simultaneously
   provide other services.

Is that intending to suggest restrictions on the host strictly
speaking (which is how it reads now to me); is it really intending to
say, "Don't run other zones using the same DNS server"?  A sentence on
what problem using a dedicated box solves (I think I know, but I want
to be sure) might be helpful.

Section 3.5:

   Although the queries received by AS112 nodes are definitively
   misdirected [. . .]

Should that be "definitely", or something else?  I'm not sure what the
"definitively" is for there.  (You could leave it out, in fact.)

Section 6:

I recall some previous discussion about whether a document is needed
that specifies the ways where some future requirement to serve other
zones might be satisfied.  I recall for certain that it was ruled out
of scope for this draft (and I agree).  What I cannot recall is
whether there was any promise of such a draft, and a reference from
this document; or whether the plan was instead just to be silent on
it.  

I do worry slightly that the text, "Such changes would be widely
announced in operational forums, and published at
<http://www.as112.net/>," amounts to a commitment on the part of the
authors about how such a change would in fact be managed (and I'm not
sure anyone's in a position to make such a commitment).  I wonder if
perhaps the "would" in that sentence ought instead to be "should" or
"ought to be" or something like that.

Best regards,

A
-- 
Andrew Sullivan
[e-mail]
[phone] x104
http://www.commandprompt.com/
_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop


 reverse map entries [RFC1034] corresponding to those
   private-use addresses.

or something similar (I'm sure those better with English prose than I
will be able to make the above more elegant).  I'm not sure whether
that reference to [RFC1034] is needed in this formulation, but it may be.

Section 2.1: 

Would there be any benefit to creating a registry for the zones that
should be covered by AS112?  I assume not, because the reservation of
the address blocks in question is already well-defined; but I thought
I'd ask anyway.

Section 3.3:

   A host which is configured to act as an AS112 anycast node should be
   dedicated to that purpose, and should not be used to simultaneously
   provide other services.

Is that intending to suggest restrictions on the host strictly
speaking (which is how it reads now to me); is it really intending to
say, "Don't run other zones using the same DNS server"?  A sentence on
what problem using a dedicated box solves (I think I know, but I want
to be sure) might be helpful.

Section 3.5:

   Although the queries received by AS112 nodes are definitively
   misdirected [. . .]

Should that be "definitely", or something else?  I'm not sure what the
"definitively" is for there.  (You could leave it out, in fact.)

Section 6:

I recall some previous discussion about whether a document is needed
that specifies the ways where some future requirement to serve other
zones might be satisfied.  I recall for certain that it was ruled out
of scope for this draft (and I agree).  What I cannot recall is
whether there was any promise of such a draft, and a reference from
this document; or whether the plan was instead just to be silent on
it.  

I do worry slightly that the text, "Such changes would be widely
announced in operational forums, and published at
<http://www.as112.net/>," amounts to a commitment on the part of the
authors about how such a change would in fact be managed (and I'm not
sure anyone's in a position to make such a commitment).  I wonder if
perhaps the "would" in that sentence ought instead to be "should" or
"ought to be" or something like that.

Best regards,

A
-- 
Andrew Sullivan
[e-mail]
[phone] x104
http://www.commandprompt.com/
_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop