Subject: [DNSOP] DNSOP future direction (agenda item 5 for Quebec)

From: Peter Koch <[email-masked]>
Date: Tue, 19 Jul 2011 18:05:57 +0200

Dear WG,

With four, admittedly long lasting, drafts now published as RFCs
and several others in or approaching WGLC, it is time to look at
the remaining action items or milestones for the DNSOP WG.
Your chairs would like to devote some time in Quebec to gauge
interest in future work. We'd like to identify DNS operations related
topics that would call for IETF action _and_ can get enough traction for
something to be delivered.

So, here are topics that have been raised in the recent or not so
recent past, in no particular order:

o AS112 next steps
  The AS112 operations community, supported by OARC, is thinking about
  expansion in the direction of IPv6 and automated adjustments to the
  list of zones served by the AS112 nodes

o Trust history
  See recent discussion on the list.

o Child-/Parent- Key (Material) exchange
  Also recently reappeared in the form of a concrete proposal for a solution.
  Most of the problem descriptions and/or solutions have in common that
  the signalling and/or data transport happens in-band as opposed to through
  a dedicated provisioning protocol.
 
o DNS Operator Change under DNSSEC
  Apparently identified as a real world problem in the registry-registrar-
  operator world, part of this has been addressed in RFC4641bis. Part of
  the solution might be more a provisioning protocol issue than a DNS one.

o A/AAAA multiple queries issue
  Over the years several suggestions have been made to optimize the lookup
  of A and AAAA RRs for the same QNAME in an attempt to ease or encourage
  IPv6 deployment.  While protocol changes haven't found support (and are
  out of the scope of DNSOP), it was often enough challenged that there
  was a problem in the first place.  Is there room or need to document
  current practice and the affect on resolution and server infrastructure?

o Updating RFC 1912
  RFC 1912 has been a landmark in documenting operational issues and is
  believed to carry the primary reference to what a "lame delegation" is,
  amongst other useful things.  However, since its publication the
  DNS operational environment has made significant progress that might
  
o Benchmarking and Performance Measurements
  Measurements of DNS server software usually report "queries per second"
  values to judge speed and performance. However, there is no agreed upon
  set of queries, neither for authoritative nor for recursive servers.

o Operational Reality Check for use of DNS in other protocols
  Several protocols, mostly in the applications area, make, sometimes tacit,
  assumptions about the DNS, the way "a domain" works or the proximity of
  "domains" and "networks".  Review, Guidance or Reacting to operational
  challenges might be future routes.

o DNS "Signing as a Service"
  Multiple vendors have started to announce DNSSEC signing services for
  remote DNSSEC zones, including fetching and pushing zones from and to
  the customers' DNS infrastructure and also including key management
  and key material handling (in the direction of the parent). Is there
  demand for standardization and how much of this is a DNS rather than
  a provisioning issue?

o Name Server Control Protocol
  Work addressing the requirements as discussed in RFC 6168.

Please take this as food for thought, not as an exhaustive list or work
proposal. All items would have to pass the admission tests:

0) Is there a problem to solve (or document)?
1) Is there enough momentum to get work done?
   This includes both editors _and_ reviewers!
2) Is there a reasonable chance to reach consensus while still having
   a useful result?
3) Is the work item in scope for the IETF and DNSOP?

Looking forward to a lively discussion in Quebec!

-Peter and Stephen

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 21 Jul 2011 09:22:21 -0400

Dear WG,

Howdy.

> recent past, in no particular order:

Some years ago, this working group formally took on a task that it did not 
pursue, concerning the emerging convention of using node names that begin with 
an underscore.

The original work was based on a preliminary specification that I wrote and that 
received some discussion.

Recently, I have twice posted queries about a revised specification but there 
has been no followup at all, in spite of additional, offline queries.

The current draft is:

      DNS Scoped Data Through Attribute Leaves
      <https://datatracker.ietf.org/doc/draft-crocker-dns-attrleaf/>

There is existing /and incompatible/ work that has produced a series of 
independent registries, for a single namespace(!)  Take a look at Section 5 of 
the draft and you will see a rather long list of specs that have defined their 
own registries for this namespace, either implicitly or explicitly.

It's difficult to imagine a stronger basis for working towards a common 
registration mechanism.

This group is the natural home for this work.

I would like to receive an explicit decision from this working group about 
whether it will take the task on or won't.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Jul 2011 22:57:33 +0900

Dave CROCKER wrote:

> Take a look at Section 
> 5 of the draft and you will see a rather long list of specs that have 
> defined their own registries for this namespace, either implicitly or 
> explicitly.

That's definitely what we should not do.

> It's difficult to imagine a stronger basis for working towards a common

We already have more than enough registration mechanisms.

> This group is the natural home for this work.

You'd better worry about registration mechanisms for file name
extensions.

							Masataka Ohta