Signaling Extensions for Wavelength Switched Optical Networks
draft-ietf-ccamp-wson-signaling-12

[Ballot comment]
I'm a bit startled that the WavelengthSelection sub-TLV has a used value of 8 bits (really 1 bit plus a handful of the 127 values) but has a length of 4 which thus forces 2 octets of padding.  I expect that there are implementations and this isn't a flaw - just wasteful.

[Ballot comment]
The security considerations say this document differs from 3473 only in "specific information communicated". In general, a change in the information carried can make a huge difference. I infer that the working group believes that this specific information does not (I hold no opinion on that), but it would be good to state that explicitly.

[Ballot comment]

Just wondering: does this (or some other document) provide me
with a way to say that node X should take an input lambda and
replicate it out twice? (I.e. forking the traffic) If so, then
that probably ought be noted somewhere as it'd enable forms of
monitoring that might otherwise require a visit to the physical
node.

[Ballot comment]
I think the choice of registration policies for the new registries -- Standards Action or Specification Required -- is a good one, and provides good flexibility.  Thanks for that.

[Ballot comment]
OPS and Sec Dir reviews from Tim Wicinski and Benjamin Kaduk raised a number of nits that should be handled:

> -- The draft header indicates that this document updates RFC6205,
>    but the abstract doesn't seem to mention this, which it should.
>
> == Outdated reference: draft-ietf-ccamp-rwa-info has been published as
>      RFC 7446
>
> Reference Comment:
>
> Under Informative References RFC6163 is listed as
>    "work in progress: draft-bernstein-ccamp-wavelength-switched-03.txt,
>      February 2008"
>
> It's the only RFC reference that looks off. 

| The list of WSON Signal Characteristics introduces the acronym FEC and
| includes its expansion in the body, but does not explicitly define the
| term.  That could be done in the Terminology section.
|
| In section 3.2, the term "3R regeneration" is used, but it is not
| mentioned in the Temrinology section.  (As not a routing person, I had to
| look it up.)
|
| In section 4.1, I think that an "in the" or "by the" (or similar) is
| missing prior to "Generalized Label Request object".
|
| Section 4.2 claims that the requirements for signaling to indicate to a
| particular node what type of processing to perform are given in section
| 3.2, however, I see no such requirements in section 3.2; is a different
| section intended?
|
| Also in section 4.2, the term "WSON Processing HOP Attribute TLV" is
| used.  Is HOP an acronym?  I do not see it in the RFC Editor's list of
| abbreviations
| (https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt)
| and I am not entirely sure that I understand its meaning.
|
| The artwork for the contents of that TLV immediately follows.  The
| subsequent descriptive text indicates that there may be padding after
| the 'Value' field, to align the end of the record to a four-octet boundary.
| It might be useful to include some padding in the artwork.
|
| The text description for the "Length" field says that the included length
| is four plus the length of the value field in octets, but the artwork has
| only one octet for each of the Type and Length fields, which would make
| the constant two, not four.  (Perhaps those two fields were changed from
| two octets to one octet in some revision of the document?)
|
| Likewise, the description of the WavelengthSelection sub-TLV in the table
| with Name/Type/Length indicates that 3 octets of padding would be needed
| after the 1 octet of 'Value' contents.  However, if the Type and Length
| fields are only one octet each, only one octet of padding would be needed,
| not three.
|
| In section 4.2.1, it is said that "No more than two ResourceBlockInfo
| sub-TLVs SHOULD be present."  However, the RBNF for the WSON Processing
| HOP Attribute allows at most two, so any more than two would be
| noncompliant with the RBNF.  It is unclear to me if this incongruity is
| actually a cause for concern; it probably depends on why SHOULD is used
| instead of MUST.

The IANA review of this document leads to the following changes in Section 6

Old:
http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te-parameters.xhtml
New:
http://www.iana.org/assignments/rsvp-te-parameters/

Old:
http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml
New:
http://www.iana.org/assignments/rsvp-parameters/

[Ballot comment]
OPS and Sec Dir reviews from Tim Wicinski and Benjamin Kaduk raised a number of nits that should be handled:

> -- The draft header indicates that this document updates RFC6205,
>    but the abstract doesn't seem to mention this, which it should.
>
> == Outdated reference: draft-ietf-ccamp-rwa-info has been published as
>      RFC 7446
>
> Reference Comment:
>
> Under Informative References RFC6163 is listed as
>    "work in progress: draft-bernstein-ccamp-wavelength-switched-03.txt,
>      February 2008"
>
> It's the only RFC reference that looks off. 

| The list of WSON Signal Characteristics introduces the acronym FEC and
| includes its expansion in the body, but does not explicitly define the
| term.  That could be done in the Terminology section.
|
| In section 3.2, the term "3R regeneration" is used, but it is not
| mentioned in the Temrinology section.  (As not a routing person, I had to
| look it up.)
|
| In section 4.1, I think that an "in the" or "by the" (or similar) is
| missing prior to "Generalized Label Request object".
|
| Section 4.2 claims that the requirements for signaling to indicate to a
| particular node what type of processing to perform are given in section
| 3.2, however, I see no such requirements in section 3.2; is a different
| section intended?
|
| Also in section 4.2, the term "WSON Processing HOP Attribute TLV" is
| used.  Is HOP an acronym?  I do not see it in the RFC Editor's list of
| abbreviations
| (https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt)
| and I am not entirely sure that I understand its meaning.
|
| The artwork for the contents of that TLV immediately follows.  The
| subsequent descriptive text indicates that there may be padding after
| the 'Value' field, to align the end of the record to a four-octet boundary.
| It might be useful to include some padding in the artwork.
|
| The text description for the "Length" field says that the included length
| is four plus the length of the value field in octets, but the artwork has
| only one octet for each of the Type and Length fields, which would make
| the constant two, not four.  (Perhaps those two fields were changed from
| two octets to one octet in some revision of the document?)
|
| Likewise, the description of the WavelengthSelection sub-TLV in the table
| with Name/Type/Length indicates that 3 octets of padding would be needed
| after the 1 octet of 'Value' contents.  However, if the Type and Length
| fields are only one octet each, only one octet of padding would be needed,
| not three.
|
| In section 4.2.1, it is said that "No more than two ResourceBlockInfo
| sub-TLVs SHOULD be present."  However, the RBNF for the WSON Processing
| HOP Attribute allows at most two, so any more than two would be
| noncompliant with the RBNF.  It is unclear to me if this incongruity is
| actually a cause for concern; it probably depends on why SHOULD is used
| instead of MUST.

[Ballot comment]
OPS and Sec Dir reviews from Tim Wicinski and Benjamin Kaduk raised a number of nits that should be handled:

> -- The draft header indicates that this document updates RFC6205, but the
>    abstract doesn't seem to mention this, which it should.
>
> == Outdated reference: draft-ietf-ccamp-rwa-info has been published as RFC
>    7446
>
> Reference Comment:
>
> Under Informative References RFC6163 is listed as
>    "work in progress: draft-bernstein-ccamp-wavelength-switched-03.txt, February 2008"
>
> It's the only RFC reference that looks off. 

| The list of WSON Signal Characteristics introduces the acronym FEC and
| includes its expansion in the body, but does not explicitly define the
| term.  That could be done in the Terminology section.
|
| In section 3.2, the term "3R regeneration" is used, but it is not
| mentioned in the Temrinology section.  (As not a routing person, I had to
| look it up.)
|
| In section 4.1, I think that an "in the" or "by the" (or similar) is
| missing prior to "Generalized Label Request object".
|
| Section 4.2 claims that the requirements for signaling to indicate to a
| particular node what type of processing to perform are given in section
| 3.2, however, I see no such requirements in section 3.2; is a different
| section intended?
|
| Also in section 4.2, the term "WSON Processing HOP Attribute TLV" is used.
| Is HOP an acronym?  I do not see it in the RFC Editor's list of
| abbreviations
| (https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt) and I am
| not entirely sure that I understand its meaning.
|
| The artwork for the contents of that TLV immediately follows.  The
| subsequent descriptive text indicates that there may be padding after the
| 'Value' field, to align the end of the record to a four-octet boundary.
| It might be useful to include some padding in the artwork.
|
| The text description for the "Length" field says that the included length
| is four plus the length of the value field in octets, but the artwork has
| only one octet for each of the Type and Length fields, which would make
| the constant two, not four.  (Perhaps those two fields were changed from
| two octets to one octet in some revision of the document?)
|
| Likewise, the description of the WavelengthSelection sub-TLV in the table
| with Name/Type/Length indicates that 3 octets of padding would be needed
| after the 1 octet of 'Value' contents.  However, if the Type and Length
| fields are only one octet each, only one octet of padding would be needed,
| not three.
|
| In section 4.2.1, it is said that "No more than two ResourceBlockInfo
| sub-TLVs SHOULD be present."  However, the RBNF for the WSON Processing
| HOP Attribute allows at most two, so any more than two would be
| noncompliant with the RBNF.  It is unclear to me if this incongruity is
| actually a cause for concern; it probably depends on why SHOULD is used
| instead of MUST.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ccamp-wson-signaling version 10.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We have a few questions for the actions requested in this document.

We received the following comments/questions from the IANA's reviewer:

Upon approval of this document, IANA understands that there are four actions which need to be completed.

Comment: Please use the following URL in the IANA Considerations section of
this draft:

http://www.iana.org/assignments/rsvp-te-parameters/

Not this:

http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te-parameters.xhtml

This will ensure the URL will always work and point to the most current
version/extension.

First, in the Attributes TLV Space subregistry of the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters registry located at:

http://www.iana.org/assignments/rsvp-te-parameters/

A new TLV is to be registered as follows:

Type: [ TBD-at-registration ]
Name: WSON Processing HOP Attributes
Allowed on LSP Attributes: No
Allowed on LSP required Attributes: No
Allowed on RO LSP Attribute Subobject: Yes
Reference: [ RFC-to-be ]

Second, a new registry is to be created called the Sub-TLV Types for WSON Processing HOP Attribute TLV registry. This new registry is to be located in the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters registry located at:

http://www.iana.org/assignments/rsvp-te-parameters/

The registry will be maintained by Standards Action and Specification Required policies as defined in RFC5226. There are initial registrations in the new registry as follows:

Value Sub-TLV Type Reference
1 ResourceBlockInfo [ RFC-to-be ]
2 WavelengthSelection [ RFC-to-be ]

Questions:
- Is there a range for this registry? Is value 0 the first value of this new Type and
should the value be marked as "reserved"?  What is the maximum Type value? Or,
is this registry an unlimited resource?

- The IC section has:

  "All assignments are to be performed via Standards Action and
  Specification Required policies as defined in [RFC5226]"

RFC5226 described Standards Action and Specification Required are two different
policies.  Are you intended to use both policies for a new registration in the new
created registry "Sub-TLV Types for WSON Processing HOP Attribute TLV"?

Third, a new registry is to be created called the Values for Wavelength Assignment method field in Wavelength selection sub-TLV registry. This new registry is to be located in the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters registry located at:

http://www.iana.org/assignments/rsvp-te-parameters/

The registry will be maintained by Standards Action and Specification Required policies as defined in RFC5226. There are initial registrations in the new registry as follows:

Value Meaning Reference
0 unspecified [ RFC-to-be ]
1 First-Fit [ RFC-to-be ]
2 Random [ RFC-to-be ]
3 Least-Loaded (multi-fiber) [ RFC-to-be ]
4-127 Unassigned [ RFC-to-be ]

Question: Same question -
- The IC section has:

  "All assignments are to be performed via Standards Action and
  Specification Required policies as defined in [RFC5226]"

RFC5226 described Standards Action and Specification Required are two different
policies.  Are you intended to use both policies for a new registration in the new
created registry "Values for Wavelength Assignment method field in
WavelengthSelection sub-TLV"?

Fourth, in the SubCodes - 24 Routing Problem subregistry of the registry RSVP
Parameters located at:

http://www.iana.org/assignments/rsvp-parameters/

Two new SubCodes are to be registered as follows:

Value: 107
Description: Unsupported WavelengthSelection symmetry value
Reference: [ RFC-to-be ]

Value: 108
Description: Unsupported Wavelength Assignment value
Reference: [ RFC-to-be ]

NOTE:
A) Please use the following URL in the IANA Considerations section of
this draft:

http://www.iana.org/assignments/rsvp-parameters/ 

Not this:

http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml

This will ensure the URL will always work and point to the most current
version/extension.

B) Please note that IANA cannot reserve specific values. However, early allocation is
available for some types of registrations. For more information, please see RFC 7120.
Otherwise, please consider to use place holders in Internet Drafts.

IANA understands that these four actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Signaling Extensions for Wavelength Switched Optical Networks) to Proposed Standard


The IESG has received a request from the Common Control and Measurement
Plane WG (ccamp) to consider the following document:
- 'Signaling Extensions for Wavelength Switched Optical Networks'
  as Proposed Standard

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 2015-03-18. 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.

Abstract

  This memo provides extensions to Generalized Multi-Protocol Label
  Switching (GMPLS) signaling for control of Wavelength Switched
  Optical Networks (WSON).  Such extensions are applicable in WSONs
  under a number of conditions including: (a) when optional
  processing, such as regeneration, must be configured to occur at
  specific nodes along a path, (b) where equipment must be configured
  to accept an optical signal with specific attributes, or (c) where
  equipment must be configured to output an optical signal with
  specific attributes. In addition this memo provides mechanisms to
  support distributed wavelength assignment with choice in distributed
  wavelength assignment algorithms. These extensions build on previous
  work for the control of lambda and G.709 based networks, i.e. update
  RFC6205, to make it applicable to WSON-LSC capable equipment.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signaling/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signaling/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1061/

AD review
====

Authors,

I've done my usual AD review of your document (the nth in the sequence
of n+1 WSON drafts!). I have a few comments, and normally I would ask
you for a new revision at once, but because of dates and things I am
going to start the IETF last call and enter these as last call comments.

The last call will end on 3/18 and you can post a new revision then (by
sending it to me to ask the Secretary to post it) or wait to post it
yourselves when the gates reopen on 3/23.

Thanks for the work,
Adrian

===

You need to split the Authors' Addresses section and move out all those
not on the current front page to be present in a Contributors section.

---

You seem to have the name of RFC 6205 in the references section a bit
wrong!

---
                                             
Do you really mean that you are updating 6205? That is the document
that defines lambda labels.

It has no mention of G.709 despite what you say in the Abstract. This
seems a little odd.                         

What is more, I don't see any discussion of updates to the label format
or usage in the document although Section 4 does say

  [RFC6205] defines the label format as applicable to LSC capable
  device. This document extends [RFC6205] as make its label format
  applicable also to WSON-LSC capable devices.

I don't think that applying the label to WSON without changing its
meaning or the way it is used is really an "update".

---

Section 2 has FOADM, but it is not used in the document.

You need to hyphenate "Cross Connect" unless you are really angry :-)

---

Section 3 gives a caption to a list

    List 1. WSON Signal Characteristics

I've not seen that before in an I-D, and since you don't refer to the
list by name, I suggest you just delete this.

---

I wish you hadn't suggested explicit values for the two new Error Codes
in 4.2.2 and 6. But we'll see what IANA says during IETF last call.

During the review of draft-ietf-teas-lsp-attribute-ro it was noted that rules are needed about where in an ERO the sub-objects are allowed, and that these rules are dependent on the TLVs included in the sub-objects.

The following text was suggested:

>  The WSON Processing HOP Attribute TLV with ResourceBlockInfo MUST be
> present after an explicit Hop addressing an TE Router ID identifying a
> specific node or a Link ID identifying an incoming TE link. it MUST NOT be
> present after a loose, abstract node, Link ID identifying an outgoing TE
> link, Component Interface ID or Label.
>
> The WSON Processing HOP Attribute TLV with WavelengthSelection only MUST
> be present after an explicit Hop addressing an TE Router ID identifying a
> specific node,  a Link ID identifying an incoming TE link, loose hop,
> abstract node, Link ID identifying an outgoing TE lin or  Component
> Interface ID. it MUST NOT be present after a Label.
>
> The WavelengthSelection may apply starting at an abstract node, but not
> after a label (as no selection is possible)

Write up for draft-ietf-ccamp-wson-signaling

> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up.
>
> Changes are expected over time. This version is dated 24 February 2012.
>
> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?

Standards Track

> Why is this the proper type of RFC? 

The document defines RSVP related formats and behaviors.

> Is this type of RFC indicated in the title page header?

Yes.

> (2) 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
>
>  Relevant content can frequently be found in the abstract
>  and/or introduction of the document. If not, this may be
>  an indication that there are deficiencies in the abstract
>  or introduction.


  This memo provides extensions to Generalized Multi-Protocol Label
  Switching (GMPLS) signaling for control of wavelength switched
  optical networks (WSON).  Such extensions are applicable in WSONs
  under a number of conditions including: (a) when optional
  processing, such as regeneration, must be configured to occur at
  specific nodes along a path, (b) where equipment must be configured
  to accept an optical signal with specific attributes, or (c) where
  equipment must be configured to output an optical signal with
  specific attributes. In addition this memo provides mechanisms to
  support distributed wavelength assignment with choice in distributed
  wavelength assignment algorithms. These extensions build on previous
  work for the control of lambda and G.709 based networks. This
  document updates [RFC6205] as make it applicable to WSON-LSC capable
  equipment.

> Working Group Summary
>
>  Was there anything in WG process that is worth noting? For
>  example, was there controversy about particular points or
>  were there decisions where the consensus was particularly
>  rough?

This topic been discussed in the WG for a very long time, perhaps 6
years.  Support for the work has been tepid, but there are multiple
sets of contributors who would like to see the work result in proposed
standards.

> Document Quality
>
>  Are there existing implementations of the protocol? Have a
>  significant number of vendors indicated their plan to
>  implement the specification? Are there any reviewers that
>  merit special mention as having done a thorough review,
>  e.g., one that resulted in important changes or a
>  conclusion that the document had no substantive issues? If
>  there was a MIB Doctor, Media Type or other expert review,
>  what was its course (briefly)? In the case of a Media Type
>  review, on what date was the request posted?

The base GMPLS protocol has been implemented.  The extensions defined in
this document are compatible with earlier implementations.  Multiple
implementors have stated their intent to implement, or have stated that
they have already implemented, the mechanisms defined in this document.

> Personnel
>
>  Who is the Document Shepherd?

Lou Berger

> Who is the Responsible Area Director?

Adrian Farrel

> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd.  If this version of the document is not ready
> for publication, please explain why the document is being forwarded to
> the IESG.

The Document Shepherd has reviewed the document as it has progressed
through the CCAMP WG, including as part of an extended WG last calls.
The Shepherd believes this document is ready for publication. This
document is part of a set of documents on WSON and final publication --
and at the AD's discretion, IETF LC -- should occur as a set.
The documents set includes:
    draft-ietf-ccamp-rwa-info
    draft-ietf-ccamp-general-constraint-encode
    draft-ietf-ccamp-rwa-wson-encode
    draft-ietf-ccamp-gmpls-general-constraints-ospf-te
    draft-ietf-ccamp-wson-signal-compatibility-ospf
    draft-ietf-ccamp-wson-signaling

> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed? 

No. 

> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that
> took place.

As part of the 2nd WG LC, both the OSPF WGs chairs were consulted, and
one provided comments.

> (6) Describe any specific concerns or issues that the Document Shepherd
> has 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.

No specific concerns.

> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why.

Yes, via messages to/on the CCAMP WG list.

> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.

No IPR has been disclosed for this document.

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

Good among interested parties. No objections from others.

> (10) 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 publicly available.)

Not to my knowledge.

> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

The document passes tools idnits with 1 warning.

> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A.

> (13) Have all references within this document been identified as
> either normative or informative?

Yes.

> (14) 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 plan for their completion?


Note that this document uses mechanisms defined in
draft-ietf-ccamp-lsp-attribute-ro which the WG expects to progress/LC
shortly. Given the size of the WSON document set, we expect this
document will be ready for publication at the roughly the same time.


> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.

None.

> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction? If the RFCs are not
> listed in the Abstract and Introduction, explain why, and point to the
> part of the document where the relationship of this document to the
> other RFCs is discussed. If this information is not in the document,
> explain why the WG considers it unnecessary.

No.

> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.
> Confirm that any referenced IANA registries have been clearly
> identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).

The IANA section was fully reviewed by the document shepherd.  Three new
allocations are requested in this document.

Two registries are created, both with Standards Action and Specification
Required policies as defined in [RFC5226].

> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find
> useful in selecting the IANA Experts for these new registries.

N/A.

> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.

This document contains RBNF as defined in RFC5511.  There are no automated
tools for the validation of such, but RBNF was reviewed and discussed as
part of last call.

Prepration for WG last call.

IPR declarations still missing:
guolintom at gmail.com(...),
jyf at bupt.edu.cn(...),

IPR declariations received:
gregb at grotto-networking.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg15256.html),
nick at sssup.it(http://www.ietf.org/mail-archive/web/ccamp/current/msg15007.html),
a.giorgetti at sssup.it(http://www.ietf.org/mail-archive/web/ccamp/current/msg15006.html),
harai at nict.go.jp(http://www.ietf.org/mail-archive/web/ccamp/current/msg14996.html),
daniel at olddog.co.uk(http://www.ietf.org/mail-archive/web/ccamp/current/msg14997.html),
leeyoung at huawei.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg14985.html),
xsg at nict.go.jp(http://www.ietf.org/mail-archive/web/ccamp/current/msg15012.html),
giomarti at cisco.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg15000.html)

Prepration for WG last call.

IPR declariations.
gregb at grotto-networking.com(...),
nick at sssup.it(http://www.ietf.org/mail-archive/web/ccamp/current/msg15007.html),
a.giorgetti at sssup.it(http://www.ietf.org/mail-archive/web/ccamp/current/msg15006.html),
guolintom at gmail.com(...),
harai at nict.go.jp(http://www.ietf.org/mail-archive/web/ccamp/current/msg14996.html), jyf at bupt.edu.cn(...),
daniel at olddog.co.uk(http://www.ietf.org/mail-archive/web/ccamp/current/msg14997.html),
leeyoung at huawei.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg14985.html),
xsg at nict.go.jp(http://www.ietf.org/mail-archive/web/ccamp/current/msg15012.html),
giomarti at cisco.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg15000.html)

Prepration for WG last call. IPR declariations.

gregb at grotto-networking.com(...),
nick at sssup.it(...),
a.giorgetti at sssup.it(...),
guolintom at gmail.com(...),
harai at nict.go.jp(http://www.ietf.org/mail-archive/web/ccamp/current/msg14996.html),
jyf at bupt.edu.cn(...),
daniel at olddog.co.uk(http://www.ietf.org/mail-archive/web/ccamp/current/msg14997.html),
leeyoung at huawei.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg14985.html),
xsg at nict.go.jp(...),
giomarti at cisco.com(...)