[AFS3-std] AFSVol tag-length-value extensions draft (second call for comments)

[Christof Hanke]

Hello Steven, Tom,

generally, your document looks good to me.
There are some implicit things in there (like dropping struct volintInfo 
altogether), but I guess that is fine, because you just describe what you do 
and not what you don't do.

I'm sorry that I can't send you a patch against the xml-file, because my
version of the xml2rfc (1.34) refuses to convert it. Anyway, in prosa now.

For rxosd, we'd need following entries :
==========
in section 5.1 

AFSVOL_TLV_TAG_BLOCKS_STORED_LOCALLY
This tuple denote the size of the volume data which is stored on the 
local partition of the fileserver.It is the TLV analogue of
volintXInfo.BlocksStoredLocally.
This tuple MUST have payload of type  AFSINT_TLV_TYPE_UINT64.

AFSVOL_TLV_TAG_FILE_QUOTA
This tuple denotes the maximum number of files which are allowed in this
volume. It is the TLV analogue of   volintXInfo.filequota.
This tuple MUST have payload of type  AFSINT_TLV_TYPE_UINT64.


Typos et.al :
===========

1. Introduction

In the introduction, you say :
"The AFS protocol stores data in volumes on fileservers. "
Maybe this is correct english (I'm no native speaker), but it seems odd to me 
that a protocol would store something. I'd propose :

"The AFS protocol implies that data is stored in volumes on fileservers."

2. section 5.1.

"AFSVOL_tLV_TAG_VOL_FILE_COUNT" should obviously  be
"AFSVOL_TLV_TAG_VOL_FILE_COUNT"

3. section 6.3

In the description of AFSVOL_TLV_TAG_VOL_OWNING_PROCESS, a cross-reference
is not resolved :

" as defined in [sub:Mapped-process-types]."


Greetings,

Christof


Am Dienstag, 16. Februar 2010 16:33:56 schrieb Steven Jenkins:
> This is a repost of the call for comments for AFSVol tag-length-value
> extensions that was done November 19, 2009.  Please review and give
> feedback so that we can move towards a Last Call.
>
> Thank you,
> Steven Jenkins
>
>
> Greetings,
>
> I have submitted an I-D covering extensions to the AFSVol Rx service
> which provide get, set, and enumerate services for tag-length-value
> (TLV) tuples.  For those of you who were in Edinburgh, or have read
> the meeting minutes, I need to point out a few deviations from the
> design discussion:
>
> 1) it is now tag-length-value instead of tag-uint64.  Further discussion
> and reflection revealed that uint64 would become a bottleneck in the near
> term. Our proposed design skirts around the XDR discriminated union problem
> by specifying that all future allocations of type identifiers (union
> discriminator)
>    automatically map onto an XDR opaque via the 'default' leg of the
> union.  Thus,
>    the RPC will have a chance to be serviced, and demarshalling problems
> can be handled by the RPC itself (by return of specific error codes),
> rather than by
>    Rx failing to demarshall the entire call argument blob.
>
> 2) A number of existing fields from structures such as volintXInfo and
>    transDebugInfo are now exported as TLV tuples, thus eliminating the
>    race conditions between the new TLV RPCs, AFSVolListOneVolume, and
>    AFSVolMonitor.
>
> 3) In addition to the single-volume get RPC, there is also a multi-volume
>     split-call interface.  The purpose of this interface is to allow a
> volser client to
>     get specific metadata for many volumes in a single call.  In order
> to circumvent
>     the heap space problem, we chose a split call where the stream is an
>     xdrrec stream of xdr-encoded TLV structures.
>
>
> You may retrieve the draft from the following locations:
>
> http://www.ietf.org/id/draft-tkeiser-afs3-volser-tlv-00.txt
> http://openafs.sinenomine.net/~tkeiser/draft-tkeiser-afs3-volser-tlv-00.htm
>l
> http://openafs.sinenomine.net/~tkeiser/draft-tkeiser-afs3-volser-tlv-00.xml
>
> Regards,
>
> -Tom
>
> _______________________________________________
> AFS3-standardization mailing list
> AFS3-standardization@openafs.org
> http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardiza
>tion