[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.
- [ppsp] Barry Leiba's Discuss on draft-ietf-ppsp-b… Barry Leiba
- Re: [ppsp] Barry Leiba's Discuss on draft-ietf-pp… Huangyihong (Rachel)
- Re: [ppsp] Barry Leiba's Discuss on draft-ietf-pp… Barry Leiba