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

Note: This ballot was opened for revision 07 and is now closed.

(Wesley Eddy) Discuss

Discuss (2013-01-23 for -07)
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.
Comment (2013-01-23 for -07)
No email
send info
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).

(Russ Housley) Discuss

Discuss (2013-01-21 for -07)
  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.

(Martin Stiemerling) Yes

(Jari Arkko) No Objection

Comment (2013-03-20 for -07)
No email
send info
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.

(Richard Barnes) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2013-01-22 for -07)
No email
send info
I support Stephen's discuss concerning MD5 and was asking myself the same question. Indeed why does the protocol not include algorithm agility?

(Benoît Claise) No Objection

(Ralph Droms) (was Discuss) No Objection

Comment (2013-02-19 for -07)
No email
send info
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?

(Adrian Farrel) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2013-03-26)
No email
send info
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.

(Brian Haberman) No Objection

Comment (2013-01-21 for -07)
No email
send info
I agree with Russ' DISCUSS point that sections 3.3 and 5 should be combined.

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2013-01-24 for -07)
No email
send info
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.

(Ted Lemon) No Objection

(Pete Resnick) (was Discuss) No Objection

(Robert Sparks) No Objection

(Sean Turner) No Objection

Comment (2013-01-23 for -07)
No email
send info
1) I support Stephen's discuss.

2) Also please consider Chris Lonvick secdir review comments:
https://www.ietf.org/mail-archive/web/secdir/current/msg03716.html