On Tue, Apr 05, 2005 at 06:14:34PM +0000, Paul Vixie wrote:
> > Just finished reading serverid-04.txt and I consider it a good
> > document. But one nagging question remains, as it does not specify a new
> > mechanism, but only lays down the requirements. Are there any plans to
> > create a followup draft which actually specifies a new mechanism?
>
> i'm planning to submit a draft recommending that "id" be bidirectional
> (so, both clientid and serverid) with the client's id being the solicitation
> of the server's id. this doesn't require rev'ing the EDNS version number
> or anything hard like that. i will propose a registry of attributes so
> that the client can, if it wants to, offer an opaque universal identifier,
> a nat-opaque transport address, current latitude and longitude, preferred
> human language, and other things to be defined later. this is primarily
> for mobility support, since i'm not confused into thinking that the internet
> is the web or vice versa. but since we've not succeeded in keeping dns
> server operators from producing policy-based rather than fact-based answers,
> i think it's time that we fully support non-universal dns. obviously this
> will require that caching be disabled in policy-based responses. and it's
> a loophole that the alternate-roots crowd will just love. but it's time
> to answer the community's needs in this regard.
>
> to that end, i don't think that the current draft goes nearly far enough.
> --
> Paul Vixie
01apr is a few weeks back thataway... :)
that said, i'm in favor of the client being
able to give up information about itself.
--bill
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
