ietf-clear
[Top] [All Lists]

[clear] Plan of Action for CSV?

2005-06-21 06:31:56
David Woodhouse <dwmw2(_at_)infradead(_dot_)org> wrote:
On Mon, 2005-06-20 at 18:58 -0400, John Leslie wrote:

We're facing the interoperability problem here. You've taken a reasonable
tack on what multiple SRV RRs could mean, but it significantly increases
the complexity. You've implemented a reasonable interpretation; but there
are other interpretations which will seem reasonable to other implementers.

I don't think 'pick one SRV record at random from the set and base your
result on that record alone' is really what Tony considers "reasonable",
although that's what his implementation is doing. It's just that he
didn't test this case, that's all. 

   Were it sufficiently clear that more than one CSA SRV record (of the
same "version") is an error, I would have to accept "pick one record at
random" as "reasonable". It's apparent that, although the spec authors
were thinking in terms of a single SRV record (and IMHO the spec reflects
that thinking fairly clearly), the spec is less clear than it should be.

I don't really see any _other_ reasonable interpretation of what
multiple SRV records could mean,i

   I don't want to argue what is "reasonable"; but I will point out that
if the same IP address is included in the target lists of incompatible
"weight" and "port", it's much less clear what "reasonable" might mean.
(And that quickly degenerates into flame-war potential if "compatible"
is taken to mean anything except "identical".)

and it is natural to expect that just as with any other DNS record,
multiple records would be permitted.

   Clearly multiple records are "permitted" in the sense that DNS servers
know how to serve them. But that shouldn't be the sense applied here.
If we can establish a completely clear _meaning_ for multiple records,
then we could "permit" them under the CSV specs, and the argument becomes
whether implementing that meaning is worth the costs.

   OTOH, if we _can't_ establish a completely clear meaning, I'm quite
strongly of the opinion we shouldn't "permit" them.

If you want to impose a maximum number of SRV records (be it 1, 5, 10 or
some other number) then you need to make it explicit, and hence remove
the scope for local interpretation. You should also explicitly define
the behaviour which is expected if that limit is exceeded.

   I'd like to see whether we can get "rough consensus" to say that the
limit of CSA SRV records of the same version ("priority" field) should
be one. This question will be easier to resolve if we defer argument
about what behavior is expected if that limit is exceeded (though any
later failure to reach rough consensus on that future issue would
suggest a need to revisit the "rough consensus" limit issue).

   (I shall try to remain reasonably neutral, asking questions to
clarify rather than expressing my doubts. But I do think we should
respect the opinions of folks actually _implementing_ CSV software.)

--
John Leslie <john(_at_)jlc(_dot_)net>