Subject: [apps-discuss] APP => ART: what are the criteria for IETF application work?

From: Larry Masinter <[email-masked]>
Date: Thu, 28 May 2015 01:34:30 +0000

The recent discussion about updating the Gopher protocol has
raised some heat, but the disagreements seem to rest on the
questions of how application protocol work is accepted or
rejected in the various streams, and by what criteria.

First, it should be clear that there is no need for any
application work to wait for the IETF to do something
in order to design, build, specify, test, deploy application
protocols. Proprietary protocols are abundant, there are
many consortia, other SDOs that do application protocol
work, without any interaction with the IETF.

A group working on applications should bring that work
to the IETF when the advantages exceed the costs, for
both the group and the whole Internet community.

I think the main benefits rest around getting review
from the broader group, but getting review involves
the cost of arranging it, dealing with review comments
you think are irrelevant, insulting, uninformed, etc.

Given limited resources of IETF, IETF application work
should focus on high-value projects that would benefit
from the context of being done within the IETF.

The various channels for bringing work to the
IETF (independent,new WG,existing WG,area WG,AD)
may have different requirements for the question
“Is the work of interest to the Internet community?”
but can we please use the same metric for that
question?

Being clearer to ourselves and newcomers about
application work seems like a good thing to manage
in the APP => ART transition/merger.

Larry
—

http://larry.masinter.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 27 May 2015 20:16:31 -0700

> you think are irrelevant, insulting, uninformed, etc.

I don't think anyone is arguing any of those points, except for one: While
it's true that sometimes one has to deal with insulting feedback, I also
think that plain fact is unfortunate and doesn't excuse the people who make
the choice to employ it.  Multiple replies on this topic, which could have
been delivered politely and/or constructively, were instead scattered
between plainly dismissive and pointedly rude, and I have been unable to
figure out how it's justified.

I certainly know what I would think of the IETF if, as a newcomer, I had
been on the receiving end of it.

-MSK

---

From: Larry Masinter <[email-masked]>
Date: Thu, 28 May 2015 05:56:23 +0000

If the question is whether the work is important enough to do here, to say no is not being inappropriately dismissive. Dismissive (of the work) is what is called for if no is the right answer.

--

On May 27, 2015, at 8:16 PM, Murray S. Kucherawy <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, May 27, 2015 at 6:34 PM, Larry Masinter <[email-masked]<mailto:[email-masked]>> wrote:

I don't think anyone is arguing any of those points, except for one: While it's true that sometimes one has to deal with insulting feedback, I also think that plain fact is unfortunate and doesn't excuse the people who make the choice to employ it.  Multiple replies on this topic, which could have been delivered politely and/or constructively, were instead scattered between plainly dismissive and pointedly rude, and I have been unable to figure out how it's justified.

I certainly know what I would think of the IETF if, as a newcomer, I had been on the receiving end of it.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 27 May 2015 23:27:12 -0700

On Wed, May 27, 2015 at 10:56 PM, Larry Masinter <[email-masked]> wrote:

>  If the question is whether the work is important enough to do here, to
> say no is not being inappropriately dismissive. Dismissive (of the work) is
> what is called for if no is the right answer.
>

I agree, Larry.  But that's not what happened.

-MSK

---

From: Claudio Allocchio <[email-masked]>
Date: Thu, 28 May 2015 10:00:27 +0200 (CEST)

very true Larry...

> http://larry.masinter.net

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

---

From: Dave Cridland <[email-masked]>
Date: Thu, 28 May 2015 09:59:54 +0100

> from the context of being done within the IETF.
It's not wholly clear to me how one might objectively measure that, short
of employing a crystal ball. In addition, it seems to me that you're not
concerned with the benefit to the project in question, but only the benefit
to the IETF. Now if the IETF is actually a self-serving collective of old
boys, that's an ideal criterion, but I'm hoping that's not what you meant.

The fact is that we have dozens of strands of work that are remarkably
esoteric. There's currently discussions about forming a working group to
discuss an atomic replace operation for IMAP. Hardly a groundbreaking
effort for the IETF, it just happens that the folks interested in it prefer
to work within the IETF structure, and output an RFC. I don't see anything
wrong with this at all - if people are willing to work here, then the worst
that happens is insufficient review, and if you care about that, there's a
quite obvious solution.

If the argument is that unless the IETF wholeheartedly gathers its
resources and hurls them at a problem it's not worth solving, then we
should pretty much immediately drop the IMAP REPLACE work. Only a
vanishingly tiny group of people will care. No headlines will be written,
either way.

On the other hand, I see significant value in attracting new communities to
the IETF, if only to improve the resources we have in both breadth and
depth. Who knows, maybe we'll attract some of those exciting young people
in their fifties.

What worries me is that really the only difference between the IMAP REPLACE
work and this Gopher work is that the people involved in the IMAP REPLACE
work are better known in the community. That's not a criterion I'm remotely
comfortable with.

> in the APP => ART transition/merger.

So we're merging areas in response to less work, and you're suggesting that
the correct reaction to this merge is to reduce the amount of work.

There's a logical conclusion to this.

Dave.