Re: provisioning software, was DNS RRTYPEs, the difficulty with

I think we should look a bit on the flow of data. If I simplify we have a flow 
like this:

Input -P-> DNS server -D-> DNS stub -Q-> Output

P is the provisioning
D is the DNS protocol
Q is the query/parsing in the consumer of the data

What we want is (as described in the IAB RFC on extensions of DNS) the ability 
to query (in D) for as precise data as possible in the triple {owner, type, 
class}. Some RR types like NAPTR and TXT have flaws where the selection between 
records in an RRSet is not in this triple. In some applications that is 
resolved by having a prefix to the owner. In some other applications that is 
resolved by parsing the RRSet.

We all do believe that IF it was easier to add a new RRType for each 
application that would be an architecturally better solution (as adding prefix 
to the owner have its drawbacks). Now, the question is what blocks the ability 
to add new RRTypes.

We seem to believe that the "D" part is deployed so that adding new "unknown" 
RRTypes is not an issue.

Problem is then in "P" and "Q".

And when we talk about parsing, we talk about what the mapping between 
provisioning and DNS packet format is.

Are we aligned so far?

   Patrik

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf