[OpenAFS-devel] Re: rx throttle counts in rx-debug-peers

[Tom Keiser]

On Mon, Mar 14, 2011 at 7:03 PM, Simon Wilkinson <sxw@inf.ed.ac.uk> wrote:
>
> On 14 Mar 2011, at 21:42, Andrew Deason wrote:
>
>> On Mon, 14 Mar 2011 16:15:57 -0500
>> Andrew Deason <adeason@sinenomine.net> wrote:
>>
>>>>>> However, discussing OpenAFS implementation details within the RFC
>>>>>> series is definitely inappropriate.
>>>
>>> I don't agree with this as an unqualified statement. The parts of the
>>> wire protocol that are OpenAFS-specific are still a wire protocol
>>> (though not necessarily AFS-3), and my limited understanding of the
>>> IETF is that pretty much any wire protocol is appropriate/eligible as
>>> at least some kind of RFC (in this case, Informational). At least,
>>> from the perspective of the IETF / the RFC series.
>
> I think you are misunderstanding some fundamentals of how the IETF works,=
 and the relationship between the IETF, the RFC series, and the afs3-standa=
rdisation group. The AFS-3 standardisation group does not exist within the =
umbrella of the IETF - in fact, it was felt that it would be very difficult=
 for it to do so. The IETF has a proud history of not rubber stamping exist=
ing protocols, are keen not to duplicate the work of existing working group=
s (in our case, NFSv4), and require the granting of change control that it =
would have been politically difficult to secure. It would be difficult to g=
et any AFS-3 documents past IETF Last Call, even as informational publicati=
ons.
>
> Instead, the afs3-standardisation group has its own model, which is based=
 loosely upon the IETF's (because those drafting the process had some famil=
iarity with the IETF, and believed that what worked there was worth emulati=
ng). Where we converge is in our use of tools, and in particular, in our ar=
chival document series. RFCs contain far more than just IETF documents. The=
re has been a long history of the Independent Submission Stream (note that =
these are distinct from independent submissions to the IETF, which ultimate=
ly end up being IETF documents) - a series of documents from independent au=
thors, which don't pass through the IETF process, and receive minimal scrut=
iny from the IESG. RFC5742 describes the process for publishing within this=
 series.
>
> It should be noted that publishing an RFC is not a lightweight process. I=
t requires the work of the RFC Production Centre to proof, sub edit, and ge=
nerally turn our drafts into publishable documents. It requires the Indepen=
dent Submissions Editor and their advisory board to review that document fo=
r technical content, and to solicit external reviews as required. It requir=
es the IESG to review the document for conflicts with work being done withi=
n the IETF. This is a substantial outlay of time and effort.
>
> We have yet to establish whether publishing AFS-3 standardisation documen=
ts within the Independent Submission Stream is seen as a suitable use of th=
at effort by those administering it. Doing so is one of the outstanding act=
ions on our standardisation group chairs. I firmly believe that doing so fo=
r OpenAFS specific documents would be an entirely inappropriate squandering=
 of scarce resources.
>

When I voiced my support last week, it was not for wasting the IETF's
time.  Rather, it was for utilizing the I-D format and tooling
specifically to publish our own independent OpenAFS-specific document
stream.  I was envisioning something along the lines of submitting
xml2rfc files to gerrit, and then letting them go into the tree
somewhere under doc/, or, perhaps, a new repository on
git.openafs.org, following some period for discussion on
openafs-devel...

Cheers,

-Tom