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

Hi,

General agreement within IESG is that a new version# is needed since
the new draft is not backwards compatible with the experimental specs.

If you want to keep the same version#, we will need to make a
convincing argument.
"People already implemented from the internet draft" is not likely to
be convincing.

I haven't gotten any response to my questions (below).
These are questions that other IESG members have asked.
Please provide answers to these questions.

dbh

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of David B Harrington
> Sent: Thursday, June 10, 2010 4:32 PM
> To: 'Watson, Mark'
> Cc: [email protected]
> Subject: Re: [Rmt] 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
> > 
> > 
> 
> _______________________________________________
> Rmt mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rmt
>