IETF Logo Mail Archive

[Rmt] AD Review: draft-ietf-rmt-flute-revised-11

"David B Harrington" <dbharrington@comcast.net> Wed, 09 June 2010 22:59 UTC

Return-Path: <dbharrington@comcast.net>
X-Original-To: rmt@core3.amsl.com
Delivered-To: rmt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1F623A6925 for <rmt@core3.amsl.com>; Wed, 9 Jun 2010 15:59:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AGodAiUbSnx for <rmt@core3.amsl.com>; Wed, 9 Jun 2010 15:59:26 -0700 (PDT)
Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id 01F0E3A6926 for <rmt@ietf.org>; Wed, 9 Jun 2010 15:59:25 -0700 (PDT)
Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA11.westchester.pa.mail.comcast.net with comcast id Tt2j1e0040Fqzac5ByzUrT; Wed, 09 Jun 2010 22:59:28 +0000
Received: from Harrington73653 ([67.189.235.106]) by omta08.westchester.pa.mail.comcast.net with comcast id TyzU1e0082JQnJT3UyzUMc; Wed, 09 Jun 2010 22:59:28 +0000
From: David B Harrington <dbharrington@comcast.net>
To: rmt@ietf.org
Date: Wed, 09 Jun 2010 18:59:27 -0400
Message-ID: <03a801cb0827$695ed340$0600a8c0@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-index: AcsGo5KHixRD6i6UQSOuTN6HJXAx6ABgk2pA
X-Mailman-Approved-At: Wed, 09 Jun 2010 16:04:25 -0700
Subject: [Rmt] AD Review: draft-ietf-rmt-flute-revised-11
X-BeenThere: rmt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Reliable Multicast Transport <rmt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rmt>, <mailto:rmt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rmt>
List-Post: <mailto:rmt@ietf.org>
List-Help: <mailto:rmt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmt>, <mailto:rmt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jun 2010 22:59:26 -0000

Hi,

I have concerns that this specification might not be totally backward
compatible with version 1 (RFC3926), and should therefore have a new
revision number.

	a) The expiration time in the FDT instance is now required to
be UTF8, but was not so required in RFC3926

	b) section 3.4.1 describes a different wraparound algorithm
than RFC3926

	c) section 3.4.2 modifies the meaning of "Complete"

	d) section 3.4.2 modifies the meaning of "Content Location"

	e) section 3.4.2 modifies the namespace, and significantly
alters the XML Schema. I think an implementation which is valid using
the schema in RFC3926 would not necessarily validate using the schema
in this draft. 

	f) section 3.4.2 modifies the requirement 
		   In case the basic FDT XML Schema is extended in
terms of new
   descriptors, for attributes applying to a single file, those MUST
be
   placed within the attributes of the element "File". 
to
   In case the basic FDT XML Schema is extended in terms of new
   descriptors (attributes or elements), for descriptors applying to a
   single file, those MUST be placed within the element "File".  

	g) section 4 modifies the definition of the CENC field:
   "This field signals the content encoding algorithm used in the FDT
   Instance payload.  The definition of this field is outside the
scope
   of this specification.  Applicable content encoding algorithms
   include, for example, ZLIB [10], DEFLATE [16] and GZIP [17]."
to
   "This field signals the content encoding algorithm used in the FDT
   Instance payload.  This subsection reserves the Content Encoding
   Algorithm values 0, 1, 2 and 3 for null, ZLIB [RFC.ZLIB], DEFLATE
   [RFC.DEFLATE] and GZIP [RFC.GZIP] respectively."

	h) normative references have changed, and it is possible that
those specifications
         have changed such that rfc3926-compliant implementations may
not be compliant
         per this draft. 

I didn't spot anything I thought was problematic if the version#
changed.

I do think that this spec is rather loose, and really should be
tightened for interoperability for proposed standard.

David Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharrington@huawei.com

v2.23.0 | Report a Bug | By Email