Subject: RE: OASIS and new RR types

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 10 Aug 2006 22:03:27 -0700

You still suffer from thinking that the world has some form of obligation to follow the proposals of this committee without any effort on the member's part to convince them that this is the case.

Much later than 1999 members of this group were still making statements such as 'if it is not possible to deploy DNSSEC in dot com then the problem is that dot com is to big and we should reduce it in size'. Small wonder it was ignored at the time. 

Until SPF appeared there was no mainstream proposal to add records to the DNS to support a feature that was not principaly an extension of the DNS itself.

Regardless of what should have happened it did not. There is plenty that this WG should have done in the past that it didn't.

The IETF produces several hundred RFCs each year. Most require several man years for a serious implementation. Most will be utterly ignored by everyone apart from their authors. The job is not done until there is a deployment constituency.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, August 11, 2006 12:13 AM
> To: Hallam-Baker, Phillip
> Cc: David Conrad; Anders Rundgren; [email-masked]
> Subject: Re: OASIS and new RR types 
> 
> 
> > Rather than rubbing peoples nose in anything I would rather 
> put 100% 
> > of my ef fort in that regard behind persuading the Redmond 
> club that 
> > it would be a goo d idea to support DNSSEC in their next 
> server release.
> > 
> > Given that the time between server releases is about six 
> years and the 
> > featur e list on the last one closed some time in 2001 it is hardly 
> > suprising that f eatures such as support for unknown RRs 
> that have not 
> > had a measurable degree  of evangelism effort behind them 
> have not been more widely adopted.
> 
> 	RFC 1034 and RFC 1035 basically say you should expect unknown
> 	RR types.  It shouldn't have required evangelism in 2001.
> 	Any decent engineer would have seen that unknown was basically
> 	opaque data.  This was made abandently clear in RFC 2535 (1999)
> 	as we had to work out how to sign future records.  The use of
> 	compression pointers (the one sticking point in 1034/1035) in
> 	rdata had ceased years earlier.
> 
> 	Sorry. There is was excuse.
>  
> > If the world does not listen to you, you can either 
> conclude that they 
> > are fo ols or that you have not spoken well enough.
> > 
> > 
> > From: Mark Andrews
> > 
> > > > [ Moderators note: Post was moderated, either because it
> > > was posted by
> > > >    a non-subscriber, or because it was over 20K.  
> > > >    With the massive amount of spam, it is easy to miss and
> > > therefore
> > > >    delete relevant posts by non-subscribers. 
> > > >    Please fix your subscription addresses. ]
> > > > 
> > > > I find this whole thing with getting RRs allocated a 
> bit confusing.
> > > > 
> > > > Would creating a form on IANA's website make this less of
> > > an issue?   
> > > > Or would that make things worse?
> > > 
> > > 	I don't think it will change a thing.  Too many keep spreading
> > > 	FUD and being Microsoft apologists.
> > > 
> > > 	If Microsoft's DNS API can't handle new types then Microsoft
> > > 	needs to fix the API.  The 20 year old libresolv API can
> > > 	handle arbitary types.  There was no excuse for Microsoft
> > > 	writing a API that can't handle unknown types.
> > > 
> > > 	If a firewall can't handle a unknown type then the firewall
> > > 	is broken.  You get the firewall fixed or you replace the
> > > 	firewall with one from a vendor that knows how to handle
> > > 	DNS.
> > > 
> > > 	It's not the ease of getting a type anymore.  It is easy
> > > 	to get new types.  A couple of pages like RFC 4431 is all
> > > 	that is required.
> > 
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
> 
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Julian Mehnle <[email-masked]>
Date: Fri, 11 Aug 2006 10:41:17 +0000

Phillip Hallam-Baker wrote:
> You still suffer from thinking that the world has some form of
> obligation to follow the proposals of this committee without any effort
> on the member's part to convince them that this is the case.

True, but there is no obligation on part of the world to care about what 
standards Microsoft chooses to implement or to ignore, either.

Microsoft's laziness shouldn't stop the world from making full use of 
standards that have existed for a long time.

> Until SPF appeared there was no mainstream proposal to add records to
> the DNS to support a feature that was not principaly an extension of the
> DNS itself.

I wonder if MS is going to implement the SPF RR type, which is part of one 
of their own protocols after all, in their next DNS resolver/server 
releases...

---

From: Douglas Otis <[email-masked]>
Date: Fri, 11 Aug 2006 16:15:21 -0700

On Aug 10, 2006, at 10:03 PM, Hallam-Baker, Phillip wrote:

> obligation to follow the proposals of this committee without any  
> effort on the member's part to convince them that this is the case.

Atlas a proprietary distributed peer-to-peer name resolution PNRP  
protocol might be seen as an alternative.  IPv6 addresses identify a  
node, and SSDP or a seed server boot-strap when retained state  
fails.  For now, UDP encapsulation of IPv6 using STUN techniques  
bridge complex and dynamic routes.  Security depends upon initial  
passwords or ad hoc exchanges of certificates to establish server- 
less relations within groups.  No registrars or centralized authorities.

- patents:
6,912,622
7,051,102
7,065,587
7,068,789
7,089,561

- ports:
Windows Peer-to-Peer Grouping - port 3587
Peer Name Resolution Protocol (PNRP) - port 3450

-Doug

---

From: bert hubert <[email-masked]>
Date: Sat, 12 Aug 2006 01:34:05 +0200

> fails.  For now, UDP encapsulation of IPv6 using STUN techniques  

It is probably lots easier then to just use another DNS client library on
Windows. The DNS protocol is not the problem, the flakey libraries are.

Using another protocol would require another library in any case.

Kind regards.

bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

---

From: Douglas Otis <[email-masked]>
Date: Fri, 11 Aug 2006 17:05:13 -0700

On Aug 11, 2006, at 4:34 PM, bert hubert wrote:

> It is probably lots easier then to just use another DNS client  
> library on Windows. The DNS protocol is not the problem, the flakey  
> libraries are.
>

This alternative will soon reside atop the OS network stack and  
utilize a DNS-ified namespace.  Integrating server applications from  
the same vendor is problematic due to DLL issues.  DNS introduces  
still other dependencies.  Not just one system, but the entire  
infrastructure is affected.  Handling unknown RR types should have  
been an easier task, assuming added functionality from DNS was desired.

-Doug