Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction
draft-ietf-msec-tesla-intro-04

[Ballot comment]
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

[Ballot comment]
It seems that TESLA itself would allow synchronization of new group members
after others have already been established; clearly the architecture of group
membership depends on the layer or protocol in which TESLA is embedded, but
I'm asking if it could be clarified that each receiver's time synchronization and startup
is independent and can start at an arbitrary time?

The copyright is dated 2000.

Typo: disclodure

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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
paragraphs.

[Ballot discuss]
In 3.2 on Sender Setup, the description of how to determine T_int and
d seems to elide the potential effects of congestion control mechanisms on
the appropriate values.    It may be that the authors believe that this will
be used primarily with transports that do not have such mechanisms (or
at other layers).  A short description still seems like it would be valuable,
especially since the alternate timing mechanism in 3.7 seems like it
could avoid the problem in many cases.

Nit in 3.7: 
Else the packet is considered aunauthenticated.
-->unauthenticated.

[Ballot comment]
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.

[Ballot discuss]
Section 3: Are the references described in this paragraph:

"TESLA is described in several academic publications: A book on
broadcast security [13], a journal paper [14], and two conference papers
[8,15]. Please refer to these publications for an in-depth treatment."

intended to be normative?  The references are only identified as a bibliography, so I can't tell if these "in-depth" references are supposed to be normative or informative, though with the rest of the (very descriptive) text in section 3 they might just be informative.  Please split the references into normative and informative sub-sections.