Subject: WG Last Call on Abstract API

From: Dave Thaler <[email-masked]>
Date: Mon, 5 Jul 1999 13:28:57 -0700 (PDT)

As a reminder, one of our WG goals is:

Jul 99  Submit the abstract API document(s0 to the IESG for consideration
        as Informational.

This message starts a WG last call on the Abstract API draft:
   draft-ietf-malloc-api-06.txt 
The last call will expire in 3 weeks.  Please send comments
by July 26th.

Thanks,
-Dave Thaler

---

From: Pavlin Ivanov Radoslavov <[email-masked]>
Date: Mon, 19 Jul 1999 20:34:35 -0700

> The last call will expire in 3 weeks.  Please send comments

Some minor comments follow (comments are starting with "*****")

Section 3:

"Note that this interface is intended only for the allocation of
dynamic multicast addresses, as used by the normal multicast service
model [2]...."

****** "traditional" is probably a better word than "normal"

Section 4: 

"- Time: An (absolute) event time...."

***** Shouldn't the "absolute time" be defined here as "number of seconds
from Jan. 1970", or this will be specified in the concrete API?

Section 5:

"A "best-effort" attempt will be made to maintain multicast routing
for the allocated multicast addresses during their lifetime,
even if there are topology changes (such as a change of upstream
provider) during this time..."

***** This sentence seems a little bit odd to me that it has to be
in the API document. It is more like to belong to the malloc
architecture document.

"...However, because of the guarantee noted above, if an application
needs to 'renumber', it will always know this in advance, at the
time it acquired its current address(es)."

***** How would the application know? If the Lease Lifetime is
shorter than the maxDesiredLifetime? Please explain in the text.
Also, even if Lease Lifetime is shorter, later the application might
succeed to extend the Lease Lifetime, so replace "needs" with
something like "MIGHT need".

"...Without advance allocation, it would be necessary to reserve an
address for a long period of time - even when it will not be
used..."

***** "reserve" should be replaced with "allocate".

***** On some ocasions the doc uses the term "multicast address",
when it should use "multicast addressES"

***** The whole document needs some formatting to avoid things like
single-word lines.

***** Should the document mention something like:
"...because the
allocation is "best effort", and does not guarantee that the same
multicast address is not used by another application, an application
that needs an additional "protection" against another application
using and sending data to the same address should use an
application-specific mechanism to discover such interference and
filter out the unwanted data..."
(well, by default any application should have the same
property/protection ;)

Thanks,
Pavlin