Re: AD Review: draft-ietf-rmt-flute-revised-11

Hi,

see draft-ietf-rmt-flute-revised-11, section 1, paragraph 1, sentence
2:
"This specification is backwards compatible with the previous
experimental version defined in
   [RFC3926]."

If backwards compatibility is NOT a goal, then you should state that.

Question: is the Experimental version deployed in real-world networks
and products? Is it normatively referenced in other standards?
Question: if both the Experimental and this specification are deployed
in the same network, will they work interoperably? will they interfere
with each other?

dbh

> -----Original Message-----
> From: Watson, Mark [mailto:[email protected]] 
> Sent: Thursday, June 10, 2010 3:34 PM
> To: David B Harrington
> Cc: [email protected]
> Subject: Re: [Rmt] AD Review: draft-ietf-rmt-flute-revised-11
> 
> David,
> 
> Is strict backwards compatibility with the experimental RFC a 
> goal ? (I agree that if it was, we did not meet it and then a 
> new version number is required for the reasons you give).
> 
> There are a number of SDOs that have based their work on the 
> drafts of this version and they would presumably like to 
> reference this RFC. A change in version number wouldn't be 
> possible for them.
> 
> I think there were a number of issues with the Experimental 
> version would we wanted to fix, which could never have been 
> done in a strict backwards compatible way, and so if we had 
> ever been concerned about interop problems with RFC3926 
> implementations we should have increased the version number long
ago.
> 
> ...Mark
> 
> On Jun 9, 2010, at 3:59 PM, David B Harrington wrote:
> 
> > 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
> > [email protected]
> > [email protected]
> > [email protected]
> > 
> > 
> > _______________________________________________
> > Rmt mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/rmt
> 
>