On 9/12/2011 1:20 PM, Keith Moore wrote:
On Sep 12, 2011, at 3:50 PM, Joe Touch wrote:
On 9/12/2011 11:46 AM, Keith Moore wrote:
On Sep 12, 2011, at 2:31 PM, Joe Touch wrote:
The issue is that if this document wants to go outside the
spec, *it* needs to update RFC2782 - and survive the discussion
that will incur.
Well, in a pedantic sense I'm sure that's true. But it doesn't
need to update RFC2782 as it pertains to anything but the ability
to locate a certain subset of NFS-based services. It certainly
doesn't have to change how SRV works with respect to other
That's trivially true for all protocol variations - they're all as
local as you define them.
But again if that's your goal - a ships-in-the-night variant - you
should consider doing declaring a new RR type. That's the point of the
RR type - to indicate when the interpretation of an RR changes.
You and I both know that RR types are limited in number, require
significant time and effort to define, and can take many years to
deploy to the point where applications can expect to use them. Which,
I suppose, is why people keep trying to use SRV even for situations
in which it's poorly suited - it's too much trouble to define and
deploy a new one.
Maybe they use this because it works too.
I'm merely suggesting that the 2782 definition should be relaxed a
bit and in a way that's compatible with existing DNS server code.
Perhaps the appropriate thing to do is to publish a separate
document that updates 2782 and explains this.
Start there (but it will be an uphill battle, vs. creating a new RR),
but then this doc would be held until that change occurs AFAICT.
Ietf mailing list