BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN
draft-ietf-l3vpn-bgp-ipv6-07

[Ballot discuss]
Two major points:

1) Can we please have a proper implementation report for this spec?

2) The document does not define a mandatory to implement encapsulation
  method. All methods mentioned after MUST's in section 4 are conditional
  on statements like "when tunneling is done", and "systems that
  implement". In other words, interop is not guaranteed.

  I would imagine that the spec would want to mandate at least the
  MPLS/LDP one.

[Ballot comment]
Note: -04 was Last Called in idr in February, satisfying our desires for BGP changes to be checked by idr.  The changes from -04 to -07 (other than the ones asked for in the idr last call) are minor and don't warrant another idr Last Call.

[Ballot comment]
References and Citations need serious checking:

  !! Missing Reference for citation: [BGP-EXTCOM]
  P008 L024:    [BGP-EXTCOM].


  !! Missing citation for Normative reference:
  P015 L018:    [BGP-EXTCOMM] Ramachandra, Tappan, Rekhter,
  "BGP Extended  Communities

  !! Missing Reference for citation: [BGP]
  P002 L051:    Protocol", [BGP, BGP-MP]) is then used by the
                Service Provider to

  !! Missing Reference for citation: [LABEL]
  P012 L009:    carried out as per [MP-BGP-v6] and [LABEL].
                When the VPN-IPv6 traffic

  !! Missing Reference for citation: [LDP]
  P009 L044:    using any label distribution technique (LDP[LDP],
                RSVP-TE [RSVP-TE],
  P009 L047:    technology, all such systems MUST support LDP [LDP].

  !! Missing Reference for citation: [MP-BGP-v6]
  P011 L034:    IPv6 routes MUST be carried out as per [MP-BGP-v6].
                This method does
  P012 L009:    carried out as per [MP-BGP-v6] and [LABEL].
                When the VPN-IPv6 traffic

  !! Missing Reference for citation: [MP-BGP]
  P005 L043:    The PE routers exchange, via MP-BGP [MP-BGP], reachability

  !! Missing citation for Normative reference:
  P015 L027:    [MPLS-ARCH] Rosen, Viswanathan, and Callon, "Multiprotocol Label

  !! Missing citation for Normative reference:
  P015 L033:    [MPLS-ENCAPS] Rosen, Rekhter, Tappan, Farinacci,
            Fedorkow, Li, and

  !! Missing citation for Normative reference:
  P015 L039:    [MPLS-LDP] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP

  !! Missing citation for Informative reference:
  P016 L015:    [SCOPE-ARCH] Deering, S., et al., "IPv6 Scoped Address
                Architecture",

  !! Missing citation for Informative reference:
  P016 L012:    [TRANS] R. Gilligan, E. Nordmark, "Transition Mechanisms
                for IPv6

[Ballot comment]
References and Citations need serious checking:

  !! Missing Reference for citation: [BGP-EXTCOM]
  P008 L024:    [BGP-EXTCOM].


!! Missing citation for Normative reference:
  P015 L018:    [BGP-EXTCOMM] Ramachandra, Tappan, Rekhter, "BGP Extended Communities

Normative reference:
  P015 L021:    [BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions
Citations to it:
  P002 L051:    Protocol", [BGP, BGP-MP]) is then used by the Service Provider to
  P004 L037:    The BGP Multiprotocol Extensions [BGP-MP] allow BGP to carry routes
  P006 L013:    The BGP Multiprotocol Extensions [BGP-MP] are used to advertise the
  P008 L031:    [BGP-MP] and [BGP-CAP], by using capability code 1 (multiprotocol

!! Missing Reference for citation: [BGP]
  P002 L051:    Protocol", [BGP, BGP-MP]) is then used by the Service Provider to

Normative reference:
  P015 L024:    [IPv6] Deering, S., and R. Hinden, "Internet Protocol, Version 6
Citations to it:
  P010 L029:    communications [IPv6]. These addresses are called Unique Local IPv6

!! Missing Reference for citation: [LABEL]
  P012 L009:    carried out as per [MP-BGP-v6] and [LABEL]. When the VPN-IPv6 traffic

!! Missing Reference for citation: [LDP]
  P009 L044:    using any label distribution technique (LDP[LDP], RSVP-TE [RSVP-TE],
  P009 L047:    technology, all such systems MUST support LDP [LDP].

!! Missing Reference for citation: [MP-BGP-v6]
  P011 L034:    IPv6 routes MUST be carried out as per [MP-BGP-v6]. This method does
  P012 L009:    carried out as per [MP-BGP-v6] and [LABEL]. When the VPN-IPv6 traffic

!! Missing Reference for citation: [MP-BGP]
  P005 L043:    The PE routers exchange, via MP-BGP [MP-BGP], reachability

!! Missing citation for Normative reference:
  P015 L027:    [MPLS-ARCH] Rosen, Viswanathan, and Callon, "Multiprotocol Label

Normative reference:
  P015 L030:    [MPLS-BGP] Rekhter and Rosen, "Carrying Label Information in BGP4",
Citations to it:
  P006 L007:    Labeled IPv6 VPN routes [MPLS-BGP]. When the advertising PE then
  P006 L021:    The NLRI field itself is encoded as specified in [MPLS-BGP]. In the

!! Missing citation for Normative reference:
  P015 L033:    [MPLS-ENCAPS] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and

!! Missing citation for Normative reference:
  P015 L039:    [MPLS-LDP] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP

!! Missing citation for Informative reference:
  P016 L015:    [SCOPE-ARCH] Deering, S., et al., "IPv6 Scoped Address Architecture",

!! Missing citation for Informative reference:
  P016 L012:    [TRANS] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6

[Ballot comment]
Please delete sections 1.3 and 1.4 prior to publication.

  Shift Figure 6 to the left so that it does not exceed the right
  page margin.

[Ballot discuss]
In Section 6, 1st paragraph, includes:
  >
  > Note that VPLS does not offer security or authentication ...
  >
  The term "security" is very vague in this context.  I propose:
  >
  > Note that VPLS does not offer confidentiality, integrity, or
  > authentication ...
  >
  I think this sets the context for "security" in the rest of the
  paragraph.

  In Section 6, last paragraph, includes:
  >
  > It is especially important in the case of multi-AS VPLSs that
  > one accept VPLS packets only from valid interfaces.
  >
  Where does one learn the information necessary to construct a
  filter to implement this suggestion?  While I do not expect a
  complete how-to in this area, pointers would be useful.

PROTO

From Ron Bonica, 7/23/05

> the write-up that I did for version 05 (see below) still applies. The only
> difference between 05 and 06 is that a few nits have been removed.

Questionairre from -05 follows:

> 1) Have the chairs personally reviewed this version of the ID and do
>    they believe this ID is sufficiently baked to forward to the IESG
>    for publication?

I have read the draft twice, once when it first appeared and again during last
call. I believe that it is fully baked.

>
> 2) 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 passed last call in both the IDR and L3VPN WGs. There were commentsfrom both WGs and the draft was modified to accommodate those comments.

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

No.

>    4) 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 whether there really is a need for it, etc., but at the same
>    time these issues have been discussed in the WG and the WG has
>    indicated it wishes to advance the document anyway.

No

>    5) 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?

There has been only one objection, posted long after the last call ended. The
author of another draft requested that his work be folded into this draft. His
work addresses a situation in which the provider network is partially IPv4 and
partially IPv6.

As that author's work is orthogonal to this draft, I am inclined to let the twodrafts progress independently.

>
> 6) Has anyone threatened an appeal or otherwise indicated extreme
>    discontent?  If so, please summarize what are they upset about.

No

>    7) Have the chairs verified that the document adheres to _all_ of the
>    ID nits?  (see http://www.ietf.org/ID-nits.html).

I have.

>    8) Does the document a) split references into normative/informative,
>    and

Yes

b) are there normative references to IDs, where the IDs are not

>    also ready for advancement or are otherwise in an unclear state?
>    (Note: the RFC editor will not publish an RFC with normative
>    references to IDs, it will delay publication until all such IDs are
>    also ready for publication as RFCs.)


There are normative references to IDs. So, this draft will have to go in to the
editor's queue behind the following drafts:

  [2547bis] Rosen et al., "BGP/MPLS VPNs", draft-ietf-l3vpn-rfc2547bis,
  work in progress

  [BGP-EXTCOMM] Ramachandra, Tappan, Rekhter, "BGP Extended Communities
  Attribute", work in progress

>
> 9) For Standards Track and BCP documents, the IESG approval
>    announcement includes a writeup section with the following
>    sections:
>


Technical Summary

  This document describes a method by which a Service Provider may use
  its packet switched backbone to provide Virtual Private Network
  services for its IPv6 customers.

  This method reuses, and extends where necessary, the "BGP/MPLS IP
  VPN" method [2547bis] for support of IPv6. In particular, this method
  uses the same "peer model" as [2547bis], in which the customers' edge
  routers ("CE routers") send their IPv6 routes to the Service
  Provider's edge routers ("PE routers"). BGP ("Border Gateway
  Protocol", [BGP, BGP-MP]) is then used by the Service Provider to
  exchange the routes of a particular IPv6 VPN among the PE routers
  that are attached to that IPv6 VPN. Eventually, the PE routers
  distribute, to the CE routers in a particular VPN, the IPv6 routes
  from other CE routers in that VPN. As with IPv4 VPNs, a key
  characteristic of this "peer model" is that the (IPv6) CE routers
  within an (IPv6) VPN do not peer with each other and there is no
  "overlay" visible to the (IPv6) VPN's routing algorithm.

  A VPN is said to be an IPv6 VPN, when each site of this VPN is IPv6
  capable and is natively connected over an IPv6 interface or sub-
  interface to the SP backbone via a Provider Edge device (PE).

  A site may be both IPv4-capable and IPv6-capable. The logical
  interface on which packets arrive at the PE may determine the IP
  version. Alternatively the same logical interface may be used for
  both IPv4 and IPv6 in which case a per-packet lookup at the Version
  field of the IP packet header determines the IP version. This
  document only concerns itself with handling of the IPv6 packets.

  As such the inter-working between an IPv4 site and an IPv6 site is
  outside the scope of this document.

  In a similar manner to how IPv4 VPN routes are distributed in
  [2547bis], BGP and its extensions are used to distribute  routes from
  an IPv6 VPN site to all the other PE routers connected to a site of
  the same IPv6 VPN. PEs use "VPN Routing and Forwarding tables" (VRFs)
  to separately maintain the reachability information and forwarding
  information of each IPv6 VPN.

  As it is done for IPv4 VPNs [2547bis], we allow each IPv6 VPN to have
  its own IPv6 address space, which means that a given address may
  denote different systems in different VPNs. This is achieved via a
  new address family, the VPN-IPv6 Address Family, in a fashion similar
  to the VPN-IPv4 address family defined in [2547bis] and which
  prepends a Route Distinguisher to the IP address.

  In addition to its operation over MPLS Label Switched Paths (LSPs),
  the IPv4 BGP/MPLS VPN solution has been extended to allow operation
  over other tunneling techniques including GRE tunnels, IP-in-IP
  tunnels [2547-GRE/IP], L2TPv3 tunnels [MPLS-in-L2TPv3] and IPsec-
  protected tunnels [2547-IPsec]. In a similar manner, this document
  allows support of an IPv6 VPN service over MPLS LSPs as well as over
  other tunneling techniques including GRE tunnels, IP-in-IP tunnels,
  L2TPv3 tunnels and IPsec-protected tunnels.

  This document allows support for an IPv6 VPN service over an IPv4
  backbone as well as over an IPv6 backbone. The IPv6 VPN service
  supported is identical in both cases.


Working Group Summary

  This document went smoothly through the WG process.

Protocol Quality

  At least two vendors have developed to earlier versions of this draft.   
  Jeffrey Haas and Pedro Marques both commented on the draft as it went through
 
  multiple revisions.

[Ballot comment]
The draft appears to recommend that a site use Unique Local addresses in preference to Global
Unicast addresses, through its quoting of the unique local draft's text here:

"They have the additional property that they will continue to work if the individual sites are
renumbered or merged."

Personally, I believe this would be contrary to good practice if the site were not already using Unique
Local addresses, since it increases the administrative and routing burden.  I do not ask the authors
to share this view, but I do note that more direct recommendation one way or the other would be clearer.

[Ballot discuss]
The document's references to draft-ietf-ipv6-unique-local-addr-09.txt need to be updated; one section refers to Section 10, which no longer exists.  I believe it should refer to Section 4.7.

-------- Original Message --------
Subject: RE: Gen-ART Review of draft-ietf-l3vpn-bgp-ipv6-06.txt
Date: Wed, 27 Jul 2005 11:35:55 -0400
From: Francois Le Faucheur (flefauch)
To: Spencer Dawkins , , ,
CC: Rick Wilder , Ross Callon , Ronald Bonica , Mark Townsley (townsley)


I think we've converged and can reflect all that in the next rev. Super.

Jeremy is about to propose a resolution for the Security section.
Cheers
francois

[Note]: '-06 updated to take care of boilerplate and nits -------- Original Message --------
Subject: Re: [Fwd: I-D ACTION:draft-ietf-l3vpn-bgp-ipv6-05.txt]
Date: Tue, 01 Mar 2005 11:08:05 -0500
From: Ronald Bonica
To: Thomas Narten
CC: zinin@psg.com, margaret@thingmagic.com, Ross Callon ,        Rick Wilder ,        "W. Mark Townsley"
References: <200502221553.j1MFrKux009401@rotala.raleigh.ibm.com> <421E0F50.8010709@juniper.net> <421F592C.3090804@juniper.net> Folks, Jeremy has cleared up the nits and resubmitted the draft. Please look for a v-06 of this v6 draft.                            Ron' added by Mark Townsley

[Note]: '-06 updated to take care of boilerplate and nits -------- Original Message --------
Subject: Re: [Fwd: I-D ACTION:draft-ietf-l3vpn-bgp-ipv6-05.txt]
Date: Tue, 01 Mar 2005 11:08:05 -0500
From: Ronald Bonica
To: Thomas Narten
CC: zinin@psg.com, margaret@thingmagic.com, Ross Callon ,        Rick Wilder ,        "W. Mark Townsley"
References: <200502221553.j1MFrKux009401@rotala.raleigh.ibm.com> <421E0F50.8010709@juniper.net> <421F592C.3090804@juniper.net> Folks, Jeremy has cleared up the nits and resubmitted the draft. Please look for a v-06 of this v6 draft.                             Ron' added by Mark Townsley

[Note]: '-06 updated to take care of boilerplate and nits -------- Original Message --------
Subject: Re: [Fwd: I-D ACTION:draft-ietf-l3vpn-bgp-ipv6-05.txt]
Date: Tue, 01 Mar 2005 11:08:05 -0500
From: Ronald Bonica
To: Thomas Narten
CC: zinin@psg.com, margaret@thingmagic.com, Ross Callon ,        Rick Wilder ,        "W. Mark Townsley"
References: <200502221553.j1MFrKux009401@rotala.raleigh.ibm.com> <421E0F50.8010709@juniper.net> <421F592C.3090804@juniper.net> Folks, Jeremy has cleared up the nits and resubmitted the draft. Please look for a v-06 of this v6 draft.                             Ron' added by Michelle Cotton

IANA Last Call Comments:
According to the IANA Considerations section, this document refers to 2 parameters that are already assigned (AFI value 2 for IP and SAFI value 128).
We understand this document to request NO IANA Actions.

[Note]: '
-06 updated to take care of boilerplate and nits

-------- Original Message --------
Subject: Re: [Fwd: I-D ACTION:draft-ietf-l3vpn-bgp-ipv6-05.txt]
Date: Tue, 01 Mar 2005 11:08:05 -0500
From: Ronald Bonica
To: Thomas Narten
CC: zinin@psg.com, margaret@thingmagic.com, Ross Callon ,        Rick Wilder ,        "W. Mark Townsley"
References: <200502221553.j1MFrKux009401@rotala.raleigh.ibm.com> <421E0F50.8010709@juniper.net> <421F592C.3090804@juniper.net>

Folks,

Jeremy has cleared up the nits and resubmitted the draft. Please look
for a v-06 of this v6 draft.

                            Ron' added by Mark Townsley

[Note]: 'Questionairre included in email below

Thomas,

I can vouch for draft-ietf-l3vpn-bgp-ipv6-05. See my responses below. Draft-defeng-l3vpn-ipv4-ipv6-hybrid-01 shouldn''t be on your plate. It hasn''t cleared WG last call. In fact, it isn''t even a WG draft.

I would ask one of the other WG chairs to fill out this form for draft-ietf-l3vpn-rt-constrain-01. I could do it, but probably should not because I am a co-author.

                                         Ron


Thomas Narten wrote:

> Generic request. When asking us to advance/publish documents, please
> fill out and submit the appended questionaire. The other INT WGs are
> doing this and it has been helpful to the ADs. AFAIK, l3vpn hasn''t
> done this, but I''d like to see this change (I''ve been lax about asking
> you to do this on previous documents).
>
> So, going forward, can you please fill out the questionare for the
> following two  documents (that are on my plate):
>
>       draft-defeng-l3vpn-ipv4-ipv6-hybrid-01.txt
>       draft-ietf-l3vpn-rt-constrain-01.txt
>
> Thanks,
> Thomas    
> [note: Version 2004-01-29]
>
> The INT ADs would like to try out something new with regards to
> document advancement.  We are asking the chairs fill out the following
> questionnaire for each document they wish to advance. We view this as
> an experiment that we will run for a bit and then assess whether this
> is helpful/useful. Purpose is to offload the ADs a bit, give chairs
> more responsibility, get things through the IESG faster (by addressing
> issues earlier that tend to trip up processing in the IESG), and get a
> better understanding of how ready a document really is.
>
> 1) Have the chairs personally reviewed this version of the ID and do
>    they believe this ID is sufficiently baked to forward to the IESG
>    for publication?


I have read the draft twice, once when it first appeared and again during last call. I believe that it is fully baked.

>
> 2) 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 passed last call in both the IDR and L3VPN WGs. There were comments from both WGs and the draft was modified to accommodate those comments.

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


No.

>    4) 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 whether there really is a need for it, etc., but at the same
>    time these issues have been discussed in the WG and the WG has
>    indicated it wishes to advance the document anyway.


No

>    5) 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?


There has been only one objection, posted long after the last call ended. The author of another draft requested that his work be folded into this draft. His work addresses a situation in which the provider network is partially IPv4 and partially IPv6.

As that author''s work is orthogonal to this draft, I am inclined to let the two drafts progress independently.

>
> 6) Has anyone threatened an appeal or otherwise indicated extreme
>    discontent?  If so, please summarize what are they upset about.


No

>    7) Have the chairs verified that the document adheres to _all_ of the
>    ID nits?  (see http://www.ietf.org/ID-nits.html).


I have.

>    8) Does the document a) split references into normative/informative,
>    and


Yes

b) are there normative references to IDs, where the IDs are not

>    also ready for advancement or are otherwise in an unclear state?
>    (Note: the RFC editor will not publish an RFC with normative
>    references to IDs, it will delay publication until all such IDs are
>    also ready for publication as RFCs.)


There are normative references to IDs. So, this draft will have to go in to the editor''s queue behind the following drafts:

   [2547bis] Rosen et al., "BGP/MPLS VPNs", draft-ietf-l3vpn-rfc2547bis,
   work in progress

   [BGP-EXTCOMM] Ramachandra, Tappan, Rekhter, "BGP Extended Communities
   Attribute", work in progress


>
> 9) For Standards Track and BCP documents, the IESG approval
>    announcement includes a writeup section with the following
>    sections:
>
>    - Technical Summary


   This document describes a method by which a Service Provider may use
   its packet switched backbone to provide Virtual Private Network
   services for its IPv6 customers.

   This method reuses, and extends where necessary, the "BGP/MPLS IP
   VPN" method [2547bis] for support of IPv6. In particular, this method
   uses the same "peer model" as [2547bis], in which the customers'' edge
   routers ("CE routers") send their IPv6 routes to the Service
   Provider''s edge routers ("PE routers"). BGP ("Border Gateway
   Protocol", [BGP, BGP-MP]) is then used by the Service Provider to
   exchange the routes of a particular IPv6 VPN among the PE routers
   that are attached to that IPv6 VPN. Eventually, the PE routers
   distribute, to the CE routers in a particular VPN, the IPv6 routes
   from other CE routers in that VPN. As with IPv4 VPNs, a key
   characteristic of this "peer model" is that the (IPv6) CE routers
   within an (IPv6) VPN do not peer with each other and there is no
   "overlay" visible to the (IPv6) VPN''s routing algorithm.

   A VPN is said to be an IPv6 VPN, when each site of this VPN is IPv6
   capable and is natively connected over an IPv6 interface or sub-
   interface to the SP backbone via a Provider Edge device (PE).

   A site may be both IPv4-capable and IPv6-capable. The logical
   interface on which packets arrive at the PE may determine the IP
   version. Alternatively the same logical interface may be used for
   both IPv4 and IPv6 in which case a per-packet lookup at the Version
   field of the IP packet header determines the IP version. This
   document only concerns itself with handling of the IPv6 packets.

   As such the inter-working between an IPv4 site and an IPv6 site is
   outside the scope of this document.

   In a similar manner to how IPv4 VPN routes are distributed in
   [2547bis], BGP and its extensions are used to distribute  routes from
   an IPv6 VPN site to all the other PE routers connected to a site of
   the same IPv6 VPN. PEs use "VPN Routing and Forwarding tables" (VRFs)
   to separately maintain the reachability information and forwarding
   information of each IPv6 VPN.

   As it is done for IPv4 VPNs [2547bis], we allow each IPv6 VPN to have
   its own IPv6 address space, which means that a given address may
   denote different systems in different VPNs. This is achieved via a
   new address family, the VPN-IPv6 Address Family, in a fashion similar
   to the VPN-IPv4 address family defined in [2547bis] and which
   prepends a Route Distinguisher to the IP address.

   In addition to its operation over MPLS Label Switched Paths (LSPs),
   the IPv4 BGP/MPLS VPN solution has been extended to allow operation
   over other tunneling techniques including GRE tunnels, IP-in-IP
   tunnels [2547-GRE/IP], L2TPv3 tunnels [MPLS-in-L2TPv3] and IPsec-
   protected tunnels [2547-IPsec]. In a similar manner, this document
   allows support of an IPv6 VPN service over MPLS LSPs as well as over
   other tunneling techniques including GRE tunnels, IP-in-IP tunnels,
   L2TPv3 tunnels and IPsec-protected tunnels.

   This document allows support for an IPv6 VPN service over an IPv4
   backbone as well as over an IPv6 backbone. The IPv6 VPN service
   supported is identical in both cases.


>    - Working Group Summary


This document went smoothly through the WG process.

>    - Protocol Quality


At least two vendors have developed to earlier versions of this draft. I suspect that there are more or will be more soon. Jeffrey Haas and Pedro  Marques both commented on the draft as it went through multiple revisions.

                                         Ron


>
>    Please provide such a writeup. (We will hopefully use it as is, but
>    may make some changes.) For recent examples, have a look at the
>    "protocol action" announcements for approved documents.
>
>    Note:
>    - When doing the technical summary, one would expect that the
>      relevant information is in the abstract and/or introduction of
>      the document. It turns out that the step of producing the writeup
>      sometimes points out deficiencies in the introduction/abstract
>      that are also worthy of rectifying.
>
>    - For the Working Group Summary, was there anything in WG process
>      that is worth noting? (E.g., controversy about particular points,
>      decisions where concensus was particularly rough, etc.)
>
>    - For the protocol quality, useful information could include:
>
>      - is the protocol already being implemented?
>
>      - have a significant number of vendors indicated they plan to
>        implement the spec?
>        - are there any reviewers (during the end stages) that merit
>        explicit mention as having done a thorough review that resulted
>        in important changes or a conclusion that the document was fine
>        (except for maybe some nits?)
>
> Thomas


' added by Mark Townsley