Subject: [DNSOP] [I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt]

From: [email-masked]
Date: Mon, 6 Feb 2012 19:12:56 +0000

Thanks to Warren, Ed, John D., David C. and Kato-san for their comments/corrections.
Any more? 

/bill

From: [email-masked]
Date: Mon, 06 Feb 2012 09:01:00 -0800
Subject: I-D Action: draft-rssac-dnsop-rfc2870bis-04.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Root Name Server Operational Requirements
	Author(s)       : Root Server System Advisory Committee
	Filename        : draft-rssac-dnsop-rfc2870bis-04.txt
	Pages           : 10
	Date            : 2012-02-06

   As the Internet has become critical to the world's social and economic
   infrastructure, attention has focused on the correct, safe, reliable, and
   secure operation of the Internet infrastructure itself.  The DNS is
considered
   a crucial part of that technical infrastructure. The root domain and its
   authoritative name servers are a part of that technical infrastructure.

   The primary focus of this document is to provide guidelines for
secure, stable,
   and resilient authoritative name service for the root zone.
Additionally it will
   look into some specifics for the operation of the name servers.
Other operators
   of authoritative name servers such as those for generic top-level
domains (gTLDs),
   country code top-level domains (ccTLDs) and other zones may also find this
   document useful.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rssac-dnsop-rfc2870bis-04.txt

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 6 Feb 2012 15:49:03 -0500

Greetings again. This looks much better than the -00, but still needs more effort.

The language in the text is still very rough (larger than "nits", not quite as bad as "confusing"). I believe that the amount of copy editing done by the RFC Editor depends on the stream through which you submit the document. If anyone in the root server operator community can spare <5 hours of an in-house copy editor, you should strongly consider it before turning the document in; otherwise, the AUTH48 comments will either be extensive enough to make finding newly-introduced mistakes difficult, or too few so as to make the document seem unprofessional (particularly when compared to RFC 2870).

The paragraph at the end of section 1 (the "isn't really 2119 language" text) is quite cute and will cause you a world of pain and delay. You have de-capped everything, so remove the paragraph. (Unless you're just trying to make John Klensin even grumpier, which is also quite cute but will also cause you a world of pain and delay).

The intro to section 3 says:
   The servers need both physical and protocol security as well as
   unambiguous authentication of their responses. Physical security focuses
   on the machines and their locations, Protocol security and response 
   authentication are covered by Internet Protocol standards.
However, there are three subsections, the middle being "network security". Further, much of the protocol security is covered by by transport layer security, not IP security. Proposed new wording:
   The servers need to be protected by physical and protocol security for
   their administration and communications. They also need to be protected
   by network security to reduce their vulnerability to attack. Physical
   security focuses on the machines and their locations, network security
   focuses on the way that the root servers are connected to the Internet,
   and protocol security focuses on administrative communication with the
   servers as well as integrity protection for the messages from the
   servers to the public.

The text in 3.2.5 doesn't make sense. NTP can't be on the list if the operator is expected to get time updates "in as secure manner as possible". A proposed rewording would be to just remove that phrase because you describe what operationally is needed to use NTP in a non-crypto secure manner.

Security Considerations are supposed to be just before references, so things are going to be reordered and renumbered by the RFC Editor unless you do it yourself sooner. Given the fact that you use sectional cross-references, doing this yourself is probably better than waiting for the RFC Editor to do it for you.

Using numbers for reference instead of something useful is allowed and makes it hard to understand the document. Consider making the references more useful. For example, references 8, 9, and 10 are (soonesqe) going to be expanded to also include draft-ietf-dnsext-dnssec-bis and RFC 5011; this would be clearer if it was clear what you were referring to.

For the author reference, consider adding the URL <http://www.root-servers.org/>, given that mail to the address listed will often be automatically lost. (Bonus points for updating that page to eliminate the decade-old presentations and just leave the news!)

--Paul Hoffman

---

From: [email-masked]
Date: Mon, 6 Feb 2012 22:19:56 +0000

Hello Paul.

First off, this is an RSSAC document so it is not clear why you think someone from the root
opserator community should do the copy editing.

> The paragraph at the end of section 1 (the "isn't really 2119 language" text) is quite cute and will cause you a world of pain and delay. You have de-capped everything, so remove the paragraph. (Un…

IETF tools complains when that text is removed.  Will see if there is a clean way around it.

>    servers as well as integrity protection for the messages from the

Going back to the document to see which parts you quoted and which were your suggested 
changes.  Will fold in the intent of your suggestion.

> The text in 3.2.5 doesn't make sense. NTP can't be on the list if the operator is expected to get time updates "in as secure manner as possible". A proposed rewording would be to just remove that p…

	or ... update the text to describe secure NTP - which is not uniformly used.
	or the use of local "clocks".

> For the author reference, consider adding the URL <http://www.root-servers.org/>, given that mail to the address listed will often be automatically lost. (Bonus points for updating that page to eli…

	again, this is an RSSAC work product, not just root-operators.  and the URL
	listed is not uniformly used by all operators.  so will likely just leave
	it as RSSAC. That said, if URLs are accepted in author references (and I have
	to admit not seeing that used previously) then a link to the RSSAC page might
	be in order.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 6 Feb 2012 17:52:12 -0500

> opserator community should do the copy editing.

There is a large/complete overlap between the RSSAC and the root server operators. Many of the companies that operate root servers have staff doing many things, such as technical writing. Some have copy editors. The fact that ICANN has not done a copy edit pass on the document after five rounds says that maybe you should look to others. Waiting for ICANN to do this might be futile, given that it doesn't involve making policy.

> IETF tools complains when that text is removed.  Will see if there is a clean way around it.

The tool might complain, but it should not prevent submission. You are now not using 2119 language, so you shouldn't need to put in the not-really-2119 preamble.

> 	or the use of local "clocks".

You can't say "can use NTP" and "in as secure manner as possible": they don't match.

> 	to admit not seeing that used previously) then a link to the RSSAC page might

You can use URLs in author references. However, the RSSAC web page is mostly worthless unless you like bureaucratic history. The root-servers.org page is useful. If you don't want to provide a useful URL, that's fine.

--Paul Hoffman

---

From: [email-masked]
Date: Tue, 7 Feb 2012 05:14:38 +0000

> There is a large/complete overlap between the RSSAC and the root server operators. Many of the companies that operate root servers have staff doing many things, such as technical writing. Some have…

	You are mistaken.  
	while all root server operators are part of RSSAC, RSSAC is a much larger community
	with membership from all the RIRs, ISOC, Research Facilities, and Governments.  I'll 
        note that ISOC, through the IAB has a presence on RSSAC.  Perhaps we could have ISOC 
        provide copy editing? 

> You can't say "can use NTP" and "in as secure manner as possible": they don't match.

	then you recommend we strike SNTP from the document?  There are ways to harden 
	and NTP only system without going completely to a secured NTP (SNTP) system.
	And from my experience, if one takes proper precautions and prudent design choices
	one can deploy  a resistant NTP strucuture without the crypto overhead on the SNTP
	datagrams or channels.  So I am confident that we can, in fact, say with a straight
	face say that servers should use NTP or SNTP in as secure a mnner as practical/possible.
	Its being done.  

> You can use URLs in author references. However, the RSSAC web page is mostly worthless unless you like bureaucratic history. The root-servers.org page is useful. If you don't want to provide a usef…

	again, RSSAC is not just the root operators.  If you want us to include a tangentially 
	related URL, we could just as easily use  www.ietf.org as www.root-servers.org
	in as far as the RSSAC represents either of those groups.

---

From: Joe Abley <[email-masked]>
Date: Thu, 9 Feb 2012 13:17:52 -0800

Hi Bill,

> Thanks to Warren, Ed, John D., David C. and Kato-san for their comments/corrections.

I see you added some text based on our conversation in sunny Christchurch, thanks for that. As promised, here's a summary of that conversation for the list(s).

I think the document requires some substantial copy-editing. I've avoided producing a list of spelling and grammar nits, since I think the clean-up would be easier to do as a single pass through rather than by correcting individual words and sentences. Substantive comments relating only to content follow.

1. Despite the definition of "server" in section 1, there are numerous examples of text in following sections that use the word server in its original 2870 sense (i.e. with an implication that we're talking about individual, discrete servers) despite the fact that architecture has moved on in the real root server system since then. I recommend re-casting the whole document to talk about the DNS service provided by root server operators as a service, and focussing on the way that service is delivered rather than how "servers" are operated.

2. I think this document should aim to provide recommendations and/or document best current practice, rather than declaring that it provides requirements. There is little or no contractual relationship between the organisations that manage the root zone and the root server operators that serve it, and setting requirements that by definition have no teeth seems out of sync with reality. Providing recommendations that root server operators can confirm that they follow seems entirely reasonable, however. Related, I don't understand why there is 2119 normative language in this document.

3. In many places I find the "requirements" far too detailed; in my view they impose specific architectural and operational choices on root server operators when diversity in the root server system is desirable, and more obviously achieved by a diversity of such choices. I think this document should limit itself to carefully specifying the service being provided, and the desired performance characteristics of that service.

For example, specifying that TSIG be used to secure zone transfers is ill-advised, I think (I know that TSIG is used today). Specifying rather that new root zone serials be authenticated and made available promptly (and defining what promptly means) across each deployed root server service seems better. The former is an implementation detail of the service as a whole; the latter restricts the concern to what we actually care about, that changes propagate swiftly and that unauthenticated updates never make it to the query-answering edge.

I would like to see this document specify key performance indicators and specify corresponding ranges of values that represent adequate service. I would also like to see a recommendation that root server operators commit to publish data corresponding to those KPIs, so that the community can gain confidence that the root server system as a whole is performing adequately. I guess I'm talking about something like a Service Level Agreement (although perhaps Service Level Commitment would be better language, given the lack of contractual relationships).

4. When it comes to security, different security policies would seem to fit different deployment approaches. I think it's better to specify that individual root server operators publish their security policy, and that this document should outline what that security policy should contain. I don't think it's useful to attempt to define a security policy that fits all deployed infrastructure.

In summary, I think the document should be substantially reorganised. This makes it difficult to provide a meaningful line-by-line critique. However, I am very happy to put my money where my mouth is and copy-edit/reorganise along the lines I'm thinking if that seems like a useful way to explain myself. I don't think the -04 draft, even with copy-editing, is useful to publish as-is.

Joe

---

From: [email-masked]
Date: Thu, 9 Feb 2012 21:39:17 +0000

> I see you added some text based on our conversation in sunny Christchurch, thanks for that. As promised, here's a summary of that conversation for the list(s).
[elided]
> In summary, I think the document should be substantially reorganised. This makes it difficult to provide a meaningful line-by-line critique. However, I am very happy to put my money where my mouth…

	I had a similar conversation with Terry (check the thread archives).
	Effectively what you propose is a "clean slate" instead of building
	off existing work and actual practice.  I think that is a fabulou
	idea but it has a couple of caveats:

	) it will take considerable time to reach consensus within the operator community,
	  let alone the large community.
	) it will not reflect actual practice but an ideal to be achieved.

	I think that starting work on such a draft is a great idea -BUT- in the mean time
	do not let "perfect" get in the way of "good enough". I beleive Terry agreed with 
	that line of thnking.   Of the existing Operators, A, B, E, G, H, J, L, and M have 
	made positive comments and worked on  upgrading this base text provided by one of 
	the Operators.  Is your opinion / argument strong enough to stop work on this draft?

	That said, I'd love to see a revamped version, if youhave the time to copy-edit/reorgnize
	the document.

/bill

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 11 Feb 2012 09:25:30 -0800

On Feb 9, 2012, at 1:39 PM, [email-masked] wrote:

> 	do not let "perfect" get in the way of "good enough".

Just to be clear: a good handful of people, me included, have said that the wording in the current doc is not good enough, or only good enough if you squint hard. It is clearly much worse than the document that this is supposed to replace.

--Paul Hoffman

---

From: David Conrad <[email-masked]>
Date: Sat, 11 Feb 2012 11:52:41 -0800

> Just to be clear: a good handful of people, me included, have said that the wording in the current doc is not good enough, or only good enough if you squint hard. It is clearly much worse than the…

To be honest, I'm unclear as to the point of the document.  Could someone clarify?  What exactly is revising 2870 supposed to do?

Thanks,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Sun, 12 Feb 2012 02:59:33 +0000

> Just to be clear: a good handful of people, me included, have said that the wording in the current doc is not good enough, or only good enough if you squint hard. It is clearly much worse than the…

wearing my rfc 2010 co-author hat: +1.

paul

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 13 Feb 2012 09:33:05 +0100

On Mon, Feb 06, 2012 at 07:12:56PM +0000,
 [email-masked] <[email-masked]> wrote 

> 	Filename        : draft-rssac-dnsop-rfc2870bis-04.txt

Section 3.2.1 : I do not understand why you need synced time for
DNSSEC. The root name servers do not generate signatures.

Section 3.2.1 : Several root name servers, such as B, reply to ICMP
echo requests, which I think is a good thing, but it seems disallowed
in your document.

Section 4.2 : This advice directly contradicts RFC 6382. Do you plan
to reclassify it as Historic?

Section 5.1 : "Announcement of planned outages also keeps other
operators from investigated a scheduled maintenance window." My
english parser broke here. Should I upgrade it or should you rewrite
the sentence?

(For the record, I agree with most of Joe Abley's remarks on
high-level issues with this document.)

---

From: Edward Lewis <[email-masked]>
Date: Tue, 14 Feb 2012 09:17:02 -0500

At 21:39 +0000 2/9/12, <[email-masked]> wrote:

>I think that starting work on such a draft is a great idea -BUT- in the
>mean time do not let "perfect" get in the way of "good enough". I beleive
>Terry agreed with that line of thnking.   Of the existing Operators, A, B,
>E, G, H, J, L, and M have made positive comments and worked on  upgrading this
>base text provided by one of the Operators.  Is your opinion / argument strong
>enough to stop work on this draft?

As David says, why is this document being republished?  Is there some deadline?

This is a document not code, and not even a first document but a 
revision.  If a revision is not "perfect" at the time it is 
published, it's pretty much not worth publishing.  Especially an 
update document - we already have an RFC on this, why update it with 
another RFC that inaccurately describes the state of the world.

My concern is that future RFPs and contracts will cite this as a 
document to comply with.  That is when it becomes my pain, even if 
the job at hand is not operating a root server.  I especially like 
Joe's point #3.

>That said, I'd love to see a revamped version, if you have the time to
>copy-edit/reorgnize the document.

I do not recommend publishing the document as is.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 14 Feb 2012 17:34:46 +0100

> Any more? 

One governance question. As far as I know (I am not a root name server
operator), several of the root name servers already comply with the
(very strong) requirments of this document. But not all. If the
document is published, what will happen of them? In other words, what
is the goal of the document? Exercice some pressure or more?

---

From: Jim Reid <[email-masked]>
Date: Tue, 14 Feb 2012 16:56:07 +0000

On 14 Feb 2012, at 16:34, Stephane Bortzmeyer wrote:

> document is published, what will happen of them?

We report them to the Internet Police's Root Server Department. :-)

To be less flippant, I would assume that someone who has a concern  
about root server operations will ask each RSO if their server meets  
or exceeds the requirements in RFC2870bis and if the answer is no,  
they'll ask why not.

> In other words, what is the goal of the document? Exercice some  
> pressure or more?

IMO RFC2870bis is probably never going to be aligned with what is  
actually done to run a real root server. Discussion of some of those  
practices probably won't be in the public domain for a while anyway.  
That said, it's good to update and revise those guidelines from time  
to time. IMO the value of this document is to describe the general  
principles and suggest to others how an "important" DNS server should  
be operated. For instance, it can (and has) been used in RFPs for DNS  
service for TLDs.

---

From: David Conrad <[email-masked]>
Date: Tue, 14 Feb 2012 08:19:11 -0800

On Feb 14, 2012, at 6:17 AM, Edward Lewis wrote:
>> Is your opinion / argument strong enough to stop work on this draft?
> As David says, why is this document being republished?  

A question I'll note has not been answered.

> My concern is that future RFPs and contracts will cite this as a document to comply with.

Agreed. A BCP on how best to provide a highly resilient DNS service would probably be useful.  The document in question isn't close.  At best, it feels like a bit of self-congradulatory back-patting for those root server operators that actually come close to what the document describes.  At worst, it can be seen as an attempt at obfuscation of the fact that the root server operators (with one notable exception) are _NOT_ subject to RFPs, contracts, or any other form of enforcement.

> I do not recommend publishing the document as is.

+1

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Tue, 14 Feb 2012 09:20:49 -0800

On Feb 14, 2012, at 8:56 AM, Jim Reid wrote:
> I would assume that someone who has a concern about root server operations will ask each RSO if their server meets or exceeds the requirements in RFC2870bis and if the answer is no, they'll ask why not.

And if no acceptable answer is provided?  Sorry, rhetorical question: can't stop myself from kicking the brown stain that used to be a dead horse.

> That said, it's good to update and revise those guidelines from time to time. IMO the value of this document is to describe the general principles and suggest to others how an "important" DNS server should be operated. For instance, it can (and has) been used in RFPs for DNS service for TLDs.

I agree, however I'd think a better approach would be to write a BCP for "important" DNS servers, not a document that sets up false expectations or assumptions.

Regards,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Tue, 14 Feb 2012 17:22:01 +0000

On 2/14/2012 4:19 PM, David Conrad wrote:
> ... At worst, it can be seen as an attempt at obfuscation of the fact
> that the root server operators (with one notable exception) are _NOT_
> subject to RFPs, contracts, or any other form of enforcement.

are you sharing insider knowledge from your time as IANA GM here? i
thought that ICANN and VeriSign were both under enforceable contracts
with respect to their role as root name server operators. but i've not
been an insider and i'm only guessing.

inside baseball warning. the agreement signed between ISC and ICANN on
january 23 2008 is not "enforceable" in that it does not specify any
recourse for either party due to any nonperformance by the other party.
see http://www.icann.org/en/announcements/announcement-23jan08.htm for
details.

paul

---

From: Paul Vixie <[email-masked]>
Date: Tue, 14 Feb 2012 17:28:06 +0000

On 2/14/2012 5:20 PM, David Conrad wrote:
> ...

+1. there are a lot of important non-root dns servers, and the collected
wisdom of all of there operators would be a good thing to gather and
peer-review and publish.

---

From: David Conrad <[email-masked]>
Date: Tue, 14 Feb 2012 09:30:39 -0800

On Feb 14, 2012, at 9:22 AM, Paul Vixie wrote:
> are you sharing insider knowledge from your time as IANA GM here?

Nope.

> i
> with respect to their role as root name server operators.

As far as I'm aware (and happy for any of the root operators to correct me), the only actual contract is between U.S. Dept. of Commerce and VeriSign for the operation of the "A" (and "J"?) root server(s).  That's part of the irrationality of root service -- it isn't even clear between whom contracts should be.

> recourse for either party due to any nonperformance by the other party.

Yep. "We acknowledge you exist, you acknowledge we exist, and we might think about discussing the possibility of perhaps considering doing some undefined stuff someday in the future. Or maybe not."  With that said, it was a step in the right direction.  Not aware of any further steps, but I haven't been paying attention.

Regards,
-drc

---

From: Jim Reid <[email-masked]>
Date: Tue, 14 Feb 2012 18:16:03 +0000

On 14 Feb 2012, at 17:20, David Conrad wrote:

>> That said, it's good to update and revise those guidelines from  
>> time to time. IMO the value of this document is to describe the  
>> general principles and suggest to others how an "important" DNS  
>> server should be operated. For instance, it can (and has) been used  
>> in RFPs for DNS service for TLDs.
>
> I agree, however I'd think a better approach would be to write a BCP  
> for "important" DNS servers, not a document that sets up false  
> expectations or assumptions.

+1

Though until that comes along RFC2870(bis) is probably the best hammer- 
shaped object for that nail-shaped problem.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 14 Feb 2012 10:33:08 -0800

On Feb 14, 2012, at 10:16 AM, Jim Reid wrote:

> Though until that comes along RFC2870(bis) is probably the best hammer-shaped object for that nail-shaped problem.

A few people have asked, but we haven't gotten any real answer, on what the nail-shaped problem is.

--Paul Hoffman

---

From: [email-masked]
Date: Wed, 22 Feb 2012 13:03:37 +0000

> DNSSEC. The root name servers do not generate signatures.

	but they do use TSIG.  And historically, channel protection via
	TSIG or SIG(0) was considered part of the DNSSEC tool box.  Granted that
	DNSSEC perception has changed over the years. but the need for sync'ed clocks
	is becuase of TSIG.

> echo requests, which I think is a good thing, but it seems disallowed

	-I- think its a good idea, but others would prefer less transparency

> to reclassify it as Historic?

	It meaning RFC 6382?  Not really.  The draft was an attempt to
	document current practice - with some leanings toward future directions.

> english parser broke here. Should I upgrade it or should you rewrite

	investigated should be investigating.  e.g. if you don't tell anyone
	you are doing maintance work, observers will presume the worst and start 
	to debug why  the L root has gone offline.
	
> high-level issues with this document.)

	There are some strong argumetns for simply stating operational goals/principles
	vs documenting practice.  I beleive that we are working on a "mission statement"
	
/bill