[tsvwg] APPSDIR review of draft-ietf-tsvwg-rfc5405bis-16

S Moonesamy <sm+ietf@elandsys.com> Fri, 05 August 2016 17:10 UTC

Return-Path: <sm@elandsys.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C7512D926; Fri, 5 Aug 2016 10:10:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.077
X-Spam-Level:
X-Spam-Status: No, score=-3.077 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=HARm6TFZ; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=Vax7jZr4
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 u4IG_Sge0uU9; Fri, 5 Aug 2016 10:10:05 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6801D12D925; Fri, 5 Aug 2016 10:10:05 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.226.54.237]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u75H9cNH026895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Aug 2016 10:09:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1470416993; x=1470503393; bh=ygXuS+OzoRvzTch5+NEn5gvIQ/BDwj3b4KWNJ5RL2zE=; h=Date:To:From:Subject:Cc; b=HARm6TFZjxby+ogFo7SwVojB/vB0/sBKsIENj9sDNpg3W6shkDBmtw+c5W6b0oBGz BHX96mzn+OOghR9Z9UgvfdAsNul6K8AY7Ax6OPtR13AP9nQ0uY3TmUhLTqmkINP71k 9BhcrABTdc5hUddqkCItc8nZIwosRYiQ2MjFzs+Y=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1470416993; x=1470503393; i=@elandsys.com; bh=ygXuS+OzoRvzTch5+NEn5gvIQ/BDwj3b4KWNJ5RL2zE=; h=Date:To:From:Subject:Cc; b=Vax7jZr4/lmP/SrY54vf307dy4oV2au675x9joNfloyG/Cbfw8/qnxZ0dkVZWWd1f PbbnprnzW8BOggZA/xG48aKQ2fROJWiZFV6TwCR8kRJ6QPrRUEJxYUH4vRwbsqbHCS J6JskBZ6oJ0GDP8FCqgzdMonTHSnefc0pv4bPP7Q=
Message-Id: <6.2.5.6.2.20160805084142.0bd419e8@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 05 Aug 2016 09:49:54 -0700
To: apps-discuss@ietf.org, Lars Eggert <lars@netapp.com>, Godred Fairhurst <gorry@erg.abdn.ac.uk>, Greg Shepherd <gjshep@gmail.com>
From: S Moonesamy <sm+ietf@elandsys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/2b0-WmASl39Y3ZXvBuyyoo9eRSA>
Cc: iesg@ietf.org, tsvwg@ietf.org
Subject: [tsvwg] APPSDIR review of draft-ietf-tsvwg-rfc5405bis-16
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Aug 2016 17:10:09 -0000

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