[ppsp] Barry Leiba's Discuss on draft-ietf-ppsp-base-tracker-protocol-10: (with DISCUSS and COMMENT)

"Barry Leiba" <barryleiba@computer.org> Thu, 15 October 2015 04:31 UTC

Return-Path: <barryleiba@computer.org>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D691B302E; Wed, 14 Oct 2015 21:31:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5vmWyrCZ-4m; Wed, 14 Oct 2015 21:31:05 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF461B2AEE; Wed, 14 Oct 2015 21:31:05 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Barry Leiba <barryleiba@computer.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.6.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151015043105.10919.514.idtracker@ietfa.amsl.com>
Date: Wed, 14 Oct 2015 21:31:05 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/ppsp/aWgkut9EPM0NoISwgmEmZu-k2pE>
Cc: ppsp-chairs@ietf.org, ppsp@ietf.org, draft-ietf-ppsp-base-tracker-protocol@ietf.org
Subject: [ppsp] Barry Leiba's Discuss on draft-ietf-ppsp-base-tracker-protocol-10: (with DISCUSS and COMMENT)
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: discussing to draw up peer to peer streaming protocol <ppsp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ppsp>, <mailto:ppsp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ppsp/>
List-Post: <mailto:ppsp@ietf.org>
List-Help: <mailto:ppsp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ppsp>, <mailto:ppsp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Oct 2015 04:31:07 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-ppsp-base-tracker-protocol-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ppsp-base-tracker-protocol/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

You use RFC 2616 as a reference for HTTP 1.1, but that's obsolete, and
the current reference should be RFC 7230 for the general references and
RFC 7231, Section 3.1.1.5 for Content-Type (the citation in Section 4
here).  The Security Considerations section should cite both 7230 and
7231.

-- Section 3.1 --

   A JSON object consists of name/value pairs.  The JSON names of the
   pairs are indicated with "".

I don't find the meaning of the second sentence to understandable at all.
 What are you trying to say?

-- Subsections of 3.2 --
Where are the semantics of the string values, such as "HIGH", "NORMAL",
and "LOW", defined?

-- Section 4 --

   For deployment scenarios where Peer (Client) authentication is
   desired at the Tracker, HTTP Digest Authentication MUST be supported,
   with TLS Client Authentication as the preferred mechanism, if
   available.

You need a normative reference to RFC 7616 for HTTP Digest
Authentication, and a citation here.

-- Section 4.1.1.1 --
Please re-check your examples carefully, and pass them through a JSON
validator.  In the first example, for instance, the Content-Length value
is wrong and the "transaction_id" member is missing its ":".  The third
example uses "TransactionID" instead of "transaction_id" for the member
name.

Be careful during AUTH48 that you re-check this, including making sure
that any Content-Length values are still correct after all the editing.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Is the definition give for "LEECH" sufficient?:

   LEECH:  A Peer that has not yet completed the transfer of all Chunks
   of the media content.

I don't think "completed the transfer" is clear enough, and "transfer"
can be outbound or inbound.  Would something like "A Peer that has not
yet received all chunks of the media content, and therefore can't be used
to share the content," be better?  And isn't it possible for a peer to
share the chunks that it has, even if it doesn't have all of the chunks?

You do seem inconsistent with capitalization of terms ("SEEDER" and
"Seeder", "LEECH" and "Leech", "SWARM and "Swarm" and "swarm").  You
should fix that -- readers often find it confusing, and the RFC Editor
will ask you about it during AUTH48.

-- Section 1.2.1 --
I don't understand the meaning of "[Peer Protocol]" in front of list
items 3, 4, and 5.  Why's it there?  And if you're going to leave it
there, I think you might do better to find notation that doesn't look
like how we write reference citations.

-- Section 2.2 --

   Requests are sent, and responses returned to these requests.  A
   single request generates a single response (neglecting fragmentation
   of messages in transport).

The word "neglecting" can make this ambiguous -- it can be taken to mean
that fragmentation can't happen.  It might be better to say it this way:

NEW
   Requests are sent, and responses returned to these requests.  A
   single request generates a single response (though both requests
   and responses can be subject to fragmentation of messages in
   transport).
END

-- Section 4.3 --

   If the peer fails to read the tracker response, the same Request with
   identical content, including the same transaction_id, SHOULD be
   repeated, if the condition is transient.

...and...

   The tracker SHOULD be prepared to receive a Request with a repeated
   transaction_id.

Given the first paragraph, why isn't the SHOULD in the second one a
MUST?

In the list of error responses, why are some of them MUST and others
SHOULD?

-- Section 4.4 --
There are no JSON things called "fields".  Objects have "members" and
arrays have "elements".  I think you mean to use "members" in this
section.

-- Section 7 --

   Additionally, a designer MUST remember that extensions themselves MAY
   also be extensible.

The "MAY" shouldn't be a 2119 key word, and should be changed to lower
case.

-- Section 8.1 --
This is not defining a registry; it's making a registration in the media
types registry.  We no longer use the term "MIME type", so please change
the title to "Media type registration", and change the first paragraph:

OLD
   This document defines registry for application/ppsp-tracker+json
   media types.
NEW
   This document registers the application/ppsp-tracker+json
   media type.
END

You also use "MIME type" in the "File extension" information (you can
actually just change that to "n/a").  And you haven't updated the
registration template to the latest one specified in RFC 6838 -- there's
a new "Fragment identifier considerations" item (which can just be "n/a"
also, but please add it).

-- Section 10 --
Some of your informative references are for required functions, and
should be normative.  In particular, RFC 2616 needs to be changed to 7230
and 7231 (see above) and needs to be normative.  2818 and 5246 should be
normative.  3986 and 5952 tell you how to encode IP addresses, and should
be normative.