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

이창규 <echkyu@etri.re.kr> Tue, 29 August 2017 08:34 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 4C2E1132C2B for <ppsp@ietfa.amsl.com>; Tue, 29 Aug 2017 01:34:18 -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=ham 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 EIkzK9368U7j for <ppsp@ietfa.amsl.com>; Tue, 29 Aug 2017 01:34:13 -0700 (PDT)
Received: from mscreen.etri.re.kr (mscreen.etri.re.kr [129.254.9.16]) by ietfa.amsl.com (Postfix) with ESMTP id 43E3D13235C for <ppsp@ietf.org>; Tue, 29 Aug 2017 01:34:12 -0700 (PDT)
Received: from unknown (HELO smtpeg.etri.re.kr) (129.254.27.141) by 129.254.9.16 with ESMTP; 29 Aug 2017 17:34:08 +0900
X-Original-SENDERIP: 129.254.27.141
X-Original-MAILFROM: echkyu@etri.re.kr
X-Original-RCPTTO: spencerdawkins.ietf@gmail.com, victor.grishchenko@gmail.com, ppsp@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org, abr800@vu.nl, r.petrocco@gmail.com, arno@cs.vu.nl
Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 29 Aug 2017 17:34:08 +0900
Received: from SMTP2.etri.info ([169.254.2.9]) by SMTP4.etri.info ([10.2.6.33]) with mapi id 14.03.0319.002; Tue, 29 Aug 2017 17:34:07 +0900
From: 이창규 <echkyu@etri.re.kr>
To: Arno Bakker <abr800@vu.nl>, 김성혜 <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: AQHTGoVLrguTR0402Em7Lnz5Zl5MN6KZhOwAgAERiyyAAAky2P//xAWAgACqJCE=
Date: Tue, 29 Aug 2017 08:34:07 +0000
Message-ID: <71469266360802499C4ECAAFC70B6A423FD85557@SMTP2.etri.info>
References: <20170821135602.062B5B810E4@rfc-editor.org> <e1e8642b-0d71-3f11-cd13-9fb116a89975@vu.nl> <609FE8B8E7BD1248A27BD3B8BC699ABD437F7EB9@SMTP1.etri.info> <71469266360802499C4ECAAFC70B6A423FD853FC@SMTP2.etri.info>, <7a4f4bae-8a91-663c-12a8-e00eaaf5a510@vu.nl>
In-Reply-To: <7a4f4bae-8a91-663c-12a8-e00eaaf5a510@vu.nl>
Accept-Language: ko-KR, en-US
Content-Language: ko-KR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [129.254.28.42]
Content-Type: multipart/alternative; boundary="_000_71469266360802499C4ECAAFC70B6A423FD85557SMTP2etriinfo_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ppsp/PcdU7wKm_OYB42AbBOXGPJ4nQgA>
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 08:34:18 -0000

Dear Arno Bakker,


please check if you can find the post in mail archive.




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
===========================================





________________________________
보낸 사람 : "Arno Bakker" <abr800@vu.nl>
보낸 날짜 : 2017-08-29 16:24:17 ( +09:00 )
받는 사람 : 이창규 <echkyu@etri.re.kr>, 김성혜 <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>
참조 : 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





I kindly request this discussion be moved back to the PPSP mailing list,



before things are cast in stone and without bothering busy people.





If possible.





Regards,



Arno Bakker





P.S. Mr. Lee, please repost to the mailing list, I do not see your post



there, despite the ppsp@ietf.org being in the CC:







On 29/08/17 04:45, 이창규 wrote:



> 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* >



> Researcher



> Infrastructure Standards Research Section



> Protocol Engineering Center (PEC)



> *ET**RI*(*E*lectronics and *T*elecommunications *R*esearch *I*nstitute)



> 138 Gajeongno, Yuseong-gu, Daejeon, 305-700, KOREA



> Phone: +82-42-860-6157



> Fax: +82-42-861-5404



> Mobile: +82-10-3215-0375



> *===========================================*



>



>



>



>



>



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



> *보낸 사람 : *"김성혜"



> *보낸 날짜 : *2017-08-29 10:26:25 ( +09:00 )



> *받는 사람 : *이창규



> *참조 : *



> *제목 : *FW: [Errata Verified] RFC7574 (4724)



>



>



>



>



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



> *보낸 사람 : *"Arno Bakker"



> *보낸 날짜 : *2017-08-29 03:07:01 ( +09:00 )



> *받는 사람 : *RFC Errata System , 김성혜



> , arno@cs.vu.nl , r.petrocco@gmail.com



> , victor.grishchenko@gmail.com



>



> *참조 : *spencerdawkins.ietf@gmail.com ,



> iesg@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



>



>



>



>>



>



>



>