Re: [e2md] Problem statement, Requirements and Use Cases (was RFC 5507 & RFC 5395)

["PFAUTZ, PENN L (ATTCORP)" <[e-mail]>]

Ray:
I see your point. It also appears that send-n and unused would never by themselves raise response size issues since I wouldn't expect to see a send-n RR in or an unused RR for a domain name that would have other NAPTR records in its RR set. So let me bump the naïve question up a level:

Please sirs, may we have an e2md WG that will analyze proposed use cases guided by RFC 5507 & RFC 5395 and propose appropriate implementations?


Penn Pfautz
AT&T Access Management
[phone]

-----Original Message-----
From: Ray Bellis [mailto:[e-mail]] 
Sent: Monday, May 17, 2010 11:09 AM
To: PFAUTZ, PENN L (ATTCORP); E.164 To MetaData BOF discussion list
Subject: Re: [e2md] Problem statement, Requirements and Use Cases (was RFC 5507 & RFC 5395)

On 17/05/2010 15:22, "PFAUTZ, PENN L (ATTCORP)" <[e-mail]> wrote:

> So I went through the RFCs which seemed to say, "You probably should use a new
> RR type if you're going to get too much data and it's not as bad getting new
> RRs as you think."
> 
> Naïve question: if we said we wanted a WG based on the assumption that we'll
> define new RR type(s) as needed would that settle the naysayers' hash?

It might, but it then doesn't meet some of the technical requirements for
some of the use cases.

For 'Send-N' and 'unused', in particular, NAPTR fits because these answers
are given back instead of "communication end points" in response to the
usual DDDS algorithm query.

A new RR type for those would be self-defeating.

Ray