Skip to main content

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

Discuss


Yes

(Martin Stiemerling)

No Objection

(Adrian Farrel)
(Benoît Claise)
(Joel Jaeggli)
(Pete Resnick)
(Richard Barnes)
(Robert Sparks)
(Ron Bonica)
(Ted Lemon)

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

Russ Housley Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2013-01-21 for -07) Unknown
  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.
Wesley Eddy Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2013-01-23 for -07) Unknown
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.
Martin Stiemerling Former IESG member
Yes
Yes (for -07) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (2013-01-24 for -07) Unknown
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.
Benoît Claise Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (2013-01-21 for -07) Unknown
I agree with Russ' DISCUSS point that sections 3.3 and 5 should be combined.
Jari Arkko Former IESG member
No Objection
No Objection (2013-03-20 for -07) Unknown
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.
Joel Jaeggli Former IESG member
No Objection
No Objection () Unknown

                            
Pete Resnick Former IESG member
(was Discuss) No Objection
No Objection (2013-04-10) Unknown

                            
Ralph Droms Former IESG member
(was Discuss) No Objection
No Objection (2013-02-19 for -07) Unknown
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?
Richard Barnes Former IESG member
No Objection
No Objection () Unknown

                            
Robert Sparks Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (2013-01-23 for -07) Unknown
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
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2013-03-26) Unknown
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.
Stewart Bryant Former IESG member
No Objection
No Objection (2013-01-22 for -07) Unknown
I support Stephen's discuss concerning MD5 and was asking myself the same question. Indeed why does the protocol not include algorithm agility?
Ted Lemon Former IESG member
No Objection
No Objection () Unknown