MPLS Upstream Label Assignment for LDP
draft-ietf-mpls-ldp-upstream-10

IANA understands that, upon approval of this document, there are four
IANA Actions that must be completed.

First, in the TLV Type Name Space registry located in the Label
Distribution Protocol (LDP) Parameters registry located at:

http://www.iana.org/assignments/ldp-namespaces

a new value is to be registered:

Range Description Reference
----- ---------------------------------------------- ----------
LDP Upstream Label Assignment Capability TLV RFC-to-be

The authors request that the value 0x0507 be assigned to this TLV .

Second, in the TLV Type Name Space registry located in the Label
Distribution Protocol (LDP) Parameters registry located at:

http://www.iana.org/assignments/ldp-namespaces

a new value is to be registered:

Range Description Reference
----- ---------------------------------------------- ----------
LDP Upstream-Assigned Label TLV RFC-to-be

The authors request that the value 0x204 be assigned to this TLV .

Third, in the TLV Type Name Space registry located in the Label
Distribution Protocol (LDP) Parameters registry located at:

http://www.iana.org/assignments/ldp-namespaces

a new value is to be registered:

Range Description Reference
----- ---------------------------------------------- ----------
LDP Upstream-Assigned Label Request TLV RFC-to-be

The authors request that the value 0x205 be assigned to this TLV .

Fourth, in the Interface ID Types subregistry of the Generalized
Multi-Protocol Label Switching (GMPLS) Signaling Parameters registry
located at:

http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xhtml

four new values are to be registered as follows:

Value Length Format Description Reference
------ ------- ------ --------------------- ----------
varies [RFC-to-be: section 5] RSVP-TE P2MP LSP TLV RFC-to-be
varies [RFC-to-be: section 5] LDP P2MP LSP TLV RFC-to-be
varies [RFC-to-be: section 5] IP Multicast Tunnel TLV RFC-to-be
varies [RFC-to-be: section 5] MPLS Context Label TLV RFC-to-be

The authors suggest the value 28 for ; 29 for ; 30 for
; and 31 for .

IANA understands that these four actions are all that are needed upon
approval of the document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

To: IETF-Announce 
From: The IESG
Reply-to: ietf@ietf.org
CC:
Subject: Second Last Call: draft-ietf-mpls-ldp-upstream (MPLS Upstream Label Assignment for LDP) to Proposed Standard

The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:

- 'MPLS Upstream Label Assignment for LDP '
    as a Proposed Standard

This SECOND last call has been made because a late IPR disclosure was
received.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-01-05. Exceptionally,
comments may be sent to iesg@ietf.org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-upstream-09.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14575&rfc_flag=0

IPR disclosures for this document exists at https://datatracker.ietf.org/ipr/1085/ and
https://datatracker.ietf.org/ipr/1454/

[Ballot comment]
Gen Art review comments from Avshalom Houri

Summary: The document is ready for a Standard Track RFC.

Major issues: None
Minor issues: None

Nits/editorial comments:

One or more occurrences in the document
a LDP -> an LDP
a LSR -> an LSR
a MPLS -> an MPLS

Line 540
  [MLDP] describe how to setup P2MP LSPs using LDP. On a LAN the
->    [MLDP] describes how to setup P2MP LSPs using LDP. On a LAN the

Line 572
  Ru on receiving this message sends back a Label Mapping message to Rd
->    On receiving this message, Ru sends back a Label Mapping message to Rd

[Ballot discuss]
A late-arriving IPR disclosure (https://datatracker.ietf.org/ipr/1454/) was posted less than an hour before the telechat.

I need to Discuss with the rest of the IESG whether to return this I-D for a further IETF last call, or to let the I-D proceed in the knowledge that the late disclosure may void the IPR owner's right to claim.

[Ballot comment]
A few comments from Ari Keränen:

The format of the packet format figures is not consistent: in the
section 5's sub-TLVs "type" is given with syntax "Type  = XX" whereas in
rest of the figures it's "Name (code)".

The second field of sub-TLVs (length?) is not defined at all in the
figures but just the value is given. Also the length seems to include
the type and length of the TLV -- is that intentional? Especially since
in the other TLVs do not seem to include type and length.

Also the sentence "The TLV value in the sub-TLV acts as the tunnel
identifier" is strange. Do you mean "the value of the sub-TLV"?


    1. RSVP-TE P2MP LSP TLV. Type = 28 (To be assigned by IANA). Value of
    the TLV is as carried in the RSVP-TE P2MP LSP SESSION Object
    [RFC4875].

The second sentence above is a bit confusing. Perhaps removing the "as
carried in" part from the sentence and changing "value of the TLV" into
"value of the sub-TLV" would help, if you mean that the whole object is
in the value of the sub-TLV.

It's also somewhat confusing that with RSVP-TE P2MP LSP TLV there are
Type and Length in the figure and with LDP P2MP LSP TLV there aren't.

The format of the 3rd and 4th sub-TLV seems underspecified. For example,
how do you encode a " tuple" in
a sub-TLV?


6. LDP Point-to-Multipoint LSPs on a LAN

    Processing
    of the Label Request and Label Mapping messages for LDP upstream-
    assigned labels is as described in section 4.2.

Section 4.2. does not exist.


    2. The following hash is performed: H = (Sum Opaque value) modulo N,
    where N is the number of candidate upstream LSRs. Opaque value is
    defined in [MLDP] and comprises the P2MP LSP identifier.

What does the "Sum" in the hash equation mean? I would assume it's sum
over all opaque values if there is more than one, but it's not really
clear from the context. Also, how do you convert the opaque value(s)
into number(s)?

[Ballot discuss]
Section 5 should explain what the semantics of the second field of the Sub-TLVs are. Presumably that has been defined in some earlier RFC that defined the syntax for Sub-TLVs. A reference would suffice.

Reference to Section 4.2 for some behaviour needs to be changed as there
is no Section 4.2.

[Ballot comment]
A few comments from Ari Keränen:

The format of the packet format figures is not consistent: in the
section 5's sub-TLVs "type" is given with syntax "Type  = XX" whereas in
rest of the figures it's "Name (code)".

The second field of sub-TLVs (length?) is not defined at all in the
figures but just the value is given. Also the length seems to include
the type and length of the TLV -- is that intentional? Especially since
in the other TLVs do not seem to include type and length.

Also the sentence "The TLV value in the sub-TLV acts as the tunnel
identifier" is strange. Do you mean "the value of the sub-TLV"?


    1. RSVP-TE P2MP LSP TLV. Type = 28 (To be assigned by IANA). Value of
    the TLV is as carried in the RSVP-TE P2MP LSP SESSION Object
    [RFC4875].

The second sentence above is a bit confusing. Perhaps removing the "as
carried in" part from the sentence and changing "value of the TLV" into
"value of the sub-TLV" would help, if you mean that the whole object is
in the value of the sub-TLV.

It's also somewhat confusing that with RSVP-TE P2MP LSP TLV there are
Type and Length in the figure and with LDP P2MP LSP TLV there aren't.

The format of the 3rd and 4th sub-TLV seems underspecified. For example,
how do you encode a " tuple" in
a sub-TLV?


6. LDP Point-to-Multipoint LSPs on a LAN

    Processing
    of the Label Request and Label Mapping messages for LDP upstream-
    assigned labels is as described in section 4.2.

Section 4.2. does not exist.


    2. The following hash is performed: H = (Sum Opaque value) modulo N,
    where N is the number of candidate upstream LSRs. Opaque value is
    defined in [MLDP] and comprises the P2MP LSP identifier.

What does the "Sum" in the hash equation mean? I would assume it's sum
over all opaque values if there is more than one, but it's not really
clear from the context. Also, how do you convert the opaque value(s)
into number(s)?

[Ballot comment]
This text is a little confusing

"As described in [RFC5331] an upstream LSR Ru MAY transmit a MPLS packet, the top label of which (L) is upstream-assigned, to a downstream LSR Rd"

Since it looks like Ru is a special type of LSR.

How about something like:

"As described in [RFC5331], a specific upstream LSR (Ru) MAY transmit a MPLS packet, the top label of which (L) is upstream-assigned, to it downstream neighbor LSR (Rd)"

[Ballot discuss]
Section 8:

#1: r/RFC 5036, RFC 5331 and RFC 5332/[RFC5036], [RFC5331] and [RFC5332]

#2: The MPLS-SEC/RFC5920 reference needs to be normative?

[Ballot discuss]
Section 5:

#1: r/RFC 5036, RFC 5331 and RFC 5332/[RFC5036], [RFC5331] and [RFC5332]

#2: The MPLS-SEC/RFC5920 reference needs to be normative?

IANA has questions about the IANA Actions requested in this document.

IANA understands that, upon approval of this document, there are four
IANA Actions that must be completed.

First, in the TLV Type Name Space registry located in the Label
Distribution Protocol (LDP) Parameters registry located at:

http://www.iana.org/assignments/ldp-namespaces

a new value is to be registered:

Range Description Reference
----- ---------------------------------------------- ----------
LDP Upstream Label Assignment Capability TLV RFC-to-be

The authors request that the value 0x0507 be assigned to this TLV .

Second, in the TLV Type Name Space registry located in the Label
Distribution Protocol (LDP) Parameters registry located at:

http://www.iana.org/assignments/ldp-namespaces

a new value is to be registered:

Range Description Reference
----- ---------------------------------------------- ----------
LDP Upstream-Assigned Label TLV RFC-to-be

The authors request that the value 0x204 be assigned to this TLV .

Third, in the TLV Type Name Space registry located in the Label
Distribution Protocol (LDP) Parameters registry located at:

http://www.iana.org/assignments/ldp-namespaces

a new value is to be registered:

Range Description Reference
----- ---------------------------------------------- ----------
LDP Upstream-Assigned Label Request TLV RFC-to-be

The authors request that the value 0x205 be assigned to this TLV .

Fourth, in the Interface ID Types subregistry of the Generalized
Multi-Protocol Label Switching (GMPLS) Signaling Parameters registry
located at:

http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xhtml

four new values are to be registered as follows:

Value Description Reference
------- --------------------------------------------- ----------
RSVP-TE P2MP LSP TLV RFC-to-be
LDP P2MP LSP TLV RFC-to-be
IP Multicast Tunnel TLV RFC-to-be
MPLS Context Label TLV RFC-to-be

The authors suggest the value 28 for ; 29 for ; 30 for
; and 31 for .

IANA QUESTION: registrations in the Interface ID Types subregistry are
supplied with a length and format. What should the length and format be
for each of these four additions to the Interface ID subregistry?

AD Review

==Major issues==

I am not comfortable with the re-use and extension of the Interface I-D
TLV from RFC 3472 the way you have done.

While RFC 3468 does not make RFC 3212 historic, it does update 3212 and
says that...

      -  adopt as an IETF policy to refrain from entertaining new
        working group documents that are extensions to RFC 3212

Clearly it is not your intention here to do work that opens up CR-LDP.
It appears that you are simply trying to utilise the Interface
Identifier TLV in order to save code points.

As I understand it, the CR-LDP TLV is not currently used in LDP
implementations except for the function you describe.

My prefered way to handle this would be to introduce a completely new
LDP TLV (performing essentially the same function) and to define the
four sub-TLVs that you need. In this way you would neither be tied to
the unfortunate effect of RFC 3472 being made historic at some time in
the future, nor would you have to dance around with allocations from
the GMPLS registry for a protocol that is clearly nothing to do with
GMPLS.

I am happy to discuss this point further if you or the WG chairs want
to try to convince me that re-using CR-LDP is correct.

(Sorry I didn't notice this when I was helping with the IANA text
previously, but it looks like you didn't accept my change there anyway
since I observed that you should use sub-TLVs in accordance with RFC
3472 not interface types in accordance with RFC 3473.)

---

In section 5 I think you need to show the TLV encodings.

You are trying to inherrit them from other specs, but this is not
satisfactory.

For example, in the first case you say that the value of the TLV is
" as carried in the
RSVP-TE P2MP LSP SESSION Object [RFC4875]". But:

- there are two versions of this seesion object depending on IPv4 or
  IPv6
- the order of data is different to that you have listed.

I think that it would not hurt to include the encoding, and it might
avoid other possible errors or confusion.

---

The security section is very weak. We are not going to get it through
the Security ADs.

You basically palm this off to 5331 and 5332.
But 5331 is a forward reference to this spec (!) while 5332 passes the
buck as follows:
- 3032 which passes the buck to
  - 3031 which is minimal
- 4023 which is about MPLS in IP and MPLS in GRE and explicitly says:
  "The use of the MPLS-in-IP encapsulation for MPLS multicast packets
  is not supported by this specification."

In addition, you are introducing a significant issue for multi-access
LANs that you need to explain carefully. If a receiver only looks at
the incoming Label it has no way to distinguish packets sent
legitimately by the ustream label allocator from packets sent in error
or as an attack by any other node on the LAN. This section definitely
needs to explain how an implementation protects against that problem.

Finally, since you are defining extensions to LDP, you might reasonably
include a reference to RFC 5036.

---

As your text is currently written, [MLDP] and [RFC4875] need to be
normative references. This might change, however, depending on how
you work on Section 5.

==Minor issues==

While section 6 is accurate and can be read correctly, it would be
massively enhanced by a figure.

---

Section 3
Do I understand from the figure that this capability cannot be
withdrawn. That is, you MUST NOT use this with S=0. If so, you
should describe this.
Or, alternatively, should you show the figure with "S" not "1"?

---

Section 3

  The Upstream Label Assignment
  Capability Parameter can be exchanged only in LDP initialization
  messages.

Are you sure you don't want to say "MUST NOT be carried on a
Capability message"?

In either case, you need to say what a node should do if it sees
an Upstream Label Assignment Capability Parameter in a Capability
messages.

---

Section 4

  This TLV MUST be carried in a Label Request message if
  an upstream-assigned label is being requested.

Isn't this a strange way to say it? Surely it is the other way
round and without any 2119 language. "To request an upstream-
assigned label, an LDP peer includes the TLV in a Label Request
message."

---

Section 4

  This is a 20-bit label value as specified in [RFC3032] represented as
  a 20-bit number in a 4 octet field.

This sentence seems to arrive without context.

I think you also intended to indicate how the 20 bits are arranged in
the 4 octet field. Wouldn't a reference to section 3.4.2.1 of RFC 5036
be better?

---

Section 4

In general, we don't define TLVs with large reserved fields unless we
have some forseen future use, or we need to get the TLV to be the
same format as another TLV. You should explain the shape of the two
TLVs in this section or clean up the TLVs.

==Nits==

idnits shows
  == Unused Reference: 'RFC3471' is defined on line 439, but no explicit
    reference was found in the text
The write-up asks that this should be removed by the RFC Editor, but
this should have been fixed before publication was requested, and needs
to be fixed before the document goes for further review.

---

Abstract
s/labels for Label/labels for the Label/
Expand LSR and LSP
s/(P2MP)LSPs/(P2MP) LSPs/

---

Section 2
s/labels for Label/labels for the Label/
Should reference 5036 in the Introduction
Expand LSR, LSP, and P2MP

UPDATED PROTO WRITE-UP BELOW:

The MPLS WG requests that:
  MPLS Upstream Label Assignment for LDP
  draft-ietf-mpls-ldp-upstream-07

is published as a RFC on the standards track.


> (1.a) Who is the Document Shepherd for this document? Has the
>      Document Shepherd personally reviewed this version of the
>      document and, in particular, does he or she believe this
>      version is ready for forwarding to the IESG for publication?

Loa Andersson is the Document Shepherd.
He has reviewed the document and believes it is ready to be
forwarded to the IESG for publication.

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

The document has been reviewed in the MPLS working gorup.


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

No.

> (1.d) Does the Document Shepherd have any specific concerns or
>      issues with this document that the Responsible Area Director
>      and/or the IESG should be aware of? For example, perhaps he
>      or she is uncomfortable with certain parts of the document, or
>      has concerns whether there really is a need for it. In any
>      event, if the WG has discussed those issues and has indicated
>      that it still wishes to advance the document, detail those
>      concerns here. Has an IPR disclosure related to this document
>      been filed? If so, please include a reference to the
>      disclosure and summarize the WG discussion and conclusion on
>      this issue.

No such concerns. There is one IPR claim for this draft

- 2009-02-09 ID # 1085  "Juniper's Statement of IPR related to
  draft-ietf-mpls-ldp-upstream-03"



> (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?

The development of upstream label allocation has been very carefully
discussed in the working group, and are no opinions vocied that goes
against what is specifeid in the document.

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

No threats or extreme discontent.

> (1.g) Has the Document Shepherd personally verified that the
>      document satisfies all ID nits? (See the Internet-Drafts Checklist
>      and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
>      not enough; this check needs to be thorough. Has the document
>      met all formal review criteria it needs to, such as the MIB
>      Doctor, media type and URI type reviews?

Checks are almost clean,

- as alwas there is a newer version of one of the refrenced documents
  (draft-ietf-mpls-mpls-and-gmpls-security-framework), it is liely that
  the referenced draft will be an RFC at the time of publication of this
  draft, the RFC-Editor should be asked to change the reference to point
  at the upcoming RFC
- there is one unused reference RFC3471, the RFC-Ed should be asked to
  remove the definition.


> (1.h) Has the document split its references into normative and
>      informative? Are there normative references to documents that
>      are not ready for advancement or are otherwise in an unclear
>      state? If such normative references exist, what is the
>      strategy for their completion? Are there normative references
>      that are downward references, as described in [RFC3967]? If
>      so, list these downward references to support the Area
>      Director in the Last Call procedure for them [RFC3967].

References are correctly split.


> (1.i) Has the Document Shepherd verified that the document IANA
>      consideration section exists and is consistent with the body
>      of the document? If the document specifies protocol
>      extensions, are reservations requested in appropriate IANA
>      registries? Are the IANA registries clearly identified? If
>      the document creates a new registry, does it define the
>      proposed initial contents of the registry and an allocation
>      procedure for future registrations? Does it suggest a
>      reasonable name for the new registry? See [RFC5226]. If the
>      document describes an Expert Review process has Shepherd
>      conferred with the Responsible Area Director so that the IESG
>      can appoint the needed Expert during the IESG Evaluation?

There are IANA actions associated with this document.

IANA is asked to assign three new TLV values from "TLV Type Name
Space" registry.


IANA is also asked to assigned codepoints for four new TLVs from
the "Interface_ID Types" registry.


> (1.j) Has the Document Shepherd verified that sections of the
>      document that are written in a formal language, such as XML
>      code, BNF rules, MIB definitions, etc., validate correctly in
>      an automated checker?

No such formal language.

> (1.k) The IESG approval announcement includes a Document
>      Announcement Write-Up. Please provide such a Document
>      Announcement Write-Up? Recent examples can be found in the
>      "Action" announcements for approved documents. The approval
>      announcement contains the following sections:

Technical Summary

  The document describes procedures for distributing upstream-assigned
  labels for the Label Distribution Protocol (LDP). It also describes
  how these procedures can be used for avoiding branch LSR traffic
  replication on a LAN for LDP point-to-multipoint (P2MP)LSPs.



Working Group Summary

Nothing to report

Document Quality

There is at least on implementation tht we know of.

> (1.a) Who is the Document Shepherd for this document? Has the
>      Document Shepherd personally reviewed this version of the
>      document and, in particular, does he or she believe this
>      version is ready for forwarding to the IESG for publication?

Loa Andersson is the Document Shepherd.
He has reviewed the document and believes it is ready to be
forwarded to the IESG for publication.

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

The document has been reviewed in the MPLS working gorup.


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

No.

> (1.d) Does the Document Shepherd have any specific concerns or
>      issues with this document that the Responsible Area Director
>      and/or the IESG should be aware of? For example, perhaps he
>      or she is uncomfortable with certain parts of the document, or
>      has concerns whether there really is a need for it. In any
>      event, if the WG has discussed those issues and has indicated
>      that it still wishes to advance the document, detail those
>      concerns here. Has an IPR disclosure related to this document
>      been filed? If so, please include a reference to the
>      disclosure and summarize the WG discussion and conclusion on
>      this issue.

No such concerns. There is one IPR claim for this draft

- 2009-02-09 ID # 1085  "Juniper's Statement of IPR related to
  draft-ietf-mpls-ldp-upstream-03"



> (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?

The development of upstream label allocation has been very carefully
discussed in the working group, and are no opinions vocied that goes
against what is specifeid in the document.

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

No threats or extreme discontent.

> (1.g) Has the Document Shepherd personally verified that the
>      document satisfies all ID nits? (See the Internet-Drafts Checklist
>      and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
>      not enough; this check needs to be thorough. Has the document
>      met all formal review criteria it needs to, such as the MIB
>      Doctor, media type and URI type reviews?

(need a -07 version)

All checks are clean.


> (1.h) Has the document split its references into normative and
>      informative? Are there normative references to documents that
>      are not ready for advancement or are otherwise in an unclear
>      state? If such normative references exist, what is the
>      strategy for their completion? Are there normative references
>      that are downward references, as described in [RFC3967]? If
>      so, list these downward references to support the Area
>      Director in the Last Call procedure for them [RFC3967].

References are correctly split.


> (1.i) Has the Document Shepherd verified that the document IANA
>      consideration section exists and is consistent with the body
>      of the document? If the document specifies protocol
>      extensions, are reservations requested in appropriate IANA
>      registries? Are the IANA registries clearly identified? If
>      the document creates a new registry, does it define the
>      proposed initial contents of the registry and an allocation
>      procedure for future registrations? Does it suggest a
>      reasonable name for the new registry? See [RFC5226]. If the
>      document describes an Expert Review process has Shepherd
>      conferred with the Responsible Area Director so that the IESG
>      can appoint the needed Expert during the IESG Evaluation?

There are IANA actions associated with this document. IANA is asked to
assigned codepoints for four new TLVs from the "Interface_ID Types"
registry.


> (1.j) Has the Document Shepherd verified that sections of the
>      document that are written in a formal language, such as XML
>      code, BNF rules, MIB definitions, etc., validate correctly in
>      an automated checker?

No such formal language.

> (1.k) The IESG approval announcement includes a Document
>      Announcement Write-Up. Please provide such a Document
>      Announcement Write-Up? Recent examples can be found in the
>      "Action" announcements for approved documents. The approval
>      announcement contains the following sections:

Technical Summary

  The document describes procedures for distributing upstream-assigned
  labels for the Label Distribution Protocol (LDP). It also describes
  how these procedures can be used for avoiding branch LSR traffic
  replication on a LAN for LDP point-to-multipoint (P2MP)LSPs.



Working Group Summary

Nothing to report

Document Quality

There is at least on implementation tht we know of.