Received changes through RFC Editor sync (changed abstract to 'A Wavelength Switched Optical Network (WSON) requires certain key information fields be made available to facilitate path computation and the establishment of Label Switched Paths (LSPs). The information model described in "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks" (RFC 7446) shows what information is required at specific points in the WSON. Part of the WSON information model contains aspects that may be of general applicability to other technologies, while other parts are specific to WSONs.

This document provides efficient, protocol-agnostic encodings for the WSON-specific information fields. It is intended that protocol- specific documents will reference this memo to describe how information is carried for specific uses. Such encodings can be used to extend GMPLS signaling and routing protocols. In addition, these encodings could be used by other mechanisms to convey this same information to a Path Computation Element (PCE).')

IESG/Authors/WG Chairs:

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

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

IANA has a question about the action requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there is a single action that IANA must complete.

This document requests that a new registry be created.

IANA QUESTION -> Where should this new registry be located? Is it a néw registry on the IANA Matrix or is it a subregistry of an existing registry? If it is a subregistry of an existing registry, in which registry will it be contained? Is it to be a subregistry of the GMPLS Signaling Parameters registry?

The new registry is to be called the Types for subfields of WSON Resource Block Information registry. The new registry will be maintained via Standards Action as defined by RFC 5226.

There are initial values in the new registry as follows:

Value Length Sub-TLV Type Reference

0 Reserved
1 variable Optical Interface Class List [ RFC-to-be ]
2 variable Acceptable Client Signal List [ RFC-to-be ]
3 variable Input Bit Rate List [ RFC-to-be ]
4 variable Processing Capability List [ RFC-to-be ]
5-65535 Unassigned

IANA understands that this action is the only one 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 <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <ccamp@ietf.org>
Reply-To: ietf@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-ccamp-rwa-wson-encode-27.txt> (Routing and Wavelength Assignment Information Encoding 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:
- 'Routing and Wavelength Assignment Information Encoding for Wavelength
  Switched Optical Networks'
  <draft-ietf-ccamp-rwa-wson-encode-27.txt> 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-02-19. 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

  A wavelength switched optical network (WSON) requires that certain
  key information elements are made available to facilitate path
  computation and the establishment of label switching paths (LSPs).
  The information model described in "Routing and Wavelength
  Assignment Information for Wavelength Switched Optical Networks"
  shows what information is required at specific points in the WSON.
  Part of the WSON information model contains aspects that may be of
  general applicability to other technologies, while other parts are
  specific to WSONs.

  This document provides efficient, protocol-agnostic encodings for
  the WSON specific information elements. It is intended that
  protocol-specific documents will reference this memo to describe how
  information is carried for specific uses. Such encodings can be used
  to extend GMPLS signaling and routing protocols. In addition these
  encodings could be used by other mechanisms to convey this same
  information to a path computation element (PCE).

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

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

No IPR declarations have been submitted directly on this I-D.

Write up for draft-ietf-ccamp-rwa-wson-encode

> 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 encodings (wire formats) for use in routing and
signaling protocols.

> 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 document provides efficient, protocol-agnostic encodings for
  the WSON specific information elements. It is intended that
  protocol-specific documents will reference this memo to describe how
  information is carried for specific uses. Such encodings can be used
  to extend GMPLS signaling and routing protocols. In addition these
  encodings could be used by other mechanisms to convey this same
  information to a path computation element (PCE).

> 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.

A late discussion about the inclusion of vendor-specific information
went back to the WG list and resulted in the removal of such TLVs
until the ITU-T has completed its work in this area.

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

This document provides background and an approach to extending
exiting RFCs for which there are implementations, but does not
itself define any protocol mechanisms.  The existing RFCs include
RFC3471, RFC3473, RFC4202, RFC4203.  This work is based on RFC6163.

> 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. (But
didn't offer any input.)

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

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

None.

> (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).

  This document introduces a new registry for GMPLS routing parameters
  for WSON encoding. This new IANA registry will be created to make
  the assignment of a new type and new values for the new "GMPLS
  Routing Parameters for WSON.

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

One new "GMPLS Routing Parameters for WSON" registry is defined.  Types
are to be assigned via Standards Action as defined in [RFC5226].

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

N/A.

AD review
======
Hello,

I've now done my AD review of this document. I am rather regretting
starting the IETF last call for draft-ietf-ccamp-general-constraint-
encode on which this document depends because it seems that this
document introduces WSON-specific encodings (all of those before
Section 4) that should/could have been made generic. In fact, I
thought the point of the general encodings document was to produce
protocol objects that could be used by technology-specific documents
like this one.

If you can respond to my comments below, we can work out whether the
general encodings document needs to be brought back for more work.

Thanks for your efforts with this.

Adrian

===========

Abstract

  while other parts are fairly specific to WSONs.

They are either specific or they are not. I think you need
s/fairly specific/specific/

---

Shouldn't the Introduction include a discussion of and reference to
[Gen-encode]?

---

The Introduction has

  This document provides efficient encodings

and

  Note that since these encodings are relatively efficient

Which are they? And relative to what?

---

Section 1.1 has

  Refer to Section 5 of [Gen-Encode] for the terminology of Resources,
  Resources Blocks, and Resource Pool.

I think you mean [RWA-Info]. That would also make [RWA-Info] a normative
reference which seems correct anyway.

---

Section 1.1 makes RFC 6163 a normative reference.

---

Section 2.1 seems somewhere between a copy of and a modification of
the Link Set Field in 2.3 of [Gen-Encode].

Some clarification would be useful. If this is different, why is it not
using one of the generic encodings applied in a specific way? If it is
the same, you should probably just reference the encoding in
[Gen-Encode] and describe here how the fields are used, but if you
insist in re-drawing the figure it should be aligned with the figure in
[Gen-Encode].

---

Section 2.1

  The RB identifier represents the ID of the resource block which is a
  32 bit integer.

You might note that the scope of the RB identifier is local to the node
on which it is applied although that node may choose to use a globally
known encoding such as from RFC 6205.

I assume that flexi-grid is out of scope for WSON. If it is not, then
you need to think further about your 32 bit identifiers.

---

Section 3.1

Why isn't the Resource Accessibility Field expressed in terms of the
use of a generic Connectivity Matrix Field from section 2.1 of
[Gen-Encode]? I thought the whole point of [Gen-Encode] was to derive
application agnostic encodings that could be used without modification
(but with applicability notes) by specific technologies.

---

Section 3.2

I looked for the equivalent of the Resource Wavelength Constraints
Field in [Gen-Encode]. I understand that Input Wavelength Constraints
Field and Output Wavelength Constraints Field are encoded using the
generic Label Set of  [Gen-Encode], but I thought that the whole concept
of Resource Constraints would be generic.

---

Section 3.3

As with the previous section I don't see anything that is WSON-specific
in the concept of the 3.3. Resource Block Pool State (RBPoolState) Field
and I wondered why [Gen-Encode] doesn't have anything to cover this.

---

Section 3.3

  Where Action = 0 denotes a list of 16 bit integers and Action = 1
  denotes a bit map. In both cases the elements of the RB Set field
  are in a one-to-one correspondence with the values in the usage RB
  usage state area.

This is not clear. I think the Action field is explaining how the
RB Usage State field is encoded.
- Not sure why you call it "Action"
- Would be good if you could make it clear that "16 bit integers"
  or "bit map" apply to the RB Usage State field.

But...

  RB#i State (16 bits, unsigned integer): indicates Resource Block #i
  is in use or available.

- You might say what value of the 16 bit unsigned integer indicates in
  use and what value indicates available.
- You should explain to me why a list of 16 bit integers to encode a
  set of Booleans is in anyway efficient or appropriate.

It is *really* hard to parse from this section that the state applies
to the whole RB when Action is 0, but applies to the elements of the RBs
when Action is 1. At least, that is what I think I parsed from the text
although I also found text in the section that convinced me you meant
something else.

In short, this section is not clear!

---

Why don't Sections 3.4 and 4 have a B-bit like that in 3.2?

---

Sections 3.4 and 4 should list the allowed settings of I and O
(presumably: 01, 10, 11). Cf. Section 3.2.

---

Section 4

How do I know the length of the ResourceBlockInfo field? I need to know
this to decide whether to try to parse the next bytes as another
Optional subfield. I *do* when I reach the end of one Optional subfield,
but I don't know whether another follows.

Possibly you intend the object that includes a ResourceBlockInfo field
to provide the length information, but other fields defined in this
document do include lengths or enough information to deduce the lengths.

---

Section 4.1

  The following I and E combination are defined:

s/E/O/

---

Section 4.1

          1: [ITU-G.698.1] application code.

          2: [ITU-G.698.2] application code.

          3: [ITU-G.959.1] application code.

          4: [ITU-G.695] application code.

You should use the same format as in the references section. E.g.,
[G.959.1].

Do you mean 698 or 694? You have references for 694.1 and 694.2, but
not 698.1 or 698.2. But 694.1 does not seem to include any "application
codes" - they're in 698.1 and 698.2.

Each of the subsections 4.1.1-4.1.4 should include a citations.

---

Section 4.1
How do I interpret a Vendor-Specific Application Code? Is there an OUI
I'm missing?

---

I discussed sections 4.1.1-4.1.4 with the authors and the WG chairs and
have asked the chairs to send a liaison to ITU-T Q6/15 asking them to
cast an eye over the text of these sections.

---

4.1.1

  Where (values between parenthesis refer to ITU defined values as
  reported above):

Please remove the parentheses from this sentence.

---

4.1.1 and 4.1.2

      An Optional F can be added indicating a FEC Encoding.

      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |B|  D  |S|  c  |  W  |  y  |  t  |  z  |  v  |  F  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          reserved                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        F (suffix): = 0 reserved, = 1 Fec Encoding

      Values not mentioned here are not allowed in this application
  code

If F is optional but only one value is allowed (viz. 1) how do I opt to
not indicate a FEC Encoding?

---

4.1.1 and 4.1.2

Your definition of parameter c makes RFC 6205 a normative reference.
                                                                              .
I think you could usefully point with more precision to Figure 2 in
Section 3.2 of RFC 6205.

However, I wonder whether you want to allow new values that may be added
to the IANA registry created by Section 5.2 of RFC 6205

---

4.1.3 and 4.1.4

        n: maximum number of channels (10 bits, up to 1024 channels)

Hmmm, 2^10 is 1024, but 10 bits can only encode 1023 unless you say that
n=0 is not valid and so n is actually max channels minus one.

---

4.4

  The processing capability list field is then given by:

      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Reserved          |        Processing Cap ID      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Possible additional capability parameters depending upon    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :  the processing ID                                          :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  When the processing Cap ID is "regeneration capability", the

I don't believe you have told me how to encode "regeneration
capability" into the Processing Cap ID field. Possibly you mean that the
numbered list above is intended to define the settings of this field.
                                           
If so then:
- say so
- explain that "Fault and performance monitoring" and "Vendor Specific
  capability" have no additional capability parameters
- probably remove the note about "Fault and performance monitoring" and
  "vendor specific capability" because if it isn't here it is, of
  course, for future study.

---

4.4

  Note that when the capability of regenerator is indicated to be
  Selective Regeneration Pools, regeneration pool properties such as
  input and output restrictions and availability need to be specified.
  The code point for this is subject to further study.

I think you mean to replace that final line with...

  These properties will be encoded in the capabilities field starting
  with the bits marked Reserved in the figure.  An additional
  specification describing the encoding of these parameters is required
  before the value C=2 can be used.

---

Section 6

In Section 6 and 6.1 you appear to be creating a new top-level registry
called "GMPLS Routing Parameters for WSON" with a sub-registry called
"Types for subfields of WSON Resource Block Information".

It's a shame to create a whole new top-level registry. I suppose you
think that this information will only ever be used in routing and
never in signaling. Probably right, in which case you are good to go,
although your text could be clearer.

---

Section A.3 is using some form of BNF to represent information.

This is probably RBNF from RFC 5511. Anyway, you need to give a
reference so people can read it.

It would be nice to lay the BNF out on the page in a more readable way.

Write up for draft-ietf-ccamp-rwa-wson-encode

> 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 encodings (wire formats) for use in routing and
signaling protocols.

> 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 document provides efficient, protocol-agnostic encodings for
  the WSON specific information elements. It is intended that
  protocol-specific documents will reference this memo to describe how
  information is carried for specific uses. Such encodings can be used
  to extend GMPLS signaling and routing protocols. In addition these
  encodings could be used by other mechanisms to convey this same
  information to a path computation element (PCE).

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

This document provides background and an approach to extending
exiting RFCs for which there are implementations, but does not
itself define any protocol mechanisms.  The existing RFCs include
RFC3471, RFC3473, RFC4202, RFC4203.  This work is based on RFC6163.

> 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. (But
didn't offer any input.)

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

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

None.

> (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).

  This document introduces a new registry for GMPLS routing parameters
  for WSON encoding. This new IANA registry will be created to make
  the assignment of a new type and new values for the new "GMPLS
  Routing Parameters for WSON.

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

One new "GMPLS Routing Parameters for WSON" registry is defined.  Types
are to be assigned via Standards Action as defined in [RFC5226].

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

N/A.

IPR declarations at September 27th 2013:

-All received
ggalimbe at cisco.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg15320.html)
imajuku.wataru at lab.ntt.co.jp(http://www.ietf.org/mail-archive/web/ccamp/current/msg15305.html)
hanjianrui at huawei.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg15314.html)

IPR declarations at September 16th 2013:

-Still missing:
ggalimbe at cisco.com(...)
imajuku.wataru at lab.ntt.co.jp(...)
hanjianrui at huawei.com(...)

- Received:
anders.gavler at acreo.se (http://www.ietf.org/mail-archive/web/ccamp/current/msg15090.html),
jonas.martensson at acreo.se(http://www.ietf.org/mail-archive/web/ccamp/current/msg15094.html)
gregb at grotto-networking.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg15254.html)
pierre.peloso at alcatel-lucent.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg15259.html)

IPR declarations at August 12th 2013:

-Still missing:
pierre.peloso at alcatel-lucent.com(...)
ggalimbe at cisco.com(...)
imajuku.wataru at lab.ntt.co.jp(...)
hanjianrui at huawei.com(...)

- Received:
anders.gavler at acreo.se (http://www.ietf.org/mail-archive/web/ccamp/current/msg15090.html),
jonas.martensson at acreo.se(http://www.ietf.org/mail-archive/web/ccamp/current/msg15094.html)
gregb at grotto-networking.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg15109.html)

Prepration for WG last call.

IPR declariations.

diego.caviglia at ericsson.com (http://www.ietf.org/mail-archive/web/ccamp/current/msg15003.html) anders.gavler at acreo.se (...),
jonas.martensson at acreo.se(...),
i-nishioka at cb.jp.nec.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg15010.html),
pierre.peloso at alcatel-lucent.com(...)
cyril.margaria at nsn.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg15014.html)
giomarti at cisco.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg15001.html)
ggalimbe at cisco.com(...)
lyong at ciena.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg15015.html)
daniele.ceccarelli at ericsson.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg14998.html) gregb at grotto-networking.com(...)
leeyoung at huawei.com (http://www.ietf.org/mail-archive/web/ccamp/current/msg14987.html)
danli at huawei.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg14994.html),
imajuku.wataru at lab.ntt.co.jp(...)
hanjianrui at huawei.com(...)

Prepration for WG last call.

IPR declariations.
diego.caviglia at ericsson.com (http://www.ietf.org/mail-archive/web/ccamp/current/msg15003.html)
anders.gavler at acreo.se (...),
jonas.martensson at acreo.se(...),
i-nishioka at cb.jp.nec.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg15010.html),
pierre.peloso at alcatel-lucent.com(...)
cyril.margaria at nsn.com(...)
giomarti at cisco.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg15001.html)
ggalimbe at cisco.com(...)
lyong at ciena.com(...)
daniele.ceccarelli at ericsson.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg14998.html)
gregb at grotto-networking.com(...)
leeyoung at huawei.com (http://www.ietf.org/mail-archive/web/ccamp/current/msg14987.html)
danli at huawei.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg14994.html),
imajuku.wataru at lab.ntt.co.jp(...)
hanjianrui at huawei.com(...)

Prepration for WG last call. IPR declariations.

diego.caviglia at ericsson.com (...)
anders.gavler at acreo.se (...),
jonas.martensson at acreo.se(...),
i-nishioka at cb.jp.nec.com(...),
pierre.peloso at alcatel-lucent.com(...)
cyril.margaria at nsn.com(...)
giomarti at cisco.com(...)
ggalimbe at cisco.com(...)
lyong at ciena.com(...)
daniele.ceccarelli at ericsson.com(...)
gregb at grotto-networking.com(...)
leeyoung at huawei.com (http://www.ietf.org/mail-archive/web/ccamp/current/msg14987.html)
danli at huawei.com(http://www.ietf.org/mail-archive/web/ccamp/current/msg14994.html),
imajuku.wataru at lab.ntt.co.jp(...)
hanjianrui at huawei.com(...)