Cookies: HTTP State Management Mechanism
draft-ietf-httpbis-rfc6265bis-22

[Ballot comment]
Thanks for this clear update. My only nit is that "infelicities" is not a word I knew, and I'm a fairly decent english-not-my-first-language speaker. I recommend rephrasing the sentences where this word is used.

[Ballot comment]
I echo the kudos from others about a very good work product here.

I support Eric's DISCUSS position.

Some of the SHOULD [NOT] instances in Section 4.1.1 could benefit from either conversion to MUST [NOT] or an explanation of the choice that's being left to implementers.  Same point in Section 5.8.3.

== Comments from Andy Newton, incoming ART AD ==

I agree with Gunter’s comment. This is a very well-written document, and many thanks go to the authors for their effort and commitment.

I do have one small observation. Section 5.7 has an ordered list with sub-lists. There seems to be an inconsistency in the “Otherwise:” sub-list between item 18 and the other items where an “Otherwise:” is embedded in a sub-list (for example items 9 and 10).

[Ballot comment]
I, too, am a fan of "infelicities" -- the word, its use in this document, and most of all, your care in illustrating several of said infelicities.

[Ballot comment]
Thanks for working on this specification.

I have following comments, I believe it would improve the specification if they are addressed -

# The following two normative behaviors could easily be part of section 3 overview. Is there any particular reason to put these in the introduction section ?

    To maximize interoperability with user agents, servers SHOULD limit themselves to the well-behaved profile defined in Section 4 when generating cookies.

    User agents MUST implement the more liberal processing rules defined in Section 5, in order to maximize interoperability with existing servers that do not conform to the well-behaved profile defined in Section 4.

# Who are "we" in section 5.2.2 's Note?

# Can we be more specific on how section 5.2.2.2 is related to set-cookies and cookies header specification? It was obvious that service worker implementation should follow the w3c specification, but how it that related to this specification? Is there any specifics that the implementer's of this specification must consider?

[Ballot comment]
# Orie Steele, ART AD, comments for draft-ietf-httpbis-rfc6265bis-19
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-httpbis-rfc6265bis-19.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

Thank you to Claudio Allocchio for the ARTART review.

### What year is it?

I suspect I'm about to embarrass myself with ABNF yet again...

```
598   NOTE: Some existing user agents differ in their interpretation of
599   two-digit years.  To avoid compatibility issues, servers SHOULD use
600   the rfc1123-date format, which requires a four-digit year.
```

later:

```
911       year            = 2*4DIGIT [ non-digit *OCTET ]
```

https://datatracker.ietf.org/doc/html/rfc1123#page-55

Perhaps a better reference than "rfc1123-date"

Would be: https://datatracker.ietf.org/doc/html/rfc6265#section-5.1.1 ?

I tripped on this ABNF, because:

https://www.rfc-editor.org/rfc/rfc3339.html#section-5.6

```
date-fullyear  = 4DIGIT
```

https://datatracker.ietf.org/doc/html/rfc7231#section-7.1.1.1

```
year        = 4DIGIT
```

https://datatracker.ietf.org/doc/html/rfc9110#section-5.6.7

```
year        = 4DIGIT
```

https://datatracker.ietf.org/doc/html/rfc9165#section-3-7

```
date-fullyear  = 4DIGIT
```

Is "2*4DIGIT [ non-digit *OCTET ]" the correct way to signal the decimal numbers expected in cookies for year?

I suspect this is leftover from the 2 digit year case.

which was:

https://datatracker.ietf.org/doc/html/rfc822#section-5.1


```
date        =  1*2DIGIT month 2DIGIT
```

And was updated to:

```
date = 1*2DIGIT month 2*4DIGIT
```

But why is it not one of these:

```
date = 1*2DIGIT month 1*4DIGIT
date = 1*2DIGIT month 4DIGIT
```

## Nits

### BCP14 update

```
216   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
217   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
218   document are to be interpreted as described in [RFC2119].
```

vvvv

```
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
```

[Ballot comment]
** Thank you to Dale R. Worley for the GENART review on -19.  Please review https://datatracker.ietf.org/doc/review-ietf-httpbis-rfc6265bis-19-genart-lc-worley-2025-02-10/.  Specifically, review the clarify of the ABNF definition on handling whitespace in addition to the other pointers where the text would benefit from clarity.

** Please cite the whatwg.org documents the same:

  [DOM-DOCUMENT-COOKIE]
              WHATWG, "HTML - Living Standard", 18 May 2021,
              .

  [FETCH]    van Kesteren, A., "Fetch", n.d.,
              .

  [HTML]    Hickson, I., Pieters, S., van Kesteren, A., Jägenstedt,
              P., and D. Denicola, "HTML", n.d.,
              .

  [SAMESITE] WHATWG, "HTML - Living Standard", 26 January 2021,
              .

-- [SAMESITE] and [DOM-DOCUMENT-COOKIE] use a date, but not [HTML] and [FETCH].  As I recollect, using the date was the resolution when this issue was last raised on a ballot from an HTTP document ballot.

-- Why is [SAMESITE] and [HTML] cited differently despite being the same spec.  [HTML] includes author names, but [SAMESITE] does not

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-httpbis-rfc6265bis-19
CC @evyncke

Thank you for the work put into this document, like other ADs I find it easy to read (for most parts).

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

Special thanks to Mark Nottingham for the shepherd's write-up including the WG consensus *and* the justification of the intended status.

Please note that Petr Špaček is the DNS directorate reviewer and you may want to consider this dns-dir review as well when it will be available (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/reviewrequest/21332/

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics:

### Section 2.1

Trivial to fix: please use the actual BCP14 template include RFC 8174 reference.

[Ballot comment]

## COMMENTS (non-blocking)


### Section 1 & abstract

Having some text about the difference with RFC 6265 would be helpful.

As a non-English speaker, I had to check the meaning of `infelicities`... I.e., I share Warren's view on unusual words.

### Section 2.1

Unsure whether using "conformance" is the right word to be used in an IETF document. The BCP14 template has also little to do with conformance. Suggest using some wording related to "interoperation" rather than "conformance". Section 3.2 uses "compatible", which is more appropriate.

### Section 3

I am far from being an HTTP expert, but can CDN/proxies also set cookies ? It does not seem so when reading `a way for an origin server to send state`, if so, then suggest adding text clarifying whether CDN/proxies can also Set-Cookie

### Section 3.1

As there are some text about deleting a cookie by sending a Expires date in the past, then the choice of `09 Jun 2021` for a valid cookie does not seem correct in 2025 ;-) Suggest adding some text in the 'valid' example stating that the request is sent in May 2021 or something similar.

### Section 4.1.2.7

To be honest and probably because I am not an HTTP expert, I was unable to understand the specification of SameSite...

### Sections 4.2 and 4.1

Suggest adding "HTTP Header" to the section title, especially for section 4.2 as I read it first about a section about cookies and not about the Cookie header.

### Section 5.2.1

Who is the "We" in `We'll define this origin,`? The authors ? The HTTPBIS WG ? The IETF ? Please refrain from using the ambiguous "we", also applicable in other places

### Section 5.3

What are the consequences of bypassing the "SHOULD" in this section ? Also applicable to many SHOULD (e.g., section 6.1), recommended may be more appropriate.

### Section 5.5

Any justification for the 400 days ? Also, please explain the consequences of bypassing the "SHOULD".

### Section 9.3

Good idea to create such a registry for easier extensions.

[Ballot comment]
I would like to second Gunter's comments. This is a nicely written and easily understandable document.

I do have one comment, which you can feel free to ignore -- while "infelicities" is a perfectly cromulent word, I suspect many readers will not be familiar with it. This may not be an issue - most readers will likely be on a computer and so can easily look it up (and learn a cool new word at the same time).
If I were an author, I'd leave it as is, but then again, I'm a fan of Pratchett's Dictionary of Eye-Watering Words...

[Ballot comment]

Many thanks to Valery Smyslov for his secdir review.

Section 5:  (Recognizing that this is from the original RFC) The nested numbered lists are difficult to parse.  For example Section 5.7, #6 has 3 sets of sub numbered lists that appear to be distinct.  If these sub numbered lists are necessary (and when there is merely a #1 without a #2, one might argue it isn't 'necessary') then perhaps characters other than numbers might be clearer.

Section 8:  I agree with Valery that this section picks and chooses some example issues ('more salient issues').  I wonder if it isn't possible to give a 1-2 sentence overview of the general security issues associated with cookies.  Something to set the stage, where what follows are examples of issues that have been seen over time (with or without mitigations).  Sadly, I do not have proposed text, and indeed, it may not be possible/feasible. 

Section 10.1:  Most (all?) of the WHATWG documents can be referenced as a snapshot to make them immutable.  There might be other ways to do this, but this is the one I've seen used.

[Ballot comment]
# Internet AD comments for draft-ietf-httpbis-rfc6265bis-19
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S4.1.2.7

* Is there anything noteworthy about a Set-Cookie header that has both
  SameSite and Domain attributes?  How could they interact (if at all)?

### S5.1.3

* Does the canonicalization referred to here mean that described in S5.1.2?
  If so, S5.1.2 does not state that canonicalized form will be lower case.

## Nits

### S3.2.2

* "users agents" -> "user agents"?

[Ballot comment]
Thanks to the authors for their work! I found this to be a well-written draft. It’s a long document, but the differences between this -bis version and the original RFC6265 were really helpful. Keeping much of the original text while adding clarifications made it much easier to follow.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-httpbis-rfc6265bis-19. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are three actions which we must complete.

First, in the Hypertext Transfer Protocol (HTTP) Field Name Registry located at:

https://www.iana.org/assignments/http-fields/

an existing registration is to be updated as follows:

Field Name: Cookie
Status: permanent
Structured Type:
Reference: [ RFC-to-be; Section 5.8.1 ]
Comments:

Second, also in the Hypertext Transfer Protocol (HTTP) Field Name Registry located at:

https://www.iana.org/assignments/http-fields/

an existing registration is to be updated as follows:

Field Name: Set-Cookie
Status: permanent
Structured Type:
Reference: [ RFC-to-be; Section 5.6 ]
Comments:

Third, a new registry group is to be created called Hypertext Transfer Protocol (HTTP) Cookie Attributes. The new registry group will have a reference of [ RFC-to-be ].

Fourth, in the new registry group created in action three above, a new registry will be created called Cookie Attributes. The new registry will be managed via RFC Required as defined by [RFC8126].

There are initial registrations in the new registry as follows:

Name Reference
----------+-----------------------------
Domain [ RFC-to-be; Section 4.1.2.3]
Expires [ RFC-to-be; Section 4.1.2.1]
HttpOnly [ RFC-to-be; Section 4.1.2.6]
Max-Age [ RFC-to-be; Section 4.1.2.2]
Path [ RFC-to-be; Section 4.1.2.4]
SameSite [ RFC-to-be; Section 4.1.2.7]
Secure [ RFC-to-be; Section 4.1.2.5]

We understand that these are the only actions required to be completed upon approval of this document.

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

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

The following Last Call announcement was sent out (ends 2025-02-11):

From: The IESG
To: IETF-Announce
CC: draft-ietf-httpbis-rfc6265bis@ietf.org, francesca.palombini@ericsson.com, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, mnot@mnot.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Cookies: HTTP State Management Mechanism) to Proposed Standard


The IESG has received a request from the HTTP WG (httpbis) to consider the
following document: - 'Cookies: HTTP State Management Mechanism'
  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 2025-02-11. 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 defines the HTTP Cookie and Set-Cookie header fields.
  These header fields can be used by HTTP servers to store state
  (called cookies) at HTTP user agents, letting the servers maintain a
  stateful session over the mostly stateless HTTP protocol.  Although
  cookies have many historical infelicities that degrade their security
  and privacy, the Cookie and Set-Cookie header fields are widely used
  on the Internet.  This document obsoletes RFC 6265.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/



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

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

Yes - we had broad participation, especially from implementers.

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

Not particularly. We used a process where major changes required a separate draft to be adopted and achieve consensus before we incorporated them.

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

Yes, a few.

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

There has been participation from members of the WHATWG, which is the most relevant body.

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.

N/A

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

No YANG here (yet).

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.

ABNF has been listed.

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

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?

N/A

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?

Proposed Standard. This is a bis of an existing PS.

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.

Yes.

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.

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

It's clean.

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

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?

USASCII (also referenced by 6265) is widely understood and usable, but the actual reference may require some hoop jumping.

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.

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?

No.

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.

Yes and yes.

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][11]).

The document updates two HTTP field name registrations and creates a new cookie attribute registry; all appears to be in order.

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.

The cookie attribute registration. No DE.


[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/

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

Yes - we had broad participation, especially from implementers.

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

Not particularly. We used a process where major changes required a separate draft to be adopted and achieve consensus before we incorporated them.

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

Yes, a few.

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

There has been participation from members of the WHATWG, which is the most relevant body.

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.

N/A

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

No YANG here (yet).

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.

ABNF has been listed.

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

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?

N/A

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?

Proposed Standard. This is a bis of an existing PS.

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.

Yes.

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.

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

It's clean.

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

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?

USASCII (also referenced by 6265) is widely understood and usable, but the actual reference may require some hoop jumping.

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.

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?

No.

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.

Yes and yes.

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][11]).

The document updates two HTTP field name registrations and creates a new cookie attribute registry; all appears to be in order.

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.

The cookie attribute registration. No DE.


[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/

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

Yes - we had broad participation, especially from implementers.

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

Not particularly. We used a process where major changes required a separate draft to be adopted and achieve consensus before we incorporated them.

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

Yes, a few.

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

There has been participation from members of the WHATWG, which is the most relevant body.

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.

N/A

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

No YANG here (yet).

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.

ABNF has been listed.

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

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?

N/A

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?

Proposed Standard. This is a bis.

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.

Yes.

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.

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

There are some spurious line length warnings and a few non-ASCII punctuation marks; I assume these can be corrected during editing as/if necessary.

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



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

USASCII (also referenced by 6265) is widely understood and usable, but the actual reference may require some hoop jumping.

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.

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?

No.

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.

Yes and yes.

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][11]).

The document updates two HTTP field name registrations and creates a new cookie attribute registry; all appears to be in order.

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.

The cookie attribute registration. No DE.


[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/