Re: [Rmt] AD Review: draft-ietf-rmt-fcast

[Vincent Roca <[e-mail]>]

Hello David,

It took us some time, but the new - 05 FCAST version is now available,
that hopefully addresses all the comments received.


> AD Review: draft-ietf-rmt-fcast
> 
> s/disconnected during a sufficient time/disconnected for a sufficient
> time/

Done.


> old:
> It is also possible that some use-cases require that each receiver
> download the whole set of objects sent in the session (e.g., with
> mirroring tools). When this is the case, the above limitation is no
> longer be a problem. 
> new:
> When use-cases require that each receiver download the whole set of
> objects sent in the session (e.g., with mirroring tools), this
> limitation is not considered a problem. 
> end

That's much better. Corrected.


> I recommend moving the applicability information in 1.1, plus the
> sentences in 1.0 that start with "depending on the use case", into a
> section entitled "operational considerations", near the security
> considerations section. I, and probably other readers, would like some
> discussion of what the protocol **is** before you go into details
> about the tradeoffs for deployment.

Good idea. Done.


> I assume "On the opposite" is a French colloquialism; it doesn't
> translate very well into English. A different word choice might be
> appropriate. But this is merely a matter of style.

It seems this French expression has not yet been adopted on the other
size of Atlantic. In the meantime I'll use "on the contrary" ;-)
 

> in 3.1, Transmission Object Identifier" "in that specification" -
> please use a reference; "described there" - please use a reference.

Done. Also corrected: Transmission => Transport.


> I think 3.2 is unnecessary, since each term defined in 3.1 could have
> the relevant abbreviation defined as well (as you already do with CID
> and TOI)

Done.


> in 4.2, s/as such//

Removed from 4.2 and from introduction.


> in 4.2, "this mechanism" - which mechanism? the one defined in this
> document or the in-band or OOB signaling mechnaisms that is out of
> scope of this document?

Clarified. Yes, we mean the in-band or OOB scheme.


> in 4.3, "Note that" is usually superfluous. Does the point get made
> without the "Note that"?

For clarity purposes, I prefer keeping the sentences.
However I have updated the "Content-Length" and "Content-MD5"
definitions and removed "Note that" so that is appears as an integral
part of the definition rather than a superfluous point.


> in 4.3, it would be good to specify the data types, sizes, ranges,
> etc. used for each of these fields, so implementations from different
> developers will use the same data types.

Very good point. This is now clarified and aligned on the XML schema
defined in FLUTE-revised (even if the i-d does not define and XML
encoding of meta-data unlike Flute).
In some cases, the use of a particular FEC scheme or transport protocol
MAY restrict the valid ranges. This is now discussed.


> s/A value strictly greater than 1/A value greater than 1/

Removed.


> I believe this would be much more readable if the header format was
> defined BEFORE the processing that manipulates the fields from the
> header.
> 
> I am concerned about the many optional ways to send or process
> metadata. This is a standard, and the compliance requirements should
> be clear and unambiguous to ensure interoperability. The flexibility
> of the options of this spec argues against interoperability. For
> example, if an implementation MAY  use the FEC OTI, it does not need
> to use the optional EXT-FTI mechanism. So what if one implementation
> chooses to use the FEC OTI, but another implementation chooses to use
> the optional EXT-FTI and not the FEC OTI? Can they communicate clearly
> and interoperably? I STRONGLY recommend going through this document
> and finding every optional implementation decision, and determine
> whether different implementation choices make interoperability harder.
> If so, get rid of the optionality and specify a clear and unambiguous
> REQUIRED behavior for COMPLIANT implementations to ensure cross-vendor
> interoperability.
> 
> "When meta-data elements are communicated out-of-band, in advance of
> data transmission, the following pieces of information MAY also be
> useful:" The whole problem with this text is that it is describing
> something totally out of scope for this specification. The
> specification.SHOULD be describing what is REQUIRED behavior for
> compliant implementations, not interesting ideas for implementations
> of features that are not part of the standard. I STRONGLY recommend
> going through this document and finding every out of scope
> implementation proposal, and determine whether different
> implementation choices make interoperability harder. If so, lose the
> discussion of the out-of-scope optionality and specify a clear and
> unambiguous REQUIRED behavior for COMPLIANT implementations to ensure
> cross-vendor interoperability.

We agree. We've now completely changed the document organization.
We kept the in-band mechanisms in the FCAST core description and moved
additional schemes to Annex B.
A new section has been added:
        5.  Requirements for Compliant Implementations
to discuss what mechanism MUST be implemented and/or used,
and what remains OPTIONAL. Interoperability will be more easily
achieved now.


> in 4.1, please move the whole discussion of the impact of the choice
> of underlying protocol and other deployment choices into an
> operational considerations section.

Done, we've added a new section:
        6. Operational Considerations

 
> I'm at section 4.3, and still waiting for you to tell me what the
> FCAST on-the-wire format is, and how that format gets processed. I'm
> seeing a lot of hand-waving and wonder "where's the beef?"

Done. You can now "eat some beef" at page 6, and then, from page 11,
understand what "you've just eaten".

 
> "FCAST is designed to be as self-sufficient as possible, in particular
> in the way object meta-data is attached to object data content.
> However, for some uses, meta-data MAY also be communicated by an out-
> of-band mechanism that is out of the scope of the present document."
> So what does this have to do with compliance requirements? There are
> six places in this document where you discuss things that are out of
> scope for this document. What you really need to discuss is what is
> **in scope** for this document.
> 
> in 4.2, FCAST "usually" carries meta-data. When do you start talking
> about compliance to a specification that works the same across
> implementations?
> 
> "This header is composed of the meta-data as well as several fields."
> This is not clear and unambiguous.
> 
> Please rewrite this document as a STANDARDS PROPOSAL, with clear and
> unambiguous compliance requirements. 

We agree.
An FCAST sender MUST send all meta-data using FCAST in-band
mechanism. All receivers MUST be able to process this in-band
meta-data communication, at a minimum.
Then, if there is a desire to optimize the receiver behavior in a well
defined use-case, a sender MAY in addition (and not as a replacement)
send meta-data (or a subset of) using an out-of-band (or NORM's
INFO message). This is an option, that may not be supported by all
receivers, but those receivers that don't support this feature will still
be able to receive and process meta-data sent in the Compound
Object. This fixes the issue.

 
> I strongly recommend starting with the on-the-wire format, and then
> discuss how the sender must/should prepare the message, how the
> receiver must/should process the message, how the receiver must/should
> respond to the message, and how the originator must/should process the
> response. Then you can discuss things like operational deployment
> considerations, security considerations, and so on. I think that will
> make a much more useful standards specification.

Done as explained above.

> 
> 
> David Harrington
> Director, IETF Transport Area
> [e-mail] (preferred for ietf)
> [e-mail]
> [phone] (cell)

Thanks a lot for all these valuable suggestions.
Cheers,

   Vincent and Brian