[ppsp] Richard Barnes' Discuss on draft-ietf-ppsp-peer-protocol-10: (with DISCUSS and COMMENT)

"Richard Barnes" <rlb@ipv.sx> Wed, 09 July 2014 17:03 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Richard Barnes <rlb@ipv.sx>
To: The IESG <iesg@ietf.org>
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140709170317.32254.77889.idtracker@ietfa.amsl.com>
Date: Wed, 09 Jul 2014 10:03:17 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/ppsp/FeapGRe5gsfpMAQRLTmallmdTeM
Cc: ppsp@ietf.org, draft-ietf-ppsp-peer-protocol@tools.ietf.org, ppsp-chairs@tools.ietf.org
Subject: [ppsp] Richard Barnes' Discuss on draft-ietf-ppsp-peer-protocol-10: (with DISCUSS and COMMENT)

Richard Barnes has entered the following ballot position for
draft-ietf-ppsp-peer-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 http://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:
http://datatracker.ietf.org/doc/draft-ietf-ppsp-peer-protocol/



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

My DISCUSS here is based mainly on the readability of the document, which
seems bad enough to be an impediment to interoperability.  

As far as I can tell, this document does not define a protocol, in the
sense of a set of actions required to achieve a given objective. 
Instead, it presents a pile of piece parts with a couple of combinations,
and notes that these combinations could be used to achieve, e.g., live
streaming.  (In the language of patents, it has not been "reduced to
practice".)

What are the steps an implementation follows to join a swarm?  To connect
to a new peer and request chunks?  The pieces seem to be here, but the
big picture is completely absent.


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

"In general, no error codes or responses are used in the protocol;
absence of any response indicates an error." -- This made me do a bit of
a double-take.  Obviously, the requesting peer should timeout if the
responding peer doesn't respond, but are there really no cases where the
responding peer knows there's a problem and wants to report it?  It seems
like the CHOKE message is an indication of this sort.

[ppsp] Richard Barnes' Discuss on draft-ietf-ppsp… Richard Barnes