Subject: RE: a suggestion for super-wildcards

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 4 Aug 2006 12:38:32 -0700

> From: william(at)elan.net [mailto:[email-masked]] 

> Yes, I was talking about /etc/services, /etc/protocols, which 
> sure sounds like IANA is needed to get new protocol deployed 
> to anything but minimum testing stage. And if you come to 
> think of it if protocol needs special type of DNS records 
> IANA and IETF are again needed. Similarly if protocol need to 
> use services of some other protocol, etc.

Its been almost a decade since I used a machine that had such files.

It has always been possible to get a port assignment without IETF involvement. There are more port assignments than RFCs.

--
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: "william(at)elan.net" <[email-masked]>
Date: Fri, 4 Aug 2006 12:46:54 -0700 (PDT)

> Its been almost a decade since I used a machine that had such files.

You know it doesn't have to be text file in a particular directory.
Local LDAP directory or XML is fine location too but in some way you
do have that on your machine too.

To be fair since this is a DNS group, you guys did create SRV records
however they are not as much used as you might have wished for ...

> It has always been possible to get a port assignment without IETF 
> involvement. There are more port assignments than RFCs.

But that is a service of IANA. Some of its services other protocol
parameters though are tied to IETF review.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 4 Aug 2006 13:17:52 -0700 (PDT)

Last message on this sub-thread from me...

I just want to point out that original text I had problem with is that 
Phillip said it "never existed before". I can quite believe that
internet developers are trying to get away from having to have IANA/IETF 
involved in every new service but never "never existed before" is just
so far from the truth ...

---

Anyway regarding "super-wildcards" - I actually do support it (maybe
not quite the same way as Phillip but in general), but as was pointed
out 1.5 years ago when I brought it up here, their introduction can not 
easily be done as just a local MACRO generated record and will require 
bigger protocol-level changes (which means reuse of PTR will not
facilitate deployment) and need to have new wildcard syntax understood
by DNS servers for DNSSEC things like DNSSEC. At the same time the
quicker this all get introduced and put in the code, the quicker we
can start getting it deployed and used; besides that I have a feeling 
deployment of these or similar new DNS feature will actually still get 
done quicker then DNSSEC...

Now getting back on-topic if I remember there was sub-group list
created by the WG chair to work on the issues of wildcards. There
were unfortunately only 3 people who actually signed up to participate
in it back then. Maybe WG chair should revisit this issue and invite
more people to discuss this and have people interested to at least
come up with list of requirements with scenarios where extended
wildcards are needed and publish that as an ID.

---

From: Douglas Otis <[email-masked]>
Date: Sat, 05 Aug 2006 09:26:16 -0700

On Fri, 2006-08-04 at 13:17 -0700, william(at)elan.net wrote:

> out 1.5 years ago when I brought it up here, their introduction can
> not easily be done as just a local MACRO generated record and will
> require bigger protocol-level changes (which means reuse of PTR will
> not facilitate deployment) and need to have new wildcard syntax
> understood by DNS servers for DNSSEC things like DNSSEC. At the same
> time the quicker this all get introduced and put in the code, the
> quicker we can start getting it deployed and used; besides that I have
> a feeling deployment of these or similar new DNS feature will actually
> still get done quicker then DNSSEC...
> 

The concern was not regarding the development of a wildcard scheme.  I
too expressed a desire back then.  The concern raised was with respect
to using the PTR RR for a wildcard scheme causing potential conflicts.
Kevin Darcy added his voice to that concern.

A new RR type for each new policy does scale.  The addition of wildcards
at each label does not, which could be a valid criticism.  Ironically,
the number of transactions needed to support the PPTR + PTR wildcard
mechanism is about the same as hunting for a non-wildcarded RR type
defined for the policy desired. 

Starting from scratch, the design of a RR supporting a wildcard below a
prefix might want to include:
 - a field that indicates the number of labels in the prefix
 - a copy of the prefix anchor
 - the location of the anchor
 - the list of RR types contained within the anchor

These added fields are to facilitate the synthesis of the initial query
once name servers have been upgraded to directly support this operation.
These fields can also identify the anchor point to filter out these RR
types when just the anchor entry is required.  A PTR RR does not permit
this information to be included, nor does it facilitate selective
filtering, where this alone seems like a major drawback.

The PTR RR wildcard approach is an interesting exercise in what is
needed to avoid the introduction of a new RR type.  Oddly, the solution
offered when this PTR RR wildcard scheme might conflict was to introduce
a new PPTR by those domains that have determined there is a problem with
their exiting use of the PTR.  There is no way to know whether the PTR
found should have been the PPTR, unless the PPTR is always requested
first. When the environment does not support the PPTR, which is why PTR
was used initially, then the conclusion reached when no PPTR is found
will be wrong. : (

-Doug