--On Tuesday, February 16, 2010 10:33:56 AM -0500 Steven Jenkins
<[email protected]> 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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
