Applicability of GMPLS for beyond 100 Gbit/s Optical Transport Network
draft-ietf-ccamp-gmpls-otn-b100g-applicability-15

[Ballot comment]
(revised ballot to correctly acknowledge the SECDIR reviewer; thanks to Rob Wilton for pointing it out)

Thank you to David Mandelberg for the SECDIR review.

** Section 8.  As the premise of this document appears be around applicability to [ITU-T_G709_2020], it seems that relationship should be explicitly described in the Security Considerations.  Consider:

OLD
This document analyses and reuses the protocol extensions in
  [RFC7138] and [RFC7139] without introducing any new extensions.
  Therefore, this document introduces no new security considerations to
  the existing signalling protocol and routing protocol comparing to
  [RFC7138] and [RFC7139]. 

NEW
This document analyzed the applicability of protocol extensions in [RFC7138] and [RFC7139] for use in the 2020 version of G.709 [ITU-T_G709_2020] and found that no new extensions are needed.  Therefore, this document introduced no new security considerations to the existing signaling and routing protocols beyond those already described in [RFC7138] and [RFC7139].

[Ballot comment]
As I am not an expert on GMPLS at all, I can only have high-level comments.

The draft explains in length in section 3 how OTN next generation could work. The only part that is relevant to the IETF appears to be the 1-page section 4.2 (which basically writes "all is good for now"). While I am unsure about the added value of this document (again I am *not* an expert on this topic by far), if the CCAMP WG wants to publish this document and as I trust the AD and doc shepherd, then it is of course fine.

Before publication, please fix the authors' section as it has an unusual format.

[Ballot comment]
As I am not an expert on GMPLS at all, I can only have high-level comments.

The draft explains in length in section 3 how OTN next generation could work. The only part that is relevant to the IETF appears to be the 1-page section 4.2 (which basically writes "all is good for now"). While I am unsure about the added value of this document (again I am *not* an expert on this topic by far), if the CCAMP WG wants to publish this document, then it is of course fine.

Before publication, please fix the authors' section as it has an unusual format.

[Ballot comment]
Thank you to Joe Clarke for the SECDIR review.

** Section 8.  As the premise of this document appears be around applicability to [ITU-T_G709_2020], it seems that relationship should be explicitly described in the Security Considerations.  Consider:

OLD
This document analyses and reuses the protocol extensions in
  [RFC7138] and [RFC7139] without introducing any new extensions.
  Therefore, this document introduces no new security considerations to
  the existing signalling protocol and routing protocol comparing to
  [RFC7138] and [RFC7139]. 

NEW
This document analyzed the applicability of protocol extensions in [RFC7138] and [RFC7139] for use in the 2020 version of G.709 [ITU-T_G709_2020] and found that no new extensions are needed.  Therefore, this document introduced no new security considerations to the existing signaling and routing protocols beyond those already described in [RFC7138] and [RFC7139].

Hi Authors,

The IETF LC has concluded and I didn't see any showstoppers. It does appear there are some outstanding edits to be done (in the thread between the authors following up to "Opsdir last call review of draft-ietf-ccamp-gmpls-otn-b100g-applicability-11"). I also see a Genart review was provided today, which it would probably be good to respond to (and possibly act on).

I'll wait for a revised version before scheduling this for IESG review.

Thanks,

--John

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-ccamp-gmpls-otn-b100g-applicability-11, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-10-06):

From: The IESG
To: IETF-Announce
CC: adrian@olddog.co.uk, ccamp-chairs@ietf.org, ccamp@ietf.org, draft-ietf-ccamp-gmpls-otn-b100g-applicability@ietf.org, jgs@juniper.net, oscar.gonzalezdedios@telefonica.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Applicability of GMPLS for Beyond 100G Optical Transport Network) to Informational RFC


The IESG has received a request from the Common Control and Measurement Plane
WG (ccamp) to consider the following document: - 'Applicability of GMPLS for
Beyond 100G Optical Transport Network'
  as Informational RFC

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
last-call@ietf.org mailing lists by 2022-10-06. 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 document examines the applicability of using existing GMPLS
  routing and signalling mechanisms to set up Optical Data Unit-k
  (ODUk) Label Switched Paths (LSPs) over Optical Data Unit-Cn (ODUCn)
  links as defined in the 2020 version of G.709.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-otn-b100g-applicability/



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

Document shepherd write-up for draft-ietf-ccamp-gmpls-otn-b100g-applicability

> ## Document History
>
> 1. Does the working group (WG) consensus represent the strong concurrence of a
>    few individuals, with others being silent, or did it reach broad agreement?

The document has 5 co-authors and 12 contributors which constitutes a
significant percentage of the active members of the working group. That
makes for broad consensus.

WG last call (which can be found in the archive at
https://mailarchive.ietf.org/arch/msg/ccamp/Hy114Qs06ANb36KQUX4XAQqKQzk/
attracted just one review (from the current document shepherd) and a few
emails of support from authors/contributors.

There was no objection to publication.

> 2. Was there controversy about particular points, or were there decisions where
>    the consensus was particularly rough?

None observed.

> 3. Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

> 4. For protocol documents, are there existing implementations of the contents of
>    the document? Have a significant number of potential implementers indicated
>    plans to implement? Are any existing implementations reported somewhere,
>    either in the document itself (as [RFC 7942][3] recommends) or elsewhere
>    (where)?

This is an applicability statement so cannot be implemented. However,
there are many implementations of G.709 2012 and 2016 in hardware, and
many of those vendors use the GMPLS control plane in their other
products.

No specific implementations of GMPLS for the 2020 version of G.709 have
been reported.

> ### Additional Reviews
>
> 5. Does this document need review from other IETF working groups or external
>    organizations? Have those reviews occurred?

None needed.

> 6. Describe how the document meets any required formal expert review criteria,
>    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal language.

> 7. If the document contains a YANG module

No YANG module.

> 8. Describe reviews and automated checks performed to validate sections of the
>    final version of the document written in a formal language, such as XML code,
>    BNF rules, MIB definitions, CBOR's CDDL, etc.

None applicable.

> ### Document Shepherd Checks

The document shepherd reviewed this document during working group last
call (-07) and in their role as document shepherd (-05). In each case,
the authors made updates and addressed all of the comments.

> 9. Based on the shepherd's review of the document, is it their opinion that this
>    document is needed, clearly written, complete, correctly designed, and ready
>    to be handed off to the responsible Area Director?

The document is clearly written, complete, and well structured.

It is a niche area, but the document is useful because it explains how
existing IETF technology can be applied to a newly extended dataplane.
By doing so, it saves attempts to unnecessarily extend the IETF
technology, and explains some of the potential issues that may arise
so that implementers can be aware.

The document is ready to hand off to the AD.

> 10. Several IETF Areas have assembled [lists of common issues that their
>    reviewers encounter][6]. Do any such issues remain that would merit specific
>    attention from subsequent reviews?

It would be easier to answer this question if a pointer was provided
to those lists.

No reviews or reviewers have pointed to any open issues that need
attention.

> 11. What type of RFC publication is being requested on the IETF stream (Best
>    Current Practice, Proposed Standard, Internet Standard, Informational,
>    Experimental, or Historic)? Why is this the proper type of RFC? Do all
>    Datatracker state attributes correctly reflect this intent?

This document is the product of the CCAMP WG and is presented for
publication as an Informational RFC. This is appropriate for an
applicability statement.

The status is properly indicated on the title page and in the
Datatracker.

> 12. Has the interested community confirmed that any and all appropriate IPR
>    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
>    explain why. If yes, summarize any discussion and conclusion regarding the
>    intellectual property rights (IPR) disclosures, including links to relevant
>    emails.

The WG chairs requested an IPR response from all authors and
contributors in an email to the CCAMP mailing list at the time of WG
last call.
Responses from all of the authors can be seen on the CCAMP mailing list
at https://mailarchive.ietf.org/arch/msg/ccamp/dgj7jwwY9YPxF8OJHVGS3JbVe3g/

No IPR has been disclosed, and all respondents declared no IP needed to
be disclosed.

The CCAMP mailing list was also invited to disclose any IPR at the same
time, but no responses were received.

> 13. Has each Author or Contributor confirmed their willingness to be listed as
>    such?

Well, no. But they have been listed there for a long time, and their
silence may be assumed to be consent. Note also that the IPR poll has
made all authors and contributors aware of their status on the document.

>    If the number of Authors/Editors on the front page is greater than 5,
>    please provide a justification.

It isn't.

> 14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
>    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
>    Simply running the idnits tool is not enough; please review the entire
>    guidelines document.

id-nits is clean.
xml2rfc reports two formatting warnings (width of figures) that it is able to autocorrect.
Manual check of guidance for documents reveals no issues.

> 15. Should any informative references be normative or vice-versa?

The distribution seems to be right.

> 16. List any normative references that are not freely available to anyone.

None

> 17. Are there any normative downward references (see [RFC 3967][10],
>    [BCP 97][11])? If so, list them.

None

> 18. Are there normative references to documents that are not ready for
>    advancement or are otherwise in an unclear state?

None

> 19. Will publication of this document change the status of any existing RFCs?

No

> 20. Describe the document shepherd's review of the IANA considerations section,
>    especially with regard to its consistency with the body of the document.

The document shepherd made themself coffee (it was quite late at night)
and sat down in their office. They then read the document including the
IANA considerations section, and thought about it carefully, concluding
that it was appropriate to make no requests of IANA.

>    Confirm that all aspects of the document requiring IANA assignments are
>    associated with the appropriate reservations in IANA registries.

Confirmed

>    Confirm that any referenced IANA registries have been clearly identified.

No such references

>    Confirm that each newly created IANA registry specifies its initial contents,
>    allocations procedures, and a reasonable name (see [RFC 8126][12]).

No new registries

> 21. List any new IANA registries that require Designated Expert Review for
>    future allocations. Are the instructions to the Designated Expert clear?
>    Please include suggestions of designated experts, if appropriate.

No new registries

Document shepherd write-up for draft-ietf-ccamp-gmpls-otn-b100g-applicability

> ## Document History
>
> 1. Does the working group (WG) consensus represent the strong concurrence of a
>    few individuals, with others being silent, or did it reach broad agreement?

The document has 5 co-authors and 12 contributors which constitutes a
significant percentage of the active members of the working group. That
makes for broad consensus.

WG last call (which can be found in the archive at
https://mailarchive.ietf.org/arch/msg/ccamp/Hy114Qs06ANb36KQUX4XAQqKQzk/
attracted just one review (from the current document shepherd) and a few
emails of support from authors/contributors.

There was no objection to publication.

> 2. Was there controversy about particular points, or were there decisions where
>    the consensus was particularly rough?

None observed.

> 3. Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

> 4. For protocol documents, are there existing implementations of the contents of
>    the document? Have a significant number of potential implementers indicated
>    plans to implement? Are any existing implementations reported somewhere,
>    either in the document itself (as [RFC 7942][3] recommends) or elsewhere
>    (where)?

This is an applicability statement so cannot be implemented. However,
there are many implementations of G.709 2012 and 2016 in hardware, and
many of those vendors use the GMPLS control plane in their other
products.

No specific implementations of GMPLS for the 2020 version of G.709 have
been reported.

> ### Additional Reviews
>
> 5. Does this document need review from other IETF working groups or external
>    organizations? Have those reviews occurred?

None needed.

> 6. Describe how the document meets any required formal expert review criteria,
>    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal language.

> 7. If the document contains a YANG module

No YANG module.

> 8. Describe reviews and automated checks performed to validate sections of the
>    final version of the document written in a formal language, such as XML code,
>    BNF rules, MIB definitions, CBOR's CDDL, etc.

None applicable.

> ### Document Shepherd Checks

The document shepherd reviewed this document during working group last
call (-07) and in their role as document shepherd (-05). In each case,
the authors made updates and addressed all of the comments.

> 9. Based on the shepherd's review of the document, is it their opinion that this
>    document is needed, clearly written, complete, correctly designed, and ready
>    to be handed off to the responsible Area Director?

The document is clearly written, complete, and well structured.

It is a niche area, but the document is useful because it explains how
existing IETF technology can be applied to a newly extended dataplane.
By doing so, it saves attempts to unnecessarily extend the IETF
technology, and explains some of the potential issues that may arise
so that implementers can be aware.

The document is ready to hand off to the AD.

> 10. Several IETF Areas have assembled [lists of common issues that their
>    reviewers encounter][6]. Do any such issues remain that would merit specific
>    attention from subsequent reviews?

It would be easier to answer this question if a pointer was provided
to those lists.

No reviews or reviewers have pointed to any open issues that need
attention.

> 11. What type of RFC publication is being requested on the IETF stream (Best
>    Current Practice, Proposed Standard, Internet Standard, Informational,
>    Experimental, or Historic)? Why is this the proper type of RFC? Do all
>    Datatracker state attributes correctly reflect this intent?

This document is the product of the CCAMP WG and is presented for
publication as an Informational RFC. This is appropriate for an
applicability statement.

The status is properly indicated on the title page and in the
Datatracker.

> 12. Has the interested community confirmed that any and all appropriate IPR
>    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
>    explain why. If yes, summarize any discussion and conclusion regarding the
>    intellectual property rights (IPR) disclosures, including links to relevant
>    emails.

The WG chairs requested an IPR response from all authors and
contributors in an email to the CCAMP mailing list at the time of WG
last call.
Responses from all of the authors can be seen on the CCAMP mailing list
at https://mailarchive.ietf.org/arch/msg/ccamp/dgj7jwwY9YPxF8OJHVGS3JbVe3g/

No IPR has been disclosed, and all respondents declared no IP needed to
be disclosed.

The CCAMP mailing list was also invited to disclose any IPR at the same
time, but no responses were received.

> 13. Has each Author or Contributor confirmed their willingness to be listed as
>    such?

Well, no. But they have been listed there for a long time, and their
silence may be assumed to be consent. Note also that the IPR poll has
made all authors and contributors aware of their status on the document.

>    If the number of Authors/Editors on the front page is greater than 5,
>    please provide a justification.

It isn't.

> 14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
>    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
>    Simply running the idnits tool is not enough; please review the entire
>    guidelines document.

id-nits is clean.
xml2rfc reports two formatting warnings (width of figures) that it is able to autocorrect.
Manual check of guidance for documents reveals no issues.

> 15. Should any informative references be normative or vice-versa?

The distribution seems to be right.

> 16. List any normative references that are not freely available to anyone.

None

> 17. Are there any normative downward references (see [RFC 3967][10],
>    [BCP 97][11])? If so, list them.

None

> 18. Are there normative references to documents that are not ready for
>    advancement or are otherwise in an unclear state?

None

> 19. Will publication of this document change the status of any existing RFCs?

No

> 20. Describe the document shepherd's review of the IANA considerations section,
>    especially with regard to its consistency with the body of the document.

The document shepherd made themself coffee (it was quite late at night)
and sat down in their office. They then read the document including the
IANA considerations section, and thought about it carefully, concluding
that it was appropriate to make no requests of IANA.

>    Confirm that all aspects of the document requiring IANA assignments are
>    associated with the appropriate reservations in IANA registries.

Confirmed

>    Confirm that any referenced IANA registries have been clearly identified.

No such references

>    Confirm that each newly created IANA registry specifies its initial contents,
>    allocations procedures, and a reasonable name (see [RFC 8126][12]).

No new registries

> 21. List any new IANA registries that require Designated Expert Review for
>    future allocations. Are the instructions to the Designated Expert clear?
>    Please include suggestions of designated experts, if appropriate.

No new registries

PENDING A NEW REVISION OF THE DRAFT TO ADDRESS SHEPHERD REVIEW

*** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT *** DRAFT ***

Document shepherd write-up for draft-ietf-ccamp-gmpls-otn-b100g-applicability

> ## Document History
>
> 1. Does the working group (WG) consensus represent the strong concurrence of a
>    few individuals, with others being silent, or did it reach broad agreement?

The document has 5 co-authors and 12 contributors which constitutes a
significant percentage of the active members of the working group. That
makes for broad consensus.

WG last call (which can be found in the archive at
https://mailarchive.ietf.org/arch/msg/ccamp/Hy114Qs06ANb36KQUX4XAQqKQzk/
attracted just one review (from the current document shepherd) and a few
emails of support from authors/contributors.

There was no objection to publication.

> 2. Was there controversy about particular points, or were there decisions where
>    the consensus was particularly rough?

None observed.

> 3. Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

> 4. For protocol documents, are there existing implementations of the contents of
>    the document? Have a significant number of potential implementers indicated
>    plans to implement? Are any existing implementations reported somewhere,
>    either in the document itself (as [RFC 7942][3] recommends) or elsewhere
>    (where)?

This is an applicability statement so cannot be implemented. However,
there are many implementations of G.709 2012 and 2016 in hardware, and
many of those vendors use the GMPLS control plane in their other
products.

No specific implementations of GMPLS for the 2020 version of G.709 have
been reported.

> ### Additional Reviews
>
> 5. Does this document need review from other IETF working groups or external
>    organizations? Have those reviews occurred?

None needed.

> 6. Describe how the document meets any required formal expert review criteria,
>    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal language.

> 7. If the document contains a YANG module

No YANG module.

> 8. Describe reviews and automated checks performed to validate sections of the
>    final version of the document written in a formal language, such as XML code,
>    BNF rules, MIB definitions, CBOR's CDDL, etc.

None applicable.

> ### Document Shepherd Checks

The document shepherd reviewed this document during working group last
call (-07) and in their role as document shepherd (-05). In each case,
the authors made updates and addressed all of the comments.

> 9. Based on the shepherd's review of the document, is it their opinion that this
>    document is needed, clearly written, complete, correctly designed, and ready
>    to be handed off to the responsible Area Director?

The document is clearly written, complete, and well structured.

It is a niche area, but the document is useful because it explains how
existing IETF technology can be applied to a newly extended dataplane.
By doing so, it saves attempts to unnecessarily extend the IETF
technology, and explains some of the potential issues that may arise.

The document is ready to hand off to the AD.

> 10. Several IETF Areas have assembled [lists of common issues that their
>    reviewers encounter][6]. Do any such issues remain that would merit specific
>    attention from subsequent reviews?

It would be easier to answer this question if a pointer was provided
to those lists.

No reviews or reviewers have pointed to any open issues that need
attention.

> 11. What type of RFC publication is being requested on the IETF stream (Best
>    Current Practice, Proposed Standard, Internet Standard, Informational,
>    Experimental, or Historic)? Why is this the proper type of RFC? Do all
>    Datatracker state attributes correctly reflect this intent?

This document is the product of the CCAMP WG and is presented for
publication as an Informational RFC. This is appropriate for an
applicability statement.

The status is properly indicated on the title page and in the
Datatracker.     

> 12. Has the interested community confirmed that any and all appropriate IPR
>    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
>    explain why. If yes, summarize any discussion and conclusion regarding the
>    intellectual property rights (IPR) disclosures, including links to relevant
>    emails.

The WG chairs requested an IPR response from all authors and
contributors in an email to the CCAMP mailing list at the time of WG
last call.
Responses from all of the authors can be seen on the CCAMP mailing list
at
https://mailarchive.ietf.org/arch/msg/ccamp/dgj7jwwY9YPxF8OJHVGS3JbVe3g/

No IPR has been disclosed, and all respondents declared no IP needed to
be disclosed.

The CCAMP mailing list was also invited to disclose any IPR at the same
time, but no responses were received.

> 13. Has each Author or Contributor confirmed their willingness to be listed as
>    such?

Well, no. But they have been listed there for a long time, and their
silence may be assumed to be consent. Note also that the IPR poll has
made all authors and contributors aware of their status on the document.

>    If the number of Authors/Editors on the front page is greater than 5,
>    please provide a justification.

It isn't.

> 14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
>    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
>    Simply running the idnits tool is not enough; please review the entire
>    guidelines document.

id-nits is clean.
Manual check of guidance for documents reveals no issues.

> 15. Should any informative references be normative or vice-versa?

The distribution seems to be right.

> 16. List any normative references that are not freely available to anyone.

None

> 17. Are there any normative downward references (see [RFC 3967][10],
>    [BCP 97][11])? If so, list them.

None

> 18. Are there normative references to documents that are not ready for
>    advancement or are otherwise in an unclear state?

None

> 19. Will publication of this document change the status of any existing RFCs?

No

> 20. Describe the document shepherd's review of the IANA considerations section,
>    especially with regard to its consistency with the body of the document.

The document shepherd made themself coffee (it was quite late at night)
and sat down in their office. They then read the document including the
IANA considerations section, and thought about it carefully, concluding
that it was appropriate to make no requests of IANA.

>    Confirm that all aspects of the document requiring IANA assignments are
>    associated with the appropriate reservations in IANA registries.

Confirmed

>    Confirm that any referenced IANA registries have been clearly identified.

Confirmed

>    Confirm that each newly created IANA registry specifies its initial contents,
>    allocations procedures, and a reasonable name (see [RFC 8126][12]).

Confirmed

> 21. List any new IANA registries that require Designated Expert Review for
>    future allocations. Are the instructions to the Designated Expert clear?
>    Please include suggestions of designated experts, if appropriate.

No new registries

PENDING A NEW REVISION OF THE DRAFT TO ADDRESS SHEPHERD REVIEW


Document shepherd write-up for draft-ietf-ccamp-gmpls-otn-b100g-applicability

> ## Document History
>
> 1. Does the working group (WG) consensus represent the strong concurrence of a
>    few individuals, with others being silent, or did it reach broad agreement?

The document has 5 co-authors and 12 contributors which constitutes a
significant percentage of the active members of the working group. That
makes for broad consensus.

WG last call (which can be found in the archive at
https://mailarchive.ietf.org/arch/msg/ccamp/Hy114Qs06ANb36KQUX4XAQqKQzk/
attracted just one review (from the current document shepherd) and a few
emails of support from authors/contributors.

There was no objection to publication.

> 2. Was there controversy about particular points, or were there decisions where
>    the consensus was particularly rough?

None observed.

> 3. Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

> 4. For protocol documents, are there existing implementations of the contents of
>    the document? Have a significant number of potential implementers indicated
>    plans to implement? Are any existing implementations reported somewhere,
>    either in the document itself (as [RFC 7942][3] recommends) or elsewhere
>    (where)?

This is an applicability statement so cannot be implemented. However,
there are many implementations of G.709 2012 and 2016 in hardware, and
many of those vendors use the GMPLS control plane in their other
products.

No specific implementations of GMPLS for the 2020 version of G.709 have
been reported.

> ### Additional Reviews
>
> 5. Does this document need review from other IETF working groups or external
>    organizations? Have those reviews occurred?

None needed.

> 6. Describe how the document meets any required formal expert review criteria,
>    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal language.

> 7. If the document contains a YANG module

No YANG module.

> 8. Describe reviews and automated checks performed to validate sections of the
>    final version of the document written in a formal language, such as XML code,
>    BNF rules, MIB definitions, CBOR's CDDL, etc.

None applicable.

> ### Document Shepherd Checks

The document shepherd reviewed this document during working group last
call (-07) and in their role as document shepherd (-05). In each case,
the authors made updates and addressed all of the comments.

> 9. Based on the shepherd's review of the document, is it their opinion that this
>    document is needed, clearly written, complete, correctly designed, and ready
>    to be handed off to the responsible Area Director?

The document is clearly written, complete, and well structured.

It is a niche area, but the document is useful because it explains how
existing IETF technology can be applied to a newly extended dataplane.
By doing so, it saves attempts to unnecessarily extend the IETF
technology, and explains some of the potential issues that may arise.

The document is ready to hand off to the AD.

> 10. Several IETF Areas have assembled [lists of common issues that their
>    reviewers encounter][6]. Do any such issues remain that would merit specific
>    attention from subsequent reviews?

It would be easier to answer this question if a pointer was provided
to those lists.

No reviews or reviewers have pointed to any open issues that need
attention.

> 11. What type of RFC publication is being requested on the IETF stream (Best
>    Current Practice, Proposed Standard, Internet Standard, Informational,
>    Experimental, or Historic)? Why is this the proper type of RFC? Do all
>    Datatracker state attributes correctly reflect this intent?

This document is the product of the CCAMP WG and is presented for
publication as an Informational RFC. This is appropriate for an
applicability statement.

The status is properly indicated on the title page and in the
Datatracker.     

> 12. Has the interested community confirmed that any and all appropriate IPR
>    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
>    explain why. If yes, summarize any discussion and conclusion regarding the
>    intellectual property rights (IPR) disclosures, including links to relevant
>    emails.

The WG chairs requested an IPR response from all authors and
contributors in an email to the CCAMP mailing list at the time of WG
last call.
Responses from all of the authors can be seen on the CCAMP mailing list
at
https://mailarchive.ietf.org/arch/msg/ccamp/dgj7jwwY9YPxF8OJHVGS3JbVe3g/

No IPR has been disclosed, and all respondents declared no IP needed to
be disclosed.

The CCAMP mailing list was also invited to disclose any IPR at the same
time, but no responses were received.

> 13. Has each Author or Contributor confirmed their willingness to be listed as
>    such?

Well, no. But they have been listed there for a long time, and their
silence may be assumed to be consent. Note also that the IPR poll has
made all authors and contributors aware of their status on the document.

>    If the number of Authors/Editors on the front page is greater than 5,
>    please provide a justification.

It isn't.

> 14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
>    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
>    Simply running the idnits tool is not enough; please review the entire
>    guidelines document.

id-nits is clean.
Manual check of guidance for documents reveals no issues.

> 15. Should any informative references be normative or vice-versa?

The distribution seems to be right.

> 16. List any normative references that are not freely available to anyone.

None

> 17. Are there any normative downward references (see [RFC 3967][10],
>    [BCP 97][11])? If so, list them.

None

> 18. Are there normative references to documents that are not ready for
>    advancement or are otherwise in an unclear state?

None

> 19. Will publication of this document change the status of any existing RFCs?

No

> 20. Describe the document shepherd's review of the IANA considerations section,
>    especially with regard to its consistency with the body of the document.

The document shepherd made themself coffee (it was quite late at night)
and sat down in their office. They then read the document including the
IANA considerations section, and thought about it carefully, concluding
that it was appropriate to make no requests of IANA.

>    Confirm that all aspects of the document requiring IANA assignments are
>    associated with the appropriate reservations in IANA registries.

Confirmed

>    Confirm that any referenced IANA registries have been clearly identified.

Confirmed

>    Confirm that each newly created IANA registry specifies its initial contents,
>    allocations procedures, and a reasonable name (see [RFC 8126][12]).

Confirmed

> 21. List any new IANA registries that require Designated Expert Review for
>    future allocations. Are the instructions to the Designated Expert clear?
>    Please include suggestions of designated experts, if appropriate.

No new registries

IPR poll (Daniele) https://mailarchive.ietf.org/arch/msg/ccamp/dgj7jwwY9YPxF8OJHVGS3JbVe3g/

AUTHORS

Qilei Wang wang.qilei@zte.com.cn https://mailarchive.ietf.org/arch/msg/ccamp/6trKgY5QmyAVvWYTudjRbyNQ2kI/
Radha Valiveti rvaliveti@infinera.com https://mailarchive.ietf.org/arch/msg/ccamp/78NkT9TNOT73J7PlG6eC_848dWU/
Haomian Zheng zhenghaomian@huawei.com https://mailarchive.ietf.org/arch/msg/ccamp/p1Qz-y6Po9q6XnDJRSjwK4aqgMw/
Huub van Helvoort huubatwork@gmail.com https://mailarchive.ietf.org/arch/msg/ccamp/-CUl0cWtDd6X9RktvYatw7Jo60k/
Sergio Belotti sergio.belotti@nokia.com https://mailarchive.ietf.org/arch/msg/ccamp/xJt5C5sqdP2gy5Flmfc08TRgEf8/
Iftekhar Hussain IHussain@infinera.com https://mailarchive.ietf.org/arch/msg/ccamp/Cl1L-JvIWpSkltnRaNsniNCxfEE/
Daniele Ceccarelli daniele.ceccarelli@ericsson.com https://mailarchive.ietf.org/arch/msg/ccamp/KnjewYzY9O7JeIQuf9zzk_jji3E/
Rajan Rao rrao@infinera.com https://mailarchive.ietf.org/arch/msg/ccamp/7Q-allGKfNL973VOIrjqmJkEZDU/
Fatai Zhang zhangfatai@huawei.com https://mailarchive.ietf.org/arch/msg/ccamp/zdxKYH5Xug-7heXzOMvE_i7XEDI/
Italo Busi italo.busi@huawei.com https://mailarchive.ietf.org/arch/msg/ccamp/YT3s7in0iGP-1a8ugGQQ6xYT3mk/
Dieter Beller Dieter.Beller@nokia.com https://mailarchive.ietf.org/arch/msg/ccamp/MqWlx6H9hzy82dXB5jNqOBa1tNY/
Yuanbin Zhang zhang.yuanbin@zte.com.cn https://mailarchive.ietf.org/arch/msg/ccamp/9E_p9N3s7oxHRmPv1-ORVESUU3k/
Zafar Ali zali@cisco.com https://mailarchive.ietf.org/arch/msg/ccamp/6VzmP6cWfe3J70jsS-zXCPBKvTA/
Daniel King d.king@lancaster.ac.uk https://mailarchive.ietf.org/arch/msg/ccamp/737YDEq_RIVnMzUuOzCbCfBV6jg/
Manoj Kumar manojk2@cisco.com https://mailarchive.ietf.org/arch/msg/ccamp/v88KR_wV-JJgmLkgvH1S5iDru34/
Antonello Bonfanti abonfant@cisco.com https://mailarchive.ietf.org/arch/msg/ccamp/avzZmKV1C4FJtyGBQ6Z-qMh7gIs/
Yuji Tochio tochio@fujitsu.com https://mailarchive.ietf.org/arch/msg/ccamp/QUoWa9yFsZr3xliCxvxEvgZAxP8/