Pekka,

On Fri, Jun 11, 2004 at 05:25:31PM +0300, Pekka Savola wrote:
> 
> During the IESG evaluation of this document, there was one comment 
> (there are probably more to come yet) from Steve Bellovin which I 
> think deserves to be discussed in the WG:
> 
> Steve said:
> ======
> 4.1 advocates service names in the DNS.  Is this our official 
> position, as opposed to SRV records?  I thought we wanted to 
> discourage such things.  If SRV records are meant, this should be 
> clarified.  (This is similar to one of my comments on 
> draft-ietf-v6ops-application-transition, and should be resolved in the 
> same way.)
> ======
> 
> (See at the bottom for what section 4.1 says.)
> 
> How do you feel about this?
> 
> My perception of the DNS *operational* situation is that:
> 
>  - yes, SRV records could be used, to the same outcome as described in 
> section 4.1,
>  - no, SRV records are not being used for these purposes for whatever
> reasons (I don't know of those, but I guess they haven't reached 100%
> penetration etc. so you can't only rely on them)
>  - yes, most people do use service names instead of node names 
> instead, so that's an established operational practice.
> 
> So, my own reaction to this comment is that we should just add a 
> paragraph to describe that the same outcome is possible with SRV 
> records but that might not always be a feasible option, and that the 
> section deals with non-SRV situation.

Yes, we would like to see a bit more discussion on the issues
involved, possibly a reference to why we (normally) don't like people
to use service names, and maybe some text why it is acceptable to
actually do this here (if that is the case) or make it clear that you
document existing practise (and I have used this practise as well :-))
but that SRV records are really better.

David Kessens
---
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

Reply via email to