Subject: MADCAP revised and submitted to IESG

From: Steve Hanna <[email-masked]>
Date: Thu, 4 Feb 1999 09:13:32 -0500 (EST)

In response to comments received during Working Group Last Call, I have revised 
the MADCAP draft and submitted it to the Internet Drafts editor for 
distribution. I have also placed a copy on the malloc web page at 
http://north.east.isi.edu/malloc/draft-ietf-malloc-madcap-04.txt. A list of 
changes made in this version appears at the end of this email.

Since we seem to have reached rough consensus on this document, I have submitted 
it to the IESG, requesting that it be published as a Proposed Standard. It 
should be entering IETF Last Call soon.

Thanks,

Steve Hanna

--------------

Removed unused references and references to Internet Drafts.

Clarified wording.

Changed MAY to SHOULD in parts of sections 2.2.2, 2.2.3, and 2.2.4 that very 
much resemble the following:

    If a server can process the request with a shorter lease time or
    later start time than the client requested, it SHOULD send an ACK
    message with the lease time or start time that it can offer.

Added a brief explanation of why it's not a good idea to adjust for substantial 
clock skew.

Changed to new boilerplate on first page.

---

From: Dave Thaler <[email-masked]>
Date: Wed, 24 Feb 1999 18:38:19 -0800 (PST)

Comments on draft-ietf-malloc-masc-01.txt:

The -01 version has been on the MALLOC web site for a while now (August '98)
but needs to be submitted as an I-D.  (BTW, for the rest of the list,
the web site has been moved to http://www.aciri.org/malloc/ instead of
the north.east.isi.edu site).

The current spec does an admirable job of separating itself from
the lower level protocol (MADCAP), but unfortunately does not
separate itself well from the higher level protocol... it doesn't
say "MDHCP" or "MADCAP" anywhere but says "MASC" all over the place.
This is probably the biggest problem with the current presentation.
It's especially important given that it's sounding likely that
people may want to start running MADCAP+AAP soon, but not MASC
anytime soon.  

Several places appear to imply that AAP only handles global
addresses, not scoped ones (other places correctly mention scopes).
For example, the first paragraph of section 3 appears to say that 
if no global prefix is known, a server cannot allocate any addresses
(even scoped ones).

It is also unclear (section 3.2 for instance) whether AAP uses a 
single address or a scope-relative address.  Since I believe
AAP is/should be using a scope-relative address (being bounded at
the Allocation-Scope for communication about all larger scopes),
this may also require some clarifications.

If AAP is to be the intra-domain protocol, it needs IANA
assignments for port and relative addresses (left as ??? in
3.2).

MADCAP's packet formats handle multi-address allocations nicely,
while AAP's packet formats are currently limited to single 
addresses.  Similarly, some of the AAP messages assume IPv4 only.

-Dave