It might help more if you explained what the motiviation and intent of the
re-chartering is. I am just guessing from what seems implied by the changes. Why
recharter? What is wrong with the old charter? Why now? Resolvers and DNSSEC
oeprations are already in scope in the old charter. Is there some new business
proposed that is presently out of scope? And if not, why re-charter?
Specifics inline.
On Mon, 27 Mar 2006, Peter Koch wrote:
> Dean,
>
> > Why is the first element left out:
> >
> > 1. Define the processes by which Domain Name System (DNS) software
> > may be efficiently and correctly administered, configured, and
> > operated on Internet networks. This will include root zone
> > name servers, gTLD name servers, name servers for other DNS
> [...]
>
> i'd not say this was left out. Instead, the new "1" reads
>
> 1) develop or review guidelines for chosing zone configuration
> parameters that affect inter-server or server-resolver communication,
> including but not limited to SOA RR parameters, TTL values, and glue
> information
This is a very narrow interpretation of "operations". There is a great deal more
to DNS server operations (particularly to root DNS server operations) than zone
configuration parameters. One only needs review the specifications contained in
RFC 2870 to see this.
It would seem that RFC 2870 updates would be out of scope for this charter.
Just about every section of RFC 2870 is out of scope in the proposed charter.
Just for example, consider RFC 2870 section 3.1.2:
3.1.2 Unless there is documentable experience that the local
power grid is more reliable than the MTBF of a UPS (i.e.
five to ten years), power continuity for at least 48 hours
MUST be assured, whether through on-site batteries, on-
site power generation, or some combination thereof.
This section (and most of RFC 2870) has nothing to do with zone configuration,
but a lot to do with root DNS server operations.
It would seem that the charter you propose precludes discussion of things like
UPS, power generation, and power grid requirements for root DNS server
operators.
> While this does not enumerate particular servers or levels, it is meant to
> apply to all levels of the DNS hierarchy (which we could say explicitly).
> It seemed not appropriate to name just a few and discriminate against others.
I agree that we should not discriminate against others. However, special care
must be given to root DNS operations. Lower level DNS users have no obligations
to follow RFC 2870, and the IETF has no special role in giving lower level
operators guidance. Though lower level domain operators might find RFC 2870
helpful, even if too burdensome to follow. While one shouldn't discriminate
_against_ lower level domains, clearly, the root level requires special
attention, both from a common sense point (if the root breaks, nothing works),
and from a MoU/RFC 2870 standpoint, the IETF has made commitments.
> > still a fundamental and important part of the DNSOP mission, particularly
> > with
> > respect to the ICANN MoU and RFC 2870, which give a substantial role to the
> > IETF
> > on DNS Root server operations.
>
> Sure this is important, but that is unrelated to the ICANN MoU. Also you seem
> to see a role for the IETF 'on DNS Root server operations' that I can't
> follow.
RFC 2870 Section 1.1:
1.1 The Internet Corporation for Assigned Names and Numbers (ICANN)
has become responsible for the operation of the root servers.
The ICANN has appointed a Root Server System Advisory Committee
(RSSAC) to give technical and operational advice to the ICANN
board. The ICANN and the RSSAC look to the IETF to provide
engineering standards.
The ICANN MoU agreement then makes the root operators agree to follow RFC 2870.
I think the DNSOP working group charter needs to be broad enough to encompass
all the topics in RFC 2870, and then some, since more operations issues might
arise that might require standards.
If no IETF working group has a charter to re-consider (if necessary) RFC 2870,
then the IETF has effectively abandoned its commitments to provide any further
engineering standards to Root DNS server operators. Things can't be both
"out-of-scope" and "in-scope" simultaneously. If there is no group charted with
the scope to consider root DNS operational standards, then ICANN and RSSAC
really shouldn't be looking to the IETF to provide these standards. Such
standards would be out-of-scope, and the IETF won't be providing them.
> dnsop is and will, I assume, continue to be chartered to provide operational
> guidance and document (best) current practices, but this will happen in the
> form of I-Ds that eventually get published as RFCs, _not_ by commenting
> or even "supervising" day to day operations.
RFC 2870 seems to do just that. Or perhaps I misunderstand your intention. Do
you agree that every element in RFC 2870 should remain in-scope? If so, then we
have a question of the wording to obtain that intent. Or is it the case that you
intend that most or all of RFC 2870 will be out-of-scope? [I'm reading your
position as the latter case, but I want to be clear on where you intend to go]
> > take over these subjects? Is the IETF planning to abdicate its role in
> > these
> > DNS operations subjects? Particularly DNS root server operations? If so, to
> > what
>
> As said above, there is no such change. But even if the dnsop WG would be
> closed, I'm sure the IETF would be able to provide for operational or other
> technical expertise. But then again, we seem to have different views of that
> role.
The IETF needs a working group chartered with the scope necessary to discuss new
engineering standards, or scope to even discuss and propose alterations of RFC
2870. If the IETF has no place for that discussion, then it seems this
discussion and standards-making would have to go to another standards body.
ICANN and the RSSAC should't be looking for the IETF to discuss these issues.
If, as the extreme example, the IETF were to close the DNSOP working group
without some other working group chartered to take over the RFC 2870 scope, it
would effectively and officially be out of the business of providing engineering
standards for root DNS server operations.
In closing, I think there is a very good reason for the current first element
of the DNSOP charter, and I think there will be some repercussions to removing
this scope. It is also too early to tell whether handing root server operations
standardization to another body would be a good thing or a bad thing.
--Dean
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
