[AFS3-std] DNS SRV Resource Records for AFS

Jeffrey Hutzelman jhutz@cmu.edu
Mon, 05 Oct 2009 20:15:25 -0400


--On Monday, October 05, 2009 07:43:12 PM -0400 David Boyes 
<dboyes@sinenomine.net> wrote:

>> Although this is an implementation detail, as a point of fact the
>> Windows cache manager records
>> AFSDB record TTL values and uses them to timeout the server lists.  It
>> is true that the
>> Unix cache manager does not do so and this should be fixed but that is
>> not a topic for this list.
>
> What it should do is *exactly* the topic for this list.

What it should do (the protocol) is a topic for this list.
What should be done to a particular implementation to bring it into 
compliance is not a topic for this list.  Jeff's point is, if the OpenAFS 
UNIX cache manager is broken, it should be fixed, but discussion of such a 
fix is not on topic here, and so he wasn't going to pursue it further in 
this forum.

> It isn't broken until we decide what un-broken is.

Not entirely true.  Neither we nor AFS implementations operate in a 
complete vacuum.  In fact, the correct behavior for clients using AFSDB 
records was defined in RFC1183, back in 1990; it is not undefined just 
because this group hasn't yet spoken on it.  Similarly for handling of 
TTL's on DNS RR's, which is specified by STD13, an Internet Standard.

I don't want to pick on you specifically, but there's an important point to 
be made here.  While this group will from time to time approve documents 
describing preexisting AFS-related protocols, this does not mean that such 
protocols are undefined until we do so.  There will, of course, be cases 
where it is not clear what the original intent was or what behavior is 
correct, or where the only known reference for something is an 
implementation whose behavior is clearly broken.  But much more commonly, 
there will be plenty of information available, either in the form of AFS 
interface specifications or, for changes introduced since 2001, in the form 
of discussion on OpenAFS mailing lists and elsewhere.

-- Jeff