[AFS3-std] Re: [OpenAFS-devel] openafs rxk5 - AFS_RXK5_DEFAULT

[Jeffrey Hutzelman]

A note on choice of forum...

The openafs-devel mailing list is an appropriate place for discussions 
related to the design and development of OpenAFS, and much of this falls 
into that category.  However, discussion of the design of the protocols 
themselves, including the 'C' pioctl space, belongs on the separate 
afs3-standardization@openafs.org list.  Since this thread contains a bit of 
each, I have copied both lists.



On Tuesday, February 20, 2007 05:09:06 PM -0500 Matt Benjamin 
<matt@linuxbox.com> wrote:

> Actually, the token interface we authored has some properties we would
> not like to see discarded in a new interface.  In particular, we value
> the XDR token description, which allows us to define an afs_token as an
> abstract type (with rxkad and rxk5 subtypes), and generated
> serialization/deserialization code instead of tedious and ugly hand
> marshalling on ioctl buffers.

OK; this is worth discussing further.  It's worth noting that the remote 
syscall protocol needs to know exactly what the arguments are for most of 
the existing pioctl's, so it can do byte-order translation.  Comments in 
that code suggest that at some point (possibly before we got the code), 
someone adopted a rule that future pioctls should take arguments expressed 
in network byte order (and word size), to avoid needed to add additional 
knowledge of this type to rmtsys.  Using XDR would be one way to achieve 
this.


> Reviewing your document at afsig.se, I would draw attention to the cm
> capabilities interface (also in our rxk5 patch), which as you suggested
> to us at AFSBPW 2005 (unforgettable hallway discussion), allows to avoid
> coding many repetitive get/(and ultimately set) ioctl calls such as
> VIOCGETSUPPORTEDTOKENS and my own lock hack.

I don't recall the conversation specifically, but there certainly is an 
established consensus that we should be adding get-capabilities ops to each 
interface.  Such an interface would return a bitmask of supported 
capabilities, similar to the ones we already have in some of the RPC 
interfaces.  Forgive me for not going back and looking at your patch to see 
if this is what you ended up defining.

Given that the number of supported token types is small, I don't see a 
problem with allocating a capability bit for each one; this is probably a 
better approach than using a separate pioctl.

Capabilities really don't address the lock thing, though.  The capabilities 
interface is intended to advertise what an interface provider is willing 
and/or able to support; they are read-only by nature.  They're also 
something that should behave consistently across implementations.  By 
contrast, the locking thing is really a configuration option for the 
OpenAFS cache manager; it needs both read and write, and is implementation 
specific.

So, I think we're talking about three pioctl's here:
- get capabilities
- get OpenAFS CM feature bits
- set OpenAFS CM feature bits

The first belongs in the 'C' space, and there needs to be a registry for 
the capabilitiy bits themselves.  We're already doing this for some of the 
other interfaces, though the web pages don't yet exist for all of the 
registries.

I think the other two belong in 'O', since they really are specific to 
OpenAFS.


I also think that neither of these interfaces covers the question of 
supported enctypes.  An aklog or equivalent program obtaining either rxk5 
or rxgk tokens needs to know what enctypes are supported by the cache 
manager, in order to avoid getting a useless ticket.  My document on rxgk 
client integration indicates the need for such an interface but doesn't 
define one; I don't recall seeing one in your patch, either.  You might 
argue that supported enctypes are capabilities, but I'd rather not treat 
them that way.  There is already an IANA registry of RFC3961/Kerberos 
enctypes, and I'd rather not have a requirement to designate a capability 
bit for every enctype before it can be used.




> As for pioctls, we'll happily send a request to
> registrar@grand.central.org for the ones we actually require.  I would
> ask, however, whether you really plan to issue an official pioctl, in
> any range, for code that is unlikely to see wide or long-term use?  Is
> it possible that there should be an X ('experimental') ioctl range for
> this sort of work?

I allocated numbers for VIOCGETTOK2 and VIOCSETTOK2, but the details of 
these interfaces are still open for discussion.  I don't believe anyone has 
yet implemented the interfaces described on the afsig.se page, but if 
anyone has, they certainly know that they are subject to change.

I'll be happy to allocate a number for a get-capabilities bit, if you want 
to send a request in.  Feel free to CC me to get it quicker attention, as I 
don't wade through the spam there very often.  But I always ask that you 
actually send the request in to the registar address, because I use that 
queue as part of my recordkeeping.


As for experimental use, the 'V' 240-247 codes are available for site 
specific use in both the ioctl and pioctl spaces; these should be usable 
for experimentation.  There is also an implementation-specific range at 
'V'248-255, which may be appropriate for some experimentation (but be 
careful - OpenAFS doesn't use these codes, but other implementations might).

The various lists of assigned codes can be found at 
<http://grand.central.org/numbers/>.  Be aware that they sometimes get 
stale, so don't assume a number is available just because it's not listed.

-- Jeff