Re: draft-rfced-info-banan-00.txt (EMSD)

[Keith Moore <moore@cs.utk.edu>]

>   Keith> I do not consider this document fit for publication as an RFC
>   Keith> in its current form.
> 
> Since I understand that you are an Area
> Director, this statement is very grave and
> causes all kinds of problems.
> 
> First, in the case of referral of a non-IETF
> document for publication as an Informational
> RFC, which does not represent an Internet
> recommendation of any sort, the determination
> for fitness for publication is with the RFC
> Editor not by the IESG or by you.

I understand that.  However, IESG was asked by the RFC Editor to
comment on the draft.  As APPS area director, I am recommending that
the draft not be published as an RFC.  If the RFC Editor chooses
not to accept my recommendation, I will help write an IESG note to 
be included with the published document.

> Further, that determination by the RFC Editor
> is supposed to be based on the following 3
> criterias.
> 
> 
>     1)  Relevance to Internet activity
> 
>         There should be no question about 
>         draft-rfced-info-banan-00.txt's relevance to Internet.

On the contrary, the relevance is highly questionable.  It will not be
relevant in a practical sense unless it might be widely deployed.  

(On the other hand, if the protocol stands a chance of being deployed, 
it might be a good idea to both document the protocol and the reasons
why it should not be deployed, in order to discourage deployment.)


>         This is a super hot topic. For example, every palmtop and 
>         handheld PC is begging to become a two-way pager over wireless 
>         IP. There are no Internet Mail Protocols that address that 
>         specific domain. draft-rfced-info-banan-00.txt has an obvious 
>         clear place there.
>         Keith has acknowledged this explicitly.

Yes, I acknowledged that there is a need for something in this problem space.
That does not imply that your protocol is a good solution or that your
protocol spec is worthy of publication as an RFC. 

>     2)  Meets the editorial standard for RFCs
> 
> 	I have been using the LaTeX templates in the rfc repository
>         directory for many years now. So the format should be 
>         fine.

This is really up to the RFC editor, but I'll point out that 
there is a lot more to an 'editorial standard' than the way 
the document is formatted.  

>     3)  Meets the technical standard for RFCs
> 
>         This specification is the result of 4 years of
>         development work by a  number of engineers.
>         The specification is generally complete.

A number of engineers disagree with you in this regard, and believe that
your protocol is neither complete nor well-designed.  Reasonable people
can disagree, of course, but it's up to the RFC Editor staff to decide 
for themselves whether your document merits publication as an RFC.
(after consulting with IESG and other technical experts such as they
choose to consult with)   

As for fixing the problems with your document, I personally feel that 
there are too many problems with your protocol to use it as a base
for a protocol that should be widely adopted, and therefore that it
is not worth the effort of IESG or the RFC editor to invest the effort
in fixing your document.  The RFC Editor, of course, might disagree.
As I've already said, if you could demonstrate that your protocol were
likely to be widely deployed, this would weigh in favor of publication
(albiet it with an appropriate disclaimer).



> Those are gross generalities with which I don't
> know what to do.
> 
> First, a quick review of something like this is
> likely to be problematic.  I really don't
> expect you to understand many of the aspects of
> what we have been working on over the past 4
> years all that quickly. I don't think anyone can.

And I don't expect you to have the understanding that comes from working
on Internet email systems for 15-20 years.

> Given its requirements and goals (which are
> documented), the protocol is as complex as it
> needs to be. First hand development experience
> with the protocol has been quite positive and
> complexity has not been a problem.

I disagree.  Complexity might not be a problem for your company and
its business model, but complexity is most assuredly a problem
for protocols with numerous and diverse implementations that must 
interoperate.  You claim "first hand" developlement experience,
but how much experience do you have trying to interoperate with
other groups who have developed the protocol from scratch?

> Can we please turn this into a positive and
> productive interaction?

Given your tirade on the IETF list, I am very dubious that this is possible.

I'm not going to take the time to respond to your other questions
unless the RFC editor requests that I do so.  IESG reviews a
large number of documents, and IESG members do not have the time
to give detailed feedback on each one -- especially when such
feedback seems unlikely to result in a document that merits 
publication.  


Keith