FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols
draft-ietf-rmt-fcast-08

[Ballot comment]

Many thanks for addressing my discuss and comment points.

I didn't check all the check all the changes you made against
the comments, but the digest thing looks fine. I'm happy to
check how you handled any of the comments if you want,
just let me know.

[Ballot comment]
I am in a no-objection position for this document. Earlier Russ was holding a discuss (copied below) based on not having gotten a response to a Gen-ART review. According to my records, on February 13th Vincent Roca responded. We have yet to see a document revision, but I do not think the issues are serious enough to warrant me to hold a discuss on submitting the edits that Vincent indicate had already happened on their copy. Sponsor AD, please ensure that once you approve this, there is a new version.

---
Original Discuss from Russ Housley:

The Gen-ART Review by Roni Even on 15-Jan-2013 did not receive a
  response.  I think that the two minor issues raised in the review
  need a response.  They are repeated below.

  Minor issues:

  1.  I had some problem when reading the document about what is
      mandatory to support. The distinction between what is required
      to be  supported and used is mentioned in section 5. Also
      section 3.3 discusses what compliant implementation is, but
      section 5 provides the full information. I think that it will be
      better to move section 5 before or at the beginning of section 3
      or as part of  3.3.  no need to have the information twice.

  2.  In section 3.3 “The support of GZIP encoding, or any other
      solution, remains optional.” I think that support is mandatory.

  Please also consider the editorial comments in the review.

[Ballot comment]
The first two Comment issues (were originally in a Discuss) should
be easy to resolve; however, in my opinion
they are critical to implementing interoperable implementations and
need to be addressed before publication.

1) Is the definition of Compound Object in section 1.2 incomplete;
e.g., "[...] Compound Object Header and Object Data" (from the
definitions in 2.1 and 3.2).  It would be helpful to include a
citation of the definition of Compound Object Header (and Object Data,
if appropriate) to signal to the reader that they are defined in this
document.

2) What is the relationship between "Compound Object Header" and
"Object Meta-Data"?  Reading the description of the "Compound Object
Header Length" on page 7, I deduce that the "Compound Object Header
includes the first 8 bytes and the optional "Object Meta-Data" in
Figure 1.

These issues are less critical:

3) Asking out of curiosity, if the length of the Object Meta-Data can
be deduced from the Compound Object Header Length, why is the Object
Meta-Data NULL-terminated?

4) In section 3.3, is the Content-Length in units of bytes?

[Ballot comment]
To the authors:
Most of my comments are already covered.  I support the DISCUSS positions by Pete, Russ, and Stephen.

To the IESG:
I also note that there's a downref to RFC 1952 (GZIP file format specification), which was not called out in the last call notice.  We should NOT re-run last call for this -- given earlier downrefs to 1952, we should just add 1952 to the downref registry now.

[Ballot discuss]
In my opinion, if there aren't known implementations (as the shepherd writeup says), then I'm not sure why we need Standards Track.  It is admittedly more limited than FLUTE, which is already on the Standards Track ... the only clue I got was in the writeup's hinting that the IPR claims against FLUTE motivated revival of an old FCAST proposal that had formerly been pushed out by FLUTE.  However, given the IPR around FEC, multicast protocols, etc., I'm not so sure that FCAST is going to be that much better in the long run in terms of IPR ...

In my opinion, there's not a lot of motivation for putting dueling Standards Track protocols out, especially if this one doesn't seem to be implemented in its current incarnation ... why not just snapshot it at Experimental or just wait for implementations?  Given how much can go wrong with this type of protocol, it would seem prudent.

[Ballot comment]
Even though I've breathlessly defended the use of MD5 checksums in other cases, in this document (and for the use cases this protocol might be envisioned for), it isn't clear at all that it's the right choice, and I basically support Stephen's DISCUSS point on it.  There doesn't seem to be much logic in the current document comparing it to alternatives and motivating why it was chosen (especially against some of the downsides that Stephen noted).

[Ballot discuss]
These Discuss points should be easy to resolve; however, in my opinion
they are critical to implementing interoperable implementations and
need to be addressed before publication.

1) Is the definition of Compound Object in section 1.2 incomplete;
e.g., "[...] Compound Object Header and Object Data" (from the
definitions in 2.1 and 3.2).  It would be helpful to include a
citation of the definition of Compound Object Header (and Object Data,
if appropriate) to signal to the reader that they are defined in this
document.

2) What is the relationship between "Compound Object Header" and
"Object Meta-Data"?  Reading the description of the "Compound Object
Header Length" on page 7, I deduce that the "Compound Object Header
includes the first 8 bytes and the optional "Object Meta-Data" in
Figure 1.

[Ballot comment]
1) Asking out of curiosity, if the length of the Object Meta-Data can
be deduced from the Compound Object Header Length, why is the Object
Meta-Data NULL-terminated?

2) In section 3.3, is the Content-Length in units of bytes?

[Ballot discuss]
Throughout the document: "plain text" and "plain text encoding" are ambiguous, and "un-encoded", "not encoded" and "without any encoding" are meaningless and wrong. All text is encoded somehow. I suspect you mean "US-ASCII text" or "net ASCII" (i.e., 7bit text in an 8bit octet). (You could put in a reference to RFC 20 if you are feeling particularly playful.) But does that mean that you are disallowing UTF-8? One way or another, throughout this document, you need to clarify what you mean.

[Ballot comment]
Thank you for a document that judiciously and correctly uses 2119 language. Well done. Only two instance where I think you've misused them:

2.1 & 5.1: MDFmt & MDEnc - "MAY be defined in the future". Lowercase the "MAY".

2.2: "If absent, a receiver MUST conclude that the session is complete." Are you saying that it is a protocol violation for me to implement this such that sessions hang around and a garbage collector cleans up old ones? I MUST mark the session as complete in my implementation if there is Fcast-CID-Complete entry or I have violated the protocol? Conversely, if I get an Fcast-CID-Complete entry set to '0', I am *not* REQUIRED to conclude the session is complete (because you never say "MUST conclude the session is complete for Fcast-CID-Complete=0")? I don't think you really mean any of this. Instead, "The absence of the entry is semantically equivalent to an Fcast-CID-Complete entry set to 0."

IANA has reviewed draft-ietf-rmt-fcast-07 and has the following comments:

IANA has questions about the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are three actions which IANA must complete.

IANA Question -> The first sentence of section 7 of the draft states that "This specification requires IANA to create two new registries."  However, IANA believes that the document calls for the creation of three registries.  Is the quantity in the first sentence a typo?

IANA Question -> Do the authors have a location (for instance, an existing registry) in mind for these three new registries; or, should they be combined as three new subregistries of a new top-level registry at: http://www.iana.org/protocols

First, a new registry will be created.  The registry will be called the "FCAST Object Meta-Data Format" registry.  The registry entries consist of a numeric value from 0 to 15, inclusive.  Future maintenance of the registry and new assignments are to be done through Expert Review with Specification Required as defined by RFC 5226.

There is an initial registration in the new registry as follows:

Value    Format Name        Format Reference          Reference
---------+-------------------+-------------------------+----------------
0        HTTP/1.1            RFC 2616                  [ RFC-to-be ]
(default) metainformation    Section 7.1
          format
1-15      Unassigned

Second, a new registry will be created.  This registry will be called the "FCAST Object Meta-Data Encoding" registry. The registry entries consist of a numeric value from 0 to 15, inclusive.  Future maintenance of the registry and new assignments are to be done through Expert Review as defined in RFC 5226.

There are initial registrations in the new registry as follows:

Value    Encoding Name      Encoding Reference        Reference
---------+-------------------+-------------------------+----------------
0        Plain Text          [ RFC-to-be]              [ RFC-to-be ]
(default)
1        GZIP                RFC1952                  [ RFC-to-be ]
2-15      Unassigned

Third, a new registry will be created.  This registry will be called the "FCAST Object Meta-Data Types" registry The registry entries consist of additional text meta-data type identifiers and descriptions for meta-data item types that are specific to FCAST operation and not previously defined in RFC1952.  Future maintenance of the registry and new assignments are to be done through Expert Review as defined in RFC 5226.

There are initial registrations in the new registry as follows:

+------------------------+--------------------------+---------------+
| Meta-Data Type        | Description              |  Reference  |
+------------------------+--------------------------+---------------+
| Fcast-Obj-Slice-Nb    | Unsigned 32-bit integer  | [ RFC-to-be ] |
|                        | that contains the total  |              |
|                        | number of slices.  A    |              |
|                        | value greater than 1    |              |
|                        | indicates that this      |              |
|                        | object is the result of  |              |
|                        | a split of the original  |              |
|                        | object                  |              |
| Fcast-Obj-Slice-Idx    | Unsigned 32-bit integer  | [ RFC-to-be ] |
|                        | that contains the slice  |              |
|                        | index (in the {0 ..      |              |
|                        | SliceNb - 1} interval)  |              |
| Fcast-Obj-Slice-Offset | Unsigned 64-bit integer  | [ RFC-to-be ] |
|                        | that contains the byte  |              |
|                        | offset at which this    |              |
|                        | slice starts within the  |              |
|                        | original object          |              |
+------------------------+--------------------------+---------------+

IANA understands that the creation of these three registries are
the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

[Ballot discuss]

Is it really sensible to define Content-MD5 for a new protocol
where there aren't current implementations?  Why not
use/define something with a better hash algorithm such as
sha-256? MD5 collisions are quite practical these days, and
even though you say this is just to prevent accidents, it
seems like a bad plan to use something so broken (for
collisions) as people might well not get that and rely on MD5
being a good hash function (which it is not these days).
Couldn't you as easily define an "Fcast-Obj-Digest" or
"Fcast-Obj-SHA-256" header and avoid the potential problems?
I'm not sure if it'd work here, but you might consider use of
the RFC 3230 digest header with sha-256, which is registered
with IANA. [1] Using MD5 for non-security purposes can also
generate false positives when code is examined by e.g.
security consultants, and adding more noise to such
assessments also seems like a bad plan. Note: I'm not saying
here that you must use a more secure hash function to clear
this discuss, I'm asking why not, since doing so won't cause
you (much) pain and will be better.

  [1] http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xml

[Ballot comment]


- abstract: if this incarnation hasn't been implemented I
wonder how we know its highly scalable? maybe it'd be better
to say "designed to be highly scalable" if in fact that's all
we know. (If you do know that it is highly scalable, then
maybe it'd be good to include some evidence for that in the
body of the document or an appendix.)

- 1.2: The carousel terminology is a bit confusing - the
general term is a process, but each instance is a set of
objects. That seems odd.

- 2.1: only 4 versions ever? ok but I'd expect you might have
been better to use the luxurious 4 additional reserved bits as
well, but whatever.

- 2.1:  If http metadata is used, are there issues with e.g.
header fields continued over multiple lines that can be used
to attack receivers?  I don't think section 4 covers this kind
of case where a sender is (perhaps accidentally) sending bad
meta-data that might cause a receiver to do a bad thing. For
an example of the kind of issue that can occur in the HTTP
protocol, see [2]. Perhaps you need some text saying that
receivers need to be careful what they do with received
meta-data and e.g. that they SHOULD NOT follow links
automatically or whatever? Or maybe there are other bad things
that a (compromised) sender could do to the receiver this way?

  [2] http://cwe.mitre.org/data/definitions/444.html

- 2.2: Is it clear how to set Fcast-CID-Complete to '1'?
i.e., which of these are ok?
  Fcast-CID-Complete: 1
  Fcast-CID-Complete: "1"
  Fcast-CID-Complete: '0';
  Fcast-CID-Complete: true
  Fcast-CID-Complete: no

- 2.2: when does CIID "start from zero" - do you mean on each
re-boot or after first install or what? Why not just start
somewhere random? (To make it harder to guess.)

- 2.2: "MUST assume" is an odd phrase in the description of
how to handle gzip encoding

- 2.2: s/equals size '='/equals sign '='/ ?

- 3.3 says that gzip support is optional, but earlier (in 2.2)
it was REQUIRED, is that a mistake or do you really want that
difference for the different cases?

- 3.6, last para: how does a receiver determine that both
objects are the same based on meta-data? If its via the
Content-MD5 header then collisions for that are a bigger
concern, even if you say they are not:-) Or maybe I'm missing
some other way to compare objects based on meta-data?

- Section 4 (which is pretty thorough btw - thanks!)
RECOMMENDs things like "at least one of these techniques be
used" (end of 4.2) but doesn't clearly make any one mandatory
to implement (MTI). 4.5 says that it will do that but doesn't
actually have any clear MUST for IPsec. I guess you might say
that the relevant MUST (or SHALL) is inherited from RFCs 5775
and 5740, but I think it'd be better to be clear here that
transport mode IPsec with ESP is a MUST implement. Or you
could add a new subsection to section 5 for that, if that is
felt to be better.

- I'm curious as to how widely you think transport mode IPsec
would be used with this. It'd be a pity to make it MTI if its
not going to be used.

[Ballot discuss]

  The Gen-ART Review by Roni Even on 15-Jan-2013 did not receive a
  response.  I think that the two minor issues raised in the review
  need a response.  They are repeated below.

  Minor issues:

  1.  I had some problem when reading the document about what is
      mandatory to support. The distinction between what is required
      to be  supported and used is mentioned in section 5. Also
      section 3.3 discusses what compliant implementation is, but
      section 5 provides the full information. I think that it will be
      better to move section 5 before or at the beginning of section 3
      or as part of  3.3.  no need to have the information twice.

  2.  In section 3.3 “The support of GZIP encoding, or any other
      solution, remains optional.” I think that support is mandatory.

  Please also consider the editorial comments in the review.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (FCAST: Scalable Object Delivery for the ALC and NORM Protocols) to Proposed Standard


The IESG has received a request from the Reliable Multicast Transport WG
(rmt) to consider the following document:
- 'FCAST: Scalable Object Delivery for the ALC and NORM Protocols'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-01-22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document introduces the FCAST object (e.g., file) delivery
  application on top of the ALC and NORM reliable multicast protocols.
  FCAST is a highly scalable application that provides a reliable
  object delivery service.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-rmt-fcast/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-rmt-fcast/ballot/


No IPR declarations have been submitted directly on this I-D.

This draft should go through another round of WG last call, as the -00 version was last called in the WG in 2010 (http://www.ietf.org/mail-archive/web/rmt/current/msg01428.html), but not any version after.

INTRODUCTION, paragraph 0:


  Check for the downrefs reported by idnits.


Section 2., paragraph 1:

>    This section details the various data formats used by FCAST.

  I was about to say that this section comes way too early in the
  draft, but I have seen in the AD review of Dave Harrington that he
  recommended to move it more upfront. So I won't interfer with this,
  i.e., moving it again.


Section 2.1., paragraph 1:

>    In an FCAST session, Compound Objects are constructed by prepending
>    the Compound Object Header (which contains the meta-data of the
>    object) before the original object data content (see Section 3.2).
>    Figure 1 illustrates the associated Compound Object header format.

  It would be good to note that everything is in network-byte order,
  not only for this format but in general for the whole document.


Section 2.1., paragraph 5:

>    +------------+------------------------------------------------------+
>    |      Field | Description                                          |
>    +------------+------------------------------------------------------+
>    |    Version | 2-bit field that MUST be set to 0 in this            |
>    |            | specification and indicates the protocol version    |
>    |            | number.                                              |

  Should the version also be registered in an IANA registry?


Section 2.1., paragraph 6:

>    |  Checksum | 16-bit field that contains the checksum computed    |
>    |            | over either the whole Compound Object (when G is set |
>    |            | to 1), or over the Compound Object header (when G is |
>    |            | set to 0), using the Internet checksum algorithm    |
>    |            | specified in [RFC1071].  More precisely, the        |
>    |            | checksum field is the 16-bit one's complement of the |
>    |            | one's complement sum of all 16-bit words to be      |
>    |            | considered.  If a segment contains an odd number of  |
>    |            | octets to be checksummed, the last octet is padded  |
>    |            | on the right with zeros to form a 16-bit word for    |
>    |            | checksum purposes (this pad is not transmitted).    |
>    |            | While computing the checksum, the checksum field    |
>    |            | itself is set to zero.                              |

  replace 'itself is set to zero.' with 'itself MUST be set to zero.'


Section 2.2., paragraph 16:

>    This string CAN also contain the TOI equivalences, if any.  The

  There is no 'CAN' keyword defined in RFC 2119 or somewhere
  else. Please check this throughout the whole draft. Just replace
  'CAN' by 'can'.


Section 2.2., paragraph 18:

>    The ABNF specification is the following:

  What incarnation of ABNF? RFC 5234?


Section 2.2., paragraph 19:

>    ciid-value  = 1*DIGIT
>    DIGIT        =  %x30-39
>                    ; a digit between O and 9, inclusive

  Replace 'between O' with 'between 0'. It is an O in the text above.


Section 3.3., paragraph 1:

>    A compliant FCAST implementation MUST support the following meta-data
>    items:

  Please add here a referene that those are out of RFC 2616.


Section 3.3., paragraph 7:

>    A compliant FCAST implementation MUST support the following meta-data
>    types that can be used for dealing with very large objects (e.g.,
>    that largely exceed the working memory of a receiver).  In that case
>    the initial object is split into several slices.  Each slice is
>    considered as a separate sub-object and the meta-data associated to
>    each sub-object MUST include the following entries:

  I wonder where those meta-data types are coming from. You are
  defining them, but you do not have any IANA registry from them.


Section 3.3., paragraph 11:

>    Future standards actions MAY extend the set of meta-data items
>    supported by FCAST.

  replace 'MAY' with 'can'.


Section 3.5., paragraph 1:

>    The FCAST sender CAN transmit an OPTIONAL Carousel Instance
>    Descriptor (CID).  The CID carries the list of the Compound Objects

  Another appearance of 'CAN'.


Section 3.5., paragraph 2:

>    that are part of a given Carousel Instance, by specifying their
>    respective Transmission Object Identifiers (TOI).  However the CID
>    does not describe the objects themselves (i.e., there is no meta-
>    data).  Additionally, the CID MAY include a "Complete" flag that is

  I assume the "Complete" flag is referring to the C flag in Section
  2.1, isn't it? However, it is not clear that the C flags is actually
  the complete flag. Either you name it here the C flag or add
  "Complete" to the flag's description in Section 2.1.


Section 3.5., paragraph 4:

>    There is no reserved TOI value for the CID Compound Object itself,
>    since this special object is regarded by ALC/LCT or NORM as a
>    standard object.  On the contrary, the nature of this object (CID) is
>    indicated by means of a specific Compound Object header field (the
>    "I" flag) so that it can be recognized and processed by the FCAST

  Where does the "I" flag come from?


Section 3.5., paragraph 5:

>    application as needed.  A direct consequence is the following: since
>    a receiver does not know in advance which TOI will be used for the
>    following CID (in case of a dynamic session), he MUST NOT filter out

  replace 'he' with 'it'.


Section 3.5., paragraph 13:

>    o  the session is still active even if there is currently no content
>      being sent.  Said differently, it can be used as a heartbeat
>      mechanism.  If the "Complete" flag has not been set, it implicitly
>      informs the receivers that new objects MAY be sent in the future;

  replace 'MAY' by 'can'.


Section 3.7., paragraph 0:

3.7.  FCAST Sender Behavior

  What is the normative status of this section and also Section
  3.8? Informative or normative? I assume informative. Please state
  it in the beginning of Section 3.7 and 3.8, if it is so.


Section 3.7., paragraph 1:

>    The following operations MAY take place at a sender:

  replace 'MAY' by 'can'.


Section 3.8., paragraph 1:

>    The following operations MAY take place at a receiver:

  replace 'MAY' by 'can'.


Section 4.1., paragraph 1:

>    A content delivery system is potentially subject to attacks.  Attacks
>    may target:

  replace 'may' by 'can' as this is cleary about the ability of
  performing attacks.


Section 6., paragraph 9:

>    The receiver set MAY be restricted to a single receiver or MAY
>    include possibly a very large number of receivers.  While the choice

  replace both 'MAY' by 'can'.


Section 7.1., paragraph 3:

>          +----------------------------------------+-------------+
>          |              format name              |    Value    |
>          +----------------------------------------+-------------+
>          | as per HTTP/1.1 metainformation format | 0 (default) |
>          +----------------------------------------+-------------+

  I would recommend to add a table column about 'formant name ref'
  and adding RFC 2616 to add, potentially also which section. I would
  also add a table column with references to where the values have
  been defined, i.e., this draft.


Section 7.2., paragraph 3:

>                        +------------+-------------+
>                        |    Name    |    Value    |
>                        +------------+-------------+
>                        | plain text | 0 (default) |
>                        |    GZIP    |      1      |
>                        +------------+-------------+

  Similar comment here as for the table in Section 7.1: add table
  columns with references to GZPI and the origin of the value.


Appendix A., paragraph 0:

Appendix A.  FCAST Examples

  Please state that this Appendix is informative and not part of
  the standard.


Appendix B., paragraph 0:

Appendix B.  Additional Meta-Data Transmission Mechanisms

  Please add a statement indicating that this appendix is normative.


Appendix B., paragraph 2:

>    In certain use-cases, FCAST MAY take advantage of another in-band
>    (e.g., via NORM INFO messages Appendix B.2) or out-of-band signaling
>    mechanism.  This additional signaling scheme MAY be used to carry the

  replace both 'MAY' by 'can'.

>    whole meta-data, or a subset of it, ahead of time, before the
>    associated compound object.  Therefore a receiver may be able to

  replace 'receiver may be' by 'receiver can be'.


Appendix B., paragraph 5:

>    When meta-data elements are communicated out-of-band, in advance of
>    data transmission, the following piece of information MAY be useful:

  replace 'MAY' by 'can'.

State changed to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup.
AD Follow-up: draft-ietf-rmt-fcast



In my AD Review, I advised that the number of options seemed too big, and each optional feature should be considered as to whether it was really needed in a standard.

Section 5 defines mandatory-to-implement features for compliance, which helps.



Much of this follow-up is questioning individual options.

I expect significant pushback from IESG as to why all these options are required in a standard.

If they really are justified, then don’t make a change, but some text at each point explaining why such options must exist might be helpful. Why is the option necessary?



There are a few other modifications that should help the document advance through IESG Evaluation.

Please address these comments and submit a new revision.

Thanks,

1) The internal references in the last paragraph in section 1 is incorrect, following the rearrangement of the document.
2) 2.2 says the CIID is optional if the FCAST session consists a single complete carousel instance. Why add the complexity of maing thsi optional? Why not make it mandatory in all cases, rather than special-casing one special case?
3) in 2.2, the sentence starts "Additionally," I am unclear what this is in addition to. Is this in addition to the mativation for making the CIID optional in the simple case?
4) The support of GZIP is optional. Then why even mention it here? Let's define a STANDARD that is INTEROPERABLE. How do you interoperate if a sender uses gzip, but the receiver doesn't?
5) the Object List CAN contain a list of TOIs, which CAN be specified as EITHER individual TOIs OR intervals. PICK ONE and STANDARDIZE IT!
6) The Object list CAN be a list of TOIs specified as a comma-spearated list of EITHER TOI values OR TOI_a-TOI_b elements. PICK ONE and STANDARDIZE it!
7) The Object List CAN contain TOI equivalences.
8) For eeadability purposes, it is RECOMMENDED that all TOI vakues be given in increaing order. Why not make this a MUST be in increasing order, and simplify this?
9) it is RECOMMENDED to group them together at the end of the list. Why not make this a MUST and simplify this?
10) A reciver MUST be able to hanlde the same TOI in the TOI and TOI equivalence lsists. Why not require thi sbe done one way and simplify this?
11) 3.3 says Appendix B describes extenisons for carrying additional metadata. Why is this needed in the STANDARD?
12) 3.3 says "This list is not limited and new meta-data information can be added. " Is this really needed in the standard? Is new metadata in a standard-compliant implementation required to be standardized, or can it be proprietary? If a vendor adds proprietary metadata and does not publish the specification of that metadata, then the metadata will not be interoperable across vendors. Is that vendor still standard-compliant? If so , WHY???? How does that "make the Internet run better"? (That is the mission statement for the IETF)
13) 3.4 allows different levels of priority, different transmission frequency, and different FEC prottections. hy do we need all these options?
14) 3.5 makes the CID optional. Why not make it mandatory and allow the list to be empty?
15) 4.3.2 allows a choice of counter-measures, applied on a packet or globally, and where integrity checking is not done, digitally signing is recommended (but not required). Do we REALLY need all these options? Why not STANDARDIZE at least one approach as mandatory-toimplement in order to ensure interoperability between any two implementations? What happens if one implementation supports RSA and anothe IPsec and another digitally signing the object? How will they interoperate?
16) 4.3.3 RECOMMENDs integrity checking and authetication; why not STANDARDIZE this and make this REQUIRED?
17) 4.3.5 RECOMMENDS requiring identification before allowing receivers to join a session. Why not at least one mandatory-to-implement identification method?
18) Finally, there is discussion of some mandatory-to-implement options. If the rest of the IESG experiences this document the way I did, they will be asking lots of questions about why so much optionality. I strongly recommend that your Introduction explains that FCAST is expected to work in many diferent environments (and I suggest mentioning some well known use cases), and is designed to be flexible (despite what it currently says about flexibility versus simplicity), and that section 5 will layout what is mandatory to implement for a compliant implementation. An alternative approach would be to move the mandatory-to-implement tables toward the beginning of the document, and use forward references in the tables, but I think that might be harder for readers.
19) There is quite a bit of work going on the IETF TSV area about streaming, especially peer to peer and content distribution networks, and that is being driven from an application layer perspective, where HTTP has become the protocol of choice. See for example, PPSP, CDNI, decade, and alto. I recommend you talk a bit more about how to use this with HTTP, i.e. include an applicability statement abuot applying this to HTTP environents, so application layer developers can better understand how to use this type of protocol for their content distribution.
20) The opeational considerations explain a lot about the architecure within which you expect FCAST to operate, and the impact that other aspects of the environments have on the design of FCAST. I am not requesting that you make this change, but I think it would have been very helpful to put some of this operational consideration stuff in the Introduction or an early part of the document, and then define the protocol, so readers could better understand what this part of the system is about compared to other parts of the system.

21) Are you requesting the creation of a new registry? If so, please be explicit that you are asking IANA to create a new registry, and specify the fields that make up that registry. Then provide the values to populate the registry. Currently, you specify the values and assume IANA will figure out the format of the registry.

22) The fields in figure 4 are not identified in the figure, so (G=1) is hard to see, MDEnc=0 is hard to see, and lack of content-length information is hard to see. Maybe you identify which bit you are referring to as G, and which bits comprise the MDEnc field, etc. Or show a figure with the fields labeled, and then a second with the values shown.


23) "If out-of-band techniques are out of the scope of this document, we explain below how this may be achieved in case of FCAST/NORM. " If this is out of scope of this document, why are you including it? I am not really objecting,b ut your wording seems pretty weird.
24) "In case a mismatch is detected, the meta-data contained in the Compound Object MUST be privileged." Does this mean that the data in the compound Object overrides the metadata in the other mechanism? I think that could be said more clearly.

State changed to AD Evaluation::Revised ID Needed from Publication Requested.
AD Review: draft-ietf-rmt-fcast

s/disconnected during a sufficient time/disconnected for a sufficient time/

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

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.

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.

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

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)

in 4.2, s/as such//
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?

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

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.

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

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.

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.

I'm at section 4.1, 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?"

"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.  THIS IS SUPPOSED TO BE A STANDARD. 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.

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. I think that will make a much more useful standards specification.

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Lorenzo Vicisano (lorenzo@vicisano.net)

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

The documents has been reviewed by group members. The level of review
seems adequate for this type of document.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.
  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

There is consensus from most of the currently active group participants
behind this document.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

Nobody that I am aware of.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

Yes, see also notes on 1.h.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

The document splits references into Normative and Informative.
All the normative references have been published as RFCs in the
"Standards Track" or "BCP" category with the following exception:

  "** Downref: Normative reference to an Informational RFC: RFC 1952"
  RFC 1952 is used as a reference for gzip. There are precedences of
  "Standards Track" RFCs with normative references to RFC 1952, such
  as RFC 6170.

Also the ID nits tool points out the following:
  "** Downref: Normative reference to an Unknown state RFC: RFC 1071"
  RFC 1071 is "Standards Track".

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The document contains an IANA consideration section that specify the
creation of 2 new registries for the assignment of internal data/metadata
types.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

ABNF syntax verified with http://www.anfdata.cz/bnfparser2/

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:
    Technical Summary
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.

This document specifies a set of data formats and instructions on how to use ALC
(RFC 5775) and NORM (RFC 5740) to implement a file-casting service. In particular
this document specifies an in-band method to advertise the content and duration
of a file-casting session. It also specifies exactly how instantiate an ALC or
NORM transport session for use within this context.

    Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?

FCAST represents the consensus of the RMT WG participants.  FCAST was initially
proposed at the beginning of the RMT effort (circa 2001) and then superseded
by a more comprehensive approach (FLUTE, draft-ietf-rmt-flute-revised-11). Due
to late reported IPR claims on FLUTE, FCAST was re-added to the WG scope to
offer an alternative to FLUTE.

    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

I am not aware of any implementation of FCAST in its newer incarnation, however
FCAST was implemented and widely reviewed in its first incarnation. The
current specification, similar to the original one, also had substantial review
from WG members.