Skip to main content

Updates for PCEPS: TLS Connection Establishment Restrictions
draft-ietf-pce-pceps-tls13-04

Revision differences

Document history

Date Rev. By Action
2024-01-26
04 Gunter Van de Velde Request closed, assignment withdrawn: Jouni Korhonen Last Call OPSDIR review
2024-01-26
04 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue
2024-01-12
04 Tero Kivinen Closed request for Early review by SECDIR with state 'Overtaken by Events'
2024-01-12
04 Tero Kivinen Assignment of request for Early review by SECDIR to Loganaden Velvindron was marked no-response
2024-01-09
04 (System) IANA Action state changed to No IANA Actions from In Progress
2024-01-09
04 (System) RFC Editor state changed to MISSREF
2024-01-09
04 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2024-01-09
04 (System) Announcement was received by RFC Editor
2024-01-09
04 (System) IANA Action state changed to In Progress
2024-01-09
04 (System) Removed all action holders (IESG state changed)
2024-01-09
04 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2024-01-09
04 Cindy Morgan IESG has approved the document
2024-01-09
04 Cindy Morgan Closed "Approve" ballot
2024-01-09
04 Cindy Morgan Ballot approval text was generated
2024-01-09
04 John Scudder Thanks for all your work!
2024-01-09
04 John Scudder IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2024-01-09
04 (System) Changed action holders to John Scudder (IESG state changed)
2024-01-09
04 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-01-09
04 Dhruv Dhody New version available: draft-ietf-pce-pceps-tls13-04.txt
2024-01-09
04 Sean Turner New version approved
2024-01-09
04 (System) Request for posting confirmation emailed to previous authors: Dhruv Dhody , Russ Housley , Sean Turner
2024-01-09
04 Dhruv Dhody Uploaded new revision
2024-01-08
03 (System) Changed action holders to Dhruv Dhody, Sean Turner, Russ Housley (IESG state changed)
2024-01-08
03 John Scudder IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::AD Followup
2024-01-04
03 Jenny Bui IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation
2024-01-03
03 Murray Kucherawy
[Ballot comment]
Further to Eric's comment, I'm completely confused by question #4 of the shepherd writeup.  While the document claims there are no implementations known, …
[Ballot comment]
Further to Eric's comment, I'm completely confused by question #4 of the shepherd writeup.  While the document claims there are no implementations known, the shepherd writeup says there's at least one (and it was easy), and makes another "Yes" remark that I don't understand.

Forwarding a comment from Orie Steele, incoming ART Area Director:

Noting the comment on 0-RTT / early data regarding secrecy, and the comment on https://datatracker.ietf.org/doc/html/rfc8253#section-3.4

*  Negotiation of a ciphersuite providing for confidentiality is  RECOMMENDED.

I'm not an expert on PCEPS, but I wonder why the need for the note at all given PCEPs only recommends confidentiality, and the requirement above states early data is forbidden.
2024-01-03
03 Murray Kucherawy Ballot comment text updated for Murray Kucherawy
2024-01-03
03 Murray Kucherawy
[Ballot comment]
Further to Eric's comment, I'm completely confused by question #4 of the shepherd writeup.  While the document claims there are no implementations known, …
[Ballot comment]
Further to Eric's comment, I'm completely confused by question #4 of the shepherd writeup.  While the document claims there are no implementations known, the shepherd writeup says there's at least one (and it was easy), and makes another "Yes" remark that I don't understand.
2024-01-03
03 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2024-01-03
03 Andrew Alston [Ballot Position Update] New position, No Objection, has been recorded for Andrew Alston
2024-01-03
03 Paul Wouters
[Ballot comment]
      Implementations that support multiple versions of the TLS protocol MUST prefer to negotiate the latest version of the TLS protocol. …
[Ballot comment]
      Implementations that support multiple versions of the TLS protocol MUST prefer to negotiate the latest version of the TLS protocol.

I'm a little confused why this needs to be stated as an update, as this is a general requirement of TLS (or any versioned protocol really)

It might be useful to point to https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.1 that deals with how to negotiate allowing TLS 1.2 when also supporting and preferring TLS 1.3.
2024-01-03
03 Paul Wouters [Ballot Position Update] New position, Yes, has been recorded for Paul Wouters
2024-01-03
03 Jim Guichard [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard
2024-01-02
03 Erik Kline [Ballot Position Update] New position, Yes, has been recorded for Erik Kline
2024-01-02
03 Martin Duke [Ballot Position Update] New position, Yes, has been recorded for Martin Duke
2024-01-02
03 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2024-01-02
03 Éric Vyncke
[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-pce-pceps-tls13-03

Thank you for the work put into this document. It was an easy and simple …
[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-pce-pceps-tls13-03

Thank you for the work put into this document. It was an easy and simple read for my first document review in 2024!

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Andrew Stone for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Section 1

Is it a `Editor's Note:` or a "Note to the IESG" or a "Note to the RFC Editor" ?

## Section 3

`MUST prefer to negotiate the latest version` is of course the preferred behavior for the initiator, but should the document clearly specify that the responser "MUST select the latest version" ? (please bear with me as English is not my primary language).

## Section 6

I wonder about the usefulness of an implementation section having `there are no known implementations of this mechanism.`
2024-01-02
03 Éric Vyncke Ballot comment text updated for Éric Vyncke
2024-01-02
03 Éric Vyncke
[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-avtcore-rtp-scip-05

Thank you for the work put into this document. It was an easy and simple …
[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-avtcore-rtp-scip-05

Thank you for the work put into this document. It was an easy and simple read for my first document review in 2024!

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Andrew Stone for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Section 1

Is it a `Editor's Note:` or a "Note to the IESG" or a "Note to the RFC Editor" ?

## Section 3

`MUST prefer to negotiate the latest version` is of course the preferred behavior for the initiator, but should the document clearly specify that the responser "MUST select the latest version" ? (please bear with me as English is not my primary language).

## Section 6

I wonder about the usefulness of an implementation section having `there are no known implementations of this mechanism.`
2024-01-02
03 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2024-01-02
03 Robert Wilton [Ballot comment]
Thank you for this document.
2024-01-02
03 Robert Wilton [Ballot Position Update] New position, Yes, has been recorded for Robert Wilton
2023-12-26
03 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2023-12-19
03 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2023-12-19
03 Dhruv Dhody New version available: draft-ietf-pce-pceps-tls13-03.txt
2023-12-19
03 Sean Turner New version approved
2023-12-19
03 (System) Request for posting confirmation emailed to previous authors: Dhruv Dhody , Russ Housley , Sean Turner
2023-12-19
03 Dhruv Dhody Uploaded new revision
2023-12-19
02 Cindy Morgan Placed on agenda for telechat - 2024-01-04
2023-12-19
02 John Scudder Ballot has been issued
2023-12-19
02 John Scudder [Ballot Position Update] New position, Yes, has been recorded for John Scudder
2023-12-19
02 John Scudder Created "Approve" ballot
2023-12-19
02 John Scudder IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2023-12-19
02 John Scudder Ballot writeup was changed
2023-12-19
02 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2023-12-12
02 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Not OK
2023-12-11
02 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2023-12-11
02 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-pce-pceps-tls13-02, which is currently in Last Call, and has a question about a …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-pce-pceps-tls13-02, which is currently in Last Call, and has a question about a comment in this document:

Section 1 of the current draft has an editor's note that says: "Editor's Note: The reference to [I-D.ietf-tls-rfc8446bis] could be changed to RFC 8446 incase the progress of the bis draft is slower than the progression of this document."

IANA Question --> What, if any, action should IANA take here; or, is this a note to the RFC Editor?

Other than this question, IANA understands that, upon approval of this document, there are no IANA Actions that need completion.

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,

David Dong
IANA Services Sr. Specialist
2023-12-08
02 Christer Holmberg Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Christer Holmberg. Sent review to list.
2023-12-08
02 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jouni Korhonen
2023-12-07
02 Jean Mahoney Request for Last Call review by GENART is assigned to Christer Holmberg
2023-12-05
02 Cindy Morgan IANA Review state changed to IANA - Review Needed
2023-12-05
02 Cindy Morgan
The following Last Call announcement was sent out (ends 2023-12-19):

From: The IESG
To: IETF-Announce
CC: andrew.stone@nokia.com, draft-ietf-pce-pceps-tls13@ietf.org, jgs@juniper.net, pce-chairs@ietf.org, pce@ietf.org …
The following Last Call announcement was sent out (ends 2023-12-19):

From: The IESG
To: IETF-Announce
CC: andrew.stone@nokia.com, draft-ietf-pce-pceps-tls13@ietf.org, jgs@juniper.net, pce-chairs@ietf.org, pce@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Updates for PCEPS: TLS Connection Establishment Restrictions) to Proposed Standard


The IESG has received a request from the Path Computation Element WG (pce) to
consider the following document: - 'Updates for PCEPS: TLS Connection
Establishment Restrictions'
  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
last-call@ietf.org mailing lists by 2023-12-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


  Section 3.4 of RFC 8253 specifies TLS connection establishment
  restrictions for PCEPS; PCEPS refers to usage of TLS to provide a
  secure transport for PCEP (Path Computation Element Communication
  Protocol).  This document adds restrictions to specify what PCEPS
  implementations do if a PCEPS supports more than one version of the
  TLS protocol and to restrict the use of TLS 1.3’s early data.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pce-pceps-tls13/



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


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-tls-rfc8446bis: The Transport Layer Security (TLS) Protocol Version 1.3 (None - Internet Engineering Task Force (IETF))



2023-12-05
02 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2023-12-05
02 John Scudder Last call was requested
2023-12-05
02 John Scudder Last call announcement was generated
2023-12-05
02 John Scudder Ballot approval text was generated
2023-12-05
02 John Scudder Ballot writeup was generated
2023-12-05
02 John Scudder IESG state changed to Last Call Requested from AD Evaluation
2023-12-05
02 (System) Changed action holders to John Scudder (IESG state changed)
2023-12-05
02 John Scudder IESG state changed to AD Evaluation from Publication Requested
2023-11-27
02 Julien Meuric
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 …
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?

-> A few individuals with others being silent.

-> General broad agreement without much contention during sessions but generally quiet on list. During WG sessions polling to expedite document was well received.

-> **Edit Nov 20th from -02** from comments received during WGLC ([05, [06], the document was re-focused and its content reduced further to scope the intended update purpose (-02). The intent of the updates and the specific update text is now more specific and clear to it's purpose.

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

-> No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize 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.)

-> 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 recommends) or elsewhere
(where)?

-> Yes, document describes allowing use of TLS 1.3 with PCEP (as an update to TLS 1.2).

-> Yes, including one WG member indicated implementation was straight forward[1].

-> No implementation section in the document.

Additional Reviews
5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

-> Yes, the document makes direct references and use of TLS 1.3 from RFC8446 and the potential RFC8446bis. Early security review request is being initiated by PCE chairs [2].


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.

-> Not applicable

7. If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in RFC 8342?

-> Not applicable

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.

-> Not applicable

Document Shepherd Checks
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?

- needed -> yes.

- clearly written -> yes.

- complete -> yes, with caveat that it is still open to decide whether this document will have normative reference to rfc8446 OR ietf-tls-rfc8446bis. The decision on such is open depending on timelines of each independent document. This does not fundamentally change the document.

- correctly designed -> yes.

- ready to be handed off to the responsible Area Director? -> yes


10. Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

-> Not applicable.

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?

-> Standards Track, as an update to RFC 8253.

-> Yes, this is proper public stream as it's an update to an existing standard stream document.

-> Yes, Datatracker state attributes reflect intent.

12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

-> Yes. IPR disclosure was requested during WG adoption and WGLC, see [3] and [4].

13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

-> Yes.

-> 3 authors.

14. Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

-> ID nits warns on RFC 5246 since it's been replaced by RFC8446. Both of these are references in the document and the usage in referencing RFC 5245 is applicable as this document provides the update transitions required to go from RFC5246 to RFC8446 in the context of PCEP.


15. Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.

-> No.

16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?

-> Not applicable.

17. Are there any normative downward references (see RFC 3967 and BCP
97
) that are not already listed in the DOWNREF registry? If so,
list them.

-> No.


18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

-> The document references ietf-tls-rfc8446bis which is in a similar state as this document at the time of reading. The document contains an editor note that indicates the RFC editor may change the reference to RFC8446. The content in the document remains compliant with RFC8446.

19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

-> The document updates RFC 8253.

-> Yes they are listed on title page and discussed in introduction.

20. 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 aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).

-> There are no IANA considerations. This is consistent with the body of the document as there are no codepoints or registries being defined in the document.

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.

-> Not applicable.


Answer References:

[1] https://mailarchive.ietf.org/arch/msg/pce/dLdcUan2psssBUgzCtXPluEr_ok/
[2] https://mailarchive.ietf.org/arch/msg/pce/9tMlNe6CoqiCOn2wfzJd04hOpWg/
[3] https://mailarchive.ietf.org/arch/msg/pce/mwiRdG4YoBTRfqfNsM05OXwrFss/
[4] https://mailarchive.ietf.org/arch/msg/pce/nJK2oV_X9OdHMrE5YqAaVD0fyO4/
[5] https://mailarchive.ietf.org/arch/msg/pce/SCyLmChul8v27cf-C7EdwNqxfoQ/
[6] https://mailarchive.ietf.org/arch/msg/pce/JmSlc7PT-ms120LXfrldyenG7Bc/


Question References:

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

2023-11-27
02 Julien Meuric Responsible AD changed to John Scudder
2023-11-27
02 Julien Meuric IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead
2023-11-27
02 Julien Meuric IESG state changed to Publication Requested from I-D Exists
2023-11-27
02 Julien Meuric Document is now in IESG state Publication Requested
2023-11-24
02 Julien Meuric IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2023-11-20
02 Andrew Stone
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 …
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?

-> A few individuals with others being silent.

-> General broad agreement without much contention during sessions but generally quiet on list. During WG sessions polling to expedite document was well received.

-> **Edit Nov 20th from -02** from comments received during WGLC ([05, [06], the document was re-focused and its content reduced further to scope the intended update purpose (-02). The intent of the updates and the specific update text is now more specific and clear to it's purpose.

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

-> No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize 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.)

-> 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 recommends) or elsewhere
(where)?

-> Yes, document describes allowing use of TLS 1.3 with PCEP (as an update to TLS 1.2).

-> Yes, including one WG member indicated implementation was straight forward[1].

-> No implementation section in the document.

Additional Reviews
5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

-> Yes, the document makes direct references and use of TLS 1.3 from RFC8446 and the potential RFC8446bis. Early security review request is being initiated by PCE chairs [2].


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.

-> Not applicable

7. If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in RFC 8342?

-> Not applicable

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.

-> Not applicable

Document Shepherd Checks
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?

- needed -> yes.

- clearly written -> yes.

- complete -> yes, with caveat that it is still open to decide whether this document will have normative reference to rfc8446 OR ietf-tls-rfc8446bis. The decision on such is open depending on timelines of each independent document. This does not fundamentally change the document.

- correctly designed -> yes.

- ready to be handed off to the responsible Area Director? -> yes


10. Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

-> Not applicable.

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?

-> Standards Track, as an update to RFC 8253.

-> Yes, this is proper public stream as it's an update to an existing standard stream document.

-> Yes, Datatracker state attributes reflect intent.

12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

-> Yes. IPR disclosure was requested during WG adoption and WGLC, see [3] and [4].

13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

-> Yes.

-> 3 authors.

14. Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

-> ID nits warns on RFC 5246 since it's been replaced by RFC8446. Both of these are references in the document and the usage in referencing RFC 5245 is applicable as this document provides the update transitions required to go from RFC5246 to RFC8446 in the context of PCEP.


15. Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.

-> No.

16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?

-> Not applicable.

17. Are there any normative downward references (see RFC 3967 and BCP
97
) that are not already listed in the DOWNREF registry? If so,
list them.

-> No.


18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

-> The document references ietf-tls-rfc8446bis which is in a similar state as this document at the time of reading. The document contains an editor note that indicates the RFC editor may change the reference to RFC8446. The content in the document remains compliant with RFC8446.

19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

-> The document updates RFC 8253.

-> Yes they are listed on title page and discussed in introduction.

20. 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 aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).

-> There are no IANA considerations. This is consistent with the body of the document as there are no codepoints or registries being defined in the document.

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.

-> Not applicable.


Answer References:

[1] https://mailarchive.ietf.org/arch/msg/pce/dLdcUan2psssBUgzCtXPluEr_ok/
[2] https://mailarchive.ietf.org/arch/msg/pce/9tMlNe6CoqiCOn2wfzJd04hOpWg/
[3] https://mailarchive.ietf.org/arch/msg/pce/mwiRdG4YoBTRfqfNsM05OXwrFss/
[4] https://mailarchive.ietf.org/arch/msg/pce/nJK2oV_X9OdHMrE5YqAaVD0fyO4/
[5] https://mailarchive.ietf.org/arch/msg/pce/SCyLmChul8v27cf-C7EdwNqxfoQ/
[6] https://mailarchive.ietf.org/arch/msg/pce/JmSlc7PT-ms120LXfrldyenG7Bc/


Question References:

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

2023-11-13
02 Tal Mizrahi Request for Early review by RTGDIR Completed: Has Issues. Reviewer: Tal Mizrahi.
2023-11-09
02 Julien Meuric Tag Revised I-D Needed - Issue raised by WGLC cleared.
2023-11-09
02 Julien Meuric IETF WG state changed to In WG Last Call from Waiting for WG Chair Go-Ahead
2023-11-05
02 Dhruv Dhody New version available: draft-ietf-pce-pceps-tls13-02.txt
2023-11-05
02 (System) New version approved
2023-11-05
02 (System) Request for posting confirmation emailed to previous authors: Dhruv Dhody , Russ Housley , Sean Turner
2023-11-05
02 Dhruv Dhody Uploaded new revision
2023-11-02
01 Dhruv Dhody Added to session: IETF-118: pce  Thu-1400
2023-10-12
01 Andrew Stone
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 …
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?

-> A few individuals with others being silent.

-> General broad agreement without much contention during sessions but generally quiet on list. During WG sessions polling to expedite document was well received.

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

-> No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize 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.)

-> 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 recommends) or elsewhere
(where)?

-> Yes, document describes allowing use of TLS 1.3 with PCEP (as an update to TLS 1.2).

-> Yes, including one WG member indicated implementation was straight forward[1].

-> No implementation section in the document.

Additional Reviews
5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

-> Yes, the document makes direct references and use of TLS 1.3 from RFC8446 and the potential RFC8446bis. Early security review request is being initiated by PCE chairs [2].


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.

-> Not applicable

7. If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in RFC 8342?

-> Not applicable

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.

-> Not applicable

Document Shepherd Checks
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?

- needed -> yes.

- clearly written -> yes.

- complete -> yes, with caveat that it is still open to decide whether this document will have normative reference to rfc8446 OR ietf-tls-rfc8446bis. The decision on such is open depending on timelines of each independent document. This does not fundamentally change the document.

- correctly designed -> yes.

- ready to be handed off to the responsible Area Director? -> possibly yes, but worth noting outstanding review comments to be addressed: [5] and [6].


10. Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

-> Not applicable.

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?

-> Standards Track, as an update to RFC 8253.

-> Yes, this is proper public stream as it's an update to an existing standard stream document.

-> Yes, Datatracker state attributes reflect intent.

12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

-> Yes. IPR disclosure was requested during WG adoption and WGLC, see [3] and [4].

13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

-> Yes.

-> 3 authors.

14. Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

-> ID nits warns on RFC 5246 since it's been replaced by RFC8446. Both of these are references in the document and the usage in referencing RFC 5245 is applicable as this document provides the update transitions required to go from RFC5246 to RFC8446 in the context of PCEP.


15. Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.

-> No.

16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?

-> Not applicable.

17. Are there any normative downward references (see RFC 3967 and BCP
97
) that are not already listed in the DOWNREF registry? If so,
list them.

-> No.


18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

-> The document references ietf-tls-rfc8446bis which is in a similar state as this document at the time of reading. The document contains an editor note that indicates the RFC editor may change the reference to RFC8446. The content in the document remains compliant with RFC8446.

19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

-> The document updates RFC 8253.

-> Yes they are listed on title page and discussed in introduction.

20. 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 aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).

-> There are no IANA considerations. This is consistent with the body of the document as there are no codepoints or registries being defined in the document.

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.

-> Not applicable.


Answer References:

[1] https://mailarchive.ietf.org/arch/msg/pce/dLdcUan2psssBUgzCtXPluEr_ok/
[2] https://mailarchive.ietf.org/arch/msg/pce/9tMlNe6CoqiCOn2wfzJd04hOpWg/
[3] https://mailarchive.ietf.org/arch/msg/pce/mwiRdG4YoBTRfqfNsM05OXwrFss/
[4] https://mailarchive.ietf.org/arch/msg/pce/nJK2oV_X9OdHMrE5YqAaVD0fyO4/
[5] https://mailarchive.ietf.org/arch/msg/pce/SCyLmChul8v27cf-C7EdwNqxfoQ/
[6] https://mailarchive.ietf.org/arch/msg/pce/JmSlc7PT-ms120LXfrldyenG7Bc/


Question References:

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

2023-10-12
01 Andrew Stone
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 …
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?

-> A few individuals with others being silent.
-> General broad agreement without much contention during sessions but generally quiet on list. During WG sessions polling to expedite document was well received.

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

-> No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize 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.)

-> 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 recommends) or elsewhere
(where)?

-> Yes, document describes allowing use of TLS 1.3 with PCEP (as an update to TLS 1.2).
-> Yes, including one WG member indicated implementation was straight forward[1].
-> No implementation section in the document.

Additional Reviews
5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

-> Yes, the document makes direct references and use of TLS 1.3 from RFC8446 and the potential RFC8446bis. Early security review request is being initiated by PCE chairs [2].


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.

-> Not applicable

7. If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in RFC 8342?

-> Not applicable

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.

-> Not applicable

Document Shepherd Checks
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?

- needed -> yes.
- clearly written -> yes.
- complete -> yes, with caveat that it is still open to decide whether this document will have normative reference to rfc8446 OR ietf-tls-rfc8446bis. The decision on such is open depending on timelines of each independent document. This does not fundamentally change the document.
- correctly designed -> yes.
- ready to be handed off to the responsible Area Director? -> possibly yes, but worth noting outstanding review comments to be addressed: [5] and [6].


10. Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

-> Not applicable.

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?

-> Standards Track, as an update to RFC 8253.
-> Yes, this is proper public stream as it's an update to an existing standard stream document.
-> Yes, Datatracker state attributes reflect intent.

12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

-> Yes. IPR disclosure was requested during WG adoption and WGLC, see [3] and [4].

13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

-> Yes.
-> 3 authors.

14. Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

-> ID nits warns on RFC 5246 since it's been replaced by RFC8446. Both of these are references in the document and the usage in referencing RFC 5245 is applicable as this document provides the update transitions required to go from RFC5246 to RFC8446 in the context of PCEP.


15. Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.

-> No.

16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?

-> Not applicable.

17. Are there any normative downward references (see RFC 3967 and BCP
97
) that are not already listed in the DOWNREF registry? If so,
list them.

-> No.


18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

-> The document references ietf-tls-rfc8446bis which is in a similar state as this document at the time of reading. The document contains an editor note that indicates the RFC editor may change the reference to RFC8446. The content in the document remains compliant with RFC8446.

19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

-> The document updates RFC 8253.
-> Yes they are listed on title page and discussed in introduction.

20. 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 aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).

-> There are no IANA considerations. This is consistent with the body of the document as there are no codepoints or registries being defined in the document.

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.

-> Not applicable.


Answer References:

[1] https://mailarchive.ietf.org/arch/msg/pce/dLdcUan2psssBUgzCtXPluEr_ok/
[2] https://mailarchive.ietf.org/arch/msg/pce/9tMlNe6CoqiCOn2wfzJd04hOpWg/
[3] https://mailarchive.ietf.org/arch/msg/pce/mwiRdG4YoBTRfqfNsM05OXwrFss/
[4] https://mailarchive.ietf.org/arch/msg/pce/nJK2oV_X9OdHMrE5YqAaVD0fyO4/
[5] https://mailarchive.ietf.org/arch/msg/pce/SCyLmChul8v27cf-C7EdwNqxfoQ/
[6] https://mailarchive.ietf.org/arch/msg/pce/JmSlc7PT-ms120LXfrldyenG7Bc/


Question References:

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

2023-10-12
01 Andrew Stone Changed consensus to Yes from Unknown
2023-10-12
01 Andrew Stone Intended Status changed to Proposed Standard from None
2023-10-06
01 Haomian Zheng Request for Early review by RTGDIR is assigned to Tal Mizrahi
2023-10-06
01 Tero Kivinen Request for Early review by SECDIR is assigned to Loganaden Velvindron
2023-10-05
01 Melinda Shore Assignment of request for Early review by SECDIR to Melinda Shore was rejected
2023-09-28
01 Tero Kivinen Request for Early review by SECDIR is assigned to Melinda Shore
2023-09-27
01 Andrew Stone Notification list changed to andrew.stone@nokia.com because the document shepherd was set
2023-09-27
01 Andrew Stone Document shepherd changed to Andrew Stone
2023-09-25
01 Julien Meuric Requested Early review by RTGDIR
2023-09-25
01 Julien Meuric Requested Early review by SECDIR
2023-09-25
01 Julien Meuric Tag Revised I-D Needed - Issue raised by WGLC set.
2023-09-25
01 Julien Meuric IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2023-09-05
01 Julien Meuric IETF WG state changed to In WG Last Call from WG Document
2023-08-19
01 Dhruv Dhody New version available: draft-ietf-pce-pceps-tls13-01.txt
2023-08-19
01 (System) New version approved
2023-08-19
01 (System) Request for posting confirmation emailed to previous authors: Dhruv Dhody , Russ Housley , Sean Turner
2023-08-19
01 Dhruv Dhody Uploaded new revision
2023-07-14
00 Dhruv Dhody Added to session: IETF-117: pce  Mon-2230
2023-06-14
00 Dhruv Dhody This document now replaces draft-dhody-pce-pceps-tls13 instead of None
2023-06-14
00 Dhruv Dhody New version available: draft-ietf-pce-pceps-tls13-00.txt
2023-06-14
00 Dhruv Dhody WG -00 approved
2023-06-14
00 Dhruv Dhody Set submitter to "Dhruv Dhody ", replaces to (none) and sent approval email to group chairs: pce-chairs@ietf.org
2023-06-14
00 Dhruv Dhody Uploaded new revision