Re: draft-manning-dnssvr-criteria-01.txt

[[e-mail]]

> 
> Please excuse the level of outrage and sarcasm.  But a little birdie told me
> that this was going to iRFC and I don't have the time to polish this into my
> normal good manners <grin>.

	This looks like your normal good manners to me.. :)

> 
> I can not support the publication of draft-manning-dnssvr-criteria-01.txt as
> either a BCP or as an informational RFC.  In a nutshell, it would impose
> strange and unnecessary constraints on those running TLDs, especially those
> in startup networks in developing countries, precisely the kind of folk we
> want to get online and up in a reasonable fashion.

	Wish you would have provided these comments when this draft was
	sent to [e-mail] or [e-mail] or [e-mail].
	But thanks for looking.  In general your concerns have already been
	expressed by Robert E. in a much more civil fashion.

> > 1. Modern BIND or equivalents (if any exist).
> 
> What's BIND?  Some kind of Californain bondage and discipline stuff?

	Bind - Berkeley Internet Naming Daemon.  Others exist
	but this seems to be the most popular and best supported.

> If Blortania does it with a 1401, Autocoder, and a bi-synch to frame relay
> converter, they should take a picture and post it on their web site.

	I can't seem to find Blortania in the ISO country code list.
	Perhaps you can forward me the relevent section.

> > 	The upgrade process will be coordinated with the zone-master staff
> > 	and will occur within 96 hours of initial notification. Zone-master
> > 	senior staff will specify the software and version(s) that will
> > 	be run in a particular zone.
> 
> This seems to mandate coordination and approval by a newly created
> net.goddom, 'zone-master' and 'zone-master staff' which are undefined, and
> not motivated as needed.  I smell a new technocracy who can solve the
> problems of the world through the wonders of technology.

	What are you blathering about? Would you like an Glossary added? 

> > 4. Singly homed (only one interface).
> > 	Name service should always answer out the same interface as requests
> > 	come in on. Also, delegations will usually list a single A RR, so there
> > 	should only be a single canonical name.
> 
> One presumes that the nameserver software will handle this properly, and I
> should not be restricted by how many interfaces my host has.

	Assuming facts not in evidence.

> > 5. Protected.
> > 	In general, each server must be adequately protected against security 
> >    	threats.  The system administrator must stay up-to-date on the latest
> >    	security methods and threats and must implement reasonable security
> >    	countermeasures. Audits by the zone administrator or authorized agents
> >    	will be permitted and corrective measures will be taken. A good way to
> >    	keep current is to follow the CERT recommendations.  A reasonable 
> > 	approach is to only run DNS sw, NTP and ICMP support with extensive 
> > 	logging. Recommended packages to assist are tcp_wrappers and ipfilter. 
> > 	Any other package which has an acceptable technology is fine.
> 
> Do the 'zone masters' give them a competence test every two months?  How
> about a lie-detector test to ensure that they are not cheating?  Maybe we
> should license DNS admins and be done with it.

	In some sense, this is a license test. Objective criteria tend
	to level the playing field.  And to be objective, there do need
	to be periodic checks.

> > 6. Servers time is synchronized via NTP.
> >    	This is useful for supporting functions; e.g. logging. It is expected 
> > 	that future enhancements such as dynamic update and security support 
> > 	will take advantage of accurate clocks. This presumes that the NTP 
> > 	server has been secured using strong authentication.
> 
> NTP is nice.  We use it here.  But we can not mandate that the national TLD
> for Blortania be secure, synchronized, ...  And, if we wanted to do so, we
> would not do it in an informational RFC on a side subject.

	Glad to hear you use NTP. And where is Blortania again?  And when
	did adding NTP as a criteria for TLD service become a "side subject"?
	Thats is what the document is about.

> > 7. Sufficient resources. 
> > 	Each system must be able to support a transaction rate of 1200/sec and
> >    	mean time to respond of 5 milliseconds per transaction as a baseline.
> 
> That's nice.  Blortania looks forward to having such a load in five years,
> and they'll be able to afford the hardware to supply it in five years.
> Right now they have a 28.8 to Brunhildeville, and hope to upgrade to 64kb
> DDS in the second half of '96.  Get out of their face.

	Yes mine Furher.  (Where are these places?  On Heir Flemmings 
	OuterInternet?)

> > 8. Representatives on TLD/Root administrator list are responsive:
> >         8a. e-mail about required changes will be answered within 24 hours;
> >         8b. vacations will cause responsibilities to be delegated, not
> >             ignored;
> >         8c. contact numbers, including after hours and emergency, on file 
> > 	      with zone-master senior staff members;
> > 	  8d. an escalation/delegation list that has at least three levels of
> > 	      hierarchy.
> 
> All nice desirable things.  But the assumptions of staffing levels, etc. are
> so wonderfuly <bleep> first-world arrogant that this is worth posting on one
> of the lists for networking in developing countries.

	If they are so bloody desireable, they why not tell people that they
	are?  Or are you in favor of keeping others information poor?

> > 9. Named.boot file will specify:
> 
> What's a named.boot file?  Something peculiar to VMS?

	See reference to Bind above.

> I give up.  It is not worth going further.  This has nothing to do with
> running 50% of the TLD servers in the world today.  And it's tone of mandate
> and arrogance precludes it being helpful technical advice to a TLD admin.

	Thanks for your inputs. Perhaps since 85% of the world has zero
	need for or near term interest in DS3 or 100Mb services that no
	one else should work on these issues or publish documents on problems
	or concerns with these issues.  Your right, perhaps we'd all better 
	wait to address any issue until it affects a majority of the global
	population.

> And, even were it to limit itself to non-national TLDs, I think it is
> attempting to mandate operational practice without the scrutiny of the BCP
> process which might ameliorate it's narrow view of the DNS as having only
> one implementation and the strange limitations and peculiarities of that one
> implementation.

	There is zero attempt to promote this a a BCP. As we all know, not all
	RFCs are standards.  This document is being proposed as Informational.
	It is not current practice.  It is proposing a practice.

	Consider it a design goal for whatever universe your living in.

> randy

--bill