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

Barry Leiba <barryleiba@computer.org> Mon, 19 October 2015 15:13 UTC

Return-Path: <barryleiba@gmail.com>
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 877171AC3C1; Mon, 19 Oct 2015 08:13:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 WNPKaN8oEHyN; Mon, 19 Oct 2015 08:13:39 -0700 (PDT)
Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2B491A9116; Mon, 19 Oct 2015 08:13:38 -0700 (PDT)
Received: by vkat63 with SMTP id t63so105931925vka.1; Mon, 19 Oct 2015 08:13:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yVbds7UxCdtVGlWRJ17WqYJWiE/FhKttlI56mLJkil8=; b=x1Ke5fZm0zJ3BcrBQ4v0HMwFPVNWw1bNOR9iagl6C5jo2JR7rUj5OG2tXlhGJWc3CR To0KqSMgDdOF+NJd9ZjKjDglvpNoLCD6QpGwzhsb5ifeV3DoklINjwIoqlS5kUxFbUEc cdX6DVuBSZx8F2lomA59htP189GAlqGy2JEpgWBCxsOlqjs5LZvY4NoaqvhSNOKrLQ0s 1gYcxUGXxsvQVg6p8e0XkEzp/PwT31Kh77n614DF4l6q4F0KGfP5QjVUWYmNJ0FhUD44 K08f/ug2AbGMuRXnU9AXrb3tgxtJC1TiSSSs+cSE2EohAM6r3e6sALffyXh50pb7JZGp vVKg==
MIME-Version: 1.0
X-Received: by 10.31.170.80 with SMTP id t77mr20103030vke.156.1445267617825; Mon, 19 Oct 2015 08:13:37 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.31.54.65 with HTTP; Mon, 19 Oct 2015 08:13:37 -0700 (PDT)
In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86441BF2@nkgeml501-mbs.china.huawei.com>
References: <20151015043105.10919.514.idtracker@ietfa.amsl.com> <51E6A56BD6A85142B9D172C87FC3ABBB86441BF2@nkgeml501-mbs.china.huawei.com>
Date: Mon, 19 Oct 2015 11:13:37 -0400
X-Google-Sender-Auth: GJ6FjPl1QSdQ5jDKZxeM--pcnW0
Message-ID: <CALaySJKsxrh3cN1bXtW+922vOtSuKPh8HehdGhW6E9GZZT4AtQ@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: "Huangyihong (Rachel)" <rachel.huang@huawei.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ppsp/OxzA0ltx2N781orcpW45LQ68gDo>
Cc: "ppsp-chairs@ietf.org" <ppsp-chairs@ietf.org>, "ppsp@ietf.org" <ppsp@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-ppsp-base-tracker-protocol@ietf.org" <draft-ietf-ppsp-base-tracker-protocol@ietf.org>
Subject: Re: [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
Precedence: list
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: Mon, 19 Oct 2015 15:13:40 -0000

Hi, Rachel, and thanks for addressing my comments.

>> -- 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?
>
> [Rachel]: Actually we mean name = quotation-mark *char quotation-mark.
> [RFC7159] has specified it, so how about we delete the related sentences?

Yes, that seems best; I'll have another look after you're updated the document.

>> -- Subsections of 3.2 --
>> Where are the semantics of the string values, such as "HIGH", "NORMAL",
>> and "LOW", defined?
>
> [Rachel]: Right. And I think it's hard to define any empirical value
> in this document. So how about changing the meaning of the 4 optional
> attributes to the requesting peer's status? So that concurrent_links,
> online_time, upload_bandwidth can be changed to ppsp_tp_integer_t
> type. Thus, tracker can do some peer selection based on peer's current
> status?

Your suggestion here seems fine, if you add a few words to give a
sense of what the integer value might mean (realizing that it's going
to be vague, and that vague is OK).

>> 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?
>
> [Rachel]: A peer can share the received chunks even if it doesn't have
> all the chunks. So how about changing to "A peer that has nothing or
> has not yet received all chunks of the media content"?

That's fine; thanks.

Barry