[AFS3-std] is the CellServDB file format a standard?

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig8A43273FD8DE0CAF70A15D2A
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The syntax of the CellServDB file format [1] is well-known but is it a
standard from the perspective of this group?  The answer to the question
will determine where discussion of replacing the file format should take
place.

The current format is limited in what can be described and is
unfortunately interpreted differently depending upon the client or
server that is in use.

For example:

 . servers only examine the IP addresses in the file
   whereas the clients sometimes examine the IP address and
   sometimes examine the DNS hostname

 . some clients treat a cell name followed by an empty
   server list as an indication that DNS lookups should be
   used and others do not

 . some clients understand server clones and some do not

 . some clients support linked cells and some do not

Here is some of the new information that I think should be included in a
future replacement with per cell granularity:

 . dns =3D {always, prefer-dns, prefer-local, never}

 . default port values for afs services

 . optional IPv6 addressing

 . local Kerberos realm list

 . service specific configuration data

 . server specific data

   - default rank

   - clone status

Should this discussion take place as a standard or should it be treated
as an implementation specific format?

Jeffrey Altman



[1] http://docs.openafs.org/Reference/5/CellServDB.html


--------------enig8A43273FD8DE0CAF70A15D2A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQIcBAEBAgAGBQJNBmljAAoJEPd6c1WStpoEpW4QAIdwb0LN0FVqRMSsdYB21Q6z
4XSdWKf/rXuPGNpkhMmdlk41CLmuva8qvTnK/iE5sbZgkRhuiu5z5sJobvsFdtu8
TetZghxp0bHEWcIasWHUV28b812gdfNheqZ1bq/ZPR4KUZjMSTDPTbD+pJ4InQCb
JbYFsgLtlnibu5aPi3QmZVwjIq6EBPWnI8a+dqVNB8NvxalJFH7jeXEUvAE9YiAF
ZIFuhw7TynW9AYm4+KYwjMcsZEg5WzZ3v1LWhzN/vWwHh2jQxXDrezkrbiHKBN6F
MdlZyLkQf7vSQsVO3UVNQD+/JybUbGhZ0LOnftc0H2/VF6b+C0nRMeHkz17AGwK2
7KO3OIaMv0XENik8Ri3TCqRpekr2SFsCuUJgcnoblglfjMlrJJPN80PFpmr3RpYg
MrOrkkext43vosA6BL0zYvz1q6Hw+IiJsBo2U7muSSJ5+PwXkl6BPZ5YYiawsTLE
2d21ckUAR9MBDydZ7QizDqBmQjG8tP+tTUARS7QBOr1Rc3ww7Ko9A4YrXbl+MIoX
wiJjWFKAKaB+8P/0TWulI9yLv8f+5HdSTA4v2Y0GkW45sZcisH+Lq3kothUAosMn
qmXRCK+bIgUJeimhIh2NY9J2cfi6Pey+rQ+WPXlvSpIBNOqHh6Vv5WxQfavv6CVI
2sl2Xz/5W0kmIfiojWev
=20kb
-----END PGP SIGNATURE-----

--------------enig8A43273FD8DE0CAF70A15D2A--