Hi Michael, Thanks for the shepherd write-up. I am not aware of any IPR related to this specification.
Best Regards, -Tiru On Mon, 2 Mar 2026 at 23:41, Michael Jones <[email protected]> wrote: > Thanks for the shepherd review, Michael. > > I know of no IPR that pertains to this specification. > > -- Mike > > From: Michael P1 <[email protected]> > Sent: Monday, March 2, 2026 8:06 AM > To: Karen ODonoghue <[email protected]>; JOSE WG <[email protected]>; > [email protected] > Subject: [jose] Re: WGLC: draft-ietf-jose-hpke-encrypt-15 (Ends 2026-02-11) > > Hi All, > > I have drafted the shepherd write-up for draft-ietf-jose-hpke-encrypt, > which is included below. Please do let me know if you have any comments. > > Authors - please also treat this as a prompt for IPR disclosures, as per > question 12 below. > > Thanks, > Michael > > > > # Document Shepherd Write-Up for Group Documents > > *This version is dated 4 July 2022.* > > Thank you for your service as a document shepherd. Among the > responsibilities is > answering the questions in this write-up to give helpful context to Last > Call > and Internet Engineering Steering Group ([IESG][1]) reviewers, and your > diligence in completing it is appreciated. The full role of the shepherd is > further described in [RFC 4858][2]. You will need the cooperation of the > authors > and editors to complete these checks. > > Note that some numbered items contain multiple related questions; please > be sure > to answer all of them. > > ## 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 received reviews on mailing lists and GitHub from a range > of individuals. Thorough review was prompted by a first WGLC in June 2025, > which did not pass but led to a number of issues being raised and > rectified. Broad agreement was reached during the second WGLC in February > 2026. There has been suggestion to include PQC algorithms in this draft, > but broad agreement to do that in a separate draft. > > 2. Was there controversy about particular points, or were there decisions > where > the consensus was particularly rough? > > Some points involved deep discussion, including the formation of a design > team. These were settled and agreed upon without controversy. > > 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 threats of appeal > > 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)? > > Yes, mailing list discussion highlights multiple interoperable > implementations. > > ## 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 is closely aligned with a corresponding draft in the > COSE WG. The WGLC's were run concurrently to ensure consistent review from > both WGs. The HPKE WG also provided review earlier in the development of > the document. > > 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 required. > > 7. If the document contains a YANG module, has the final version of the > module > been checked with any of the [recommended validation tools][4] 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][5]? > > N/A > > 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. > > N/A > > ## 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? > > Yes, the document is clearly written (including a glossary of terms), > complete, correct, and ready to be handed to the responsible AD. > > 10. Several IETF Areas have assembled [lists of common issues that their > reviewers encounter][6]. For which areas have such issues been > identified > and addressed? For which does this still need to happen in subsequent > reviews? > > This draft focuses on considerations highlighted by the Security Area and > includes this discussion in the Security Considerations section. No further > reviews are required. > > 11. What type of RFC publication is being requested on the IETF stream > ([Best > Current Practice][12], [Proposed Standard, Internet Standard][13], > [Informational, Experimental or Historic][14])? Why is this the proper > type > of RFC? Do all Datatracker state attributes correctly reflect this > intent? > > This document is requesting Proposed Standard publication. This consistent > with the other JOSE specifications and is accurate in Datatracker. > > 12. Have reasonable efforts been made to remind all authors of the > intellectual > property rights (IPR) disclosure obligations described in [BCP 79][7]? > 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. > > Post sent to mailing list as part of shepherd review > > 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, they have. There are 5 authors at time of writing. > > 14. Document any remaining I-D nits in this document. Simply running the > [idnits > tool][8] is not enough; please review the ["Content Guidelines" on > authors.ietf.org][15]. (Also note that the current idnits tool > generates > some incorrect warnings; a rewrite is underway.) > > One nit with a reference as a later version (-22) exists of > draft-ietf-cose-hpke-21. These drafts are proceeding through WGLC > concurrently, so this can be rectified. > > 15. Should any informative references be normative or vice-versa? See the > [IESG > Statement on Normative and Informative References][16]. > > References are correct. > > 16. List any normative references that are not freely available to anyone. > Did > the community have sufficient access to review any such normative > references? > > All normative references are freely available. > > 17. Are there any normative downward references (see [RFC 3967][9] and [BCP > 97][10]) that are not already listed in the [DOWNREF registry][17]? If > so, > list them. > > None > > 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? > > Normative reference to > https://datatracker.ietf.org/doc/html/draft-ietf-hpke-hpke-02. This draft > has been through WGLC but is being held to publish with > https://datatracker.ietf.org/doc/draft-ietf-hpke-pq/, which itself is > waiting on drafts from CFRG. > > Discussion of timelines are on HPKE mailing list > https://mailarchive.ietf.org/arch/msg/hpke/5bCbbTB5wkgtB9wjCaufBsdAMpk/ > > 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. > > This specification updates RFC 7516. This is highlighted in the title, > abstract, introduction, and a standalone section to state the changes. > > 20. Describe the document shepherd's review of the IANA considerations > section, > especially with regard to its consistency with the body of the document
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
