From nobody Fri Jun 12 14:46:30 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16311B2AFA for ; Fri, 12 Jun 2015 14:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 6ZRsipGyx_a6 for ; Fri, 12 Jun 2015 14:46:27 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 277451B2AF8 for ; Fri, 12 Jun 2015 14:46:27 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7DC6120DCD for ; Fri, 12 Jun 2015 17:46:26 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Fri, 12 Jun 2015 17:46:26 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=qXn9wtbxoC7XFMqkZI0Q4uq+f4U=; b=MCz9C1 2EKVTFOjdz2+c/roXoFqxagJHjzAVg0mgds6eWV2SoLuvIK1YTg6Q18nYNn8sR/O eeTgfabSgVzedqqVS9HUz2RLVxSTsyZ6nbZMNEla9yAp5ONBqJI28aB/R/W6hWAm TpffuNuLFYvmwY1btDzRGCxBkGaUF6DnRRg48= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=qXn9wtbxoC7XFMq kZI0Q4uq+f4U=; b=UcQbb1tKHH4E4MSVgtqFZE7mgWXGRRBFLVqkKRNq8DueoHf Wh0omqfU5JSxUKEEStEadD9qGv8RzZeJJbeMr44dd18oTTtEprgOmyAqgFPMnTb5 dMppiR1nO+8P1WB8Z4Siufd9WLaA4GslUDULqePi2JXoqkPLcblFV8+ov9TU= X-Sasl-enc: AyAQVaF6JqWSYGghdx2gmeLpGVaZUyzJKc0qdoP3laZc 1434145586 Received: from dhcp-171-68-21-86.cisco.com (unknown [171.68.21.86]) by mail.messagingengine.com (Postfix) with ESMTPA id 8242E6801C3; Fri, 12 Jun 2015 17:46:25 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <5550F04B.6030401@haw-hamburg.de> Date: Fri, 12 Jun 2015 14:46:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3FDC7858-7FD2-44C6-B118-67F0A6562A95@cooperw.in> References: <0dbe3c40f2784076b961e730dd1f17d4@HUB01.mailcluster.haw-hamburg.de> <5538C4D6.1030007@haw-hamburg.de> <454a62af9d0f466c9351c64ac36f1b7e@HUB01.mailcluster.haw-hamburg.de> <5550F04B.6030401@haw-hamburg.de> To: "Thomas C. Schmidt" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: p2psip Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-share-04 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 21:46:30 -0000 Hi Thomas, Checking in on the status of this. Thanks, Alissa On May 11, 2015, at 11:09 AM, Thomas C. Schmidt = wrote: > Hi Alissa, >=20 > it's coming ASAP. I was blocked by paper deadlines ... >=20 > Thanks, >=20 > Thomas >=20 > On 11.05.2015 19:36, Alissa Cooper wrote: >> Hi Thomas, >>=20 >> What is the status of this update? >>=20 >> Thanks, >> Alissa >>=20 >> On Apr 23, 2015, at 3:09 AM, Thomas C. Schmidt = wrote: >>=20 >>> Hi Emmanuel, >>>=20 >>> many thanks! >>>=20 >>> We'll fix the issues and resubmit during the next few days. >>>=20 >>> Best wishes, >>>=20 >>> thomas >>>=20 >>> On 23.04.2015 12:03, Emmanuel Baccelli wrote: >>>> Hi Alissa, Hi WG, >>>>=20 >>>> I have reviewed draft-ietf-p2psip-share-05, and here are my = comments. >>>>=20 >>>>=20 >>>> General comments: >>>> in my opinion the draft is in good shape and reads well. I have a = few >>>> nits and editorial suggestions detailed below. I believe these can = be >>>> addressed quite easily with a quick resubmission and my impression = is >>>> the doc is ready to go. >>>>=20 >>>>=20 >>>> Detailed comments: >>>>=20 >>>> in Section 1: refer to RFC6940 (and which section, if applicable) = the >>>> first time specific terms are used such as "RELOAD Usage" or = "RELOAD >>>> security model". Spoiler: I will have a lot of such comments below = ;) >>>>=20 >>>> in Section 2: for reader convenience, I suggest listing the key = terms >>>> (without recalling their definitions) imported from RFC6940, and = the >>>> p2psip-concepts draft in the paragraph right after the 2119 = boilerplate. >>>>=20 >>>> in Section 3.1: in step 3, I suggest being explicit that the 8bit = part >>>> is a suffix (least significant bits) >>>>=20 >>>> in Section 4.1: >>>> - "...Alice is also granted (limited) write access..." >>>> Either explain what "limited" means here, or remove this adjective. >>>>=20 >>>> - "Note that overwriting existing items in an Access Control List = that >>>> reference a different Kind-ID..." >>>> Clarify: different from what? I suppose you mean that the overwrite >>>> results in changing the Kind-ID >>>>=20 >>>> - "The Resource Owner is allowed to overwrite any existing ACL = item, but >>>> should be aware of its consequences." >>>> Either quickly explain / give examples of consequences or remove = this >>>> sentence. >>>>=20 >>>> in Section 5.1: "The specifications in this document scheme adhere = to >>>> this paradigm...". >>>> add reference to RFC6940 (and the exact section). It will help = readers >>>> grasp quicker what draft-ietf-p2psip-share specification adds here. >>>>=20 >>>> in Section 6.1: >>>> - first sentence "Write access ... solely be issued by the Resource = Owner." >>>> rephrase needed (confusing as readers already know that delegation = is >>>> possible). >>>>=20 >>>> - "... stored in the numerical order... starting with the index of = the >>>> root item...". >>>> I have a (stupid) question: What if the Node-ID of the an = authorized >>>> peer with ad=3D1 has a node-ID that is numerically smaller that = that of >>>> the owner? >>>> I suggest rephrasing in order to clarify this corner case, just to = make >>>> sure no one is confused? >>>>=20 >>>> in Section 6.5: Step 1. reference "as per RFC 6940 Section X.Y." >>>>=20 >>>> in Section 6.6: Because it is possible here, I would have preferred = to >>>> see the last 2 paragraphs written in steps + pseudo-code style >>>> if...else..else. But that's a matter of taste. >>>>=20 >>>>=20 >>>> Best, >>>>=20 >>>> Emmanuel >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Tue, Apr 21, 2015 at 9:08 PM, Alissa Cooper >>> > wrote: >>>>=20 >>>> Yes, that=92s fine, thanks. >>>> Alissa >>>>=20 >>>> On Apr 21, 2015, at 1:40 AM, Emmanuel Baccelli >>>> > = wrote: >>>>=20 >>>> > >>>> > Hi Alissa, >>>> > >>>> > if it is not too late: I am currently reviewing the document. = ETA early next week. >>>> > Sorry for the delay. Is that alright with you? >>>> > >>>> > Best, >>>> > >>>> > Emmanuel >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > P2PSIP mailing list >>>> >P2PSIP@ietf.org >>>> >https://www.ietf.org/mailman/listinfo/p2psip >>>>=20 >>>>=20 >>>=20 >>> -- >>>=20 >>> Prof. Dr. Thomas C. Schmidt >>> =B0 Hamburg University of Applied Sciences = Berliner Tor 7 =B0 >>> =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, = Germany =B0 >>> =B0 http://www.haw-hamburg.de/inet Fon: = +49-40-42875-8452 =B0 >>> =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875-8409 =B0 >>>=20 >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >=20 > --=20 >=20 > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences Berliner = Tor 7 =B0 > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, = Germany =B0 > =B0 http://www.haw-hamburg.de/inet Fon: = +49-40-42875-8452 =B0 > =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875-8409 =B0 From nobody Wed Jun 17 04:23:07 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429391A895D for ; Wed, 17 Jun 2015 04:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.14 X-Spam-Level: * X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] 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 AUmiTIgP6sJg for ; Wed, 17 Jun 2015 04:23:03 -0700 (PDT) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C9B31A8938 for ; Wed, 17 Jun 2015 04:16:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,632,1427752800"; d="scan'208";a="22086553" Received: from post.haw-hamburg.de (HELO HUB01.mailcluster.haw-hamburg.de) ([141.22.24.50]) by mail3.is.haw-hamburg.de with ESMTP/TLS/AES128-SHA; 17 Jun 2015 13:16:12 +0200 Received: from CAS01.mailcluster.haw-hamburg.de (2002:8d16:183c::8d16:183c) by HUB01.mailcluster.haw-hamburg.de (2002:8d16:1832::8d16:1832) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 17 Jun 2015 13:16:12 +0200 Received: from [194.210.137.201] (141.22.200.50) by haw-mailer.haw-hamburg.de (141.22.24.60) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 17 Jun 2015 13:16:11 +0200 Message-ID: <558156F8.30203@haw-hamburg.de> Date: Wed, 17 Jun 2015 12:16:08 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Emmanuel Baccelli , p2psip References: <0dbe3c40f2784076b961e730dd1f17d4@HUB01.mailcluster.haw-hamburg.de> In-Reply-To: <0dbe3c40f2784076b961e730dd1f17d4@HUB01.mailcluster.haw-hamburg.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-share-04 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 11:23:05 -0000 Hi Emmanuel, all, On 23.04.2015 11:03, Emmanuel Baccelli wrote: > I have reviewed draft-ietf-p2psip-share-05, and here are my comments. > > > General comments: > in my opinion the draft is in good shape and reads well. I have a few > nits and editorial suggestions detailed below. I believe these can be > addressed quite easily with a quick resubmission and my impression is > the doc is ready to go. > thanks - please find our records below. > > Detailed comments: > > in Section 1: refer to RFC6940 (and which section, if applicable) the > first time specific terms are used such as "RELOAD Usage" or "RELOAD > security model". Spoiler: I will have a lot of such comments below ;) > Done: We prepended the statement fixing the relation to RFC6940: "[RFC6940] defines the base protocol for REsource LOcation And Discovery (RELOAD) that allows for application-specific extensions by Usages." > in Section 2: for reader convenience, I suggest listing the key terms > (without recalling their definitions) imported from RFC6940, and the > p2psip-concepts draft in the paragraph right after the 2119 boilerplate. Done: We named the most prominent terms: " This document uses the terminology and definitions from the RELOAD base [RFC6940] and the peer-to-peer SIP concepts draft [I-D.ietf-p2psip-concepts], in particular the RELOAD Usage, Resource and Kind." > > in Section 3.1: in step 3, I suggest being explicit that the 8bit part > is a suffix (least significant bits) > Oh, thanks for that one. We clarified: " 3. Append an 8 bit long short individual index value to those 24 bit of the Node-ID" > in Section 4.1: > - "...Alice is also granted (limited) write access..." > Either explain what "limited" means here, or remove this adjective. > Good point, thanks: The right is actually explained in the following sentence, so we removed "(limited)": " peer Alice is also granted write access to the ACL as indicated by the allow_delegation flag (ad) set to 1. This configuration authorizes Alice to store further trust delegations to the Shared Resource, i.e., add items to the ACL." > - "Note that overwriting existing items in an Access Control List that > reference a different Kind-ID..." > Clarify: different from what? I suppose you mean that the overwrite > results in changing the Kind-ID Yes, we clarified: "Note that overwriting existing items in an Access Control List with a change in the Kind-ID revokes all trust delegations in the corresponding subtree (see Section 6.2)." > > - "The Resource Owner is allowed to overwrite any existing ACL item, but > should be aware of its consequences." > Either quickly explain / give examples of consequences or remove this > sentence. O.K., we clarified: "The Resource Owner is allowed to overwrite any existing ACL item, but should be aware of its consequences on the trust delegation chain." > > in Section 5.1: "The specifications in this document scheme adhere to > this paradigm...". > add reference to RFC6940 (and the exact section). It will help readers > grasp quicker what draft-ietf-p2psip-share specification adds here. > Done: " Each RELOAD node uses a certificate to identify itself using its user name (or Node-ID) while storing data under a specific Resource-ID (see Section 7.3 in [RFC6940]). The specifications in this document scheme adhere to this paradigm, but.." > in Section 6.1: > - first sentence "Write access ... solely be issued by the Resource Owner." > rephrase needed (confusing as readers already know that delegation is > possible). > O.k., we clarified: " Write access to a Kind that is intended to be shared with other RELOAD users can solely be *initiated* by the Resource Owner." > - "... stored in the numerical order... starting with the index of the > root item...". > I have a (stupid) question: What if the Node-ID of the an authorized > peer with ad=1 has a node-ID that is numerically smaller that that of > the owner? That does not matter. Each node has a unique prefix (up to unlikely collisions) and writes in its own index space to avoid race conditions (see Sect. 3.1). Here we only describe the node-specific indexing. > I suggest rephrasing in order to clarify this corner case, just to make > sure no one is confused? > We clarified: "For each succeeding ACL item, the Resource Owner increments its individual index value by one (see Section 3.1) so that items can be stored in the numerical order of the array index starting with the index of the root item." > in Section 6.5: Step 1. reference "as per RFC 6940 Section X.Y." > > in Section 6.6: Because it is possible here, I would have preferred to > see the last 2 paragraphs written in steps + pseudo-code style > if...else..else. But that's a matter of taste. > I guess ... ;) So, we've updated and submit in a second. Thanks again, Thomas > > > On Tue, Apr 21, 2015 at 9:08 PM, Alissa Cooper > wrote: > > Yes, that’s fine, thanks. > Alissa > > On Apr 21, 2015, at 1:40 AM, Emmanuel Baccelli > > wrote: > > > > > Hi Alissa, > > > > if it is not too late: I am currently reviewing the document. ETA early next week. > > Sorry for the delay. Is that alright with you? > > > > Best, > > > > Emmanuel > > > > > > > > > > > > _______________________________________________ > > P2PSIP mailing list > >P2PSIP@ietf.org > >https://www.ietf.org/mailman/listinfo/p2psip > > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Wed Jun 17 04:26:10 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39BB1A1EF9; Wed, 17 Jun 2015 04:26: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 udDqjFdcBY3j; Wed, 17 Jun 2015 04:26:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE3B1A009B; Wed, 17 Jun 2015 04:26:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150617112606.4423.8626.idtracker@ietfa.amsl.com> Date: Wed, 17 Jun 2015 04:26:06 -0700 Archived-At: Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-share-06.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 11:26:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF. Title : A Usage for Shared Resources in RELOAD (ShaRe) Authors : Alexander Knauf Thomas C. Schmidt Gabriel Hege Matthias Waehlisch Filename : draft-ietf-p2psip-share-06.txt Pages : 21 Date : 2015-06-17 Abstract: This document defines a RELOAD Usage for managing shared write access to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic primitive for enabling various coordination and notification schemes among distributed peers. Access in ShaRe is controlled by a hierarchical trust delegation scheme maintained within an access list. A new USER-CHAIN-ACL access policy allows authorized peers to write a Shared Resource without owning its corresponding certificate. This specification also adds mechanisms to store Resources with a variable name which is useful whenever peer-independent rendezvous processes are required. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-p2psip-share/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-p2psip-share-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-p2psip-share-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 17 04:46:29 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51EA1A89A1 for ; Wed, 17 Jun 2015 04:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.14 X-Spam-Level: * X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] 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 ra990FV45dnI for ; Wed, 17 Jun 2015 04:46:25 -0700 (PDT) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F111A89A0 for ; Wed, 17 Jun 2015 04:46:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,632,1427752800"; d="scan'208";a="22087327" Received: from post.haw-hamburg.de (HELO HUB01.mailcluster.haw-hamburg.de) ([141.22.24.50]) by mail3.is.haw-hamburg.de with ESMTP/TLS/AES128-SHA; 17 Jun 2015 13:46:23 +0200 Received: from CAS01.mailcluster.haw-hamburg.de (2002:8d16:183c::8d16:183c) by HUB01.mailcluster.haw-hamburg.de (2002:8d16:1832::8d16:1832) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 17 Jun 2015 13:46:22 +0200 Received: from [194.210.137.201] (141.22.200.50) by haw-mailer.haw-hamburg.de (141.22.24.60) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 17 Jun 2015 13:46:22 +0200 Message-ID: <55815E0A.6090207@haw-hamburg.de> Date: Wed, 17 Jun 2015 12:46:18 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Alissa Cooper References: <0dbe3c40f2784076b961e730dd1f17d4@HUB01.mailcluster.haw-hamburg.de> <5538C4D6.1030007@haw-hamburg.de> <454a62af9d0f466c9351c64ac36f1b7e@HUB01.mailcluster.haw-hamburg.de> <5550F04B.6030401@haw-hamburg.de> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: p2psip Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-share-04 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 11:46:26 -0000 Hi Alissa, so status is o.k.. Maybe, if we get the open Ack from Roland, we can move p2psip-share and p2psip-sip jointly forward, which would be good for keeping the references intact. Best, Thomas On 12.06.2015 22:46, Alissa Cooper wrote: > Hi Thomas, > > Checking in on the status of this. > > Thanks, > Alissa > > On May 11, 2015, at 11:09 AM, Thomas C. Schmidt wrote: > >> Hi Alissa, >> >> it's coming ASAP. I was blocked by paper deadlines ... >> >> Thanks, >> >> Thomas >> >> On 11.05.2015 19:36, Alissa Cooper wrote: >>> Hi Thomas, >>> >>> What is the status of this update? >>> >>> Thanks, >>> Alissa >>> >>> On Apr 23, 2015, at 3:09 AM, Thomas C. Schmidt wrote: >>> >>>> Hi Emmanuel, >>>> >>>> many thanks! >>>> >>>> We'll fix the issues and resubmit during the next few days. >>>> >>>> Best wishes, >>>> >>>> thomas >>>> >>>> On 23.04.2015 12:03, Emmanuel Baccelli wrote: >>>>> Hi Alissa, Hi WG, >>>>> >>>>> I have reviewed draft-ietf-p2psip-share-05, and here are my comments. >>>>> >>>>> >>>>> General comments: >>>>> in my opinion the draft is in good shape and reads well. I have a few >>>>> nits and editorial suggestions detailed below. I believe these can be >>>>> addressed quite easily with a quick resubmission and my impression is >>>>> the doc is ready to go. >>>>> >>>>> >>>>> Detailed comments: >>>>> >>>>> in Section 1: refer to RFC6940 (and which section, if applicable) the >>>>> first time specific terms are used such as "RELOAD Usage" or "RELOAD >>>>> security model". Spoiler: I will have a lot of such comments below ;) >>>>> >>>>> in Section 2: for reader convenience, I suggest listing the key terms >>>>> (without recalling their definitions) imported from RFC6940, and the >>>>> p2psip-concepts draft in the paragraph right after the 2119 boilerplate. >>>>> >>>>> in Section 3.1: in step 3, I suggest being explicit that the 8bit part >>>>> is a suffix (least significant bits) >>>>> >>>>> in Section 4.1: >>>>> - "...Alice is also granted (limited) write access..." >>>>> Either explain what "limited" means here, or remove this adjective. >>>>> >>>>> - "Note that overwriting existing items in an Access Control List that >>>>> reference a different Kind-ID..." >>>>> Clarify: different from what? I suppose you mean that the overwrite >>>>> results in changing the Kind-ID >>>>> >>>>> - "The Resource Owner is allowed to overwrite any existing ACL item, but >>>>> should be aware of its consequences." >>>>> Either quickly explain / give examples of consequences or remove this >>>>> sentence. >>>>> >>>>> in Section 5.1: "The specifications in this document scheme adhere to >>>>> this paradigm...". >>>>> add reference to RFC6940 (and the exact section). It will help readers >>>>> grasp quicker what draft-ietf-p2psip-share specification adds here. >>>>> >>>>> in Section 6.1: >>>>> - first sentence "Write access ... solely be issued by the Resource Owner." >>>>> rephrase needed (confusing as readers already know that delegation is >>>>> possible). >>>>> >>>>> - "... stored in the numerical order... starting with the index of the >>>>> root item...". >>>>> I have a (stupid) question: What if the Node-ID of the an authorized >>>>> peer with ad=1 has a node-ID that is numerically smaller that that of >>>>> the owner? >>>>> I suggest rephrasing in order to clarify this corner case, just to make >>>>> sure no one is confused? >>>>> >>>>> in Section 6.5: Step 1. reference "as per RFC 6940 Section X.Y." >>>>> >>>>> in Section 6.6: Because it is possible here, I would have preferred to >>>>> see the last 2 paragraphs written in steps + pseudo-code style >>>>> if...else..else. But that's a matter of taste. >>>>> >>>>> >>>>> Best, >>>>> >>>>> Emmanuel >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Apr 21, 2015 at 9:08 PM, Alissa Cooper >>>> > wrote: >>>>> >>>>> Yes, that’s fine, thanks. >>>>> Alissa >>>>> >>>>> On Apr 21, 2015, at 1:40 AM, Emmanuel Baccelli >>>>> > wrote: >>>>> >>>>> > >>>>> > Hi Alissa, >>>>> > >>>>> > if it is not too late: I am currently reviewing the document. ETA early next week. >>>>> > Sorry for the delay. Is that alright with you? >>>>> > >>>>> > Best, >>>>> > >>>>> > Emmanuel >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > _______________________________________________ >>>>> > P2PSIP mailing list >>>>> >P2PSIP@ietf.org >>>>> >https://www.ietf.org/mailman/listinfo/p2psip >>>>> >>>>> >>>> >>>> -- >>>> >>>> Prof. Dr. Thomas C. Schmidt >>>> ° Hamburg University of Applied Sciences Berliner Tor 7 ° >>>> ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° >>>> ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° >>>> ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° >>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/p2psip >> >> -- >> >> Prof. Dr. Thomas C. Schmidt >> ° Hamburg University of Applied Sciences Berliner Tor 7 ° >> ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° >> ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° >> ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Sun Jun 21 03:17:44 2015 Return-Path: X-Original-To: p2psip@ietfa.amsl.com Delivered-To: p2psip@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420331A00E0 for ; Sun, 21 Jun 2015 03:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.423 X-Spam-Level: * X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 Mk7KOy-OLNHL for ; Sun, 21 Jun 2015 03:17:39 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 473A01ACE60 for ; Sun, 21 Jun 2015 03:17:39 -0700 (PDT) Received: by oigx81 with SMTP id x81so105416210oig.1 for ; Sun, 21 Jun 2015 03:17:38 -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=dFQ//xG7As+x5v7kPRm5XeDfB00lt81TaEgAcO4WeRc=; b=y3GZuZBvY8te05HsQzx0IDAS0Isu6ar/Mqo9r9s4LAElqUBzfUcucyBxlMLiM59rHy 75MH3O9+W7KvSxxeYfhfldwxEFbM+VQ83fv3idm8UZ75ZUDYuxx+oqmNDW8BrQL/6jNH g1mWUsktLdYkw9ZZ/IdTn4C0moaY85tF4U1FVkX7OG/WxbRgKLHrEVkahjuGNmmG5OHk q6zorOkuaVLho+srTQLGUEvDP1gdG8ndGAs4PcpYqVTp/Hx1QyIIFtIjammKnkNN4IZB tPzVo6q1X/UkrizCAGZm/wHTHvY0li8uA8AfbYE0pFasvuWys9iTDcdw3399dd8/JrlM Gwww== MIME-Version: 1.0 X-Received: by 10.60.173.7 with SMTP id bg7mr20663940oec.86.1434881858738; Sun, 21 Jun 2015 03:17:38 -0700 (PDT) Sender: emmanuel.baccelli@gmail.com Received: by 10.76.10.170 with HTTP; Sun, 21 Jun 2015 03:17:38 -0700 (PDT) Received: by 10.76.10.170 with HTTP; Sun, 21 Jun 2015 03:17:38 -0700 (PDT) In-Reply-To: <558156F8.30203@haw-hamburg.de> References: <0dbe3c40f2784076b961e730dd1f17d4@HUB01.mailcluster.haw-hamburg.de> <558156F8.30203@haw-hamburg.de> Date: Sun, 21 Jun 2015 12:17:38 +0200 X-Google-Sender-Auth: gi9XrNJyK8yQS9OMu084fPR2OeY Message-ID: From: Emmanuel Baccelli To: "Thomas C. Schmidt" Content-Type: multipart/alternative; boundary=047d7bd767887c2218051904773b Archived-At: Cc: p2psip Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-share-04 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2015 10:17:42 -0000 --047d7bd767887c2218051904773b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Thomas, Thanks. I think the new/updated text fixes the comments I had. Best, Emmanuel Le 17 juin 2015 13:16, "Thomas C. Schmidt" a =C3=A9crit : > Hi Emmanuel, all, > > On 23.04.2015 11:03, Emmanuel Baccelli wrote: > > I have reviewed draft-ietf-p2psip-share-05, and here are my comments. >> >> >> General comments: >> in my opinion the draft is in good shape and reads well. I have a few >> nits and editorial suggestions detailed below. I believe these can be >> addressed quite easily with a quick resubmission and my impression is >> the doc is ready to go. >> >> > thanks - please find our records below. > > >> Detailed comments: >> >> in Section 1: refer to RFC6940 (and which section, if applicable) the >> first time specific terms are used such as "RELOAD Usage" or "RELOAD >> security model". Spoiler: I will have a lot of such comments below ;) >> >> > Done: We prepended the statement fixing the relation to RFC6940: > > "[RFC6940] defines the base protocol for REsource LOcation And > Discovery (RELOAD) that allows for application-specific extensions by > Usages." > > in Section 2: for reader convenience, I suggest listing the key terms >> (without recalling their definitions) imported from RFC6940, and the >> p2psip-concepts draft in the paragraph right after the 2119 boilerplate. >> > > Done: We named the most prominent terms: > > " This document uses the terminology and definitions from the RELOAD > base [RFC6940] and the peer-to-peer SIP concepts draft > [I-D.ietf-p2psip-concepts], in particular the RELOAD Usage, Resource > and Kind." > > >> in Section 3.1: in step 3, I suggest being explicit that the 8bit part >> is a suffix (least significant bits) >> >> > Oh, thanks for that one. We clarified: > > " 3. Append an 8 bit long short individual index value to those 24 bit > of the Node-ID" > > in Section 4.1: >> - "...Alice is also granted (limited) write access..." >> Either explain what "limited" means here, or remove this adjective. >> >> > Good point, thanks: The right is actually explained in the following > sentence, so we removed "(limited)": > > " peer Alice is also granted write access to the ACL as indicated by > the allow_delegation flag (ad) set to 1. This configuration > authorizes Alice to store further trust delegations to the Shared > Resource, i.e., add items to the ACL." > > - "Note that overwriting existing items in an Access Control List that >> reference a different Kind-ID..." >> Clarify: different from what? I suppose you mean that the overwrite >> results in changing the Kind-ID >> > > Yes, we clarified: > > "Note that > overwriting existing items in an Access Control List with a change in > the Kind-ID revokes all trust delegations in the corresponding > subtree (see Section 6.2)." > > >> - "The Resource Owner is allowed to overwrite any existing ACL item, but >> should be aware of its consequences." >> Either quickly explain / give examples of consequences or remove this >> sentence. >> > > O.K., we clarified: > > "The Resource Owner is allowed > to overwrite any existing ACL item, but should be aware of its > consequences on the trust delegation chain." > > >> in Section 5.1: "The specifications in this document scheme adhere to >> this paradigm...". >> add reference to RFC6940 (and the exact section). It will help readers >> grasp quicker what draft-ietf-p2psip-share specification adds here. >> >> > Done: > > " Each RELOAD node uses a certificate to identify itself using its user > name (or Node-ID) while storing data under a specific Resource-ID > (see Section 7.3 in [RFC6940]). The specifications in this document > scheme adhere to this paradigm, but.." > > in Section 6.1: >> - first sentence "Write access ... solely be issued by the Resource >> Owner." >> rephrase needed (confusing as readers already know that delegation is >> possible). >> >> > O.k., we clarified: > > " Write access to a Kind that is intended to be shared with other > RELOAD users can solely be *initiated* by the Resource Owner." > > - "... stored in the numerical order... starting with the index of the >> root item...". >> I have a (stupid) question: What if the Node-ID of the an authorized >> peer with ad=3D1 has a node-ID that is numerically smaller that that of >> the owner? >> > > That does not matter. Each node has a unique prefix (up to unlikely > collisions) and writes in its own index space to avoid race conditions (s= ee > Sect. 3.1). Here we only describe the node-specific indexing. > > I suggest rephrasing in order to clarify this corner case, just to make >> sure no one is confused? >> >> > We clarified: > > "For each succeeding ACL item, the Resource Owner > increments its individual index value by one (see Section 3.1) so > that items can be stored in the numerical order of the array index > starting with the index of the root item." > > > in Section 6.5: Step 1. reference "as per RFC 6940 Section X.Y." >> >> in Section 6.6: Because it is possible here, I would have preferred to >> see the last 2 paragraphs written in steps + pseudo-code style >> if...else..else. But that's a matter of taste. >> >> > I guess ... ;) > > > So, we've updated and submit in a second. > > Thanks again, > > Thomas > > > >> >> On Tue, Apr 21, 2015 at 9:08 PM, Alissa Cooper > > wrote: >> >> Yes, that=E2=80=99s fine, thanks. >> Alissa >> >> On Apr 21, 2015, at 1:40 AM, Emmanuel Baccelli >> > >> wrote: >> >> > >> > Hi Alissa, >> > >> > if it is not too late: I am currently reviewing the document. ETA >> early next week. >> > Sorry for the delay. Is that alright with you? >> > >> > Best, >> > >> > Emmanuel >> > >> > >> > >> > >> > >> > _______________________________________________ >> > P2PSIP mailing list >> >P2PSIP@ietf.org >> >https://www.ietf.org/mailman/listinfo/p2psip >> >> >> > -- > > Prof. Dr. Thomas C. Schmidt > =C2=B0 Hamburg University of Applied Sciences Berliner = Tor 7 =C2=B0 > =C2=B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Ge= rmany =C2=B0 > =C2=B0 http://www.haw-hamburg.de/inet Fon: +49-40-42875= -8452 > =C2=B0 > =C2=B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875= -8409 > =C2=B0 > --047d7bd767887c2218051904773b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Thomas,

Thanks. I think the new/updated text fixes the comments I ha= d.

Best,

Emmanuel

Le=C2=A017 juin 2015 13:16, "Thomas C. Schm= idt" <t.schmidt@haw-ham= burg.de> a =C3=A9crit=C2=A0:
Hi Emmanuel, all,

On 23.04.2015 11:03, Emmanuel Baccelli wrote:

I have reviewed draft-ietf-p2psip-share-05, and here are my comments.


General comments:
in my opinion the draft is in good shape and reads well. I have a few
nits and editorial suggestions detailed below. I believe these can be
addressed quite easily with a quick resubmission and my impression is
the doc is ready to go.


thanks - please find our records below.


Detailed comments:

in Section 1: refer to RFC6940 (and which section, if applicable) the
first time specific terms are used such as "RELOAD Usage" or &quo= t;RELOAD
security model". Spoiler: I will have a lot of such comments below ;)<= br>

Done: We prepended the statement fixing the relation to RFC6940:

=C2=A0 "[RFC6940] defines the base protocol for REsource LOcation And<= br> =C2=A0 =C2=A0Discovery (RELOAD) that allows for application-specific extens= ions by
=C2=A0 =C2=A0Usages."

in Section 2: for reader convenience, I suggest listing the key terms
(without recalling their definitions) imported from RFC6940, and the
p2psip-concepts draft in the paragraph right after the 2119 boilerplate.

Done: We named the most prominent terms:

=C2=A0 " This document uses the terminology and definitions from the R= ELOAD
=C2=A0 =C2=A0base [RFC6940] and the peer-to-peer SIP concepts draft
=C2=A0 =C2=A0[I-D.ietf-p2psip-concepts], in particular the RELOAD Usage, Re= source
=C2=A0 =C2=A0and Kind."


in Section 3.1: in step 3, I suggest being explicit that the 8bit part
is a suffix (least significant bits)


Oh, thanks for that one. We clarified:

=C2=A0 " 3.=C2=A0 Append an 8 bit long short individual index value to= those 24 bit
=C2=A0 =C2=A0 =C2=A0 =C2=A0of the Node-ID"

in Section 4.1:
- "...Alice is also granted (limited) write access..."
Either explain what "limited" means here, or remove this adjectiv= e.


Good point, thanks: The right is actually explained in the following senten= ce, so we removed "(limited)":

=C2=A0 =C2=A0" peer Alice is also granted write access to the ACL as i= ndicated by
=C2=A0 =C2=A0the allow_delegation flag (ad) set to 1.=C2=A0 This configurat= ion
=C2=A0 =C2=A0authorizes Alice to store further trust delegations to the Sha= red
=C2=A0 =C2=A0Resource, i.e., add items to the ACL."

- "Note that overwriting existing items in an Access Control List that=
reference a=C2=A0 =C2=A0 different Kind-ID..."
Clarify: different from what? I suppose you mean that the overwrite
results in changing the Kind-ID

Yes, we clarified:

=C2=A0 "Note that
=C2=A0 =C2=A0overwriting existing items in an Access Control List with a ch= ange in
=C2=A0 =C2=A0the Kind-ID revokes all trust delegations in the corresponding=
=C2=A0 =C2=A0subtree (see Section 6.2)."


- "The Resource Owner is allowed to overwrite any existing ACL item, b= ut
should be aware of its consequences."
Either quickly explain / give examples of consequences or remove this
sentence.

O.K., we clarified:

=C2=A0 "The Resource Owner is allowed
=C2=A0 =C2=A0to overwrite any existing ACL item, but should be aware of its=
=C2=A0 =C2=A0consequences on the trust delegation chain."


in Section 5.1:=C2=A0 "The specifications in this document scheme adhe= re to
this paradigm...".
add reference to RFC6940 (and the exact section). It will help readers
grasp quicker what draft-ietf-p2psip-share specification adds here.


Done:

=C2=A0 " Each RELOAD node uses a certificate to identify itself using = its user
=C2=A0 =C2=A0name (or Node-ID) while storing data under a specific Resource= -ID
=C2=A0 =C2=A0(see Section 7.3 in [RFC6940]).=C2=A0 The specifications in th= is document
=C2=A0 =C2=A0scheme adhere to this paradigm, but.."

in Section 6.1:
- first sentence "Write access ... solely be issued by the Resource Ow= ner."
rephrase needed (confusing as readers already know that delegation is
possible).


O.k., we clarified:

=C2=A0 " Write access to a Kind that is intended to be shared with oth= er
=C2=A0 =C2=A0RELOAD users can solely be *initiated* by the Resource Owner.&= quot;

- "... stored in the numerical order... starting with the index of the=
root item...".
I have a (stupid) question: What if the Node-ID of the an authorized
peer with ad=3D1 has a node-ID that is numerically smaller that that of
the owner?

That does not matter. Each node has a unique prefix (up to unlikely collisi= ons) and writes in its own index space to avoid race conditions (see Sect. = 3.1). Here we only describe the node-specific indexing.

I suggest rephrasing in order to clarify this corner case, just to make
sure no one is confused?


We clarified:

=C2=A0 =C2=A0 =C2=A0"For each succeeding ACL item, the Resource Owner<= br> =C2=A0 =C2=A0 =C2=A0 increments its individual index value by one (see Sect= ion 3.1) so
=C2=A0 =C2=A0 =C2=A0 that items can be stored in the numerical order of the= array index
=C2=A0 =C2=A0 =C2=A0 starting with the index of the root item."


in Section 6.5: Step 1. reference "as per RFC 6940 Section X.Y."<= br>
in Section 6.6: Because it is possible here, I would have preferred to
see the last 2 paragraphs written in steps + pseudo-code style
if...else..else. But that's a matter of taste.


I guess ... ;)


So, we've updated and submit in a second.

Thanks again,

=C2=A0Thomas




On Tue, Apr 21, 2015 at 9:08 PM, Alissa Cooper <alissa@cooperw.in
<mailto:alissa@co= operw.in>> wrote:

=C2=A0 =C2=A0 Yes, that=E2=80=99s fine, thanks.
=C2=A0 =C2=A0 Alissa

=C2=A0 =C2=A0 On Apr 21, 2015, at 1:40 AM, Emmanuel Baccelli
=C2=A0 =C2=A0 <Emmanuel.Baccelli@inria.fr <mailto:Emmanuel.Baccelli@inria.fr>>= ; wrote:

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Hi Alissa,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > if it is not too late: I am currently reviewing the docu= ment. ETA early next week.
=C2=A0 =C2=A0 > Sorry for the delay. Is that alright with you?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Best,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Emmanuel
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > P2PSIP mailing list
=C2=A0 =C2=A0 >P2PS= IP@ietf.org <mailto:P2PSIP@ietf.org>
=C2=A0 =C2=A0 >https://www.ietf.org/mailman/listinfo/= p2psip



--

Prof. Dr. Thomas C. Schmidt
=C2=B0 Hamburg University of Applied Sciences=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Berliner Tor 7 =C2=B0
=C2=B0 Dept. Informatik, Internet Technologies Group=C2=A0 =C2=A0 20099 Ham= burg, Germany =C2=B0
=C2=B0 http://www.haw-hamburg.de/inet=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Fon: +49-40-42875-8452 =C2= =B0
=C2=B0 http://www.informatik.haw-hamburg.de/~schmidt=C2=A0 =C2=A0 Fax: +49-40-42875-8409 =C2=B0
--047d7bd767887c2218051904773b--