Subject: [dnsop] as112 drafts

From: Joe Abley <[email-masked]>
Date: Wed, 19 Jul 2006 09:19:15 -0400

Hi all,

As Peter pointed out during the meeting in Montreal, the items from  
my "open issues" slide in the AS112 deck might indicate the need for  
another draft, in addition to the two drafts that were specifically  
discussed and adopted (the one for operators, and the one for  
confused users).

I'd like to propose a three-document set:

1. draft-ietf-dnsop-as112-ops-00 (substantially the same as draft- 
jabley-as112-ops-00)

2. draft-ietf-dnsop-as112-being-attacked-help-help-00 (substantially  
the same as draft-jabley-as112-being-attacked-help-help-00)

3. draft-ietf-dnsop-as112-project-00 (new work)

The -project document would include a description of the goals of the  
AS112 project and a brief history, such as is currently in -ops. It  
would also document the names of the AS112 nameservers, the anycast  
service prefix, and a list of the zones delegated from the IANA  
towards those nameservers.

This would provide us with a single reference for what AS112 is all  
about, and a single document which could be updated by future work if  
it is decided to delegate more zones to the AS112 servers. That gives  
us a process by which AS112 service can be redefined in the future.

The overlapping text from -ops and -being-attacked-help-help would be  
replaced with a reference to -project.

Most of the text for this new document is already written (just  
spread amongst the other two drafts) and William and I are happy to  
edit it.

Is the working group amenable to this approach?

Joe
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Dean Anderson <[email-masked]>
Date: Wed, 19 Jul 2006 11:12:10 -0400 (EDT)

Why have AS112 at all? 

Why not just put in delegations to NS 127.0.0.1 for the .local and local
in-addr zones?  This info would also be cached locally and remove
traffic from root nameservers.  On most nameservers, this also creates
an error (recursion to self), which shows up in logs--giving the local 
admin a clue that they need local zones configured. 

Problem solved simply and without additional complications created by
AS112.

By contrast, AS112 responses are just silently wrong in some way without
giving the local DNS admin a clue about what.

If someone wants to work on a draft with me, I'll be happy to write this
up as a recommendation to the ICANN, etc.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   

.

---

From: Peter Koch <[email-masked]>
Date: Wed, 19 Jul 2006 18:43:59 +0200

> discussed and adopted (the one for operators, and the one for  

<hat chair>These adoption actions need confirmation on this list. Please
allow the scribe and chairs some time to get the minutes straight before
we go ahead with that part.</hat>

> towards those nameservers.

The latter might refer to the IANA registry that
draft-ietf-dnsop-default-local-zones-00.txt (a.k.a. "AS112 in a box) asks
to create. The target audience would be project participants?

-Peter
.

---

From: Joe Abley <[email-masked]>
Date: Wed, 19 Jul 2006 13:03:16 -0400

> we go ahead with that part.</hat>

Oops, thanks for the gentle wielding of the clue-bat.

> to create. The target audience would be project participants?

Indeed. An IANA registry is a clean approach.

Joe

.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 20 Jul 2006 09:51:50 +1000

> Indeed. An IANA registry is a clean approach.

	I suspect the AS112 zones will be a partially overlapping set
	of zones with those in draft-ietf-dnsop-default-local-zones.

	Remember draft-ietf-dnsop-default-local-zones does not deal
	with direct children of the root zone.  Also the intent
	of draft-ietf-dnsop-default-local-zones was to prevent the
	need expand AS112 to handle the newer zones.

	Direct children of the root zone if the root zone will be
	handled in another draft.
 
	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html