Subject: Updated MALLOC "abstract API" draft released

From: Ross Finlayson <[email-masked]>
Date: Sun, 13 Jun 1999 11:16:30

I have submitted a new version of the MALLOC "Abstract API" Internet Draft.
 This should get announced shortly; it is also online as
<http://www.live.com/malloc-api.txt>.

This version incorporates comments/suggestions from Dave Thaler and Steve
Hanna.  I plan to do one more revision prior to the Oslo cutoff date.  (I
believe Roger Kermode has changes that he'd like to make, so Roger, if you
get these to me soon, I'll incorporate them in the next release.)

	Ross.

---

From: Dave Thaler <[email-masked]>
Date: Mon, 14 Jun 1999 20:46:30 -0700 (PDT)

> get these to me soon, I'll incorporate them in the next release.)

Ross, looks much better, thanks for your work on this!

Two minor nitpicks (since you said you'd rev it again anyway :)

1) Section 4, in the "Scope:" description, a scope is not required
   to have a default name.  Hence, I suggest changing
   > For each scope, one (language tag, name) pair is defined
   to
   > For each scope, a (language tag, name) pair may be defined

2) The TRY_LATER status code is currently mentioned only in the
   Advance Allocation section.  However, we should allow its
   use in other cases too (I believe the MADCAP spec already mentions
   Retry After without limiting it to advance allocations).
   Hence, in my opinion, the discussion of TRY_LATER should be
   moved earlier in the document.

   Just for discussion, an example might be the following:
      You send a request for immediate allocation, but the server has 
      no space, but will have space in (say) 15 seconds from now.  
      (Perhaps because it's already claimed space and has to wait for
      collisions for 15 more seconds.)  So the server
      fails the request with TRY_LATER and a time of 15 seconds.

   Whether or not implementations actually do this is not as
   important... the API shouldn't be too restrictive here in
   my opinion.

-Dave

---

From: Roger Kermode <[email-masked]>
Date: Wed, 16 Jun 1999 04:22:24 +1000

> get these to me soon, I'll incorporate them in the next release.)

Ross,

Nice document! I would like to suggest the following additions, based
upon the incorporation of nested scoping features within MZAP,
MADCAP, and SADP. At this stage I've only included comments
regarding nested scopes within MADCAP, and have not mentioned
SADP for two reasons. First, the issue of finding an already allocated
address within a scope is orthogonal to allocating a new address to that
scope, and second SADP is but one solution to this problem
(others may be possible).

cheers,

Roger

-------------
[Addition to 1. Introduction]

add a reference to draft-ietf-malloc-madcap-nest-opt-01.txt
after referencing MADCAP  "..(MADCAP) [1][7]. Alternatively..."

[Additions to 4. Abstract Data Types]
- NestingRelationship: A binary data type that describes whether
        or not two scopes nest. Two scopes nest if traffic sent
        sent to a multicast group within one scope could be seen
        by all hosts present within the other scope were they to
        join the multicast group within the first scope. This value
        would be "False" for overlapping scopes where only some
        (or none) of the hosts within the second scope could see
        traffic sent to an address due to the presence of an
        administratively scoped boundary. In cases where the first
        and second scopes are topologically identical this value
        would be "True."

[Additions to 5. The Abstract Interface]

Querying the nesting state of known usable multicast address scopes:
        get_scope_nesting_state(in "set of" Scope,
                                out "array of" NestingRelationship)

        Possible errors:
            - bad scope.
            - nesting state undetermined at this time.

        This operation would return an array that shows the
        current nesting relationships between the supplied
        set of scopes which would have previously been supplied
        via the get_multicast_addr_scopes(...) function.

Querying the set of scopes that a given scope is known to nest inside:
        get_larger_scopes(in Scope,
                          out "set of" Scope)

        This operation returns the set of administrative multicast
        address scopes that are known to encompass the supplied
        Scope.

        Possible errors:
            - bad scope.
            - nesting state undetermined at this time.

Querying the set of scopes that are known to nest inside a given scope:
        get_smaller_scopes(in Scope,
                          out "set of" Scope)

        This operation returns the set of administrative multicast
        address scopes that are known to nest inside the supplied
        Scope (NB this would include those scopes that are
        topologically identical to the supplied scope).

        Possible errors:
            - bad scope.
            - nesting state undetermined at this time.

[additions to references]
[7] Kermode, R. "MADCAP Multicast Scope Nesting State Option,"
    Work-In-Progress, Internet-Draft
    <draft-ietf-malloc-madcap-nest-opt-01.txt>, April 1999.