Re: Informational RFC to be: draft-shah-extreme-eaps-05.txt

[RJ Atkinson <rja@extremenetworks.com>]

On Wednesday, Jan 22, 2003, at 17:56 America/Montreal, Bill Fenner 
wrote:
> > "send text".
> The text already says
>
> 	The second statment is used when "republishing" standards produced
> 	by ... individual companies.
>
> which seems to describe Ran's intent fairly precisely.  Maybe the 
> problem
> is that the three statements to choose between precede the text that
> describes their intent, so if you think you know the intent you might
> skip the explanatory text?
(NB: I'll spin the I-D to use the second version of boilerplate in order
to make the IESG happy; will take a day or two of course to get the new
I-D through the system. :-)

That noted,

	I selected option (3) because after reading RFC-2026, Section 10, it 
seemed
that such was sufficient for the purpose and was the best fit.  After 
all, RFC-2026,
Section 10 is focused on IETF stuff and the publication of an 
individual-submission
that is unrelated to anything in the IETF ought not have to jump 
through a bunch of hoops
that are needed only for stuff originating with an IETF WG or destined 
for the IETF
standards-track.  So my "mistake" was actually trying to be a good 
citizen and
actually read the RFC text and consider what it said before selecting a 
boilerplate.
Folks with nefarious intent no doubt would not actually try to read 
that text.

	Perhaps my confusion was that I think of the RFC-Editor as being a 
separate
entity from the IETF and that now the RFC-Editor is de facto part of 
the IETF.
I used to think the two were separate, but maybe I was just confused.  
In this
regard, the boilerplate in question talks about limiting what rights 
the *IETF*
is granted, not about what rights the *RFC Editor* is granted.  It was 
easy for me
to consider that one might not grant the IETF any rights other than to 
publish
as an I-D, whilst not so limiting the RFC Editor (which, again, I 
thought was
separate from, albeit cooperative with, the IETF).  Sorry for my 
confusion on
that front.

	The second boilerplate option requires that a proposed 
individual-submission RFC
that is not related to IETF work (e.g. the case here) agree to a lot of 
stuff in
RFC-2026 Section 10 that is not in any way relevant.  For example, the 
actual
text of RFC-2026 Section 10.3.1.6 talks about "contributions" (to the 
IETF process),
when in fact the documents are not necessarily "contributions" to the 
*IETF* at all,
but rather might well be intended as information for the broader 
Internet community
(specifically not limited to or focused upon the IETF as a standards 
body) in the
RFC tradition dating back many many years before the existence of IPv4.

	Note also that the text about the 3rd option talks specifically about
how documents in that mode cannot be used as the basis for any IETF WG
activity.  Well, since we aren't (to my knowledge) targeting an IETF WG
but are instead making information available for the broader Internet 
community,
"can't be used as the basis for any IETF WG activity" sounds about 
right.  Certainly
it is not Extreme's intent (as far as I know) to propose that IETF 
undertake any
sort of standards activity with regards to EAPS.  I did talk the 
company into
making the information public, because I thought that this was a good 
thing
for the broader Internet community.

	IMHO, a better approach would be either to edit the third choice to 
permit
RFC publication (subject to the usual processes for any individual 
submission),
OR create a 4th option which is identical to the 3rd option but also 
permitting
RFC publication (subject to the usual processes for any individual 
submission).

	I'm definitely not the world's best editor, but maybe this means 
replace
"...publish as an  internet-draft" with "...publish as an 
internet-draft or
publish as an RFC (if so requested and subject to normal RFC Editor 
processes)."
[edit to taste]

Yours,

Ran
rja@extremenetworks.com