NAME or NAME , can you merge this (now-updated) PR, or give me write access so I can do this ;-) ?
I don't know how to give you write access, so I merged it. :)
Based on the original comment: URL and the response: URL it is proposed to add requirements for the stub router behavior on the AIL regarding: advertising itself as a default router on the AIL; advertising a default route on the AIL. For correct operation the stub router MUST NOT advertise both of these. While Section 5.4 has requirements for default router/route advertising on the stub network, there is no section yet with specific requirements for the AIL side. This needs to be added. (FYI NAME
See also some more detailed suggestions at the bottom of mail: URL
This issues was self-assigned to NAME Hi, That was the case in the past, but RFC 6724 introduced a "label" for ULA that is distinct from GUA. Since matching labels are preferred, the match between two IPv4 addresses (one label for IPv4) is preferred over the mismatched labels of GUA and ULA. There is another possible failure case, when a remote ULA is received via DNS although the traffic would have to go via Internet. This case is solved in RFC 6724 by specifying a lower "precedence" for ULA than for IPv4. (Not all hosts implement the latter part, e.g., GNU/Linux has a higher preference for ULA than for IPv4.) That should work, but RFC 4191 states that in section 4: "When ceasing to be an advertising interface and sending Router Advertisements with a Router Lifetime of zero, the Router Advertisement SHOULD also set the Route Lifetime to zero in all Route Information Options." RFC 4861 describes in section 6.2.3: "A router might want to send Router Advertisements without advertising itself as a default router. For instance, a router might advertise prefixes for stateless address autoconfiguration while not wishing to forward packets. Such a router sets the Router Lifetime field in outgoing advertisements to zero." So using a router lifetime of 0 does not imply that the interface is not an advertising interface. This combination does not seem obvious to me, but it seems valid. Going back to RFC 4191, section 5.2 mentions the combination of router lifetime 0 with RIOs with lifetime > 0 as a solution for type C hosts. The solution for type B hosts for a single isolated network is preference based, and there is no solution for type A hosts. I think that Route Information Options should be accepted from RAs with a Router Lifetime of 0 according to those RFCs. Yes, several stub routers each using each others as Internet gateways would not work. Thus I think that stub routers must not advertise themselves as default routers on the AIL. Perhaps this could be made explicit? I would like the draft to be explicit regarding RA contents, preferably with a rationale. I would really like to read short explanations for the specific settings, i.e., how this is supposed to work. It would be great if draft-ietf-snac-simple could mention section 5.2 of RFC 4191 and that a lifetime of 0 should suffice for type A and B hosts to ignore the stub router, i.e., do no harm, but a type C host is required for stub network reachability from the host. Since supporting a type B host would risk creating problems for a type A host, I would prefer SNAC to only work for type C hosts. As soon as more than one stub network is connected to the AIL, only type C hosts can reliably choose the correct stub router anyway. The case of multiple stub networks is more complex than the scenario from RFC 4191 section 5.2. Best regards, Erik A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable. -- Leslie Lamport
Hello, I can try to respond from my viewpoint. This could help to identify the open issues. I don't see how RFC 8028 is relevant here. It has the following applicability: IPv6 host in a network that has more than one prefix, each allocated by an upstream network that is assumed to implement BCP 38 [RFC2827] ingress filtering The network/link (AIL) considered for SNAC-simple is a link with a single IPv6 on-link prefix. Either a global/ULA prefix allocated by e.g. a home router, or if that is missing, a ULA prefix allocated by one of the stub routers. So there's not "more than one prefix" and I don't see immediately if any problem would occur if we would have > 1 prefix. For example the IPv6 host on the AIL would remain reachable from an on-stub-network host, regardless of the IPv6 source address that the host on the AIL used. See also below for more info on this case for the packets in the other direction. This part I agree should be clarified in SNAC-simple. I assumed a Type C host for sure. And I would consider Type A and Type B to be even out of scope if required to keep the solution simple! One question is: what if a Type A/B host sent an IPv6 packet to the ULA dest address of a stub-Host ; and the packet would be routed to the default router of the home network? (E.g. home router / Wi-Fi AP / ISP box) Wouldn't that default router immediately discover that the correct route is to send it to the stub router, based on the RA RIO advertisements? So the routing is not most efficient then but it works. If that is the case, we can still support Type A/B hosts although with some degraded performance/latency. I think we could clarify that the stub router must never ever advertise itself as a default router (or advertise a default route ::/0) on the AIL. This isn't in the draft yet. Not sure if that is what you meant here? The existing mentions of "default route(r)" in SNAC-simple are pertain to advertising itself as default route on the stub network side, not the AIL side, I believe. Given the above, even if the host would not follow rule 5.5, it would pick another source address, but still that address would be based on an IPv6 prefix that is on-link. So it means the stub router can correctly route back to that prefix and use IPv6 ND to find the host back on the link. And the IPv6 host if it is type C would still use the RA RIO advertisements to pick the next-hop router, regardless of its IPv6 source address. The only question I have is for the Type A/B hosts - they might pick a default router instead and the question is there if it would route back the packet to the right stub router on the AIL instead of sending the packet out onto the wider Internet. (My expectation is that it would work, but ... ) But this Type A/B host problem is there independent of the source address selection. Or am I missing something? Also keep in mind that there are in total 3 possible cases for a given stub router: Stub router uses its generated ULA prefix to assign a prefix for the stub network; and also to assign a prefix for the AIL. Stub router uses its generated ULA prefix to assign a prefix for the stub network; but another stub-router (there may be N stub routers in total, each with a different stub network) has assigned the AIL prefix. That means the prefixes don't use a shared ULA prefix. Stub router uses its generated ULA prefix to assign a prefix for the stub network; but another non-stub-router (e.g. home AP) has already assigned a prefix for the AIL. That means the prefixes don't use a shared ULA prefix. So we cannot rely on features that only work well when a single ULA prefix is used to derive the AIL on-link prefix and the stub network on-link prefix. Esko -----Original Message----- From: Snac On Behalf Of Erik Auerswald Sent: Sunday, August 20, 2023 20:24 To: SNAC List Subject: [Snac] Host Requirements for SNAC Use? Hello SNAC WG, when looking at the basic idea of connecting a stub network via stub router to an existing link (the AIL), in general a host on the AIL would need to use the stub router as gateway to reach the stub network. If this host already has IPv6 connectivity to the Internet, the stub router may be added to that list. Now the host needs to determine which gateway to use for a given packet. Both the IETF Proposed Standard RFCs and existing host implementations allow to choose the wrong gateway, i.e., a gateway that does not have a next-hop to deliver the packet. It seems to me as if some assumptions beyond the most minimal IPv6 host implementations are required to connect a stub network via stub router without additional configuration. RFC 8504 (BCP 220) requires adherence to RFC 4191 which describes three host types called A, B, and C. Only type C hosts can reliably choose the correct gateway. BCP 220 also recommends (but does not require) adherence to RFC 8028 for first-hop router selection. Among other contents, RFC 8028 recommends use of RFC 6724 section 5 rule 5.5. If the host behaves like a type C host from RFC 4191, and the stub router advertises the stub prefix(es) as off-link, the host chooses the stub router to reach the stub network. If the stub router also uses a low default router preference there is some chance that the host will not use it to reach destinations not on the stub network. Perhaps this could be added to draft-ietf-snac-simple? If the host conforms to RFC 6724, and follows RFC 6724 section 5 rule , and it implements the procedure described in RFC 6724 section 10.6, and the stub router advertises a ULA prefix as on-link on the AIL, and the stub network uses ULAs from the same 48-bit global ULA prefix as advertised by the stub router on the AIL, then the host will use the stub router to reach the stub network, and will not use it to reach other destination. Perhaps this could be added to draft-ietf-snac-simple? Since a host may decide to send packets for destinations off the stub network to the stub router, it might be a good idea to require the stub router to forward such packets to a default router detected on the AIL (e.g., via RA). If there is no IPv6 default router on the AIL, the stub router should make it likely that connecting it does not break IPv4 connectivity to the Internet. If the host conforms to RFC 6724, use of ULAs by the stub router suffices. This, of course, means that the RFC 6724 preference of IPv4 over ULA is required for safe stub router use. Perhaps this could be added to draft-ietf-snac-simple? Best regards, Erik Inside every large problem is a small problem struggling to get out. -- Hoare's Law of Large Problems Snac mailing list EMAIL URL
Hello SNAC WG, when looking at the basic idea of connecting a stub network via stub router to an existing link (the AIL), in general a host on the AIL would need to use the stub router as gateway to reach the stub network. If this host already has IPv6 connectivity to the Internet, the stub router may be added to that list. Now the host needs to determine which gateway to use for a given packet. Both the IETF Proposed Standard RFCs and existing host implementations allow to choose the wrong gateway, i.e., a gateway that does not have a next-hop to deliver the packet. It seems to me as if some assumptions beyond the most minimal IPv6 host implementations are required to connect a stub network via stub router without additional configuration. RFC 8504 (BCP 220) requires adherence to RFC 4191 which describes three host types called A, B, and C. Only type C hosts can reliably choose the correct gateway. BCP 220 also recommends (but does not require) adherence to RFC 8028 for first-hop router selection. Among other contents, RFC 8028 recommends use of RFC 6724 section 5 rule 5.5. If the host behaves like a type C host from RFC 4191, and the stub router advertises the stub prefix(es) as off-link, the host chooses the stub router to reach the stub network. If the stub router also uses a low default router preference there is some chance that the host will not use it to reach destinations not on the stub network. Perhaps this could be added to draft-ietf-snac-simple? If the host conforms to RFC 6724, and follows RFC 6724 section 5 rule , and it implements the procedure described in RFC 6724 section 10.6, and the stub router advertises a ULA prefix as on-link on the AIL, and the stub network uses ULAs from the same 48-bit global ULA prefix as advertised by the stub router on the AIL, then the host will use the stub router to reach the stub network, and will not use it to reach other destination. Perhaps this could be added to draft-ietf-snac-simple? Since a host may decide to send packets for destinations off the stub network to the stub router, it might be a good idea to require the stub router to forward such packets to a default router detected on the AIL (e.g., via RA). If there is no IPv6 default router on the AIL, the stub router should make it likely that connecting it does not break IPv4 connectivity to the Internet. If the host conforms to RFC 6724, use of ULAs by the stub router suffices. This, of course, means that the RFC 6724 preference of IPv4 over ULA is required for safe stub router use. Perhaps this could be added to draft-ietf-snac-simple? Best regards, Erik Inside every large problem is a small problem struggling to get out. -- Hoare's Law of Large Problems


Based on comment: URL and responses: URL URL it is clear that the SNAC stub router solution may in some cases not work if the IPv6 Host on the AIL that needs to send an IPv6 packet to a host on a stub network is a Type A or Type B Host. In fact, our assumption so far has been that it is a Type C host. Proposal: add clarification that solution scope is intended for Type C hosts on the AIL. (Though it might work for Type A and B hosts in particular cases, this is not in our scope.) Refer to RFC 4191 Section for the 3 host types. (FYI NAME
Looks like a good place to add this scoping information - in the goals section. Thanks Hello, I can try to respond from my viewpoint. This could help to identify the open issues. I don't see how RFC 8028 is relevant here. It has the following applicability: IPv6 host in a network that has more than one prefix, each allocated by an upstream network that is assumed to implement BCP 38 [RFC2827] ingress filtering The network/link (AIL) considered for SNAC-simple is a link with a single IPv6 on-link prefix. Either a global/ULA prefix allocated by e.g. a home router, or if that is missing, a ULA prefix allocated by one of the stub routers. So there's not "more than one prefix" and I don't see immediately if any problem would occur if we would have > 1 prefix. For example the IPv6 host on the AIL would remain reachable from an on-stub-network host, regardless of the IPv6 source address that the host on the AIL used. See also below for more info on this case for the packets in the other direction. This part I agree should be clarified in SNAC-simple. I assumed a Type C host for sure. And I would consider Type A and Type B to be even out of scope if required to keep the solution simple! One question is: what if a Type A/B host sent an IPv6 packet to the ULA dest address of a stub-Host ; and the packet would be routed to the default router of the home network? (E.g. home router / Wi-Fi AP / ISP box) Wouldn't that default router immediately discover that the correct route is to send it to the stub router, based on the RA RIO advertisements? So the routing is not most efficient then but it works. If that is the case, we can still support Type A/B hosts although with some degraded performance/latency. I think we could clarify that the stub router must never ever advertise itself as a default router (or advertise a default route ::/0) on the AIL. This isn't in the draft yet. Not sure if that is what you meant here? The existing mentions of "default route(r)" in SNAC-simple are pertain to advertising itself as default route on the stub network side, not the AIL side, I believe. Given the above, even if the host would not follow rule 5.5, it would pick another source address, but still that address would be based on an IPv6 prefix that is on-link. So it means the stub router can correctly route back to that prefix and use IPv6 ND to find the host back on the link. And the IPv6 host if it is type C would still use the RA RIO advertisements to pick the next-hop router, regardless of its IPv6 source address. The only question I have is for the Type A/B hosts - they might pick a default router instead and the question is there if it would route back the packet to the right stub router on the AIL instead of sending the packet out onto the wider Internet. (My expectation is that it would work, but ... ) But this Type A/B host problem is there independent of the source address selection. Or am I missing something? Also keep in mind that there are in total 3 possible cases for a given stub router: Stub router uses its generated ULA prefix to assign a prefix for the stub network; and also to assign a prefix for the AIL. Stub router uses its generated ULA prefix to assign a prefix for the stub network; but another stub-router (there may be N stub routers in total, each with a different stub network) has assigned the AIL prefix. That means the prefixes don't use a shared ULA prefix. Stub router uses its generated ULA prefix to assign a prefix for the stub network; but another non-stub-router (e.g. home AP) has already assigned a prefix for the AIL. That means the prefixes don't use a shared ULA prefix. So we cannot rely on features that only work well when a single ULA prefix is used to derive the AIL on-link prefix and the stub network on-link prefix. Esko -----Original Message----- From: Snac On Behalf Of Erik Auerswald Sent: Sunday, August 20, 2023 20:24 To: SNAC List Subject: [Snac] Host Requirements for SNAC Use? Hello SNAC WG, when looking at the basic idea of connecting a stub network via stub router to an existing link (the AIL), in general a host on the AIL would need to use the stub router as gateway to reach the stub network. If this host already has IPv6 connectivity to the Internet, the stub router may be added to that list. Now the host needs to determine which gateway to use for a given packet. Both the IETF Proposed Standard RFCs and existing host implementations allow to choose the wrong gateway, i.e., a gateway that does not have a next-hop to deliver the packet. It seems to me as if some assumptions beyond the most minimal IPv6 host implementations are required to connect a stub network via stub router without additional configuration. RFC 8504 (BCP 220) requires adherence to RFC 4191 which describes three host types called A, B, and C. Only type C hosts can reliably choose the correct gateway. BCP 220 also recommends (but does not require) adherence to RFC 8028 for first-hop router selection. Among other contents, RFC 8028 recommends use of RFC 6724 section 5 rule 5.5. If the host behaves like a type C host from RFC 4191, and the stub router advertises the stub prefix(es) as off-link, the host chooses the stub router to reach the stub network. If the stub router also uses a low default router preference there is some chance that the host will not use it to reach destinations not on the stub network. Perhaps this could be added to draft-ietf-snac-simple? If the host conforms to RFC 6724, and follows RFC 6724 section 5 rule , and it implements the procedure described in RFC 6724 section 10.6, and the stub router advertises a ULA prefix as on-link on the AIL, and the stub network uses ULAs from the same 48-bit global ULA prefix as advertised by the stub router on the AIL, then the host will use the stub router to reach the stub network, and will not use it to reach other destination. Perhaps this could be added to draft-ietf-snac-simple? Since a host may decide to send packets for destinations off the stub network to the stub router, it might be a good idea to require the stub router to forward such packets to a default router detected on the AIL (e.g., via RA). If there is no IPv6 default router on the AIL, the stub router should make it likely that connecting it does not break IPv4 connectivity to the Internet. If the host conforms to RFC 6724, use of ULAs by the stub router suffices. This, of course, means that the RFC 6724 preference of IPv4 over ULA is required for safe stub router use. Perhaps this could be added to draft-ietf-snac-simple? Best regards, Erik Inside every large problem is a small problem struggling to get out. -- Hoare's Law of Large Problems Snac mailing list EMAIL URL
Hi, I was looking for existing methods for a host to select the correct gateway when there are more than one. RFC 8028 is one example. I agree. I would not expect an existing home router to look at any RAs from inside the home network, much less to populate its routing table with the information from those. As such, the home router would either forward the packet via its default route, or drop it. I doubt that to be the case. I think that a stub router following the new SNAC ideas could learn routes from RAs received on the AIL, and use these to forward packets towards the home router or even other stub networks. But as fas as I know this is not common home router behavior. This might be nice to avoid breaking Internet connectivity when adding a stub router to a home network But for reliable connectivity to the stub network, the host would still need to select the stub router as gateway. If the stub router sends an RA with a non-zero lifetime, it advertises itself as a default router. An RFC 4191 type B or C host would evaluate a default router preference and should thus prefer the home router if the stub router uses a Low Preference (unless the home router were also to use a Low Preference), but an RFC 4191 type A host does not evaluate the Preference. I would suggest to require a stub router to use a Low Preference in the RA, but a High Preference for its stub network prefix(es). I have read RFC 6724 again, and I think I made a mistake. RFC 6724 expects that the first hop gateway is selected via destination address, and then describes how to optionally choose a better source address for use with this gateway. This does pertain to RFC 8028, but not to SNAC. I think you are correct. I would expect independent stub networks to use different 48-bit ULA prefixes. In general, a single stub network should suffice with using a single 48-bit ULA prefix, but current implementations may not restrict themselves to this since it is not seen as necessary. I think we cannot rely on many features to be consistently present in existing home networks. Currently, SNAC implicitly requires RFC 4191 type C host behavior. This could be made explicit. I think that would improve the draft. I do not see a rationale for the requirement of a single ULA prefix in draft-ietf-snac-simple-02. It seems logical that a stub router would not need more than one ULA prefix, and one such prefix might be nice. It might help in troubleshooting. It might help keep RAs sufficiently small. It might help keeping routing tables small. It might work together with source address selection to help selecting the stub router as first hop gateway (but that is not described in RFC 6724, but a rather different idea). With no explicit reasons for a single ULA prefix, the requirement could be reduced to a SHOULD or even dropped from the draft. The current motivation to drop the single ULA prefix requirement seems to be that an existing stub router implementation does not limit itself to a single prefix. I find this reasoning quite weak. I wrongly interpreted RFC 6724 section 5 rule 5.5 to help select a gateway after selecting the source address, but it works the other way around. Thus I do not have a strong reason for a single 48-bit ULA prefix any more. I do think that it would be neat to have just one 48-bit ULA prefix per stub network, but that is insufficient for a MUST, I'd say. Best regards, Erik The computing scientist’s main challenge is not to get confused by the complexities of his own making. -- Edsger W. Dijkstra
Hello SNAC WG, when looking at the basic idea of connecting a stub network via stub router to an existing link (the AIL), in general a host on the AIL would need to use the stub router as gateway to reach the stub network. If this host already has IPv6 connectivity to the Internet, the stub router may be added to that list. Now the host needs to determine which gateway to use for a given packet. Both the IETF Proposed Standard RFCs and existing host implementations allow to choose the wrong gateway, i.e., a gateway that does not have a next-hop to deliver the packet. It seems to me as if some assumptions beyond the most minimal IPv6 host implementations are required to connect a stub network via stub router without additional configuration. RFC 8504 (BCP 220) requires adherence to RFC 4191 which describes three host types called A, B, and C. Only type C hosts can reliably choose the correct gateway. BCP 220 also recommends (but does not require) adherence to RFC 8028 for first-hop router selection. Among other contents, RFC 8028 recommends use of RFC 6724 section 5 rule 5.5. If the host behaves like a type C host from RFC 4191, and the stub router advertises the stub prefix(es) as off-link, the host chooses the stub router to reach the stub network. If the stub router also uses a low default router preference there is some chance that the host will not use it to reach destinations not on the stub network. Perhaps this could be added to draft-ietf-snac-simple? If the host conforms to RFC 6724, and follows RFC 6724 section 5 rule , and it implements the procedure described in RFC 6724 section 10.6, and the stub router advertises a ULA prefix as on-link on the AIL, and the stub network uses ULAs from the same 48-bit global ULA prefix as advertised by the stub router on the AIL, then the host will use the stub router to reach the stub network, and will not use it to reach other destination. Perhaps this could be added to draft-ietf-snac-simple? Since a host may decide to send packets for destinations off the stub network to the stub router, it might be a good idea to require the stub router to forward such packets to a default router detected on the AIL (e.g., via RA). If there is no IPv6 default router on the AIL, the stub router should make it likely that connecting it does not break IPv4 connectivity to the Internet. If the host conforms to RFC 6724, use of ULAs by the stub router suffices. This, of course, means that the RFC 6724 preference of IPv4 over ULA is required for safe stub router use. Perhaps this could be added to draft-ietf-snac-simple? Best regards, Erik Inside every large problem is a small problem struggling to get out. -- Hoare's Law of Large Problems


NAME The new sections need to go in just after all the "", otherwise the XML doesn't build (order is fixed).
Question on the cases included: isn't there a case possible where network is managed and is IPv6 only DHCPv6 addressing is used (as intended by operator) - assume DHCPv6 hands out ULA addresses no RA-Guard is applied user brings stub router, plugs it in, and it advertises a ULA prefix in PIO other devices on the link start configuring a SLAAC IPv6 address and try to use this to communicate (and routing fails because the DHCP managed ULA was not used as the source, but rather the SLAAC based ULA) But maybe this is not relevant because the source address selection algorithm would always pick the correct, managed ULA due to a better prefix match with the IPv6 destination address ?
Regarding the DHCPv6-only use case, we are assuming that the network operator wants to control which devices have addresses on the local link. In this case, they MUST use RA Guard. If they do not, then there is no protection against random devices sending RAs. So this would be a misconfiguration, and hence we don't need to do anything about it.
NAME Right, I also agree we don't have to do anything about solving this "problem" other than pointing to RA guard. But still I think it's worth mentioning: it's the one identified corner case where the SNAC router has unwanted side effects. I wasn't even sure if I was correct in predicting the effects. Considering that there is I think no other IETF-specified / IETF-compliant device that, when plugged in, would instantly disrupt this network in the way that the stub router does. If this is the worst case we can find, it should actually show that our stub router is good to go.
During email discussion in 2023, there were worries that placing a SNAC stub router in a network (with its default configurations) would disturb / harm the existing network / AIL. For example due to the advertising of extra prefixes, or advertising particular (deviating?) values of bits, routes or time-durations in the RA. One proposed solution was to provide a taxonomy (e.g. an appendix) that explains which particular topologies/configurations a SNAC stub router can work, and in which ones it doesn't work, and in which ones it can cause malfunctions (if any). Some examples: stub router doesn't work in a network that has RA-guard in a network without RA guard, and where no suitable prefix is advertised on AIL, stub router can "disrupt" by advertising its ULA prefix. In this case we assume the ULA prefix is not intended by the admin. (Maybe the admin and/or network users should know better here, but anyhow it's a possibility.) Having a better overview of success/fail cases also helps reviewers of the document to judge the risk. FYI here's a pointer to one of the messages in the thread of 2023 that summarizes some cases and how it could be documented: URL
PR resolves this issue.
In -04, "'L' bit is set" is required for a suitable prefix. However section 5.1.2.3 allows sending PIO with L flag cleared, in particular cases. This leads to the issue that the generated PIO AIL prefix won't be recognized as a "suitable prefix" by other stub routers. So the requirement "'L' bit is set" must be relaxed for particular link layer technologies where L=0. Taking one step back – I just tried to summarize SNAC stub router scenario archetypes; both good and bad. Of the below it seems that only scenario 4 is now discussed as having a risk of breaking the network, correct? 1) Non-expert home user connects stub router to own unmanaged home network; it magically works and provides IPv6 stub/AIL routing – no matter whether user’s ISP offers IPv6 or not. 2) Ignorant employee brings stub router to work and plugs it into well-managed network; companies’ IT network magically protects the network from ill effects (RA guard, and/or port-based access control, … ) 3) Ignorant employee brings stub router to work and plugs it into unmanaged (IPv6) network; nothing bad happens - there’s already a PIO prefix with ‘A’ on the AIL 4) Ignorant employee brings stub router to work and plugs it into not-so-well managed DHCPv6-only network; stub router sends RA PIO; many hosts on the link now autoconfigure a ULA which somehow breaks connectivity for these existing hosts. 5) Ignorant network admin connects stub router to company network without changing the default settings; then it becomes similar to 4. This case is btw probably out of our scope to solve and could be solved by the mantra “don’t do that then”. (The stub router is only intended for case 1, but of course the stub router cannot tell apart cases 1,4,5.) +1 on clearly defining the possible breakage scenarios. E.g. some devices may not configure multiple addresses and get stuck with a ULA only? Or known issues with source address selection; IPv4 interactions, etc. in presence of ULAs. When doing this the Type A, B and C IPv6 hosts may also be considered. If we find no issues then we may also state this in the draft in an Appendix – what was considered, and why it isn’t a problem. Esko From: Lorenzo Colitti Sent: Friday, September 8, 2023 11:38 To: Ole Trøan Cc: Lorenzo Colitti ; Ted Lemon ; Juliusz Chroboczek ; Esko Dijk ; Michael Richardson ; Handa Wang ; EMAIL Subject: Re: [Snac] Should a stub router learn RA header parameters from other routers? I am not OK with a SNAC router connecting to an existing IPv6 network and breaking it. If you can elaborate on the type of breakage you are concerned about, then we can discuss it and possibly design for it. FWIW, just the fact of the hosts getting new addresses does not qualify as breakage IMO. All IPv6 hosts have multiple addresses and source address selection generally gets hosts to do the right thing.


Refer to state-begin-advertising to describe the states when ULA site prefix is advertised.
has currently: The "as needed" part here is not so clear and needs to be detailed. E.g. only if an on-link prefix on the AIL is not present, the stub router provides one from its own ULA prefix only if the stub network does not have an on-link prefix or on-mesh prefix (whatever applies), then it creates one from its own ULA prefix. sizes of the involved prefixes? Better to either specify sizes or say it's up to implementation. state some randomness requirements - although for the ULA Global ID it may be clear that it must be randomized; we also have Subnet ID to have requirements for (or not). In any case state these assumptions.
This can be resolved easily by a pointer to other parts of the draft ("as defined in Section N"). Because there are still some pending PRs that impact the text here and add the details, this issue can be postponed until after these PRs are merged.


Current Github text (May 9) still has the text In the last SNAC interim and a recent PR we changed this to L flag MUST be set (case of L=0 is out of scope). Above text still needs to be updated accordingly.


In internet drafts, the IANA Considerations and Security Considerations sections are mandatory. Exact text for security can be adapted also later on if needed.
It's not really true that stub routers create a security problem by sending RAs: rather, it's the case that this security problem potentially exists on networks where RA guard is present, but this issue is in no way our responsibility, and probably shouldn't be mentioned in security considerations.
NAME I've removed the RA Guard text. It was there not because SNAC-routers introduce a security issue, but because we think that there's a group of people/network-administrators/IETFers/others who consider any device that can autostart acting as IPv6 router and can autostart sending ND message on a link as a "security hazard" even if it's not. Mentioning RA Guard there could be a proactive way to hopefully avoid too many discussions around this during future document reviews.
For security we may add: risk of advertising self-generated ULA prefix? Any specifics? if site employs technology like RA-guard, the RAs of our unmanaged stub router will be blocked
These sound more like operational considerations than security considerations. I suppose if we want to advise sites that do not want stub routers attaching to block RA, that would make sense, but I don't think that's really a problem unique to stub routers. Regarding the ULA prefix, the only risk is one we've already addressed: that the prefix could be used for tracking. I think the text on varying prefixes per-link probably needs work, but that addresses the privacy concern.


Closing issue This PR is not building, so need to clean it up before commit. Comments appreciated during that process.
NAME PR is still needed before anything can build ;-)
NAME NAME sorry I didn't intend to close this PR, Github did that somehow after me pushing to the branch. But it's good to have this one closed and replaced by , because the merge direction was specified here the wrong way around. The build is now fixed in the branch and also updated to make it merge-able into main. I prefer to merge rather sooner than later - nits can be corrected with future PRs easily.


… AIL change situations
Section 5.2.3 defines the mandatory DHCPv6-PD client role for the stub router. However, there are no details here what should trigger the stub router to renew/rebind the prefix lease. A reference to RFC 8415 should be added (as it contains some requirements on this topic). See section 18.2.12. Refreshing Configuration Information of RFC 8415. Do we define the SHOULD requirements of 18.2.12 about detecting a new network (new AIL) as mandatory for the stub router, or not? (If not: has consequences for wider IPv6 connectivity in such new-AIL cases) And what about the SHOULD requirement that involves "if the client detects a significant change regarding the prefixes available on the link (when new prefixes are added or existing prefixes are deprecated), as this may indicate a configuration change. " -> can we specify this better? What are the significant changes in our case? And how to do this detection? (e.g. monitor RAs?)
For this issue, we could reference the improved text in URL instead of RFC 8415. This text should be sufficient detail that stub router implementers know what to do. (Or at least, the DHC WG thinks it is enough for DHCPv6 client implementers to know what to do :-) ) PR with this pointer text is still needed.


Flag bits can be referred to as "bit", "flag", or "flag bit". This issue is an editorial reminder to update to a consistent term later on. E.g. "flag" or "flag bit" is most clear I think.
Assigning to myself, to make a PR later on. Everyone and NAME feel free to suggest preferred term. I find "flag bit" the most clear.


Update draft version "stub router flag" -> SNAC router flag fix a few cases where Esko (I think!) missed changing stub router to SNAC router but should have (there are some cases where "stub router" is correct and I hope I did not change any of those.
In the update to the 'SNAC router' name () the flag name was not yet taken along in the update. This issue is to decide on that change also, and if needed make the change. (The 6man document would also need to change the flag name then, first.)


As Esko pointed out, the term "SNAC network" crept in during editing a few weeks ago, and doesn't add value. This pull request changes all instances of "SNAC network" to "stub network".
In -05, the term "SNAC network" is now used but not defined. Could we use the more generic term "stub network" instead? I.e. a SNAC router is able to automatically connect a stub network to an infrastructure network. So the stub network served by this SNAC router is still a "stub network". Or we could use the term "SNAC network" for any stub network that gets automatically connected via a SNAC router. But doing this adds an extra term throughout the document: it's not possible to mass-replace all occurrences of "stub network".
See also which overlaps with this issue, but targets a specific definition paragraph.
Right, this happened when we added a bunch of text in the last interim, and I think was a mistake. I think we just want to use the term "stub network" and not invent a new term. The thing that's new here is the "SNAC router", not the stub network.
I agree - "stub network" makes more sense here.
removed


Add text to the suitable prefix section that allows a prefix that is local and has either the A flag or the P flag set to be considered usable, whereas before only prefixes with the A flag set were considered usable.


This change does two things: change the SHOULD to a MUST when specifying what size of prefix to request, so that only requests for /64 prefixes are allowed, and providing a reference to RFC8415 that says how to provide such a hint. Additional text describes what to do if there is more than one prefix.
OLD: A SNAC router SHOULD request stub network prefixes with length 64. New: A SNAC router should request stub network prefixes using IAPD with IAPrefix with a hint of 64 as defined in RFC 8415 Section 18.3.9.
Agree with adding the details. Is there a reason to change SHOULD -> should ? Seems wise to keep the SHOULD in caps given the MUST requirement that follows soon after it:


Because CE routers are infrastructure
This addresses
NAME could we change "customer edge router" to "home gateway" (per our official terminology )? I see now also the RFC reference in the PR is incorrect (rfc 704).
the text in this section can be confusing when dealing with 2 usable prefixes (see section 5.2.1.4 - ULA/non-ULA). In MCR's words: if there are two suitable prefixes, one of them will still need to be deprecated. According to Ted, this issue is orthogonal to reachability. Perhaps, we should explain that this state-machine does not talk about reachability for both the suitable prefixes. At least give forward reference to section 5.4 for complete behavior. This will explain that we can only transition to STATE-BEGIN-ADVERTIZING and in no case we transition to STATE_USABLE
I think the issue here is not about usable prefixes, but about routes. Suppose we have a DHCPv6 prefix, and the DHCPv6 server doesn't renew it. In this case, we probably want to stop advertising it at some point and start advertising a prefix based on our site ULA. We should talk about the timing of this switch-over. Separately, whenever we have advertised a prefix on either link, we need to continue advertising a route to that prefix until the prefix is no longer valid on the link on which we advertised it. So if we switch from DHCPv6 prefix to ULA prefix on infrastructure, we need to be advertising routes to both for as long as both are valid. Similarly, if we advertise a prefix on the stub network and later withdraw it because a higher-priority prefix is advertised there, we need to continue advertising a route to that prefix on the infrastructure link until the valid lifetime of the prefix we advertised has expired. I think all routers that have seen the prefix need to do this. Then there's the case where a stub router advertising a prefix reboots. We can't assume that it's written anything to stable storage other than what prefix it's allocated for the stub network and for the infrastructure network. So when the router comes up after booting, it needs to advertise routes to these prefixes on the appropriate link until the maximum possible valid lifetime for the prefix has expired. And finally there's the DHCPv6 case, where we got a prefix to advertise on the stub network via DHCPv6. In this case, I think we need to write the DHCPv6 prefix to stable storage when we get it, and remove it from stable storage when it expires. We should limit the lifetime we advertise on the stub network to a constant value (e.g. 30 minutes), and then if we find the DHCPv6 prefix recorded in stable storage, we advertise a route to it on infrastructure for 30 minutes after reboot. After 30 minutes, we can erase it from stable storage so that this doesn't repeat. I think if the BR doesn't have stable storage, then if it reboots with a DHCPv6 prefix still valid on the stub network, we just have to hope that it gets the same prefix when it comes back. If it does not, then that prefix may become unreachable while hosts on the stub network are still using it. We could have the stub network snoop source addresses to discover prefixes still in use on the stub network to ameliorate this situation, but that's somewhat problematic because it's a lot of work.
I think the conclusion of the WG is that we need to have an explicit state machine for the stub router on-link prefix because it's actually quite different from the state machine for infrastructure, where for example we do not need to do DHCP. Important to mention that we need to explicitly deprecate the DHCP prefix if we switch to ULA and vice versa.
One of the things that this state machine needs to talk about is what happens if the SNAC router sees an RIO on /its/ stub network that does not have the SNAC router flag bit set. In this case, the SNAC router should treat this network as an infrastructure network and should not perform SNAC router routing functions or service discovery functions between the two networks. Essentially in this case the SNAC router functionality should be completely disabled while such an RA is seen on the stub network.


Initial try at the definition of a workload.
Closes issue
I think we could be a bit more specific here. Every software is executed for a purpose... I believe the key practical difference between workload identity and user run software such as browsers and interactive applications in that there is no user to perform some interactive authentication flow. Maybe we could try and reflect that? For example, For the purpose of this document, workload is defined as a non-interactive instance of software interacting over network with other software and services. Certain workloads can be live for a very short durations of time (nanoseconds) and run for a specific purpose such as to provide a response to an API request. Other kinds of workloads might be executed for a very long durations such as months or years - examples include database services and machine learning training jobs.
I think I understand what your are saying, but I'm not sure I can express it yet. Also it seems there maybe some special workloads that do interact with user authentication mechanisms. Perhaps those are architecturally distinct pieces "Authenticaition Services"


added Attestation as a function performed within the Server box. defined Agent. defined Attestation.
Thanks I think this helps my understanding, I'm sure we'll have more refining to do, but thanks for providing the text to get started.


Updated figure in
NAME I made a slight update to remove the word authentication in the text since authentication is one specific type of interaction, there may be many others. This might also be a good place to introduce "context" that is propagated (although that seems to be more a topic of the next section


Define workload identity. Resolves issue
The section talks about identity then defines identifier -- I would recommend it separate things a little more and clarify the differences and relationship. Is the identifier part of the identity? Does it point to the overall identity? Augment it?
NAME - I modified the section to differentiate workload identity and identifier a bit more. Let me know if it looks good enough to merge in as a straw man for the identity section. IN any case we can discuss in the 120 meeting
NAME definitely clearer that they're separate concepts now, and all this can be refined as the draft moves on. Thanks for updating!
Some (rather nit) comments that are not related to what's being discussed on the mailing list.


Fixed some of the wording and parallelism in the intro to keep the same ordering of X.509 certificates followed by Workload identity tokens. Generalized some of the phrasing. Removed concepts that aren't well defined in the document, such as "bottom turtle". I'm not opposed to adding these, I just don't think they make sense without an explanation of the analogy either inline or by-reference; so I tended towards keeping the document self-contained. Provided initial content for the Delegation and Impersonation, and Asynchronous and Batch Requests sections.


[8:31 AM May 30 in slack] To summarize the near term plan: Joe: security considerations and interaction with TLS Brian: ID Token and DPoP-inspired Yaron: Message Signatures this is the "DPoP-inspired" part A preview editors' copy of this PR can be seen at URL


There's nothing necessarily RESTful about this nor should it be limited to REST. Let's just not use the term. URL is a fun semi-related read, if you have or can find the time.
Quoting the article: I am not as young but I agree with this sentiment. Having said that, I guess a standard needs to be reasonably precise in its usage of terminology, and so I accept the PR.


Change trust root to trust anchor, to align with Trust Anchor terminology as used in rfc5280.
sure


Editorial.
Commenting as identity enthusiast as opposed to WIMSE co-chair. Consider replacing WIMSE Identities with WIMSE Credentials since it is the credential that is being verified, which may include a Workload identifier and possibly other claims.
WIT stays though.


Revised the workload identity section to align with RFC 5280 and include trust domain. Aligns closely with SPIFFE, but allows other schemes to be defined.


Reworked the TLS section a little. mostly addresses issue
Mostly editorial changes, but also MUST->SHOULD


sorry about the trailing spaces ...
Some editorial things, content-wise I'm happy.


Adds 'wth' claim to WPT to bind WPT to WITs.
NAME please also update the relevant IANA section so we don't forget.
I realize I missed a meeting but why did we add this?
What's the threat? Different WITs with the same cnf key and a compromised middle thing?
I just don't see it...
Iss in the WPT is even less useful with this too.
Yes, currently we don't have strong binding between WPT and WIT. Only the fact that . I don't understand the "even less" part but I see that this is somewhat duplicated now.
Should be: WIT sub == WPT iss. And just to state it explicitly: people are likely to extend the WIT with various "junk" (i.e., policy) and that wouldn't be covered otherwise.


Taking our last conversation into account I wanted to contribute my take on the problem and wrote the introduction the way I see it. This is not a version that can be merged, but the best way to show it in a diff and allow comments. Let me know what you think.


These changes focus this draft on the minimal definitions required to secure the data structures defined in RFC9162 using CBOR and COSE. Extraneous information has been removed. There is a wip implementation available here: URL There is a demo here: URL
LGTM!sry 4 the l8 approvalI recommend merging now


Feedback gathered from URL
Consider attempting better CDDL by applying URL We would like some time to discuss this draft at IETF 117: URL https://ietf-URL We've made several changes that were requested at 116. We provide a sample implementation demonstrating how to use RFC9162 tree algorithm with COSE Sign1 to create signed "inclusion" and "consistency" proofs. We updated the draft to support registration of other tree algorithms which can be specified in separate documents. If there are other changes folks would like to see, we are happy to try to get them in before the cut off date. Regards, OS ORIE STEELE Chief Technology Officer www.transmute.industries


This PR attempts to generalize "merkle tree alg" and associated tags for "merkle tree proof types", to: "verifiable data structure" and associated "verifiable data structure proof types". This is intended to support similar structures that provide similar proof types, but that are not based on merkle trees. We are specifically thinking of cryptographic accumulators, and the merkle^2 paper.
I'm not attached to "verifiable data structure" or "verifiable data structure proof types", just needed a word that didn't imply "trees".
The overall "verifiable data structure" generalization is fine, and doesn't impact the structure of the document too much. However, I am not fully satisfied with generalization of proof types. It seems very strange that TBD1 ("binary merkle tree using sha256", a tag that appears in the protected header of the COSE signed root) and TBD2 ("binary merkle tree using sha256, inclusion proof", a tag that appears in the CBOR type for inclusion proof associated with TBD1). It seems clear that TBD2 and TBD3 are refinements of TBD1 that should ideally be in a separate registry. Furthermore, as discussed last week, the notion of proof type (inclusion proof, consistency proof, freshness proof...) is a lot more meaningful than the notion of verfiable data structure type for protocols that build on COMETRE. Therefore, it may be natural to define either a universal type for each proof type, or at least agree on the convention that proofs for all verifiable data structures must be CBOR tagged with the same proof type, which is then defined as a separate registry. Each RFC that extends COMETE must define a new verifiable data structure but may or may not extend the proof type registry. For instance, it would allow the CCF_ledger to use the same CBOR tags for inclusion proof and consistency proof instead of having to define 3 tags with different semantics.
There were basically 2 paths discussed: (implemented in this PR) treealg (TBD1): RFC9162 (1) inclusion proof (TBD2): bytes based on treealg consistency proof (TBD3): bytes based on treealg treealg (TBD1): BitcoinMerkleTree (2) inclusion proof (TBD2): bytes based on treealg consistency proof (TBD3): bytes based on treealg treealg (TBD1): Merkle^2 Tree (3) inclusion proof (TBD2): bytes based on treealg consistency proof (TBD3): bytes based on treealg search proof (TBD4): bytes based on treealg non inclusion proof (TBD5): bytes based on treealg (previously discussed at IETF 115) treealg (TBD1) : "RFC9162SHA256INCLUSIONPROOF" (TBDA) proof (TBDB): bytes based on alg treealg (TBD1) : "RFC9162SHA256CONSISTENCYPROOF" (TBDC) proof (TBDB): bytes based on alg Other things to consider... Can an unprotected header contain multiple proofs for a single type? Can an unprotected header contain multiple proofs of multiple types?
NAME NAME thank you for the reviews. All the CDDL examples will need some help, and certainly there is a lot more editorial work that needs to be done to fully align to this approach. I tried to do the minimum in this PR to host the discussion, but if we merge this, there will need to be further cleanup.
I should point out that the deletion of the consistency proof CDDL, means that it shows up before you define it below. If you think that is ok, I am fine with it.Approved, acknowledging the need for further editorial work & CDDL examplesI agree with Orie's choices; "verifiable data structure" and "proof type" are good generalizations, and I prefer the 2-layer algorithm as e.g. some verifiers may care about a commitment to a VDS even if they don't use a particular proof type.


This PR aligns the abstract and intro with generalizing away from specific merkle trees
LGTM


For exploration purposes, the document had a number of tree algorithms that are not specified in RFCs or similar. This PR removes them again, transferring them to PRs for further evaluation.
I'm good to merge this from a process standpoint I still hope we can document these in some acceptable way for IETF.


This PR build on and attempts to clarify what is generic vc what is specific to RFC9162 encodings
Mostly improves on the earlier version, I like the generality it allows for. A couple of larger questions in here amongst the suggestions


Informal references: URL URL TODO: Add CCF reference to Merkle tree definition (including details on the leaves). Change target branch to after is merged.


Informal reference: URL TODO: Add QLDB reference to Merkle tree definition. Change target branch to after is merged.


and have been incorrectly merged. This PR brings the content to the state of 00 as in URL
NAME can you give me merge permissions?


Changes from IETF 116 hackathon
I'm stopping on this PR, before it gets even larger.
NAME I have made several more changes, please review when you have a chance.
I am merging, we reviewed this content together at IETF.


The Connection header field is oddly inconsistent with the other field definitions in how it defines the grammar late in the description. I think it is worth an editorial fix.


See URL
Mailing list discussion:
We might want to clarify the nature of the response elsewhere, but this seems fine.


In Caching 3.3, we say "a cache may store a response body that is not complete" -- I think we should drop "body" In Caching 7.1, we use "payload" -- probably should be "content"


That needs some tweaks ... the action words like SHOULD are supposed to be targeted to implementation roles, not protocol extensions. Can we just copy the same Note from the Accept section?
I can avoid the SHOULD NOT. I used different text because for transfer codings "we" actually own the registry, while for content types we do not...
Heh, I think it's a stretch of the imagination to think that we control the registry even when we define it ... people still deploy first and register later. In any case, a simple should be sufficient.
I actually reverse my opinion about the SHOULD NOT - we already use BCP14 keywords in the paragraphs before and after this one. So please consider again the pull request.
My .02 - acknowledging that 2119 keywords are only intended for implementations roles, I don't think that throwing up our hands and saying "people will do what they will" is productive. While some people ignore (or just don't read) the RFCs, many do, and when they do, we owe it to them to communicate in the clearest, concise way possible. 2119 keywords are a fantastic tool for doing that.
NAME - so are you ok with this change?
I am - although if we come up with a unified way to deal with requirements consistently across the documents, it might change.
Continuing from URL In the current spec, nothing is said about how to handle transfer-parameters. Notably, nothing is said about the case sensitivity of the parameter key. This results in a conflict with the TE header: if you see a "q" token, you cannot know if it is a transfer-parameter vs a t-ranking. It is noted that the "q" token is case insensitive in section 4.3.
See URL
OK. An edge case of an edge case. Note that among the currently registered transfer codings, none defines parameters. Drastic options might be: Disallow parameters on transfer codings (and thus also on content codings) Remove quality values on transfer coding negotiation. More realistic: in the registration procedure for content/transfer codings, note that a parameter "q" is discouraged (forbidden) due to the ambiguity in "TE". Should I make a proposal for this?
Actually, we have a similar situation for Accept:; see :
Not only "q" but also "Q": case sensitivity isn't mentioned for transfer parameters.


HTTP defines its own protocol versions as having two numbers "URL" regardless of anyone's future opinions on the subject. This is necessary for Via and Upgrade. In the past, it has always been assumed that no document claiming to define a version of HTTP would ignore that fact. Regardless, HTTP/1.1 needs to refer to future versions of HTTP within the scope of its own syntax. Hence, the following text (currently in crefs) has been suggested for the last paragraph of the section "Protocol Versioning" in Semantics.
SGTM
Why "ought to be used"? I understand that you want to avoid MUST/SHOULD,..., but why not just "is used"? That would make it:
+1, let's limit the RFC6919 language. You're defining a mapping between formats, not really adding new normative or moral requirements. The "0" is simply how a major-only version is rendered in a URL field.
The background here is that we used 'ought' liberally in 723x (e.g., 49 times in 7231) to give implementers guidance towards good behaviour without affecting conformance for existing deployments. So this is entirely in the spirit of the existing specifications.
That use is often appropriate. In this case, the conditions are such that "is" works. It is also more assertive, which works.
all: try and do your best to focus on the substance of the question rather than the editorial wrappings. Thanks.
The substance of the question is obvious, in my opinion. I'd question whether there's a need for discussion on that. However, the editorial wrappings do actually matter in having the final document communicate what we want it to communicate. It's feedback I'd typically give on a PR rather than the issue, but in this case the issue contains proposed text, so the editorial feedback is here too.
Agree with Mike. I came to this issue almost by chance, I thought it was important because Julian wrote a mail to the mailing list. When I had a look at the issue, the only thing that caught my eye was the "ought", because the substance is indeed obvious (at least to me). If "ought" is used liberally in 723x, there may be good reasons for it, and in many places it may make sense. But I'd ask the editors to go through these 49++ times and see if it wouldn't be possible to replace some of them with "is". "is" just reads so much more easily where it's appropriate than "ought".


The text is almost the same as in RFC 4918, except that I removed the somehow bogus claim that status code 400 wouldn't be right.
Are we updating the IANA registry to point to this document? The only slight concern I have here is that this may unintentionally reinforce the view that "real" status codes are required to be in the core document. If we can find a way to discourage that view, that would be great (but that's a separable issue).
Yes. For all codes. That occurred to me as well.
Ok, should I merge this one?
It's commonly used, but defined in RFC 4918 (WebDAV),, which continues to confuse people. Should we include it in the core specs?
For reference: URL
+1
Discussed in Montreal; support for doing this.


Looks good to me.
incorporate: URL
What do you want to incorporate exactly?
418 is reserved.
Well, not in the IANA registry right now. Wasn't the plan to do so without publishing something?
My recollection was that a publication is necessary; that's why it's here.
ok


The specification of can be read to allow the response to be reused for another concurrent request, since it's specified in terms of non-volatile memory. Likewise, other cache directives are silent on such reuse. So-called "request collapsing" has become quite common in proxies, reverse proxies and CDNs. Clarification as to whether such reuse for temporally concurrent requests would be helpful (in the case of and otherwise).
This also seems related to and , which allow the response to be re-used after cache control would say not to re-use it: URL
Discussed in Montreal; introduce the concept of a single-use response, and carve out no-store.


seems like it should be in messaging.
Part of it needs to be in messaging (how to do it per version), while a shorter description needs to be here just to point out that it is version dependent. The semantics don't make any sense otherwise.
Ack. Will take a stab at it.
The caching document should clarify that only final responses are cached.
Works for me.


I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).


Sounds good to me.
Might want to mention the scope of applicability for HTTP caching a bit more carefully, esp. with respect to other caches (esp. in browsers).
I think the best thing to do might be to change to something like "Relationship to Other Caches and History Lists" and expand accordingly.
Applications using HTTP often specify additional forms of caching. For example, Web browsers often have history mechanisms such as "Back" buttons that can be used to redisplay a representation retrieved earlier in a session. Likewise, some Web browsers implement caching of images and other assets within a page view; they may or may not honor HTTP caching semantics. The requirements in this specification do not necessarily apply to how applications use data after it is retrieved from a HTTP cache. That is, a history mechanism can display a previous representation even if it has expired, and an application can use cached data in other ways beyond its freshness lifetime. This does not prohibit the application from taking HTTP caching into account; for example, a history mechanism might tell the user that a view is stale, or it might honor cache directives (e.g., Cache-Control: no-store).


Caching : Can the cache send any old entity-tag it has stored for the URL in these headers, or must it only do it for those that can be selected by the incoming request, as per the secondary cache key algorithm? Also, this section uses "selected" in a different meaning; that should probably be changed to avoid confusion.
I think it needs to constrain it to the selected stored responses.
We need to be careful to include the case where an upstream cache (or UA) has sent a conditional request (perhaps with some of its own stored etags) and this cache is forwarding them along.
When sending a conditional request for validation, a cache updates the request it is attempting to satisfy with one or more precondition header fields. These contain validator metadata sourced from the stored response(s) that have the same cache key (both primary and secondary, as applicable). The precondition header fields are then compared by recipients to determine whether any stored response is equivalent to a current representation of the resource. [rest as before]
Isn't this presuming the validation is part of an upstream request? What if the cache is auto-refreshing stored responses during idle time? Maybe we should define these as separate cases?
When generating a conditional request for validation, a cache starts with either a request it is attempting to satisfy, or -- if it is initiating the request independently -- it synthesises a request using a stored response by copying the method, request-target, and request header fields used for identifying the secondary cache key [ref]. It then updates that request with one or more precondition header fields. These contain validator metadata sourced from stored response(s) that have the same cache key (both primary and secondary, as applicable). The precondition header fields are then compared by recipients to determine whether any stored response is equivalent to a current representation of the resource.


NAME PTAL.
Client/Server Messaging still is HTTP/1.1-specific. Suggested deletions below: Also, trailers?
Textual reason-phrase is also 1.1 specific.
NAME what's the implication of that? It's already suggested to be deleted.
It wasn't in a previous iteration of your suggestion -- see your edit history. Perhaps we noticed this in parallel?
Ah ;)
Somewhat related is .
This text seems out of place in 3.2 Storing Responses to Authenticated Requests. It also omits .
It seems like it's covered by 4.2.4 pretty completely.


Good catch.
...currently defined in RFC 7538.
This would obsolete 7538?
Yes. Now the good question is how much of RFC 7538 include. My proposal would be just to include parts of URL, but to point back to RFC 7538 for additional information (non-normatively).
Seems reasonable to me.
Maybe we should also add the table from URL somewhere.
Possibly at the top of the 3xx section.


I had in mind something a little more general, that would include fields which are defined like Vary:


Note that there's one more reference to pragma remaining, but that will be taken care of by .
... is still hanging around, and even less relevant. We still recommend sending it in certain circumstances; can we drop that?
Specifically: [ ] In Constructing Responses from Caches -- although see [ ] In Pragma, "When sending a no-cache request, a client ought to include both the pragma and cache-control directives" [ ] In Pragma, "When the Cache-Control header field is not present in a request, caches must consider the no-cache request pragma-directive as having the same effect as if "Cache-Control: no-cache" were present" Proposal: Change s registration status to "obsoleted" Remove requirements relating to it. Retain text explaining its semantics, and note that it's superseded by .
BTW, I'm comfortable doing this because we're getting rid of requirements on request CC anyway -- see .
I have a few editorial changes to suggest here to make it more readable and remove the trailing note, but it is probably easier to commit this as is and we can tweak it later.


For .
Caching still refers to a "disconnected" state, as well as "cannot reach" and similar states. This needs to be rationalised. See thread: URL
Should wait for resolution of .
I'm inclined to move the definition of "disconnected" up into "overview of cache operation" and refer to it consistently -- including when "cannot be reached" is used.
Wow, that is a bad choice of word for that definition in the old text, but +1 to the change. I used to know what the right term was for that ... drawing a blank at the moment. I think it was something like "origin unreachable" or "upstream unavailable". Bah.


For
I believe the registry URI should actually say "http-header-fields". Can I change that?
The text might be confusing to IANA as the registry does not exist yet.


I also suggest closing here : the main reason for getting data without a request is an error reported by the server before closing (e.g. 408). Another reason may be a server implementation issue (extra CRLF, inconsistent multiple content-length, inconsistent content-length+transfer-encoding, user-fed incorrect error message). In all these cases the message delimitation is wrong and unrecoverable. Thus the client trying to "fix" it will in the best case be useless (close following), and in the worst case have nasty side effects. In haproxy the only case we try to address is the extra CRLF that a few old servers send slightly after data. If extra bytes are sent immediately after data, we close. If the extra CRLF happens slightly later, we find it while parsing the next response and the CRLF is silently skipped.
Everyone OK with this now?
Well, like Roy, I'd even prefer a MUST close, but I can live with a SHOULD.
It doesn't seem to account for the extra CRLF case. Maybe just add "... unless the data is limited to CRLF"?
CR and CRLF?
I was thinking the same but hesitating. BTW NAME it would be LF and CRLF. But quite frankly we could stick to CRLF only since it's the only known bogus pattern widely deployed in field.
updated.


Also: change scripts that BAP is invoked with correct options. Note: I did not use "%i" for case-insensitive strings as this is the default anyway. If there is confusion about how a certain protocol element is matched, we should re-state that IMHO in the prose. The collected ABNF uses non-extended ABNF syntax. If this is a problem I'll need to do a bit more work on the tooling.
Should we just adopt wherever we use a string?
Yes, I think that's what the IESG wants us to do. (We were directed to use it in alt-svc)
I've started a branch (mnot-133). Question: do we want to convert things like this: into: ? We do that a fair amount for case-sensitive strings.
Yes. Let me take care of this.
+1
OK. I'll leave my branch there if you want to start with it; otherwise feel free to delete it.
FWIW, I'd prefer to do this only in the places where the string actually is case-sensitive.
I guess I forgot to close the ticket.
Looks good to me. I checked and we also say that they're case-sensitive in the accompanying prose for each instance (although for weak ETags, it's a bit far away).


(alternative approach)
AcceptAccept-CharsetAccept-Encoding`](URL) request headers is of very limited use, because: With a qvalue higher than another value, it says "send anything in preference to something specific", which isn't useful With a qvalue lower than another media type, it says "send a more specific value in preference to something else", which is already implied by HTTP With a qvalue of 0, it says "don't ever send other value" -- but a server can always ignore that, because this is an optional-to-implement extension In media types (e.g., ), it has been cargo culted a lot, but doesn't actually give the server information it can use. Can we deprecate in these headers, or at least restrict its use / give better guidance?
Discussed in Montreal; support for documenting limitations / caveats.
We can't deprecate it. We can explain when and where it isn't useful.
+1 to generalize this. However, we may want to still reference these rules from each individual header field definition.I think the first sentence needs some editorial work, but +1 to committing this first.


This one is almost trivial. Except: previously, the ABNF sort-of ruled out parameters in the ABNF (at least that was the intent) this is now done in prose - we need to say though what to do when parameters are present - is "SHOULD treat as error" correct?
Should not enumerate the actual coding names. Make the ABNF generic and point out that the predefined encodings do not have parameters.
See URL
Instead of saying in each encoding that the presence of an undefined parameter should be treated as an error, it would be better to say that once in the main section for any encoding that does not define its own parameters. But +1 anyway.


I think this is ready.
I think the registry is supposed to reference the obsolete spec where it was last defined, not the spec that mentions it briefly in a change note. In this case, it should be referring to RFC2616 Section 14.15.
NAME - I think the IANA registry should point to both - pull request updated.


() work in progress, feedback appreciated. is the actual rule mapping correct? prose in the convered ABNF, should I add the cardinality as comment?
re 3) turns out to be hard as long as we have productions that mix list with something else (see separate issue), because we can't inline comments inside and ABNF production
NAME - your turn to review...
See . Mailing list discussion starts here:
See also
A simple fix for this would be to simplify the list expansion to just map , and to put all other constraints in prose (the current approach doesn't work anyway due to the rules for empty list elements which are not counted).
Proposal for recipient list rule mapping: More eyes requested :-) NAME NAME
The current proposal is incorrect as it does not allow a singleton element.
Maybe: better... for readability:
PR updated
And maybe 1#element => element *( OWS "," OWS [ element ] ) right?
NAME that'd outlaw , which seems wrongish?
Closed by commit e475f36 for the recipient case. Note that this may become obsolete if we switch to only providing ABNF for what is good to send.


NAME yes, as per issue discussion I was reconsidering this. See updated PR.
yeah, I like that. Will update.
It'd be good to say something about how weakly-framed content (e.g., no Content-Length in 1.0; no CL or chunked in 1.1) should be handled differently by caches, especially during reload. From URL
In , add:
currently has: Observations: the reference really should be more specific and go to "6.3. Message Body Length" is this clear enough for protocols other than HTTP/1.1?
Referring to h1-messaging 6.3 would make this specific to H1. Referring to 4.3.1 in caching keeps it protocol-generic. If another version doesn't crisply define what's an incomplete message, we can deal with that separately.
I think the text in 3.1 should change to:
This seems reasonable. It's also related to URL, asking whether servers can wait for end-of-stream to consider a message complete in HTTP/3. (Proposal in URL is "no, you can't.")
No, HTTP/1.0 is consistently optimistic. If the server desires more rigor, it can do the work to supply the framing that would indicate an error occurred. When it fails to do so, it is deliberately choosing to maximize performance over correctness. Hence, the assumption has always been that a close-delimited message is always complete.
I think Mark's suggestion is right. I would characterize HTTP/1.0 as ambiguous and that causes revalidation deadlocks. Its somewhat worse that this pattern needlessly shows up in HTTP/1.1 as well.
Thinking on this for a while, I think MAY might be more appropriate than SHOULD here; I have a strong suspicion that most caches will not consider a close-delimited response as incomplete. I could test it, I suppose.
Also, in the sentence: ...I think s/partial/incomplete/, based on context. Any concerns there?


See ; the issue is not just about moving the text.
I understand that, I just thought it would be good if we could split this into two changes; that makes it easier later on...
See - I'm on it.
I think I'm ok with the actual changes, but we need a summary for the "Changes from RFC 723" section. Proposal:
NAME I think this is ready to go.
We still need to document this as a normative change from RFC 723.
Done.
LGTM.
As discussed quite a bit, retries in HTTP need to be better defined. In particular, HTTP does not offer a guarantee that any particular request will not be automatically retried.
Messaging - 9.4.1. Retrying Requests contains some things that probably belong in Semantics, probably somewhere up in the architecture section. Beyond that, I think the action here is to clarify a bit more that POST etc. requests are actively retried by many UAs (e.g., most Web browsers) because of H1's connection management issues. NAME can you confirm that that's H1-specific?
generally goaway would determine this in h2
Semantics - 7.2.2 Idempotent Methods talks about retries some. I'm inclined to add a very short reference to it in architecture -- e.g., "Some requests can be retried in the event of failure; see ref" -- around the sentence starting "A client sends an HTTP request..." in 2.1 Client Server Messaging. In h1-messaging, I'd like to add the behaviour that UAs actually implement to the list of examples of how they'd know it's OK to retry. AIUI, that would be something like: NAME is that accurate?
Well, the server could have had an opportunity to process a request, because they routinely start processing based on only a small amount of the header. The fact is that some clients retry based on very weak signals, risking duplicate processing in favour of greater robustness. The retry logic as I understand it is "have I seen any hint of a response? no? retry."
It seems like either clients or the spec should change, then. I suspect clients will not...
There's two things you might consider here: noting that clients might do some things to retry based on their own determination of when that is appropriate (for example, in the extreme, retrying if the connection breaks before any byte of a response is seen).recommendations about good practice, which probably doesn't want to point at what the most aggressive clients (i.e., browsers) might choose to do Trying to walk the line without making that distinction is probably too hard.
That seems like a good direction, except that the spec currently contains a MUST NOT; "good practice" isn't that strong... MUST NOT (BUT WE KNOW YOU WILL)?
Yep. Part of this work is in aligning the spec with reality. A SHOULD NOT is probably appropriate. No need to resort to RFC 6919 language.
Proposal:
LGTM. s/; f/. F/
While I'm fine with this, I'm stil having a big problem with retries. Some of our (haproxy) users are pressuring us to implement the so-called "L7 retries" by which if the intermediary faces a problem with the server after the request was delivered, it happily retries it, even for a POST! Not only it's a technical problem (requires all requests to be buffered for the time it takes a server to respond) but it's in total violation of all rules. The problem here is that there's an ongoing trend for doing this and users find it normal since it allows them to hide their constantly crashing servers... And usually they consider that the application deals with replay protection by itself so obviously the infrastructure must retry. Thus my big concern here is to figure till what extent an intermediary could reasonably retry, or how we could have signals between UA and server to indicate if the request is retry-safe.
A protocol extension seems reasonable for that case; I think it could be interesting to clients -- both intermediary and otherwise.
Just leaving a note to remember to go through to make sure we got everything.
I had a bunch of editorial suggestions to make and decided to just make them directly to the pull request to save you the time and annoyance. I hope that is okay, since my changes just reduce the prior diffs.


…se) (see )
I chose "Payload" in the reason phrase for consistency with 413... We do use "enclosed representation" in many other places, such as in the definitions of PUT, 401, and Content-Location. Maybe use "payload" throughout? (I guess we have way more terminology to clean up)
NAME it's not incorrect, but sure we can tune things even more...
The term entity to be dismissed, in favor of It's used here, as 422 is C&P from webdav URL
The only thing that causes me concern here is that you're using both "representation" and "payload" in a manner that's technically correct (I think), but is likely to cause readers confusion about the difference between the two. We don't use "enclosed representation" elsewhere, but we do use "representation data enclosed in the payload body" and "enclosed payload body" (which seems odd to me). It would be very good if we could clarify and consistently use this terminology (here or in another bug). PS I was very tempted to ask you to move the prose tuning to a separate PR, but I won't.


HTTP Methods have 3 boolean properties, all of which says a registration needs to define, but only "Safe" and "Idempotent" were included in the registry while "Cacheable" was omitted. I filed this as URL, but it probably makes more sense as a change for ter.
I think the only concern I have here is that people often misinterpret "cacheable" - e.g., see .
FWIW, that's because it isn't a boolean property of the method, but rather a capability inherent in the system in which one aspect is the method semantics. I'd prefer to remove that from the registration table. We could still require that the registration describe how and under what conditions the method semantics might be cacheable.
It's not in the registration table, and I tend to agree it should be kept out for the reasons above.
This was discussed regarding Variants, and I think the answer will be the same; we should record this sort of thing in documentation elsewhere, e.g., the .
URL says but then the method definitions themselves seem to consistently say After this discussion, I think the method definitions ("The response is cacheable") are more correct, and that therefore my initial suggestion in this erratum is incorrect. URL repeats the less-correct form by listing "cacheable" along with "safe" and "idempotent" as properties of the method. I think removing "cacheable" from that list, and changing "If the new method is cacheable, ..." to something like would have prevented me from getting confused enough to file this issue. Do the experts here like that direction?
Note that RFC7540 Section 8.2 relies on that distinction by saying that pushed requests MUST be cacheable in order to be pushed, but conditionally defines what happens if the delivered response does turn out to be cacheable. Eliminating the distinction entirely would leave 7540 slightly unmoored.
I think the proposed edit to considerations for new methods is helpful; we could address the 7540 concern by parenthetically adding "also known as cacheable methods" or similar. Note also the first bullet of . If we can come up with a better phrase than "defined as cacheable" that's great, but it needs to be distinct from response cacheability.
ietf104: mark needs to research the 7540 question to determine if this can be made editorial based on jyasskin's above comment
7540 points directly to 723x for this, so we have some leeway. I think we can address this by parenthetically stating that a method that does not define the conditions under which it can be used by a cache is by definition not cacheable. Will do a PR.
Looks good to me.


In its current wording, I interpret to allow to be used in the following two situations: The requested operation is forbidden in the current state of the resource. The requested operation is forbidden (for the user identified) by the provided authentication credentials. This ambiguity is established in the following paragraph: The ambiguity is somewhat lifted (but not entirely) by the last sentence: However, I believe the ambiguity exists and causes a lot of developers to believe that is only applicable to authorization errors. I think the wording in the previous paragraph: …the example given in : …and the wording in : …as well as existing practice establishes that is the correct status code to respond with when the requested operation is not allowed in the current state of the application (use-case 1 above), regardless of the header provided. Introducing the ambiguity of only being applicable to the provided authorization when authorization is available makes the status code harder to reason about and therefore harder to use in practice. Would it be possible to remove this ambiguity somehow? Here's some suggested wording:
ISTM that the phrase "authorize it" in the first sentence of 6.5.3 is the root of the issue. I note that 2616 used "fulfill it" instead; we should dig around and see if that was an intentional change.
I agree "authorize it" is the root issue, but think it's exacerbated by the following paragraph. It would be good to clarify the entire section to make it obvious that the presence of an header doesn't require the semantics to change.
Discussed in Montreal; ok to change.
The change from “authorize” to “fulfill” helps to resolve the ambiguity, although I would like to see a in the following paragraph: >If authentication credentials were provided in the request, the server consider them insufficient to grant access. The client SHOULD NOT automatically repeat the request with the same credentials. The client MAY repeat the request with new or different credentials.
I don't think a "MAY" helps here. The current text is: That's a statement of fact. If the credentials would have been sufficient, there wouldn't be an error. (It does not necessarily imply that things would have worked with different credentials).
I think that’s exactly what the current text implies: That sufficient credentials would have lead to a successful request, regardless of the state of the resource. If we take the example from RFC 7807, there is nothing that a change of credentials can do to make the request succeed — the credit is out regardless of the authorisation.
Question: this change makes 429 a specialization of 403, right?
But that proposed "MAY" isn't permissive. This is a statement, not necessarily of fact, but of one likely possibility. Perhaps "the server considers" => "the server might consider"


: That is incorrect, as the status code could be 204, or the response might come with chunked encoding (even when empty). This is .
What purpose is this requirement serving? It seems to have the effect of prohibiting with a zero length payload. Shouldn't RFC 7230, "3.3.3. Message Body Length" be sufficient for determining payload sizes?
Agreed. The text makes it sound as if OPTIONS is somehow special. Giving advice might be good, but the use of normative keywords makes this confusing. The simplest fix might indeed be to remove the sentence.
LGTM


For .
NAME it didn't so much introduce it as much as it just changed the nature of the example.
Well, before the term "timing attack" did not appear in the spec...
... needs a rewrite. I'm thinking of splitting up into distinct sections, e.g., Cache Poisoning Timing Attacks Caching of Sensitive Information Information Leakage ... with appropriate mitigations in each (e.g., double keying).
This also adds "Timing Attacks", right. Updated change log as well.


As suggested in the issue. Looking at it, more text could be moved up, or the entire section could be moved up (e.g., as a subsection of where this text went), but this seemed reasonable.
-1; this needs to be where CRLF is used, not a different section.
Like that? Wasn't sure what you meant by "moving HTTP version up..."
I meant literally move the section titled "HTTP Version" up above the section titled "Message" and then move "Parsing" to a subsection of "Message". I'll see if I can tweak it.
Would this
... is awfully far from the definition of the message format; IME people read the start of section 3 in isolation and don't see the text below. Maybe move 3.5 up?
Agreed. I have fixed this in 33c709c76bfeafbc2b44b682f1e88f99877e3aca
How about moving the three paras starting with "Although the line terminator..." to 2.1, and moving the out of the definition of and into , to be consistent with ? Then all of the text about is in one place.
See also .
My idea of moving version up to top didn't work out,but moving it down to the third subsection solves both problems, I think.


and with the hope of being useful for quicwg/base-drafts I suspect that we also need to move "Initiating HTTP over TLS" down to the section on Routing, but that can be done separately.
This is now ready to merge, IMO. There is more work to do after merging, specifically taking the old RFC2818 description of initiating HTTP over TLS out and moving just the 1.1-specific bits to Messaging, but I don't want to do that in the same PR.
I agree with Roy. This is big enough that merging and iterating is the right path.
From :
Looks good enough to merge and iterate upon. Will need change notes, of course.


pasted twice, second should have been s-maxage
The commit d4695a3e422f677d880dc64504c492bf71b6039d for added a paragraph to s-maxage that contains the directive must-revalidate. I think this was supposed to say s-maxage and worded for shared caches?
Sorry, been travelling. This was intentional (although I forgot to update the directive name). implies , which implies . That seems like a lot of indirection in the definition. I agree this wasn't a great way to do it, though. I think the options are: Leave it as is (i.e., two levels of indirection). Leave it as is, but use linking more explicitly so that the indirections can be followed more easily (at least in HTML renderings). Inline the appropriate text from into both and . I think those are ordered according to my preferences, least to most. (I strongly suspect many people don't realise has these semantics, because of it having a name similar to . Making them inline rather than referenced might help)
I agree with the conclusion, but am pretty sure that you meant to say s-maxage in that section defining s-maxage. That's all I changed, so it should be fine unless you wanted to add more text to explain why. I don't think it is necessary to explain more because adding s-maxage implies the server wants shared caches to reuse the response.
I agree with NAME that the additional semantics of are surprising. In particular due to section 4.2.1, comes disguised as the "different value for shared caches". So , and the difference is the handling of error cases like with ? Could you please try to explain why the additional semantics of make sense – that is, why did you not just make it the alternative TTL for shred caches? Thank you!
Ah, okay, so the added paragraph had the right directive before but simply doesn’t make any sense given the context.


(also adds two paragraph breaks)
Thanks! To be completely formally correct, the term from RFC3986 should not be quoted as "user authentication information in the URI" but as "user authority information in the URI". Is that correction possible?
WFM. NAME ?
No, it isn't correct to say that it is user authority information. The purpose of userinfo in a server-based URI format (this://server/) is to supply canned authentication data for use if the server requests such information. It is strictly for use on the client-side and is not directly passed in HTTP unless that (Basic) happens to be the form of challenge requested by the server.
That would be an override by HTTP of the definition in RFC3986 then? (Not saying that is illegal; HTTP predates this URI spec.)
The generalises the constrained use for authentication by allowing the entire URI to be a server-side spec and the client to derive a hint about it as a possible authentication user. This can end any such difference in interpretation between HTTP/bis and the URI format. I do know this is a broadening of the user concept in HTTP; I also believe that this is not without a need.
RFC3986 says: Specifically, the userinfo supplies the information necessary to gain access to the identified resource via a process of authentication. That process is selected and defined by the origin, not by the URI, and the username is not an identifier of authority. Note that userinfo for http and https URLs has never been allowed, going all the way back to RFC1738. Some applications do use that syntax, internally and in a way that is not subject to the Internet standards process, so we warn about it in general.
The states RFC3986 does not forbid or even discourage the "user" in the userinfo subcomponent. It only says and continues to describe the intricacies of ":password" handling. The user is part of the authority section of the URI and its purpose is to zoom in on a scope for authoritative resource addressing. This syntax has in the past been (ab)used for Basic/Digest authentication details, which only works if visitor and visited resource happen to be the same user; it is this (ab)use that is now deprecated. I have written an that places it in a header with the intention of adding user names in much the same manner as host names, as a selector for a naming scope of resources. I believe that obscuring the authority for the purposes of phishing is not really mitigated by parsing the userinfo; subdomains in DNS offer similar notational flexibility. Parsing does help against misleading password popups, but these are probably easier to remedy when credential inquiries are only made in response to and headers.
Discussed in Basel. Correcting the reasoning of why it was deprecated can be addressed editorially. Changing what was deprecated needs to be a much larger discussion and pull in the security community.


I think this is the right thing to do; we added too much text here in 7234.
From : Both state that a (depending on context private, shared or both types of) "cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable". To my understanding, this does not intend to override the requirements from the "Storing Responses in Caches" section (URL) altogether. Instead, I would assume that it only refers to the condition "has a status code that is defined as heuristically cacheable" in that section (or, as it was stated in RFC7234, "has a status code that is defined as cacheable by default")? Would it make sense to amend the list of conditions in that section, appending to the "the response either..." second-level list: "contains a private response directive if the cache is not shared"?
OP here
I'll trust you on the actual change :-)


Header field-names are defined as tokens. This is an extremely permissive syntax, including characters that will cause confusion and likely break some senders/recipients. Most of the special characters allowed are not in the registry or seen "in the wild." Some research would be good to substantiate their use, but a starting point might be: There are a number of strategies we could take to the transition: Like / , mark some characters as "do not generate" but "should consume" Disallow registration of header fields with those characters, and discourage their use in unregistered headers If we have more confidence that they're not in use, just ignore headers containing those characters.
My opinion is that Apache httpd team would prefer to reduce the syntax to reduce the security issues.
Discussed in Montreal; interest in doing something, take to list.
I'm not sure why this is being considered. All browsers support headers such as . Changing that seems likely to break applications.
The restrictions exist to protect legacy server gateways (like CGI) that are far more restrictive than browsers need to be due to the terrible idea of passing names through env vars and command-lines.
in bkk: no real consensus, concern about compatibility. reconsider on impact of a case by cases
For the record, NGINX drops request header fields with names containing characters other than letters, digits, hyphens and optionally underscores (if configured using  directive). Unfortunately, virtually anything seems to be accepted and forwarded in the response headers.
Since I'm seeing the conversation moved from the WG to GH, I'm just pasting what I sent there for completeness. Right now haproxy only accepts : "-" / "" / "." / "+" / DIGIT / ALPHA / "!" / "#" / "$" / "%" / "&" / "'" / "*" / "^" / "" / "|" / "~" i.e. everything matching a token. Quite honestly, seeing any character from this extra list in a field name would look extremely suspicious to me, and I'd rather get rid of them. As Roy mentioned, the restriction is to avoid trouble with CGIs doing : eval "hdrname=$value" Characters like backquote (), dollar ($), or pipe(|) have long been abused to attack servers...
Also I proposed that we could do something less extreme than blocking messages containing such header field names, we could recommend to simply drop these fields by default. This will have no impact if they're here by accident. Then we can let the agents decide if they want to let them pass or not. Thus we could make the difference between "forbidden characters" (the historical ones) and "unusual characters" (those excluded by the new, more restrictive list).
Discussed in Bangkok, but no consensus on an approach.
ietf104: still seeking data for characters used in the wild. http archive mentioned as a possible source.
I'm sceptical about the "protect CGI servers" (and servers similar to those). We have 2020; shouldn't these all have their own protections by now?
Discussed in Basel; suggestion is to document "safe" characters in prose (for now), both below the ABNF and in the new header field recommendations.
Those CGI servers cannot protect themselves. The issue is that both hyphens and underscores are converted to underscores in CGI servers, so both and are converted to at the protocol level, and CGI servers cannot tell which HTTP header did it originate from, since that information is lost.
Hey Piotr, We chatted about that here and tend to agree -- will remove underscore and see how that goes down.
Well, to be clear, it is the HTTP server that invokes CGI that is creating the environment variables from the received header fields. That server is responsible for avoiding bad transformations, such as the underscore problem above. However, since we are just talking about the characters that are good practice, we can exclude underscores since they are not commonly used in field names.


Does not address Vary (see ), and some more discussion of some of the conditional request headers might be warranted.
Similar to , we need to use consistent language when talking about list values. Includes: [ ] Vary: