On Mon, 3 Mar 2003, Margaret Wasserman wrote:
> Title : Requirements for IPv6 prefix delegation
> Author(s) : S. Miyakawa, R. Droms
> Filename : draft-ietf-ipv6-prefix-delegation-requirement-01.txt
> Pages : 5
> Date : 2003-2-28
>
> The document can be found at:
> http://www.ietf.org/internet-drafts/draft-ietf-ipv6-prefix-delegation-requirement-01.txt
>
> Please send substantive comments to the ipng mailing list, and minor
> editorial comments to the authors. This last call period will end two
> weeks from today on March 17, 2003.
I've re-read the document, and I believe it is not yet ready to be sent to
the IESG. Comments below.
substantial/semi-editorial:
---------------------------
==> first issue: the draft contains RFC2119 upper-case keywords; I'm not
sure how useful these are in a requirements document (compared to a prefix
delegation protocol document), as you can't really honestly say that
something would be "mandatory to implement for interoperability" etc.
So, I'd be interested to hear whether others see this as a potential
problem, and whether they should be changed.
4. Requirements for Prefix Delegation
The purpose of the prefix delegation mechanism is to communicate
prefixes to the CPE automatically.
==> further than that, is how the CPE handles required
prefixes in scope?
==> in any case this should be reworded a bit, at least mention
prefix lifetimes. (Ie., it's not just "delegate and forget", right?)
4.1 Number and Length of Delegated Prefixed
The prefix delegation mechanism SHOULD allow for delegation of
prefixes of length /48, /64 and other lengths, and SHOULD allow for
delegation of more than one prefix to the customer.
==> maybe reword a bit and change this to a simpler format:
The prefix delegation mechanism SHOULD allow for delegation of
prefixes of length between /48 and /64, inclusive. Other lengths
MAY be supported. The mechanism SHOULD allow for delegation of
more than one prefix to the customer.
4.3 Automated Assignment
The prefix delegation mechanism SHOULD allow for long-lived pre-
assignment of one or more prefix(es) to a customer and for
automated, possibly short-lived assignment of a prefix to a customer
on demand.
==> this section seems mostly redundant, as the requirement for multiple
prefixes was already listed, so the title should change and some rewording
happen.
This includes two "new" components, "Different Prefix-Specific Properties"
(ie. ability to request short lifetimes for a set of prefixes, and long
for other -- or at least have them separated), or on the prefix delegation
mechanism itself ("manual" vs. automatic") which seems like a non-goal in
requirements doc.
Additionally, "on-demand" feature seems like a trivial requirement, and
more to ISPs' operations than the protocol.
Though, at the same
time, it should be noted that now ISP would like to have a solution
for Point-to-Point link which has own authentication mechanism first.
PPP link with CHAP authentication is a good example. (Simulated)
Ethernet and IEEE802.11 (wireless LAN) should be covered in near
future, but they have low priority (just) for now.
==> does the working group agree on this priorization? I'm not sure if this
is good for for a requirements document.
6. Security considerations
Section 4.5 specifies security requirements for the prefix delegation
mechanism.
==> I'm not sure if this would fly past security area AD's, at least :-).
==> in particular, it would be extremely useful to try to identify the
threats associated with prefix delegation, and how the requirements set here
correspond and meet those threats.
editorial:
----------
==> upper-case words in the titles and section headers
widely deployed "always on" media as ADSL, and the expectation that
==> s/as/such as/
\------/
Illustration of ISP-customer network architecture
==> this is probably meant to be "figure text"; if so, it should be more
clearly attached to it (alignment, no empty line, perhaps "Figure 1: xxx" or
the like
PE Provider edge device; the device at which the link to the customer
site is terminated
==> , and which is connected to the provider's network infrastructure. (or
something similar, otherwise PE/CPE definitions seem too much like circular
definitions)
CPE Customer provided equipment; the device at the customer site at
which the link to the ISP is terminated
==> s/provided/premises/ !!
The method SHOULD work on any layer 2 technologies. In other words,
==> s/ies/y/
References
==> there should probably be classified as normative references. In any
case, refs need to be "split".
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
