Subject: IPv6 WG Last Call on "Requirements for IPv6 prefix delegation"

From: Margaret Wasserman <[email-masked]>
Date: Mon, 03 Mar 2003 13:06:07 -0500

This is an IPv6 working group last call for comments on submitting the
following document for consideration as an Informational RFC:

         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.

Margaret Wasserman / Bob Hinden

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Wed, 5 Mar 2003 17:07:42 +0200 (EET)

> 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