jiebi/CodeConvo huggingface dataset:
Code change:
sent to that router, it will ultimately reach host (B) on the stub network. <ins> To achieve the reachability goal described above, this document assumes hosts attempting to reach destinations on the stub network maintain a routing table - Type C hosts as defined in RFC4191).  Type A and Type B hosts are out-of-scope for this document. </ins> 1.2. In addition to the interoperability goals we've described above, the

Related discussion:
text: 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?
Code change:
sent to that router, it will ultimately reach host (B) on the stub network. <ins> To achieve the reachability goal described above, this document assumes hosts attempting to reach destinations on the stub network maintain a routing table - Type C hosts as defined in RFC4191).  Type A and Type B hosts are out-of-scope for this document. </ins> 1.2. In addition to the interoperability goals we've described above, the

Related discussion:
text: 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.
Code change:
sent to that router, it will ultimately reach host (B) on the stub network. <ins> To achieve the reachability goal described above, this document assumes hosts attempting to reach destinations on the stub network maintain a routing table - Type C hosts as defined in RFC4191).  Type A and Type B hosts are out-of-scope for this document. </ins> 1.2. In addition to the interoperability goals we've described above, the

Related discussion:
text: 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.
Code change:
sent to that router, it will ultimately reach host (B) on the stub network. <ins> To achieve the reachability goal described above, this document assumes hosts attempting to reach destinations on the stub network maintain a routing table - Type C hosts as defined in RFC4191).  Type A and Type B hosts are out-of-scope for this document. </ins> 1.2. In addition to the interoperability goals we've described above, the

Related discussion:
text: 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.
Code change:
sent to that router, it will ultimately reach host (B) on the stub network. <ins> To achieve the reachability goal described above, this document assumes hosts attempting to reach destinations on the stub network maintain a routing table - Type C hosts as defined in RFC4191).  Type A and Type B hosts are out-of-scope for this document. </ins> 1.2. In addition to the interoperability goals we've described above, the

Related discussion:
text: 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
Code change:
PROTOCOL_ERROR.  A server cannot set the SETTINGS_ENABLE_PUSH setting to a value other than 0 (see SettingValues). <del> 8.2.1. </del> <ins> 8.4.1. </ins> Server push is semantically equivalent to a server responding to a request; however, in this case, that request is also sent by the

Related discussion:
text: This is a rearrangement of the HTTP-related sections, in preparation for actually addressing 867.
This doesn't actually address the issue -- I came to a point where I realised this would add a bunch of new requirements and prose that would need heavy scrutiny, and if we want to finish soon, that may not be advisable (although maybe we can figure it out during WGLC). In the meantime, I think this rearrangement is much clearer than the original ordering -- see what you think.
The section talks about how to generate the various pseudo-header fields from a message, but not not how to create a message from the abstract constructs in HTTP semantics, such as the target URI. This includes security considerations around trusting the contents of . I'm happy to do a PR for this. Also, this is a weird paragraph: "HTTP/2 shares the same default port numbers" implies that it could choose to do otherwise; while that might have been an open question pre-core, I think this needs to be re-worded. Likewise, "requests for target resource URIs" is odd; is this meant to be "requests with target URIs"?
Yeah, most of this is just OLD. For instance, the "discovery" aspect really only relates to the need to use ALPN, but we have a better nomenclature now. If you are happy to do a PR, I'm more than happy to review rather than write.
Code change:
SD-JWT VCs compliant with this specification MUST use the media type <del> as defined in application-vc-sd-jwt. </del> <ins> as defined in media-type. The base subtype name is meant to stand for "digital credential", which is a term that is emerging as a conceptual synonym for "verifiable credential". </ins> 3.2.

Related discussion:
text: Update the anticipated media type registration request from to per the Dublin Accord (last slide of URL)
Code change:
respond with a StreamErrorHandler or ConnectionErrorHandler of type FLOW_CONTROL_ERROR if it is unable to accept a frame. <del> The frame payload of a WINDOW_UPDATE frame is one reserved bit plus an unsigned 31-bit integer indicating the number of octets that the sender can transmit in addition to the existing flow-control window. The legal range for the increment to the flow-control window is 1 to 2 </del> <ins> The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fields are described in FramingLayer.  The frame payload of a WINDOW_UPDATE frame is one reserved bit plus an unsigned 31-bit integer indicating the number of octets that the sender can transmit in addition to the existing flow-control window.  The legal range for the increment to the flow-control window is 1 to 2 </ins> -1 (2,147,483,647) octets.

Related discussion:
text: I haven't adjusted for vs. until that war is over. Note that I've explicitly added a format for the SETTINGS frame itself, which was missing.
+1 . This would make it easier to write extensions for both h2 and h3. Priorities draft suffers from the mixed presentation format right now.
OK, thanks for doing this NAME I merged this manually after fixing a few things up. From my commit: Use all caps for frame names Add a value for Type in frame definitions Change order of flag descriptions to match order in layout Make Exclusive field of PRIORITY optional Move PING ACK Flag to the right place Add SETTINGS ACK Flag Double-checking FTW. Of course, there's a good chance I also messed something up here. So feel free to check my work also.
I think the language about ordering is a bit weird, but it is clarified somewhat by the hex representations shortly after. I think those hex representations are doing the heavy lifting, as I’m not aware of any issue with interoperability caused by getting the flag indices wrong in practice. Nonetheless, if we’re really worried about it we could just delete “bit n” and replace it with “the x bit”, e.g. delete “bit 0” and replace it with “the bit”.
Code change:
I-D.ietf-oauth-selective-disclosure-jwt. The three-party-model, i.e., actors, Verifiable Credentials and <del> Verifiable Presentations, are further described in [VCDM2.0]. However, this specification focuses on a specific version of the three-party-model which can have different features but will provide a representation of the model described in [VCDM2.0]. </del> <ins> Verifiable Presentations, are further described in VC-DATA.  However, this specification focuses on a specific version of the three-party- model which can have different features but will provide a representation of the model described in VC-DATA. </ins> 1.2.

Related discussion:
text: Fixed VCDM transformation algo,
omitting claim in Presentation and treating it as a default value
We will do the following: Instead of pseudo code, we will use algorithmic description Add algorithms for VPs and VCs.
Code change:
default option or given similar prominence in the user experience as the "grant" option. <ins> The user experience MAY include information to further educate the user on cross-device consent phishing attacks and reinforce the conditions under which authorization grants may be requested. </ins> This information may be communicated graphically or in a simple message (e.g., "It looks like you are trying to access your files on a digital whiteboard in your city center office.  Click here to grant access to your files.  If you are not trying to access your files, you should decline this request and notify the security department"). <del> The service may provide out-of-band reinforcement to the user on the context and conditions under which an authorization grant may be requested.  For example if the service provider does not send e-mails with QR codes requesting users to grant authorization, this may be reinforced in marketing messages, in-app experiences and through anti-fraud awareness campaigns. </del> Improvements to user experience on their own is unlikely to be sufficient and SHOULD be used in conjunction with other controls described in this document. <del> 5.1.14. </del> <ins> 5.1.15. </ins> By requiring a user to authenticate on the Initiating Device with a phishing resistant authentication method before initiating a cross-

Related discussion:
text: Added user education as an explicit mitigation ()
Based on discussions with UX researchers at royal Holloway University and the latest requirements from the Payment Service Directive 3, user education does provide benefits in aggregate and should e considered as an additional mitigation (either as part of the UX section, or as its own section).
Small additions/changes, otherwise looks good to me.
Code change:
be sent along with "same-site" requests.  If the value is "Lax", the cookie will be sent with same-site requests, and with "cross-site" top-level navigations, as described in strict-lax.  If the "SameSite" <del> attribute's value is neither of these, the cookie will be ignored. </del> <ins> attribute's value is neither of these, the attribute will be ignored. </ins> 4.1.3.

Related discussion:
text: There is currently a discrepancy in the spec regarding invalid values in the SameSite cookie attribute. For example, this cookie: Set-Cookie: foo=bar; SameSite=bogus is expected to be dropped entirely according to the "Server Requirements" under Section 4.1.2.7: If the "SameSite" attribute's value is neither of these [ "Lax", "Strict" ], the cookie will be ignored. whereas under Section 5.3.7 of "User Agent Requirements", the cookie is to be kept but the attribute is ignored: If cookie-av's attribute-value is not a case-insensitive match for "Strict" or "Lax", ignore the "cookie-av". Additionally, the end of Section 4.1.2 also matches the behavior described in Section 5.3.7: User agents ignore unrecognized cookie attributes (but not the entire cookie). From a forward-compatibility point of view, the behavior described in section 5.3.7 is the ideal one since it allows for future expansion of this feature such as: Set-Cookie: foo=bar; SameSite=medium
NAME
Done. Let me know if I missed anything else.
URL Section 3.1 of the spec states that "SameSite" alone (without an attribute value) is a valid token: URL Section 4.1 URL states If "cookie-av"'s "attribute-value" is not a case-insensitive match for "Strict" or "Lax", ignore the "cookie-av".
Ah. URL draft is outdated vs. URL The latter no longer allows a bare "SameSite" token, and it calls for the cookie to be dropped in the event that the samesite-value isn't either "strict" or "lax". However, I think this text isn't quite right: If 's is not a case-insensitive match for "Strict" or "Lax", ignore the . The in this case is 'SameSite=whatever' and we want to ignore the whole cookie, not just the invalid attribute?
is my proposal to fix this. We ran into this issue in the Firefox implementation: URL
Thanks!
Code change:
The status code indicates that the server understood the request but <del> refuses to authorize it.  A server that wishes to make public why the </del> <ins> refuses to fulfill it.  A server that wishes to make public why the </ins> request has been forbidden can describe that reason in the response payload (if any).

Related discussion:
text: 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.
Code change:
The status code indicates that the server understood the request but <del> refuses to authorize it.  A server that wishes to make public why the </del> <ins> refuses to fulfill it.  A server that wishes to make public why the </ins> request has been forbidden can describe that reason in the response payload (if any).

Related discussion:
text: 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"