[AFS3-std] AFSVol Tag-Length-Value extensions I-D
Tom Keiser
tkeiser@gmail.com
Sat, 18 Dec 2010 23:19:59 -0500
--0016369896bd7adb370497bbb773
Content-Type: text/plain; charset=ISO-8859-1
On Dec 17, 2010 11:17 PM, "Matt W. Benjamin" <matt@linuxbox.com> wrote:
>
> Hi Tom,
>
> I've read the tag-length-value draft specification multiple times quickly,
and once carefully. Though I'm not expert in volser, the proposed protocol
seems very coherent and reasonable.
>
> Though it's a nit, I find some of the long token constants (e.g.,
"VOLSERTAGUNSUPPORTEDENCODING") hard to read. It might be nice to break up
the token namespace with understores (e.g.,
"VOLSER_TAG_UNSUPPORTED_ENCODING"), if the token length exceeds some minumum
(14 characters seems plausible)? This is already done for most token
namespaces in the draft.
>
Sounds good. I'll make the necessary changes for draft -04.
> I wondered also if the tag cache coherence ambiguity could be helped
through the use of some type of data version or serialization token in
relevant calls?
>
Hmm. That's an interesting idea. Proposal: If we were to add an OUT
parameter to each Get...TLV RPC, which communicated the generation number
for the tag namespace, then--combined with rx epoch checks--the caller would
know when to re-fetch the list of available tags.
Although I doubt this issue is likely to come up very often in the real
world, an additional four byte payload hardly seems objectionable...
Does that sound reasonable and sufficient? If so, I can incorporate the
idea into draft -04...
Thanks very much for the feedback.
-Tom
> Matt
>
> ----- "Tom Keiser" <tkeiser@sinenomine.net> wrote:
>
> > Hi All,
> >
> > Now that the elections are complete, I'd like to make a second call
> > for review of draft-tkeiser-afs3-volser-tlv-03. Any feedback would
> > be
> > greatly appreciated.
> >
> > Cheers,
> >
> > -Tom
> >
> >
> > Tom Keiser <tkeiser@sinenomine.net> wrote:
> > > The other week I submitted a new draft to the IETF which implements
> > > the aforementioned changes (as well as a few others). The new
> > draft
> > > is available at the following URLs:
> > >
> > > http://tools.ietf.org/html/draft-tkeiser-afs3-volser-tlv-03
> > >
> >
http://openafs.sinenomine.net/~tkeiser/i-d/draft-tkeiser-afs3-volser-tlv-03.html
> > >
> >
http://openafs.sinenomine.net/~tkeiser/i-d/draft-tkeiser-afs3-volser-tlv-03.xml
> > >
> >
http://openafs.sinenomine.net/~tkeiser/i-d/draft-tkeiser-afs3-volser-tlv-02-03.xml.diff
> > >
> > >
> > /afs/
sinenomine.net/user/tkeiser/public_html/i-d/draft-tkeiser-afs3-volser-tlv-03.txt
> > >
> > /afs/
sinenomine.net/user/tkeiser/public_html/i-d/draft-tkeiser-afs3-volser-tlv-03.html
> > >
> > /afs/
sinenomine.net/user/tkeiser/public_html/i-d/draft-tkeiser-afs3-volser-tlv-03.xml
> > >
> > /afs/
sinenomine.net/user/tkeiser/public_html/i-d/draft-tkeiser-afs3-volser-tlv-02-03.xml.diff
> > >
> > >
> > > The complete revision history is as follows:
> > >
> > > - split unsigned 64-bit type down into several more descriptive
> > types
> > > that allow the TLV data stream to be more self-describing.
> > > - add a signed 64-bit integer type to allow for relative timestamps
> > > - now that we have more descriptive types, use them in a number of
> > places
> > > - change AFSVOL_TLV_TAG_VOL_TRANS_CALL_VALID into a boolean type
> > payload
> > > - make sure rxgen can parse the XDR in the appendix
> > > - make sure generated C code compiles and links
> > > - add in-text cites for AFS3-VVL, AFS3-FSCM, DAFS, and OSD.
> > > - provide motivations for GetCapabilities RPC
> > > - provide protocol semantic definitions for each newly allocated
> > capability bit
> > > - allocate AFSVOL_TLV_FLAG_MORE bit to notify caller when we can't
> > > send all tags due to AFSVOL_TLV_TAG_MAX length limit
> > >
> > > Any comments or feedback are appreciated.
> > >
> > > -Tom
> > >
> >
> > _______________________________________________
> > AFS3-standardization mailing list
> > AFS3-standardization@openafs.org
> >
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
>
> --
>
> Matt Benjamin
>
> The Linux Box
> 206 South Fifth Ave. Suite 150
> Ann Arbor, MI 48104
>
> http://linuxbox.com
>
> tel. 734-761-4689
> fax. 734-769-8938
> cel. 734-216-5309
> _______________________________________________
> AFS3-standardization mailing list
> AFS3-standardization@openafs.org
> http://lists.openafs.org/mailman/listinfo/afs3-standardization
--0016369896bd7adb370497bbb773
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<p>On Dec 17, 2010 11:17 PM, "Matt W. Benjamin" <<a href=3D"ma=
ilto:matt@linuxbox.com">matt@linuxbox.com</a>> wrote:<br>
><br>
> Hi Tom,<br>
><br>
> I've read the tag-length-value draft specification multiple times =
quickly, and once carefully. =A0Though I'm not expert in volser, the pr=
oposed protocol seems very coherent and reasonable.<br>
><br>
> Though it's a nit, I find some of the long token constants (e.g., =
"VOLSERTAGUNSUPPORTEDENCODING") hard to read. =A0It might be nice=
to break up the token namespace with understores (e.g., "VOLSER_TAG_U=
NSUPPORTED_ENCODING"), if the token length exceeds some minumum (14 ch=
aracters seems plausible)? =A0This is already done for most token namespace=
s in the draft.<br>
></p>
<p>Sounds good.=A0 I'll make the necessary changes for draft -04.=A0 <b=
r></p>
<p>> I wondered also if the tag cache coherence ambiguity could be helpe=
d through the use of some type of data version or serialization token in re=
levant calls?<br>
></p>
<p>Hmm.=A0 That's an interesting idea.=A0 Proposal: If we were to add a=
n OUT parameter to each Get...TLV RPC, which communicated the generation nu=
mber for the tag namespace, then--combined with rx epoch checks--the caller=
would know when to re-fetch the list of available tags.</p>
<p>Although I doubt this issue is likely to come up very often in the real =
world, an additional four byte payload hardly seems objectionable...</p>
<p>Does that sound reasonable and sufficient?=A0 If so, I can incorporate t=
he idea into draft -04...</p>
<p>Thanks very much for the feedback.</p>
<p>-Tom</p>
<p>> Matt<br>
><br>
> ----- "Tom Keiser" <<a href=3D"mailto:tkeiser@sinenomine.=
net">tkeiser@sinenomine.net</a>> wrote:<br>
><br>
> > Hi All,<br>
> ><br>
> > Now that the elections are complete, I'd like to make a secon=
d call<br>
> > for review of draft-tkeiser-afs3-volser-tlv-03. =A0Any feedback w=
ould<br>
> > be<br>
> > greatly appreciated.<br>
> ><br>
> > Cheers,<br>
> ><br>
> > -Tom<br>
> ><br>
> ><br>
> > Tom Keiser <<a href=3D"mailto:tkeiser@sinenomine.net">tkeiser@=
sinenomine.net</a>> wrote:<br>
> > > The other week I submitted a new draft to the IETF which imp=
lements<br>
> > > the aforementioned changes (as well as a few others). =A0The=
new<br>
> > draft<br>
> > > is available at the following URLs:<br>
> > ><br>
> > > <a href=3D"http://tools.ietf.org/html/draft-tkeiser-afs3-vol=
ser-tlv-03">http://tools.ietf.org/html/draft-tkeiser-afs3-volser-tlv-03</a>=
<br>
> > ><br>
> > <a href=3D"http://openafs.sinenomine.net/~tkeiser/i-d/draft-tkeis=
er-afs3-volser-tlv-03.html">http://openafs.sinenomine.net/~tkeiser/i-d/draf=
t-tkeiser-afs3-volser-tlv-03.html</a><br>
> > ><br>
> > <a href=3D"http://openafs.sinenomine.net/~tkeiser/i-d/draft-tkeis=
er-afs3-volser-tlv-03.xml">http://openafs.sinenomine.net/~tkeiser/i-d/draft=
-tkeiser-afs3-volser-tlv-03.xml</a><br>
> > ><br>
> > <a href=3D"http://openafs.sinenomine.net/~tkeiser/i-d/draft-tkeis=
er-afs3-volser-tlv-02-03.xml.diff">http://openafs.sinenomine.net/~tkeiser/i=
-d/draft-tkeiser-afs3-volser-tlv-02-03.xml.diff</a><br>
> > ><br>
> > ><br>
> > /afs/<a href=3D"http://sinenomine.net/user/tkeiser/public_html/i-=
d/draft-tkeiser-afs3-volser-tlv-03.txt">sinenomine.net/user/tkeiser/public_=
html/i-d/draft-tkeiser-afs3-volser-tlv-03.txt</a><br>
> > ><br>
> > /afs/<a href=3D"http://sinenomine.net/user/tkeiser/public_html/i-=
d/draft-tkeiser-afs3-volser-tlv-03.html">sinenomine.net/user/tkeiser/public=
_html/i-d/draft-tkeiser-afs3-volser-tlv-03.html</a><br>
> > ><br>
> > /afs/<a href=3D"http://sinenomine.net/user/tkeiser/public_html/i-=
d/draft-tkeiser-afs3-volser-tlv-03.xml">sinenomine.net/user/tkeiser/public_=
html/i-d/draft-tkeiser-afs3-volser-tlv-03.xml</a><br>
> > ><br>
> > /afs/<a href=3D"http://sinenomine.net/user/tkeiser/public_html/i-=
d/draft-tkeiser-afs3-volser-tlv-02-03.xml.diff">sinenomine.net/user/tkeiser=
/public_html/i-d/draft-tkeiser-afs3-volser-tlv-02-03.xml.diff</a><br>
> > ><br>
> > ><br>
> > > The complete revision history is as follows:<br>
> > ><br>
> > > - split unsigned 64-bit type down into several more descript=
ive<br>
> > types<br>
> > > that allow the TLV data stream to be more self-describing.<b=
r>
> > > - add a signed 64-bit integer type to allow for relative tim=
estamps<br>
> > > - now that we have more descriptive types, use them in a num=
ber of<br>
> > places<br>
> > > - change AFSVOL_TLV_TAG_VOL_TRANS_CALL_VALID into a boolean =
type<br>
> > payload<br>
> > > - make sure rxgen can parse the XDR in the appendix<br>
> > > - make sure generated C code compiles and links<br>
> > > - add in-text cites for AFS3-VVL, AFS3-FSCM, DAFS, and OSD.<=
br>
> > > - provide motivations for GetCapabilities RPC<br>
> > > - provide protocol semantic definitions for each newly alloc=
ated<br>
> > capability bit<br>
> > > - allocate AFSVOL_TLV_FLAG_MORE bit to notify caller when we=
can't<br>
> > > send all tags due to AFSVOL_TLV_TAG_MAX length limit<br>
> > ><br>
> > > Any comments or feedback are appreciated.<br>
> > ><br>
> > > -Tom<br>
> > ><br>
> ><br>
> > _______________________________________________<br>
> > AFS3-standardization mailing list<br>
> > <a href=3D"mailto:AFS3-standardization@openafs.org">AFS3-standard=
ization@openafs.org</a><br>
> > <a href=3D"http://michigan-openafs-lists.central.org/mailman/list=
info/afs3-standardization">http://michigan-openafs-lists.central.org/mailma=
n/listinfo/afs3-standardization</a><br>
><br>
> --<br>
><br>
> Matt Benjamin<br>
><br>
> The Linux Box<br>
> 206 South Fifth Ave. Suite 150<br>
> Ann Arbor, MI =A048104<br>
><br>
> <a href=3D"http://linuxbox.com">http://linuxbox.com</a><br>
><br>
> tel. 734-761-4689<br>
> fax. 734-769-8938<br>
> cel. 734-216-5309<br>
> _______________________________________________<br>
> AFS3-standardization mailing list<br>
> <a href=3D"mailto:AFS3-standardization@openafs.org">AFS3-standardizati=
on@openafs.org</a><br>
> <a href=3D"http://lists.openafs.org/mailman/listinfo/afs3-standardizat=
ion">http://lists.openafs.org/mailman/listinfo/afs3-standardization</a><br>
</p>
--0016369896bd7adb370497bbb773--