Re: [icnrg] [irsg] Resolving the ballot comments on draft-oran-icnrg-qosarch

Colin Perkins <csp@csperkins.org> Wed, 25 November 2020 20:57 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D683A1D3F; Wed, 25 Nov 2020 12:57:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=csperkins.org
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 gt6bSwAEOgUq; Wed, 25 Nov 2020 12:57:16 -0800 (PST)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67C1D3A1D27; Wed, 25 Nov 2020 12:57:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=aX7oOMenx7rqGwZCjKg81QqHpC36PcTIj1LhmaRUHhQ=; b=cVA/JXezI1uvgfXCNDyTB3fcLH XA6UzsTTO+lEl55XdI2NjvDFz1AnWKus0AXsNgb4YjrF86wo5GQKDFdh5yebXTq36k8VNKg6Xb1Dt VN0PCWnX7fPZhs+G13tSl0dX8LfG/nItauhS43MOXi6Lfk05DLYeGjywiiTTjW0IzGI8vH6M4DNHz ZsyHC8Yx62UWHFpYQuY5pVpT560sz9KPkhK7u5zPnvZCquJFrmSupadIHOzXCvygFG7csSbPVt/7p E1gEqsxJzhBIgmgfIbmhKWPRNIEoePb10p8MFj31S8IC/UtU6dxMMnvxTQeUpV4TdvE49/Bf9zOi5 p+XpmR/A==;
Received: from [81.187.2.149] (port=34182 helo=[192.168.0.67]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <csp@csperkins.org>) id 1ki1qg-00063a-0u; Wed, 25 Nov 2020 20:57:14 +0000
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <1CAEF486-341B-411C-9CBB-6EDA55E76CB9@orandom.net>
Date: Wed, 25 Nov 2020 20:57:00 +0000
Cc: Mallory Knodel <mknodel@cdt.org>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, irtf-chair <irtf-chair@irtf.org>, ICNRG <icnrg@irtf.org>, The IRSG <irsg@irtf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DE71549F-020C-4832-AAFD-0620A52251E7@csperkins.org>
References: <160581041927.13669.15053749519312973677@ietfa.amsl.com> <1CAEF486-341B-411C-9CBB-6EDA55E76CB9@orandom.net>
To: Dave Oran <daveoran@orandom.net>
X-Mailer: Apple Mail (2.3445.104.17)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/JL2PQ-AvZz3mkw9e1XiOPDy-UuY>
Subject: Re: [icnrg] [irsg] Resolving the ballot comments on draft-oran-icnrg-qosarch
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Nov 2020 20:57:19 -0000

Thanks, Dave.

I also believe the IRSG comments have been addressed. If anyone disagrees with that statement, and thinks this draft is not ready to progress, please comment now. If there are no objections by 4 December, I’ll send this draft for IESG conflict review.

Colin



> On 19 Nov 2020, at 18:31, David R. Oran <daveoran@orandom.net> wrote:
> 
> I believe this version addresses all the IRSG ballot comments and contains new text specifically around my responses to Mallory & Spencer’s comments on the ballot (and which we informally resolved via email).
> 
> If so, this should be ready for progression to IESG conflict review and RFC editor processing. Thanks to everybody who read and commented on this!
> 
> I’ve attached a diff from the prior version in case you want to review the changes only.
> 
> 
> 
> DaveO
> 
> Forwarded message:
> 
>> From: internet-drafts@ietf.org
>> To: David Oran <daveoran@orandom.net>et>, Dave Oran <daveoran@orandom.net>
>> Subject: New Version Notification for draft-oran-icnrg-qosarch-06.txt
>> Date: Thu, 19 Nov 2020 10:26:59 -0800
>> 
>> A new version of I-D, draft-oran-icnrg-qosarch-06.txt
>> has been successfully submitted by Dave Oran and posted to the
>> IETF repository.
>> 
>> Name:		draft-oran-icnrg-qosarch
>> Revision:	06
>> Title:		Considerations in the development of a QoS Architecture for CCNx-like ICN protocols
>> Document date:	2020-11-19
>> Group:		icnrg
>> Pages:		29
>> URL:            https://www.ietf.org/archive/id/draft-oran-icnrg-qosarch-06.txt
>> Status:         https://datatracker.ietf.org/doc/draft-oran-icnrg-qosarch/
>> Html:           https://www.ietf.org/archive/id/draft-oran-icnrg-qosarch-06.html
>> Htmlized:       https://tools.ietf.org/html/draft-oran-icnrg-qosarch-06
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-oran-icnrg-qosarch-06
>> 
>> Abstract:
>>   This is a position paper.  It documents the author's personal views
>>   on how Quality of Service (QoS) capabilities ought to be accommodated
>>   in ICN protocols like CCNx or NDN which employ flow-balanced
>>   Interest/Data exchanges and hop-by-hop forwarding state as their
>>   fundamental machinery.  It argues that such protocols demand a
>>   substantially different approach to QoS from that taken in TCP/IP,
>>   and proposes specific design patterns to achieve both classification
>>   and differentiated QoS treatment on both a flow and aggregate basis.
>>   It also considers the effect of caches in addition to memory, CPU and
>>   link bandwidth as a resource that should be subject to explicitly
>>   unfair resource allocation.  The proposed methods are intended to
>>   operate purely at the network layer, providing the primitives needed
>>   to achieve both transport and higher layer QoS objectives.  It
>>   explicitly excludes any discussion of Quality of Experience (QoE)
>>   which can only be assessed and controlled at the application layer or
>>   above.
>> 
>>   This document is not a product of the IRTF Information-Centric
>>   Networking Research Group (ICNRG) but has been through formal last
>>   call and has the support of the participants in the research group
>>   for publication as an individual submission.
>> 
>> 
>> 
>> 
>> 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.
>> 
>> The IETF Secretariat
> <qosarch-06-05diff.txt>



-- 
Colin Perkins
https://csperkins.org/