ISP IPv6 Deployment Scenarios in Broadband Access Networks
draft-ietf-v6ops-bb-deployment-scenarios-05

[Ballot discuss]
Section 6.5 says:
  >
  > Authentication and authorization should be used wherever possible.
  >
  In the flow of the section, it is not clear to me what entities are
  to be authenticated.  Also, it is not clear to me what authorization
  decisions are anticipated.  I am asking for additional description.

[Ballot discuss]
Discuss comments:
=================

> Some ISPs that are currently providing IPv4 based Multicast and VoIP
> services are evaluating IPv6 to improve and expand their service.
> The Multicast services consist of video and audio streaming of
> several programs (streams).  The content provider delivers these
> streams to BB subscribers.  One of today's challenges is the fact
> that when done through IPv4, there is generally a single device
> directly attached to the CPE that receives the Multicast stream.  By
> moving to IPv6, ISP should be capable to provide multiple streams to
> multiple devices on the customer site.

This seems possible even in IPv4. Please explain or
reformulate.

> Communication between hosts behind different CMs is always forwarded
> through the CMTS.  IPv6 communication between the different sites
> relies on multicast IPv6 ND [17] frames being forwarded correctly by
> the CM and the CMTS.  As with the CM, a bridged CMTS that selectively
> forwards multicast datagrams on the basis of MLD will potentially
> break IPv6 ND.

Bridging that *correctly* looks at MLD should work. See RFC 4541. Or
did you mean "on the basis of IGMP"?

> The other aspect of security enhancement is mandated IPSec support in
> IPv6.  The IPv6 specifications mandate implementation of IPSec, but
> they do not mandate its use.  The IPv4 specifications do not mandate
> IPSec.  IPSec is the same for both IPv4 and IPv6, but it still
> requires a key distribution mechanism.  Cable operators may consider
> deploying it end-to-end on IPv6 as there is not an intermediate
> device(i.e.  NAT).

End-to-end IPsec through NATs is very widely deployed
already. Not sure there's a real difference to IPv6
in this respect. And what does the sentence about the
key distribution mechanism intend to tell us?

But most importantly, this section does not tell us
what the intended use of IPsec would be in this
context. It is unreasonable to expect it to be used
for any kind of purpose, but it could be deployed
for a specific need (e.g. protection of some service
from the provider's network).

Suggestion: do not talk about this unless you have
a specific application in mind.

> If however the ISPs are required
> by regulations to track their users at /128 address level, the
> Privacy Extensions can be implemented only in parallel with network
> management tools that could provide traceability of the hosts.  IPv6
> firewall functions should be enabled on the hosts or customer premise
> router if present.

I am unsure whether there can be such traceability tools. If there is
a router in the home and it advertises a prefix, hosts within that
network can connect and get their chosen interface identifiers.
Lacking secure connection to the hosts, it seems hard to determine
which specific host has acquired a specific /128.

Other substantive comments:
===========================

How widely has this document been reviewed? Has
it been reviewed by the DOCSIS folks, for instance,
or people who deploy WLANs?

Section 4.1:

I'm somewhat surprised to see a mention of specific ISP deployments
and specific brand names for movie distribution.

> Without proper classification all IPv6 traffic will need to be sent
> best effort (BE) which can cause problems when deploying services
> like VOIP and IP Multicast video.

On a broadband network? Hmm... I would suggest deleting
VoIP from the above example. Or reformulate to say that
service providers that wish to deploy quality of service
mechanisms also have to support classification of IPv6
traffic.

Editorial comments:
===================

Five levels of subsections. A tough read!

> Out of the many tunneling mechanisms developed [2], [3], [4], [26],
> A [29], [5] some are more popular than the others.

I am sure the reader would find it easier if the names
of the mechanisms were listed here too.

> Due to the above mentioned limitations in deployed cable networks,
> the only available option to cable operators is to use tunneling
> techniques in order to transport IPv6 traffic over their current IPv4
> infrastructure.  The following sections will cover these deployment
> scenarios in more detail.
>  ... (half a page down)...
> IPv6 can be deployed in a bridged CMTS network either natively or via
> tunneling.  This section discusses the native deployment model.  The

The text in the first paragraph appears to indicate that
only tunneling is going to be studied, yet the latter part
starts talking about native deployment.

> through already established IPv4 IPSec sessions would provide a

s/IPSec/IPsec/ (also elsewhere)

> Details of a tunnel based deployment are
> offered in the next section of this document (section 6).  In the
> case of Cable Access where the current DOCSIS specifications do not
> provide support for native IPv6 access.

The latter sentence seems to point to nowhere. Change to "Details of a
tunnel based deployment are offered in the next section of this
document which discusses the case of Cable Access where the current
DOCSIS specifications do not provide support for native IPv6 access.",
or something to that effect.

Reference issues:
  - Missing Reference: [MFF] is mentioned on line 3464, but not defined
  - Unused Reference: [12] is defined on line 3545, but not referenced
  - Unused Reference: [20] is defined on line 3572, but not referenced
  - Unused Reference: [16] is defined on line 3559, but not referenced

> IEEE 802.11
> offers maximum transmission speed from 1 or 2 Mbps, IEEE 802.11b
> offers 11 Mbps and IEEE 802.11a/g offer up to 54 Mbps.

Delete this (and other similar statements), as the document
is already too long and it should focus on the main topic.

[Ballot discuss]
Discuss comments:
=================

> Some ISPs that are currently providing IPv4 based Multicast and VoIP
> services are evaluating IPv6 to improve and expand their service.
> The Multicast services consist of video and audio streaming of
> several programs (streams).  The content provider delivers these
> streams to BB subscribers.  One of today's challenges is the fact
> that when done through IPv4, there is generally a single device
> directly attached to the CPE that receives the Multicast stream.  By
> moving to IPv6, ISP should be capable to provide multiple streams to
> multiple devices on the customer site.

This seems possible even in IPv4. Please explain or
reformulate.

> Communication between hosts behind different CMs is always forwarded
> through the CMTS.  IPv6 communication between the different sites
> relies on multicast IPv6 ND [17] frames being forwarded correctly by
> the CM and the CMTS.  As with the CM, a bridged CMTS that selectively
> forwards multicast datagrams on the basis of MLD will potentially
> break IPv6 ND.

Bridging that *correctly* looks at MLD should work. See RFC 4541. Or
did you mean "on the basis of IGMP"?

> The other aspect of security enhancement is mandated IPSec support in
> IPv6.  The IPv6 specifications mandate implementation of IPSec, but
> they do not mandate its use.  The IPv4 specifications do not mandate
> IPSec.  IPSec is the same for both IPv4 and IPv6, but it still
> requires a key distribution mechanism.  Cable operators may consider
> deploying it end-to-end on IPv6 as there is not an intermediate
> device(i.e.  NAT).

End-to-end IPsec through NATs is very widely deployed
already. Not sure there's a real difference to IPv6
in this respect. And what does the sentence about the
key distribution mechanism intend to tell us?

But most importantly, this section does not tell us
what the intended use of IPsec would be in this
context. It is unreasonable to expect it to be used
for any kind of purpose, but it could be deployed
for a specific need (e.g. protection of some service
from the provider's network).

Suggestion: do not talk about this unless you have
a specific application in mind.

> If however the ISPs are required
> by regulations to track their users at /128 address level, the
> Privacy Extensions can be implemented only in parallel with network
> management tools that could provide traceability of the hosts.  IPv6
> firewall functions should be enabled on the hosts or customer premise
> router if present.

I am unsure whether there can be such traceability tools. If there is
a router in the home and it advertises a prefix, hosts within that
network can connect and get their chosen interface identifiers.
Lacking secure connection to the hosts, it seems hard to determine
which specific host has acquired a specific /128.

Other substantive comments:
===========================

Section 4.1:

I'm somewhat surprised to see a mention of specific ISP deployments
and specific brand names for movie distribution.

> Without proper classification all IPv6 traffic will need to be sent
> best effort (BE) which can cause problems when deploying services
> like VOIP and IP Multicast video.

On a broadband network? Hmm... I would suggest deleting
VoIP from the above example. Or reformulate to say that
service providers that wish to deploy quality of service
mechanisms also have to support classification of IPv6
traffic.

Editorial comments:
===================

Five levels of subsections. A tough read!

> Out of the many tunneling mechanisms developed [2], [3], [4], [26],
> A [29], [5] some are more popular than the others.

I am sure the reader would find it easier if the names
of the mechanisms were listed here too.

> Due to the above mentioned limitations in deployed cable networks,
> the only available option to cable operators is to use tunneling
> techniques in order to transport IPv6 traffic over their current IPv4
> infrastructure.  The following sections will cover these deployment
> scenarios in more detail.
>  ... (half a page down)...
> IPv6 can be deployed in a bridged CMTS network either natively or via
> tunneling.  This section discusses the native deployment model.  The

The text in the first paragraph appears to indicate that
only tunneling is going to be studied, yet the latter part
starts talking about native deployment.

> through already established IPv4 IPSec sessions would provide a

s/IPSec/IPsec/ (also elsewhere)

> Details of a tunnel based deployment are
> offered in the next section of this document (section 6).  In the
> case of Cable Access where the current DOCSIS specifications do not
> provide support for native IPv6 access.

The latter sentence seems to point to nowhere. Change to "Details of a
tunnel based deployment are offered in the next section of this
document which discusses the case of Cable Access where the current
DOCSIS specifications do not provide support for native IPv6 access.",
or something to that effect.

Reference issues:
  - Missing Reference: [MFF] is mentioned on line 3464, but not defined
  - Unused Reference: [12] is defined on line 3545, but not referenced
  - Unused Reference: [20] is defined on line 3572, but not referenced
  - Unused Reference: [16] is defined on line 3559, but not referenced

> IEEE 802.11
> offers maximum transmission speed from 1 or 2 Mbps, IEEE 802.11b
> offers 11 Mbps and IEEE 802.11a/g offer up to 54 Mbps.

Delete this (and other similar statements), as the document
is already too long and it should focus on the main topic.

[Ballot discuss]
Section 8.5 and section 9.4 say:
  >
  > Authentication and authorization should be used wherever possible.
  >
  In the flow of the section, it is not clear to me what entities are
  to be authenticated.  Also, it is not clear to me what authorization
  decisions are anticipated.  I am asking for additional description.

  In section 9.4, please add a reference for 802.1X.

  In section 9.4, I am surprised to see a discussion of 802.1X without
  a linkage to 802.11i.  Please add discussion of 802.11i.

[Ballot comment]
1. In many places in the document the construct 'MIBs' is being used. The expression that is recommended is 'MIB modules'. I suggest to do a search and replace wherever relevant. For example in 6.2.6.2:

OLD:
  The current DOCSIS, PacketCable, and CableHome MIBs are already
  designed to support IPv6 objects. 
NEW:
  The current DOCSIS, PacketCable, and CableHome MIBs are already
  designed to support IPv6 objects.

2. In 6.2.6.2 the following phrase shows up:

OLD:
  An object to
  identify the IP version, InetAddressType has been added to all the
  appropriate SNMP objects related to IP address.

I suggest that a better way to describe this change is:

NEW:
The Textual Convention used to represent SMIv2 objects representing IP addresses was updated [RFC4001] and a new Textual Convention InetAddressType was added to identify the type of the IP address used for IP address objects in MIB modules.

3. Section 6.2.6.2 refers to several MIB modules. I suggest to add appropriate Informative References to the documents where these MIB modules are being defined.

4. Sections 7.6, 8.6 and 9.5 include the following sentence:

OLD:
The management stations are located on the core network.

The notion of a management station is not well defined. Also the phrasing may be interpreted as having a physical topology implication. I suggest:

NEW:
The management applications are running on hosts belonging to the NSP core network domain.

5. Fig 8.2.1 - replace 802.1q by 802.1Q

6. Section 10.6 includes:

OLD:
  Conceptually network management in PLC Networks should be similar to
  Broadband Ethernet Networks as described in section 8.6.  Although
  there could be a need to develop some PLC specific MIBs.

While this is probably true, the need to define MIB modules is not related to IPv6 Network Management and this is not what this section should really focus on. I suggest:

NEW:
  The issues related to IPv6 Network Management in PLC networks should be similar to those discussed for Broadband Ethernet Networks in section 8.6. Note that there may be a need to define MIB modules for PLC networks and interfaces, but this is not necessarily related to IPv6 management.

[Ballot comment]
1. In many places in the document the construct 'MIBs' is being used. The expression that is recommended is 'MIB modules'. I suggest to do a search and replace wherever relevant. For example in 6.2.6.2:

OLD:
  The current DOCSIS, PacketCable, and CableHome MIBs are already
  designed to support IPv6 objects. 
NEW:
  The current DOCSIS, PacketCable, and CableHome MIBs are already
  designed to support IPv6 objects.

2. In 6.2.6.2 the following phrase shows up:

OLD:
  An object to
  identify the IP version, InetAddressType has been added to all the
  appropriate SNMP objects related to IP address.

I suggest that a better way to describe this change is:

NEW:
The Textual Convention used to represent SMIv2 objects representing IP addresses was updated [RFC4001] and a new Textual Convention InetAddressType was added to identify the type of the IP address used for IP address objects in MIB modules.

3. Section 6.2.6.2 refers to several MIB modules. I suggest to add appropriate Informative References to the documents where these MIB modules are being defined.

4. Sections 7.6, 8.6 and 9.5 include the following sentence:

OLD:
The management stations are located on the core network.

The notion of a management station is not well defined. Also the phrasing may be interpreted as having a physical topology implication. I suggest:

NEW:
The management applications are running on hosts belonging to the NSP core network domain.

4. Fig 8.2.1 - replace 802.1q by 802.1Q

5. Section 10.6 includes:

OLD:
  Conceptually network management in PLC Networks should be similar to
  Broadband Ethernet Networks as described in section 8.6.  Although
  there could be a need to develop some PLC specific MIBs.

While this is probably true, the need to define MIB modules is not related to IPv6 Network Management and this is not what this section should really focus on. I suggest:

NEW:
  The issues related to IPv6 Network Management in PLC networks should be similar to those discussed for Broadband Ethernet Networks in section 8.6. Note that there may be a need to define MIB modules for PLC networks and interfaces, but this is not necessarily related to IPv6 management.

[Ballot discuss]
Beginning with Section 3, this document is well-written. However, section 1 and 2 are horribly-written, make inaccurate claims, and overall do not add any value to the document. In fact, in my opinion they seriously take away from the overall credibility of the document. I recommend deleting these sections entirely, letting the document begin with section 3 "Scope of the Document" as the introduction.

Beginning at section 4:
> 4.1.  Layer 2 Access Provider Network
>    In this type of a network the impact of deploying IPv6 is minimal.
>    The network is transparent to the Layer 3 protocol.

Unfortunately, I don't think that is always true. Broadcast and Multicast is not always handled as one might expect on broadband L2 access networks, which could affect Stateless Autoconfiguration in IPv6. For example, it was very unclear whether or not early versions of draft-melsen-mac-forced-fwd-04.txt were compatible with IPv6. This lead to the "IPv6 Considerations" section you see in this document now. Further, DSL L2 access networks are often expected to provide more than simply transmission of L3 packets. Witness draft-wen-ipv6-rsra-opt-pid, which points out that DSLAMs operating at L2 in access networks provide line id information in DHCP packets for AAA servers to use for access authorization. This obviously affects DHCPv6 and Stateless Autoconfiguration. Whole working groups are formed to ensure that IPv6 operates over new broadband access networks, witness the 16ng chartering discussion ongoing now. Thus, I think that this section could use a more cautionary tone.


Section 5 - Tunneling Overview

>    Out of the many tunneling mechanisms developed [2], [3], [4], [26],
>    [29], [5] some are more popular than the others.

You might wish to mention the "softwire" working group here, stating that its task at the time of this writing was to standardize a single tunneling protocol for this application.

Paragraph 2:

> follow.  Deploying IPv6 using tunneling techniques can imply as
> little changes to the network as upgrading SW on tunnel end points
> (TEP).  A Service Provider could use tunneling to deploy IPv6 in the
> following scenarios:

"TEP" is defined here and never again used in the document. Seems like you could just remove it.

> (there are several types
>    that can transport layer 2 messages such as GRE, L2TPv3 or
>    Pseudowire),

Please provide references for the above mechanisms

Section 6.2:

>    IPv6 can be enabled on the
>    CM, CMTS and ER for management purposes.  Currently portions of the
>    cable infrastructure use [1] IPv4 addresses; however, there are a
>    finite number of those.  Thus, IPv6 could have utility in the cable
>    space implemented on the management plane initially and later on
>    focused on the data plane for end user services.

It turns out that this was a very wise statement, that IPv6 might have utility on the management plane initially. In fact, that seems to be how it is playing out, though unfortunately the rest of this section focuses mostly on delivering IPv6 to an end user first :-/

>    In the
>    case of Cable Access where the current DOCSIS specifications do not
>    provide support for native IPv6 access.
>    DOCSIS standardizes and documents the operation of data over Cable
>    Networks.  The current version of DOCSIS has limitations that do not
>    allow for a smooth implementation of native IPv6 transport.  Some of

DOCSIS 3.0 will include IPv6, as discussed here:

draft-mule-cablelabs-docsis3-ipv6-00.txt

Please provide a version and reference for actual DOCSIS version discussed in this document (or update it to the current version, though I suspect that is asking a little too much!).

>  cable infrastructure use [1] IPv4 addresses; however, there are a

s/use [1] IPv4 addresses/use private IPv4 address space [1]

Section 6.2, subsection 2, bullet "A" and "B" seem to be a subset of "C" - Suggestion, move text of C into the paragraph above A and B.

>    Due to the above mentioned limitations in deployed cable networks,
>    the only available option to cable operators is to use tunneling
>    techniques in order to transport IPv6 traffic over their current IPv4

"The only *currently* available option at the time of this writing..."

In general, please be sure to write this document in a way that makes it clear that it is a snapshot in time.

> 6.2.2.3.2.  Addressing
>
>    In today's cable networks the CM receives a private IPv4 address
>    using DHCPv4 for management purposes.  In an IPv6 environment, the CM
>    will continue to use an IPv4 address for management purposes.  The
>    cable operator can also choose to assign an IPv6 address to the CM
>    for management, but the CM will have to be upgraded to support this
>    functionality.

> 6.2.1.2.1.  IP Addressing for CM
>
>    The CM will be provisioned in the same way as in currently deployed
>    cable networks, using an IPv4 address on the cable interface
>    connected to the MSO network for management functions.  During the
>    initialization phase, it will obtain its IPv4 address using DHCPv4,
>    and download a DOCSIS configuration file identified by the DHCPv4
>    server.

The above two sections sort of say the same thing, something that I see repeated several times for multiple scenarios. In any case, it looks like the CM is in fact destined to become an IPv6-only device. Once the CM is being managed via IPv6, there is no real reason for it to have IPv4. It still must be able to bridge IPv4 of course, but not have an IPv4 address.

I see that Section 6.2.6.1. discusses "Using IPv6 for Management in Cable Networks" - this section should probably be updated to reflect how this is being done in DOCSIS 3.0 now, at least by way of informational reference. It's probably important to mention that the CM would no longer require an IPv4 address.

>    If using manual tunneling, the GWR and ER can use static routing or
>    they can also configure RIPng.  The RIPng updates can be transported
>    over a manual tunnel, which does not work when using 6to4 tunneling.

This paragraph does not make it very clear why RIPng doesn't work with 6to4 tunneling, or why RIPng would be a good choice in general even if manual tunneling is used. Also, please provide a reference for RIPng - RFC2080, I believe.

Note: I am finding that a lot of text is repeated as various scenarios are presented. Comments on one bit of text generally apply to all identical sections of text, thought I will not repeat them here.

Please provide references to the first use of PPPoE, PPPoA and L2TP.

>    An example of such circumstances is that of a provider using an LAA
>    design for its IPv4 services.  In this case all the PPP sessions are
>    bundled and tunneled across the entire NAP infrastructure which is
>    made of multiple BRAS routers, aggregation routers etc.  The end
>    point of these tunnels is the ISP Edge Router.  If the provider
>    decides to offer multicast services over such a design, it will face
>    the problem of NAP resources being over utilized.  The multicast
>    traffic can be replicated only at the end of the tunnels by the Edge
>    router and the copies for all the subscribers are carried over the
>    entire NAP.

RFC 4045 addresses this issue.

Section 7 focuses on an ATM DSL model, and uses "VLAN" in some places where I believe it should be "PVC"

Sections [7,8].2.2

>    The BRAS authorizes the session,
>    authenticates the subscriber, and provides an IP address on behalf of
>    the ISP.  The BRAS then does Layer 3 routing of the subscriber
>    traffic to the NSP Edge Router.  This model is often used when the
>    NSP is also the NAP.

In fact, when the NSP is also the NAP, the BRAS and Edge Router are generally the same piece of equipment. Thus, the BRAS does not need to "Layer 3 route" to the NSP Edge Router. This is the source of some confusion in multiple places as I read this part of the document.

Figure 9.1, it is strange to see a functional block titled "Underlying Technology"

>    ii.  Tunnels directly to hosts with public or private IPv4 addresses.
>    Recommendations on the exact tunneling mechanisms that can/should be
>    used for last mile access need to be investigated further and should
>    be covered in a future IETF draft.

Again, an informational reference to the softwire effort could be in order.

>    J. New deployment models are emerging for the Layer 2 portion of the
>    NAP where individual VLANs are not dedicated to each subscriber.
>    This approach allows Layer 2 switches to aggregate more then 4096
>    users.  MAC Forced Forwarding [MFF] is an example of such an
>    implementation where a broadcast domain is turned into a NBMA like
>    environment by forwarding the frames based on both Source and
>    Destination MAC addresses.  Since these models are being adopted by
>    the field, the implications of deploying IPv6 in such environments
>    need to be further investigated.

A reference to draft-melsen-mac-forced-fwd-04.txt could be in order here.

PROTO-write-up for the record:

-----Original Message-----
From: Kurt Erik Lindqvist [mailto:kurtis@kurtis.pp.se]
Sent: Saturday, March 18, 2006 15:20
To: David Kessens
Cc: Bert Wijnen; Dan Romascanu; Baker Fred
Subject: draft-ietf-v6ops-bb-deployment-scenarios-04.txt



David,

please find the request from the v6ops WG to publish the above 
document as below.



>  1.a) Have the chairs personally reviewed this version of the 
> Internet
>        Draft (ID), and in particular, do they believe this ID is 
> ready
>        to forward to the IESG for publication?  Which chair is the WG
>        Chair Shepherd for this document?
>

I have read this document and I believe it is ready for publication.


>    1.b) Has the document had adequate review from both key WG members
>        and key non-WG members?  Do you have any concerns about the
>        depth or breadth of the reviews that have been performed?
>

The document have been analysed, referenced and discussed in several 
WGs so I believe this condition to be satisfied.


>    1.c) Do you have concerns that the document needs more review 
> from a
>        particular (broader) perspective (e.g., security, operational
>        complexity, someone familiar with AAA, internationalization,
>        XML, etc.)?
>

No. If there where a int-area directorate I might have suggested that 
(there isn't one, right?).


>    1.d) Do you have any specific concerns/issues with this document 
> that
>        you believe the ADs and/or IESG should be aware of?  For
>        example, perhaps you are uncomfortable with certain parts 
> of the
>        document, or have concerns whether there really is a need for
>        it.  In any event, if your issues have been discussed in 
> the WG
>        and the WG has indicated it that it still wishes to advance 
> the
>        document, detail those concerns in the write-up.
>

I personally think that this is a highly useful document that should 
be published as is and that it will bring additional value to the 
community.


>    1.e) How solid is the WG consensus behind this document?  Does it
>        represent the strong concurrence of a few individuals, with
>        others being silent, or does the WG as a whole understand and
>        agree with it?
>

By my judgement there is very broad consensus for the publication of 
this document.


>    1.f) Has anyone threatened an appeal or otherwise indicated extreme
>        discontent?  If so, please summarise the areas of conflict in
>        separate email to the Responsible Area Director.  (It 
> should be
>        separate email because this questionnaire will be entered into
>        the tracker).
>
>

No threats or appeals have been discussed around this document.


>    1.g) Have the chairs verified that the document checks out against
>        all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
>        Boilerplate checks are not enough; this check needs to be
>        thorough.
>

This document does pass the id nits test. The nits tool says :



idnits 1.88

tmp/draft-ietf-v6ops-bb-deployment-scenarios-04.txt:


  Checking nits according to http://www.ietf.org/ID-Checklist.html:

    Checking conformance with RFC 3978/3979 boilerplate...

  * The document seems to lack an RFC 3978 Section 5.4 Copyright 
Line --
    however, there's a paragraph with a matching beginning. 
Boilerplate error?

    RFC 3978 Section 5.4 paragraph 1 text:
    "Copyright (C) The Internet Society (2006)."

    ... text found in draft:
    "Copyright (C) The Internet Society (2005).  This document is 
subject
............................................^
    to the rights, licenses and restrictions contained in BCP 78, and
    except as set forth therein, the authors retain all their rights.")


  * The document seems to lack an RFC 3978 Section 5.4 Reference to 
BCP 78.

    RFC 3978 Section 5.4 paragraph 2 text:
    "This document is subject to the rights, licenses and restrictions
    contained in BCP 78, and except as set forth therein, the authors
    retain all their rights."


  Checking nits according to http://www.ietf.org/ietf/1id-
guidelines.txt:
    Nothing found here (but these checks do not cover all of
    1id-guidelines.txt yet).

  Miscellaneous warnings:
    None.


Of which I don't know the process for fixing the fist and the second 
error is actually a parse error by the tool.

I also note that there is a hyphenation on a single line that is 
missed by the tool, but I am not sure if that is reason enough to 
send the draft back.


>    1.h) Has the document split its references into normative and
>        informative?  Are there normative references to IDs, where the
>        IDs are not also ready for advancement or are otherwise in an
>        unclear state?  The RFC Editor will not publish an RFC with
>        normative references to IDs (will delay the publication until
>        all such IDs are also ready for RFC publicatioin).  If the
>        normative references are behind, what is the strategy for 
> their
>        completion?  On a related matter, are there normative 
> references
>        that are downward references, as described in BCP 97, RFC 3967
>        RFC 3967 [RFC3967]?  Listing these supports the Area 
> Director in
>        the Last Call downref procedure specified in RFC 3967.
>

It does.


>    1.i) For Standards Track and BCP documents, the IESG approval
>        announcement includes a write-up section with the following
>        sections:
>
>        *    Technical Summary
>
>        *    Working Group Summary
>
>        *    Protocol Quality
>
>    1.j) Please provide such a write-up.  Recent examples can be 
> found in
>        the "Action" announcements for approved documents.
>

This is an Informational document.

Kurtis & Fred