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