Subject: [appsdir] Request for review: draft-ietf-decade-reqs-05

From: SM <[email-masked]>
Date: Tue, 10 Jan 2012 13:51:02 -0800

Hi John,

Could you review draft-ietf-decade-reqs-05 before January 20?  Please 
post your review to apps-discuss (see below), and DO NOT post it to appsdir.

The review should be sent to apps-discuss, the authors, the WG Chairs 
and document shepherd, if applicable.  You can use the tools alias 
[email-masked] to cover the authors, WG 
chairs, and shepherd.  If your review recommends significant changes 
to a working-group document, you should also consider copying the 
working group's mailing list.

Suggested distribution:
    To: [email-masked],   [email-masked]
    Cc: [email-masked]

You can view the Apps-review template at 
http://trac.tools.ietf.org/area/app/trac/wiki/template  Some previous 
reviews are accessible at http://trac.tools.ietf.org/area/app/trac/wiki/tracker

Best regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Tue, 10 Jan 2012 19:03:44 -0500

Hi SM,

These comments are procedural ones within the Review Team/
Directorate and not intended as a substantive review of the
document, so I am sending it back to the list you copied on the
request and adding Dave Harrington for reasons that will be
obvious.

I am willing to try to do this, but, after a quick look at the
DECADE work and charter, I have three observations that may
suggest handling it differently:

(1)  This document, which is supposedly a requirements
statement, should probably be considered only in the light of
the abbreviated problem statement in the DECADE charter, the
revised and more extensive problem statement in
draft-ietf-decade-problem-statement and the putative
architecture in draft-ietf-decade-arch-04.  I note that,
according to the I-D database, the problem statement is under
discussion with the AD and the architecture statement is also in
"publication requested" state.  Since a key criterion for a
requirements statement is that it address the issues in the
problem statement, I believe that we should defer a review on
this document (whether I do it or someone else does) until the
Problem Statement is stable.  See Dave Harrington's rather
extensive comments, and request for a new I-D, in the tracker as
of 2011-12-16.

(2) The comments above also suggest that, when all three
documents are ready, they should be reviewed by the same person
or as part of a coordinated effort.  I do not have time to be
that person this month.   In addition...

(3) In the interest of full disclosure (even though what I'm
about to say will not come as news to many of the readers of
this note), I have attitudes toward application protocol designs
and architectures that are left over from experiences gained
starting with the very first (circa 1970-71) applications
development efforts for the ARPANET, including an understanding
of how those architectures did and did not require changes for
the Internet and, more important, how they were informed by bad
experiences with other architectures.  In that context, I
suggest that:

(3a) Most Internet applications are peer to peer in the sense
that, administrative restrictions aside, there is nothing in the
Internet world that is  particularly special about being able to
listen on a port for a connection.   The ability to initiate a
(virtual?) connection does not a client make, even though we may
find that terminology convenient.  Conversely, if it were the
fact of initiating a connection that made a host a client, then
there are no, or substantially no, unbrokered P2P applications.
Put differently, one may use an intrinsically P2P application
like SMTP or FTP in a client-server style or describe its
operation in client-server terms, but neither makes it other
than a P2P application.

(3b) By contrast, an application or set of applications that
operate, not between a pair of hosts, but with significant
look-aside to obtain network-based resources from other hosts or
systems, that application is inherently multiparty.  It is not
peer to peer in any of the classic uses of that terminology.   I
think I know how to think about peer to peer relationships in a
mesh but, from reading the charter, that is not what DECADE is
about.

(3c) As you may have deduced from the above, I have an extremely
bad attitude toward applications and application architectures
that require or enable highly centralized services, especially
services provided by "service providers" rather than, e.g.,
"application providers".  We know where those approaches lead
and those places include monopoly or oligarchic leverage, the
costs that go with that, and the regulators that typically
follow in that sequence (perhaps if one is lucky because the
alternates are sometimes worse). To a considerable degree, the
network we are now running was designed around the notion of
getting back into those traps.

I do not mean to suggest that the DECADE work should not be
done.  If people are going to do these things, then it is
probably better to have them done in a standard way with careful
investigation of security, privacy, and long-term economic
implications (not just assertions about saving bandwidth and
similar resources).  But it may be impossible for me to do a
review without my biases about architectural models and the
importance of correct and precise terminology dominating it.
So, for that reason even if not the advantages of an integrated
review of the three documents, you might want to find someone
else.

     regards,
       john

--On Tuesday, January 10, 2012 13:51 -0800 SM
<[email-masked]> wrote:

> Hi John,
> 
> Could you review draft-ietf-decade-reqs-05 before January 20?
> Please post your review to apps-discuss (see below), and DO
> NOT post it to appsdir.
> 
> The review should be sent to apps-discuss, the authors, the WG
> Chairs and document shepherd, if applicable.  You can use the
> tools alias [email-masked] to
> cover the authors, WG chairs, and shepherd.  If your review
> recommends significant changes to a working-group document,
> you should also consider copying the working group's mailing
> list.
> 
> Suggested distribution:
>     To: [email-masked],
> [email-masked]
>     Cc: [email-masked]
> 
> http://trac.tools.ietf.org/area/app/trac/wiki/template  Some
> previous reviews are accessible at
> http://trac.tools.ietf.org/area/app/trac/wiki/tracker
> 
> Best regards,
> -sm
> 
> _______________________________________________
> appsdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/appsdir

---

From: SM <[email-masked]>
Date: Tue, 10 Jan 2012 16:58:30 -0800

Hi John,
>request and adding Dave Harrington for reasons that will be

I'll provide some background on how this draft ended up in the batch 
of assignments.  As you may have noticed, the Applications 
Directorate has been doing early reviews of drafts and this draft was 
selected as part of the early review effort.

>"publication requested" state.  Since a key criterion for a

Although I read each draft and sometimes the background discussion, 
it is not possible for me to have a good view before sending out the 
assignment.  I noticed the state and misguidedly assumed that the 
draft was considered as ready for publication.

>extensive comments, and request for a new I-D, in the tracker as

I am Ok with deferring the review.  I would appreciate if Dave 
Harrington sent me a note if he would like an Appsdir review.

>that person this month.   In addition...

Ok.  It is a problem for me to ask someone to review three drafts at 
the same time.  I try to distribute the workload or else it will end 
up as a more work for a subset of the team.

>getting back into those traps.

If a reviewer has a strong opinion about a draft, it is entirely 
appropriate for him to decline the assignment.  From what you 
explained above, I prefer if you do not take up the review of 
draft-ietf-decade-reqs-05.

>importance of correct and precise terminology dominating it.

See above.

>review of the three documents, you might want to find someone

Thanks for the advice.

As you might have guessed, there will be other Appsdir requests. :-)

Best regards,
-sm

---

From: John C Klensin <[email-masked]>
Date: Tue, 10 Jan 2012 22:26:36 -0500

SM,

One further comment...

--On Tuesday, January 10, 2012 16:58 -0800 SM
<[email-masked]> wrote:

>> documents are ready, they should be reviewed by the same
>> person or as part of a coordinated effort.  I do not have
>> time to be that person this month.   In addition...
> 
> Ok.  It is a problem for me to ask someone to review three
> drafts at the same time.  I try to distribute the workload or
> else it will end up as a more work for a subset of the team.

Understood.  But, first, there are long drafts and short drafts.
I This "requirements" piece is 24 (really 23) pages long
(including boilerplate).   The corresponding "problem statement"
piece is a tad over 14 and some of Dave's comments could easily
result in the next version being shorter.  The "architecture"
piece is somewhat longer, running to 44 pages.  But, even then,
it is not clear to me that reviewing one 75 or 100 page document
is a lot easier than reviewing 82 pages or closely-related ones.

Second, it would take a bit more coordination on your part, but
it seems to me that the requirement/preference implicit in my
suggestion could be served as well by having three (or two)
reviewers who were willing to coordinate and exchange reactions
enough to do a coordinated or integrated set of reviews.

Just some thoughts.

best,
    john

---

From: SM <[email-masked]>
Date: Tue, 10 Jan 2012 21:09:43 -0800

Hi John,
>is a lot easier than reviewing 82 pages or closely-related ones.

Yes.  I picked three reviews last year as they were closely 
related.  I'll give what you suggested above a try.

>enough to do a coordinated or integrated set of reviews.

I don't mind the extra coordination.  I am going to do an experiment 
based on your suggestion.  I am going to have two reviewers for each 
assignment from the next batch and ask for a joint review.  The first 
reviewer gets to select someone else on the team to work with 
him/her.  In case it is not clear:

   (a) Assignment to first reviewer

   (b) First reviewer acks assignment

   (c) First reviewer contacts another reviewer from the team

   (d) Second reviewer acks

   (e) Joint review performed

If any of you have any comments about the above, please post them to 
the list or send them to me.

Best regards,
-sm