Re: [apps-discuss] [tsvwg] APPSDIR review of draft-ietf-tsvwg-rfc5405bis-16

"Black, David" <david.black@emc.com> Tue, 23 August 2016 03:59 UTC

Return-Path: <david.black@emc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30EA912D85C; Mon, 22 Aug 2016 20:59:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level:
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.com header.b=n58A6jMP; dkim=pass (1024-bit key) header.d=emc.com header.b=k+yNBqXx
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 H5gC4wl_SGYW; Mon, 22 Aug 2016 20:59:32 -0700 (PDT)
Received: from esa6.dell-outbound.iphmx.com (esa6.dell-outbound.iphmx.com [68.232.149.229]) (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 A8E5912D7FF; Mon, 22 Aug 2016 20:59:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=emc.com; i=@emc.com; q=dns/txt; s=jan2013; t=1471924772; x=1503460772; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=L5HnpjHfJJPjL9PnlqJz00gASoCoCuptAGSfRbGJ9lA=; b=n58A6jMPHUQ9dOdKzzfswZNqZW4Oec3DAnCdDBu/NuK4RFTC2Sd6monX b2Fki0VArnz23KJgpmVVBIvW3LmIAnSiZAzUZCI/31bBWyTdIgewp7HCC CKPB+7VmauHE4YqlNdEqGte3ZcbcZhp2Dd76A+n5SWr54JBVH95zLE/hl g=;
Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa6.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Aug 2016 22:59:32 -0500
Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Aug 2016 09:59:30 +0600
Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u7N3xSX6022680 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Aug 2016 23:59:29 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com u7N3xSX6022680
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1471924769; bh=dL8dX1UXYRhwf/A2LQzif9xKgSY=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=k+yNBqXxHvHrF+zpLM0etCSgX8S2fl2JIKJgIzCyj4Z9pDTLAiMGeblRTZDJrSBWe V+IT16ps2QAirOxPVLoyEj3sU5iEEzEWTANq6w6IjSZkhwy2Bb4NSZSg2xL1ukplIb hMqjQIl4ZUo3gfPE7uHZKqTtnlVCmlerGrChXm3Q=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com u7N3xSX6022680
Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd06.lss.emc.com (RSA Interceptor); Mon, 22 Aug 2016 23:59:05 -0400
Received: from MXHUB303.corp.emc.com (MXHUB303.corp.emc.com [10.146.3.29]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u7N3xA59021587 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Mon, 22 Aug 2016 23:59:11 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB303.corp.emc.com ([10.146.3.29]) with mapi id 14.03.0266.001; Mon, 22 Aug 2016 23:59:10 -0400
From: "Black, David" <david.black@emc.com>
To: S Moonesamy <sm+ietf@elandsys.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, Lars Eggert <lars@netapp.com>, Godred Fairhurst <gorry@erg.abdn.ac.uk>, Greg Shepherd <gjshep@gmail.com>
Thread-Topic: [tsvwg] APPSDIR review of draft-ietf-tsvwg-rfc5405bis-16
Thread-Index: AQHR7zxJfVZEuBWmF02p/XQC8WgdsqBWBgow
Date: Tue, 23 Aug 2016 03:59:09 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949362F65D270@MX307CL04.corp.emc.com>
References: <6.2.5.6.2.20160805084142.0bd419e8@elandnews.com>
In-Reply-To: <6.2.5.6.2.20160805084142.0bd419e8@elandnews.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.97.6.90]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com
X-RSA-Classifications: public
Archived-At: <https://mailarchive.ietf.org/arch/msg/apps-discuss/gzgWyQPTQwRnbXAVUhb_sshHr3E>
Cc: "Black, David" <david.black@emc.com>, "iesg@ietf.org" <iesg@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Subject: Re: [apps-discuss] [tsvwg] APPSDIR review of draft-ietf-tsvwg-rfc5405bis-16
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Aug 2016 03:59:34 -0000

> In Section 3.1.9:
> 
>    "Applications intended for the Internet SHOULD NOT assume that
>     QoS mechanisms are supported by the networks they use, and
>     therefore need to provide congestion control, error recovery,
>     etc. in case the actual network path does not provide
>     provisioned service."
>
> Is there a case when an application intended for use on the Internet
> can assume that QoS mechanisms are supported throughout both ends of
> the connection?

I guess that begs the definition of "intended for the Internet" - if such an
application has complete knowledge of the network path or paths involved
it could know that there is provisioned QoS.  That's a specialized case, but
it is possible.

Thanks, --David (as draft shepherd).

> -----Original Message-----
> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of S Moonesamy
> Sent: Friday, August 05, 2016 12:50 PM
> To: apps-discuss@ietf.org; Lars Eggert; Godred Fairhurst; Greg Shepherd
> Cc: iesg@ietf.org; tsvwg@ietf.org
> Subject: [tsvwg] APPSDIR review of draft-ietf-tsvwg-rfc5405bis-16
> 
> I have been selected as the Applications Area Directorate reviewer
> for this draft (for background on APPSDIR, please see
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).
> 
> Please resolve these comments along with any other Last Call comments
> you may receive. Please wait for direction from your document
> shepherd or AD before posting a new version of the draft.
> 
> Document: draft-ietf-tsvwg-rfc5405bis-16
> Title: UDP Usage Guidelines
> Reviewer: S. Moonesamy
> Review Date: August 5, 2016
> IETF Last Call Date: May 17, 2016
> 
> Summary: This draft is almost ready for publication as an Best Common
> Practice RFC.
> 
> The document is applicable to application protocol designers instead
> of application developers as the recommendation about UDP would have
> to be part of the application protocol for ease of implementation.
> 
> Major issues: None
> 
> 
> Minor issues:
> 
> In Section 3.1.9:
> 
>    "Applications intended for the Internet SHOULD NOT assume that
>     QoS mechanisms are supported by the networks they use, and
>     therefore need to provide congestion control, error recovery,
>     etc. in case the actual network path does not provide
>     provisioned service."
> 
> Is there a case when an application intended for use on the Internet
> can assume that QoS mechanisms are supported throughout both ends of
> the connection?
> 
> Nits:
> 
> In Section 1:
> 
>    "In such cases, it is RECOMMENDED that application designers cite
>     the respective section(s) of this document in the technical
>     specification of their application or protocol and explain
>     their rationale for their design choice.'
> 
> The RFC 2119 key word is used before its definition in Section 2.
> 
> Regards,
> S. Moonesamy