Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction
RFC 4082

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

(Russ Housley) Yes

(Harald Alvestrand) No Objection

Comment (2004-09-02 for -)
No email
send info
Reviewed by Joel Halpern, Gen-ART

His review:

I assume that the unusual intellectual property statement is acceptable:
    The authors are not aware of any patents that encumber the free
    use of TESLA. as it seems to say the right thing.

The revisions have addressed the significant comments I had.
Ship it.

(Steven Bellovin) No Objection

(Margaret Cullen) No Objection

Comment (2004-09-02 for -)
No email
send info
It is possible that some details are lost in the lack of distinction that this document makes between broadcast and multicast traffic.  

In particular, the document talks about broadcasting authentication information when I believe that it is important that the authentication information for a multicast flow is multicast to the same multicast group, to ensure that it will reach the same set of intended recipients.

I did not follow the references to determine if this level of detail is better described elsewhere.

BTW, it doesn't make sense that all of the references are informative, because this document seems to be normatively dependent on other TESLA references.

(Bill Fenner) No Objection

(Ted Hardie) (was Discuss) No Objection

(Scott Hollenbeck) (was Discuss) No Objection

Comment (2004-08-17)
No email
send info
I originally had a discuss in for version -08 (the version that was announced for IESG review), but -09 came out before the telechat.  I've cleared my discuss because the update noted that all references are informative.

(David Kessens) No Objection

Comment (2004-09-01 for -)
No email
send info
From Pekka Savola, ops directorate:

I just glanced this through for obvious editorial problems:

- Section 6 "IP Statement" must be removed being inappropriate, and
replaced with proper IPR boilerplates.

- Don't you *really* have anyone else than one person to acknowledge
for feedback, etc.?  Please check that the section is up-to-date.

- The abstract could be shorter, like 5-10 lines, not three

(Allison Mankin) No Objection

Comment (2004-09-02 for -)
No email
send info
It seems that TESLA does not allow synchronization of new group members
after others have already been established except perhaps by the branch approach
described in the extensions (for heterogeneous delay groups); clearly it is the case
the group membership issues are outside the scope of TESLA, but it's a limit on
applicability that should be noted.

The copyright is dated 2000.

Typo: disclodure

(Jon Peterson) No Objection

(Bert Wijnen) No Objection

(Alex Zinin) No Objection