Fwd: [AFS3-std] review comments on draft-keiser-afs3-xdr-union-06
Thomas Keiser
tkeiser@gmail.com
Fri, 4 Apr 2014 16:49:58 -0400
--20cf3011d9df28523404f63da9e8
Content-Type: text/plain; charset=ISO-8859-1
Oops. This was intended to be reply-all.
---------- Forwarded message ----------
From: Thomas Keiser <tkeiser@gmail.com>
Date: Fri, Apr 4, 2014 at 4:47 PM
Subject: Re: [AFS3-std] review comments on draft-keiser-afs3-xdr-union-06
To: Benjamin Kaduk <kaduk@mit.edu>
On Apr 4, 2014 4:24 PM, "Benjamin Kaduk" <kaduk@mit.edu> wrote:
> Hi all,
>
> Another document with delightfully little for me to say about it!
>
> I think the only substantive comment I have is that starting off the
> abstract with "AFS-3 relies upon XDR to carry Rx RPC call payloads" leaves
> the reader wondering what "XDR" is (if they don't know already). Adding a
> few words describing what XDR does could be useful (e.g., "the XDR encoding
> scheme" or "the XDR data format" or "the XDR data format description
> language").
>
>
Hi Ben,
That's a good point. We probably should make such a change. I'll defer to
Andrew and Mike, though, as I'm not even sure I have a copy of the source
xml anymore.
> I think it is well-understood that we are creating an AFS-3 fork of
> XDR/RPC-L by approving this document, and we're okay with that. I don't
> know the state of previous discussions with respect to trying to get this
> extension approved as an IETF standards-track RFC (per RFC 4506's IANA
> considerations) so as to merge the fork back into the main XDR standard.
> Does anyone remember offhand?
>
>
Spencer Shepler contacted me in late 2012 to ask whether I intended this
for IETF standards-track (because he was concerned that I was pushing many
I-D revisions without making any entreaties to his WG). At the time, I
told him that I assumed the mechanism was uninteresting to the NFS WG--due
to their reliance upon ONC RPC's interface versioning mechanism to achieve
a similar effect. Our correspondence died there, so I gather he agreed
with that assessment.
Nevertheless, if the group feels we should seek publication as an extension
to 4506, I'm certainly willing to ask the WG chairs whether they think this
would be of general interest. I can certainly see an argument where
standards-track would make sense; there are many XDR consumers outside of
NFS/ONC RPC that could potentially benefit from this enhancement (e.g.,
NDMP?).
Cheers,
-Thomas
--20cf3011d9df28523404f63da9e8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Oops. =A0This was intended to be reply-all.<div><br><div c=
lass=3D"gmail_quote">---------- Forwarded message ----------<br>From: <b cl=
ass=3D"gmail_sendername">Thomas Keiser</b> <span dir=3D"ltr"><<a href=3D=
"mailto:tkeiser@gmail.com">tkeiser@gmail.com</a>></span><br>
Date: Fri, Apr 4, 2014 at 4:47 PM<br>Subject: Re: [AFS3-std] review comment=
s on draft-keiser-afs3-xdr-union-06<br>To: Benjamin Kaduk <<a href=3D"ma=
ilto:kaduk@mit.edu">kaduk@mit.edu</a>><br><br><br><div dir=3D"ltr"><div =
class=3D"">
<p dir=3D"ltr">On Apr 4, 2014 4:24 PM, "Benjamin Kaduk" <<a hr=
ef=3D"mailto:kaduk@mit.edu" target=3D"_blank">kaduk@mit.edu</a>> wrote:<=
br></p></div><div class=3D"gmail_quote"><div class=3D""><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi all,<br>
<br>
Another document with delightfully little for me to say about it!<br>
<br>
I think the only substantive comment I have is that starting off the abstra=
ct with "AFS-3 relies upon XDR to carry Rx RPC call payloads" lea=
ves the reader wondering what "XDR" is (if they don't know al=
ready). =A0Adding a few words describing what XDR does could be useful (e.g=
., "the XDR encoding scheme" or "the XDR data format" o=
r "the XDR data format description language").<br>
<br></blockquote><div><br></div></div><p dir=3D"ltr">Hi Ben,</p><div>That&#=
39;s a good point. =A0We probably should make such a change. =A0I'll de=
fer to Andrew and Mike, though, as I'm not even sure I have a copy of t=
he source xml anymore.</div>
<div class=3D"">
<div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2=
04);border-left-style:solid;padding-left:1ex">
I think it is well-understood that we are creating an AFS-3 fork of XDR/RPC=
-L by approving this document, and we're okay with that. =A0I don't=
know the state of previous discussions with respect to trying to get this =
extension approved as an IETF standards-track RFC (per RFC 4506's IANA =
considerations) so as to merge the fork back into the main XDR standard. =
=A0Does anyone remember offhand?<br>
<br></blockquote><div><br></div></div><div><p dir=3D"ltr">Spencer Shepler c=
ontacted me in late 2012 to ask whether I intended this for IETF standards-=
track (because he was concerned that I was pushing many I-D revisions witho=
ut making any entreaties to his WG).=A0 At the time, I told him that I assu=
med the mechanism was uninteresting to the NFS WG--due to their reliance up=
on ONC RPC's interface versioning mechanism to achieve a similar effect=
. =A0Our correspondence died there, so I gather he agreed with that assessm=
ent.<br>
</p><p>Nevertheless, if the group feels we should seek publication as an ex=
tension to 4506, I'm certainly willing to ask the WG chairs whether the=
y think this would be of general interest. =A0I can certainly see an argume=
nt where standards-track would make sense; there are many XDR consumers out=
side of NFS/ONC RPC that could potentially benefit from this enhancement (e=
.g., NDMP?).</p>
<p>Cheers,</p><p>-Thomas</p></div></div></div></div></div></div>
--20cf3011d9df28523404f63da9e8--