Re: [ppsp] [Errata Verified] RFC7574 (4724)

이창규 <echkyu@etri.re.kr> Tue, 29 August 2017 02:46 UTC

Return-Path: <echkyu@etri.re.kr>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA951326F7 for <ppsp@ietfa.amsl.com>; Mon, 28 Aug 2017 19:46:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=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 pYGhw5181JnU for <ppsp@ietfa.amsl.com>; Mon, 28 Aug 2017 19:46:01 -0700 (PDT)
Received: from mscreen.etri.re.kr (mscreen.etri.re.kr [129.254.9.16]) by ietfa.amsl.com (Postfix) with ESMTP id 863F51326F4 for <ppsp@ietf.org>; Mon, 28 Aug 2017 19:46:00 -0700 (PDT)
Received: from unknown (HELO smtpeg.etri.re.kr) (129.254.27.142) by 129.254.9.16 with ESMTP; 29 Aug 2017 11:45:55 +0900
X-Original-SENDERIP: 129.254.27.142
X-Original-MAILFROM: echkyu@etri.re.kr
X-Original-RCPTTO: spencerdawkins.ietf@gmail.com, iesg@ietf.org, ppsp@ietf.org, victor.grishchenko@gmail.com, rfc-editor@rfc-editor.org, arno@cs.vu.nl, r.petrocco@gmail.com
Received: from SMTP5.etri.info (129.254.28.75) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 29 Aug 2017 11:45:59 +0900
Received: from SMTP2.etri.info ([169.254.2.9]) by SMTP5.etri.info ([129.254.28.75]) with mapi id 14.03.0319.002; Tue, 29 Aug 2017 11:45:53 +0900
From: =?utf-8?B?7J207LC96rec?= <echkyu@etri.re.kr>
To: =?utf-8?B?6rmA7ISx7Zic?= <shkim@etri.re.kr>, "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, "arno@cs.vu.nl" <arno@cs.vu.nl>, "r.petrocco@gmail.com" <r.petrocco@gmail.com>, "victor.grishchenko@gmail.com" <victor.grishchenko@gmail.com>
CC: "spencerdawkins.ietf@gmail.com" <spencerdawkins.ietf@gmail.com>, "iesg@ietf.org" <iesg@ietf.org>, "ppsp@ietf.org" <ppsp@ietf.org>
Thread-Topic: [Errata Verified] RFC7574 (4724)
Thread-Index: AQHTGoVLrguTR0402Em7Lnz5Zl5MN6KZhOwAgAERiyyAAAky2A==
Date: Tue, 29 Aug 2017 02:45:53 +0000
Message-ID: <71469266360802499C4ECAAFC70B6A423FD853FC@SMTP2.etri.info>
References: <20170821135602.062B5B810E4@rfc-editor.org>, <e1e8642b-0d71-3f11-cd13-9fb116a89975@vu.nl>, <609FE8B8E7BD1248A27BD3B8BC699ABD437F7EB9@SMTP1.etri.info>
In-Reply-To: <609FE8B8E7BD1248A27BD3B8BC699ABD437F7EB9@SMTP1.etri.info>
Accept-Language: ko-KR, en-US
Content-Language: ko-KR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [129.254.28.41]
Content-Type: multipart/alternative; boundary="_000_71469266360802499C4ECAAFC70B6A423FD853FCSMTP2etriinfo_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ppsp/Jwb_V_P7l0d9bILelpVzMwxyRXo>
Subject: Re: [ppsp] [Errata Verified] RFC7574 (4724)
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 29 Aug 2017 02:46:05 -0000

Dear Arno Bekker,


This is Changkyu Lee, one of reporters.

It is glad to hear a new opinion regarding the errata.


Well... I don't think redefining "swarm ID" is not enough to resolve the errata.

However, the new definition can be one great step for resolving the errata.


Let see the errata one by one.


 - 4724 proposes to modify the definition of "swarm ID".

   The report comes from the description when content integrity protection is disabled.


   Your proposal clearly defines "swarm ID" for the situation and it sounds reasonable.

   However, I don't know how a peer recognizes the length of  smallest output of Merkle Hash Tree function.

   Yes, it is possible in implementation level since RFC mandates to implement Merkle Hash Tree function.

   The implementation, of course, can easily get the size, but let's think about the protocol level.


   In protocol level, logically, we cannot guarantee that a peer can get the length of Merkle Hash Tree scheme's output.

   It is because RFC describe that "If PPSPP operates in a benign environment, this scheme MAY be used.", in section 5.


  Maybe we can use your definition when we change the above description in section 5 as follows.

  "This scheme MUST be used even if PPSP operates in benign environment. However use of the scheme in benign environment

   is limited to get the output length of the scheme, and the output length will be used to decide the length of swarm ID when content

   integrity protection scheme is not used."


   Then the link will be perfect with the next sentence, "So the scheme is mandatory to implement, ~".


 - 4725 proposes to remove current description or to add a new description regarding chunk exchange.

   The report does not come from the missing link between swarm ID and content integrity protection scheme.

   It is reported because RFC does not specify how peers exchange chunks when the integrity protection scheme is not used.



   Please see section 2.2. Even in the example, there is no simple mention such as "INTEGRITY message is not used, when

   content integrity protection scheme is disabled."


 - 4726 is similar to 4724. So it can be resolved similarly.


 - 4880 can also be resolved, if RFC has clear description when content integrity protection method is not used.


Thank you again for giving great opinion.



Regards,

===========================================
Chang-Kyu Lee    <echkyu@etri.re.kr<mailto:echkyu@etri.re.kr>>
Researcher
Infrastructure Standards Research Section
Protocol Engineering Center (PEC)
ETRI(Electronics and Telecommunications Research Institute)
138 Gajeongno, Yuseong-gu, Daejeon, 305-700, KOREA
Phone: +82-42-860-6157
Fax: +82-42-861-5404
Mobile: +82-10-3215-0375
===========================================





________________________________
보낸 사람 : "김성혜" <shkim@etri.re.kr>;
보낸 날짜 : 2017-08-29 10:26:25 ( +09:00 )
받는 사람 : 이창규 <echkyu@etri.re.kr>;
참조 :
제목 : FW: [Errata Verified] RFC7574 (4724)




________________________________
보낸 사람 : "Arno Bakker" <abr800@vu.nl>;
보낸 날짜 : 2017-08-29 03:07:01 ( +09:00 )
받는 사람 : RFC Errata System <rfc-editor@rfc-editor.org>;, 김성혜 <shkim@etri.re.kr>;, arno@cs.vu.nl <arno@cs.vu.nl>;, r.petrocco@gmail.com <r.petrocco@gmail.com>;, victor.grishchenko@gmail.com <victor.grishchenko@gmail.com>;
참조 : spencerdawkins.ietf@gmail.com <spencerdawkins.ietf@gmail.com>;, iesg@ietf.org <iesg@ietf.org>;, ppsp@ietf.org <ppsp@ietf.org>;
제목 : Re: [Errata Verified] RFC7574 (4724)



Hello





please stop the press, if possible.





There is a simpler solution. The errata stem from an incomplete



definition of swarm ID. I communicated this to Spencer on March 14th,



2017, before Victor's post to the PPSP mailing list of March 24th.



Unfortunately, there was no communication with me afterwards.





Please advice how to update just the definition (erratum 4724), which



resolves all other errata, IMHO.





The RFC does not tell what the swarm ID is when content integrity



protection is not used. The errata reporters then voice the opinion that



the ability to run without protection should be removed from the RFC and



all their subsequent errata implement that opinion. The IESG did not ask



for the removal, and I also think the no-protection option should be kept.





Therefore, the only relevant erratum is 4724. As a resolution I propose



to change the definition of a swarm ID as follows:





Original:



"swarm ID



Unique identifier for a swarm of peers, in PPSPP a sequence of



bytes. For video on demand with content integrity protection



enabled, the identifier is the so-called root hash of a Merkle



hash tree over the content. For live streaming, the swarm ID is



a public key.



"





NEW



"swarm ID



Unique identifier for a swarm of peers, in PPSPP a sequence of



bytes. For video on demand with content integrity protection



enabled, the identifier is the so-called root hash of a Merkle



hash tree over the content. For video on demand without content



integrity protection, the identifier serves just to identify the



swarm, and the ID's length MUST be equal to the smallest output



of the supported Merkle hash functions. For live streaming, the



swarm ID is a public key.



"





Apologies for the slow resolution of this erratum, IMHO it involves just



a minor underspecification in the RFC, hence the low priority.





Regards,



Arno Bakker









On 21/08/17 15:56, RFC Errata System wrote:



> The following errata report has been verified for RFC7574,



> "Peer-to-Peer Streaming Peer Protocol (PPSPP)".



>



> --------------------------------------



> You may review the report below and at:



> http://www.rfc-editor.org/errata/eid4724



>



> --------------------------------------



> Status: Verified



> Type: Technical



>



> Reported by: Sung Hei Kim, Chang Kyu Lee



> Date Reported: 2016-07-01



> Verified by: Spencer Dawkins (IESG)



>



> Section: 1.3



>



> Original Text



> -------------



> swarm ID



> Unique identifier for a swarm of peers, in PPSPP a sequence of



> bytes. For video on demand with content integrity protection



> enabled, the identifier is the so-called root hash of a Merkle



> hash tree over the content. For live streaming, the swarm ID is



> a public key.



>



> Corrected Text



> --------------



> swarm ID



> Unique identifier for a swarm of peers, in PPSPP a sequence of



> bytes. For video on demand, the identifier is the so-called root hash



> of a Merkle hash tree over the content. For live streaming, the



> swarm ID is a public key.



>



> Notes



> -----



> According to chapter 5 and chapter 6.1, it seems that it is not mandatory to use content integrity protection scheme.



> The definition of swarm ID in the original text does not define how the ID is used in environment with the content integrity protection disabled.



> It is possible to add new description on how swarm ID is defined in the content integrity protection scheme is disabled.



> Or, it is possible to remove the parts regarding content integrity protection.



>



> We propose to remove "with content integrity protection enabled" part.



>



> Spencer: confirmed in conversations with Victor Grishchenko on the PPSP mailing list.



>



> --------------------------------------



> RFC7574 (draft-ietf-ppsp-peer-protocol-12)



> --------------------------------------



> Title : Peer-to-Peer Streaming Peer Protocol (PPSPP)



> Publication Date : July 2015



> Author(s) : A. Bakker, R. Petrocco, V. Grishchenko



> Category : PROPOSED STANDARD



> Source : Peer to Peer Streaming Protocol



> Area : Transport



> Stream : IETF



> Verifying Party : IESG



>