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

[Jeffrey Hutzelman]

--On Tuesday, February 16, 2010 10:33:56 AM -0500 Steven Jenkins 
<steven.jenkins@gmail.com> wrote:

> 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.

The TLV-based approach to accessing attributes of objects such as volumes 
is a good one.  However, I believe the introductory material in this 
document becomes too ambitious when it essentially declares that all RPC 
extension from here on out will use this approach.  I suggest limiting this 
document to extending the AFSVol interface, rather than trying to set 
policy for future protocol extensions.  Specifically...

- Rewrite the introduction and abstract to focus on the problem you are
  actually solving, which is providing an extensible mechanism for access
  to volume-level metadata, rather than focusing on why you are using
  a TLV-based approach instead of defining AFSVolListOneVolume2 et al.
- Drop section 2 entirely
- Rewrite the intitial part of section 3 (before 3.1) to refer
  specifically to the AFSVol interface.  I also suggest moving this
  to just before the "Acknowledgements" section, as I believe it reads
  better to fully define the new interface before talking about backward
  compatibility, rather than after.
- Delete the introductory paragraph of section 3.1, and promote the rest
  to a new top-level section.
- Renumber section 4.2.1 as 4.2, and promote the remainder of section
  4.2 (4.2.2..4.2.5) collectively to a new top-level section, such that
  the syntax and semantics of TLVs are described separately from the
  AFSVol RPCs that provide TLV-based access to volume attributes.  This
  allows future documents which define TLV-based RPCs to refer directly
  to section 4 of the present document for the syntax and semantics of
  TLVs without confusing things too much.

I believe these changes will produce a more focused, easier to read 
document that creates a new tool and effectively uses it to extend the 
AFSVol interface without insisting that the new tool be a hammer used to 
solve all problems.


In addition, a few notes about registry considerations...

- Please don't make references to the "Grand Central Registrar"; no such
  entity exists.  The current term is currently AFS Assigned Numbers
  Registry/Registrar,

- For each new registry, describe what the registry is for, what
  information must be provided to register new values, what will be
  contained in registry entries, and complete initial contents of the
  registry.  While not all of it applies here, RFC5226 Section 4 does
  a good job of describing what goes into a new IANA registry.


Finally...

- Don't use RFC2119 requirements language to make recommendations to
  future protocol designers, as near the bottom of page 7, "it is
  RECOMMENDED that future protocol augmentations...".  This language
  is reserved for specifying how implementations are expected to
  behave.



-- Jeff