Question: ADDRESS_REQUEST capsules, endpoints MAY send ADDRESS_ASSIGN capsules unprompted. <ins> Note that the IP forwarding tunnels described in this document are not fully featured "interfaces" in the IPv6 addressing architecture sense IPv6-ADDR.  In particular, they do not necessarily have IPv6 link-local addresses.  Additionally, IPv6 stateless autoconfiguration or router advertisement messages are not used in such interfaces, and neither is neighbor discovery. </ins> 4.7.2. The ADDRESS_REQUEST capsule (see iana-types for the value of the

From Vinny Parla on the :
Connect IP follows the same . We should probably spell that out somewhere. Similarly, we should remind implementers that they may need to treat link-local differently to avoid forwarding it, and that they may need to ensure they properly handle link-local multicast. Using ULAs is deployment-specific so I don't think anything needs to be said here: ULA isn't different from other IPv6 address blocks and we decided early on that addressing schemes are out of scope for this document Regarding RAs, I don't think anything needs to be said in this document since some deployments might want them while others might not Some additional review comments from an internal review that I wanted to share with you. Section 4.6 has a minor issue as the IANA registry mixes IPv6 extension header with layer-4 headers. It should also specify the use of RFC 5952 for representing IPv6 addresses. However, this can be ignored for now. Section 4.7.1 unsure whether "IP Version" field is useful as it can be derived from "IP Address" length/notation, also not critical but perhaps this would reduce unnecessary information. There is also a minimum 68-byte MTU for IPv4 ;-) - not sure that is important, but wanted to share. The recursive DNS server info (found in RA and DHCP), is not present. Was this an intentional decision or perhaps something that was not considered for some reason? There is no discussion of link-local addresses / ULA (I would expect both end of the 'tunnel' to have link-local addresses), or link-local multicast (e.g., ff02::1). Or perhaps the IP proxy send an IPv6 RA ? or should be prevented from sending one ? Should IP proxy reply to ff02::2 (all link-local routers), ... -Vinny


Question: 6.1. <del> If a caching forwarder consults multiple resolvers, it may be possible for it to cache records for the "resolver.arpa" Special Use Domain Name (SUDN) for multiple resolvers.  This may result in clients sending queries intended to discover Designated Resolvers for resolver "foo" and receiving answers for resolvers "foo" and "bar". A client will successfully reject unintended connections because the authenticated discovery will fail or the resolver addresses do not match.  Clients that attempt unauthenticated connections to resolvers discovered through SVCB queries run the risk of connecting to the wrong server in this scenario. To prevent unnecessary traffic from clients to incorrect resolvers, DNS caching resolvers SHOULD NOT cache results for the "resolver.arpa" SUDN other than for Designated Resolvers under their control. </del> <ins> A DNS forwarder SHOULD NOT forward queries for "resolver.arpa" upstream.  This prevents a client from receiving an SVCB record that will fail to authenticate because the forwarder's IP address is not in the upstream resolver's Designated Resolver's TLS certificate SAN field.  A DNS forwarder which already acts as a completely blind forwarder MAY choose to forward these queries when the operator expects that this does not apply, either because the operator knows the upstream resolver does have the forwarder's IP address in its TLS certificate's SAN field or that the operator expects clients of the unencrypted resolver to use the SVCB information opportunistically. Operators who choose to forward queries for "resolver.arpa" upstream should note that client behavior is never guaranteed and use of DDR by a resolver does not communicate a requirement for clients to use the SVCB record when it cannot be authenticated. </ins> 6.2.

Addressing issues and to make the SUDN forwarding a SHOULD NOT unless the operator understands and accepts the implications to authenticated discovery.
This is exactly what was intended, so we're on the same page.
Migrated from original DEER issue: URL
The Special Use Domain Name (SUDN) URL needs more clarification. Specifically: Queries against the .arpa nameservers The draft should mention that .arpa is a delegated zone, currently served by the root nameservers. Clients that query a resolver that is unaware of this requirement will "leak" queries to the root nameservers. When URL is not present in a resolver configuration Section 6.1 discusses how a forwarder should behave and suggests that results should not be cached other than for Equivalent Encrypted Resolvers under their control. How is that determined? There is no discussion around a non-forwarding resolver's behaviour. Should it return NODATA? Forwarding queries to URL will attempt to attach a client to an upstream resource's equivalent resolver. If that equivalent resolver's cert doesn't include the forwarder, the client must reject the answer. Is it not therefore the case that the forwarder caching behaviour is irrelevant? All valid responses to this query must be equivalent to the forwarder itself. When URL is present in a resolver configuration I would suggest some clarification wording something like this: The expectation is that this record set will detail equivalent resolvers. A client that chooses not to interact with any of these equivalent resolvers SHOULD continue to use the unencrypted resolver, honouring the SVCB TTL. When the SVCB TTL expires, the client may choose to re-query in an attempt to discover newly available equivalents. I would suggest (prefer?) changing the SUDN behaviour so that queries against it are never sent upstream. Resolvers (and forwarders) that do not have a configured URL RRset should return NODATA. This would mean that URL SUDN RRsets are always specific to the IP queried.
It may be good to model the advice after RFC8880, which defines URL
I am leaving this open so I can re-review the text after addressing other PRs; PR 14 addressed some of the points raised in this issue but not all of them.
Migrated from original DEER issue: URL
The text says This is not true of any reasonable forwarder.


Question: 6.1. <del> If a caching forwarder consults multiple resolvers, it may be possible for it to cache records for the "resolver.arpa" Special Use Domain Name (SUDN) for multiple resolvers.  This may result in clients sending queries intended to discover Designated Resolvers for resolver "foo" and receiving answers for resolvers "foo" and "bar". A client will successfully reject unintended connections because the authenticated discovery will fail or the resolver addresses do not match.  Clients that attempt unauthenticated connections to resolvers discovered through SVCB queries run the risk of connecting to the wrong server in this scenario. To prevent unnecessary traffic from clients to incorrect resolvers, DNS caching resolvers SHOULD NOT cache results for the "resolver.arpa" SUDN other than for Designated Resolvers under their control. </del> <ins> A DNS forwarder SHOULD NOT forward queries for "resolver.arpa" upstream.  This prevents a client from receiving an SVCB record that will fail to authenticate because the forwarder's IP address is not in the upstream resolver's Designated Resolver's TLS certificate SAN field.  A DNS forwarder which already acts as a completely blind forwarder MAY choose to forward these queries when the operator expects that this does not apply, either because the operator knows the upstream resolver does have the forwarder's IP address in its TLS certificate's SAN field or that the operator expects clients of the unencrypted resolver to use the SVCB information opportunistically. Operators who choose to forward queries for "resolver.arpa" upstream should note that client behavior is never guaranteed and use of DDR by a resolver does not communicate a requirement for clients to use the SVCB record when it cannot be authenticated. </ins> 6.2.

RRsets are atomic collections, and cannot be mixed from multiple sources. Doing so would entirely break DNSSEC, for example. Unless you know of a forwarder that exhibits this seriously broken behavior, I don't think it bears mentioning.
Addressed with PR 14
Typo, but this seems like a reasonable tweak. The description on list was a bit worrying regarding IP address, but this just says don't forward unless it is deliberate. And by deliberate, I mean that the forwarder knows it will work or that clients might not care. That seems ok.


Question: are not modified by this document.  In case of aggregates the A-Label is treated as an S-Label and it is not modified as well. <del> To support outgoing DetNet MPLS over IP, an implementation MUST support the provisioning of IP/UDP header information in place of sets of F-Labels.  Note that multiple sets of F-Labels can be provisioned to support PRF on transmitted DetNet flows and therefore, when PRF is supported, multiple IP/UDP headers MAY be provisioned. When multiple IP/UDP headers are provisioned for a particular </del> <ins> 4. To support outgoing DetNet MPLS over UDP/IP, an implementation MUST support the provisioning of UDP/IP header information in addition or in place of sets of F-Label(s).  Note that multiple sets of F-Labels can be provisioned to support PRF on transmitted DetNet MPLS flows and therefore, when PRF is supported, multiple UDP/IP headers MAY be provisioned. [Note: PRF is an MPLS function.  It produces member flows.  Member flows have 1to1 mapping to UDP/IP headers.  So why are multiple headers provisioned?  Delete next sentence?] When multiple UDP/IP headers are provisioned for a particular </ins> outgoing DetNet IP flow, a copy of the outgoing packet, including the <del> pushed S-Label, MUST be made for each.  The headers for each outgoing packet MUST be based on the configuration information and as defined in RFC7510, with one exception.  The one exception is that the UDP Source Port value MUST be set to uniquely identify the DetNet (forwarding sub-layer) flow.  The packet MUST then be handed as a DetNet IP packet, per I-D.ietf-detnet-ip. </del> <ins> pushed S-Label (and optional F-label(s)), MUST be made for each.  The headers for each outgoing packet MUST be based on the configuration information and as defined in RFC7510, with one exception.  The one exception is that the UDP Source Port value MUST be set to uniquely identify the DetNet (forwarding sub-layer) flow.  The packet MUST then be handed as a DetNet IP packet, per I-D.ietf-detnet-ip. [Note: What about IPv4 Type of Service and IPv6 Traffic Class Fields? Do we intend to set them?] </ins> To support receive processing an implementation MUST also support the <del> provisioning of received IP/UDP header information.  When S-Labels are taken from platform label space, all that is required is to provision that receiving IP/UDP encapsulated DetNet MPLS packets is permitted.  Once the IP/UDP header is stripped, the S-label uniquely identifies the app-flow.  When S-Labels are not taken from platform label space, IP/UDP header information MUST be provisioned.  The provisioned information MUST then be used to identify incoming app- flows based on the combination of S-Label and incoming IP/UDP header. Normal receive processing, including PEOF can then take place. </del> <ins> provisioning of received UDP/IP header information. </ins> <del> 4. </del> <ins> [Note: Are the receiving nodes T-PE nodes?  Why?] When S-Labels are taken from platform label space, all that is required is to provision that receiving UDP/IP encapsulated DetNet MPLS packets is permitted.  Once the UDP/IP header is stripped, the S-label uniquely identifies the app-flow.  When S-Labels are not taken from platform label space, UDP/IP header information MUST be provisioned.  The provisioned information MUST then be used to identify incoming app-flows based on the combination of S-Label and incoming IP/UDP header.  Normal receive processing, including PEOF can then take place. 5. The following summarizes the set of information that is needed to identify individual and aggregated DetNet flows: IPv4 and IPv6 source address field. IPv4 and IPv6 source address prefix length, where a zero (0) value effectively means that the address field is ignored. IPv4 and IPv6 destination address field. IPv4 and IPv6 destination address prefix length, where a zero (0) effectively means that the address field is ignored. IPv4 protocol field.  Only UDP is allowed, and the ability to ignore this field, e.g., via configuration of the value zero (0), is desirable. IPv6 next header field.  Only UDP is allowed, and the ability to ignore this field, e.g., via configuration of the value zero (0), is desirable. IPv4 Type of Service and IPv6 Traffic Class Fields. IPv4 Type of Service and IPv6 Traffic Class Field Bitmask, where a zero (0) effectively means that theses fields are ignored. UDP Source Port.  Exact and wildcard matching is required.  Port ranges can optionally be used. This information MUST be provisioned per DetNet flow via configuration, e.g., via the controller or management plane. Information identifying a DetNet flow is ordered and implementations use the first match.  This can, for example, be used to provide a DetNet service for a specific UDP flow, with unique Source and Destination Port field values, while providing a different service for the aggregate of all other flows with that same UDP Destination Port value. It is the responsibility of the DetNet controller plane to properly provision both flow identification information and the flow specific resources needed to provided the traffic treatment needed to meet each flow's service requirements.  This applies for aggregated and individual flows. 6. </ins> The security considerations of DetNet in general are discussed in I- D.ietf-detnet-architecture and I-D.ietf-detnet-security.  MPLS and IP

Based on 06.17 discussions. F-lables(s) added to Fig1 and text fixed. Adding procedures sections. Multiple notes added for clarifications. Adding controller plane section.
reviewed in Jun 24 meeting


Question: differ after the handshake, then A is compatible with B and B is compatible with A. <del> Version compatibility is not bijective: it is possible for version A </del> <ins> Version compatibility is not symmetric: it is possible for version A </ins> to be compatible with version B and for B not to be compatible with A.  This could happen for example if version B is a strict superset of version A.

Bijective should be symmetric. We're describing a relation not a function. This is a very minor comment, will send a PR hopefully soon.
Indeed, my math is pretty rusty :) Totally agree with you, and thanks for offering to write the PR!
NAME any luck with the PR?
I completely forgot about this!
URL opened
Closing now that has been merged.


Question: to implement version negotiation to protect against downgrade attacks. <del> I-D.duke-quic-version-aliasing is a more robust, but much more complicated, proposal to address these ossification problems.  By design, it requires incompatible version negotiation.  QUICv2 enables exercise of compatible version negotiation mechanism. </del> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

, , , , , .
Just a style thing (and something we should try an capture in a QUIC style guide).
There a bit of inconsistency through the document. Personally I prefer the QUIC version N style.
is there a missing word here?
Nope, extra word, thanks
I find this awkward to read in isolation, it requires converting the RFC 9000 types definition format into a different encoding to realize there is a change. A clearer alternative could be "All version 2 Long Packet Types are different: Initial: 0b01 0-RTT: 0b10 Handshake 0b11 Retry: 0b00
Starting with This might be a matter of style but to me the term "changes" imply that you're modifying the original, not creating something new. How about we term these as differences instead? The the opening paragraph of Section 3 could be something like "QUIC version 2 endpoints MUST implement the QUIC version 1 specification as described in ], ], and ]. However, the following differences apply in version 2."
This might have been important earlier in the document lifetime but it seems to stick out now.
This could be misread to imply the salt is universally known and universally applicable, which I don't think is your intention. In fact, I find the construction of this entire paragraph a bit awkward. Can we rephrase this for better clarity? Something like "In QUIC version 1, Initial packets are encrypted with the version-specific salt as described in Section 5.2 of [QUIC-TLS]. Protecting Initial packets in this way allows observers to inspect their contents, which includes the TLS Clent Hello or Server Hello messages. Again, there is the potential for middleboxes to ossify on the 1 key derivation and packet formats."
Couple of nits but otherwise LGTM


Question: Initialize VDAF preparation and initial outputs as described in input-share-prep. <del> [[OPEN ISSUE: consider moving the helper nonce check into #early- </del> <ins> [[OPEN ISSUE: consider moving the helper nonce check into early- </ins> input-share-validation]] Once the helper has processed each valid report share in

Justify text after bullets consistenly Make sure all lines break at 80 characters
LGTM, modulo conflicts. It'd be nice if we had a linter that blocked PRs until their formatting was right, since changes like this taint git history.


Question: MUST still contain the suit-authentication-wrapper element, but the content MUST be a list containing only the SUIT_Digest. <ins> The algorithms used in SUIT_Authentication are defined by the profiles declared in I-D.moran-suit-mti. </ins> 8.4. The manifest contains:

adds a missing digest parameter corrects CDDL for suit-text removes dangling
I have discovered this because the EAT build process pulls the SUIT CDDL in for validation using the cddl tool.
NAME posted to the list the following: I think I found a little typo in the draft-ietf-suit-manifest-14 ... At the "Appendix A. A. Full CDDL" of the "SUITSeverableMembersChoice", the last two members are pointing to "SUITCommand_Sequence" are probably typos as following,
In draft-ietf-suit-manifest-04 In the example manifest image-digest parameter is set for component 0 in common sequence. The load sequence sets component-index to 1 and after directive-copy it specifies image-match condition. However, the image-digest parameter has not been set for component-index 1 causing the condition to fail as . Is it expected that parameters are implicitly copied from source component when copy-directive is executed? Should the image-digest be also specified for component-index 1 or perhaps for all components? Another observation in the example is that vendor-id and class-id parameters and corrsponding condition checks are specified for component 0, which seems to be the "external storage". Wouldn't it be better to specify the VID and CID globally for the entire device or for the component 1, which seems to be the one running the image? / common / 3:h'a2024782814100814101045856880c0014a40150fa6b4a5 3d5ad5fdfbe9de663e4d41ffe02501492af1425695e48bf429b2d51f2ab45038202582 000112233445566778899aabbccddeeff0123456789abcdeffedcba98765432100e198 7d001f602f6' / { / components / 2:h'82814100814101' / [ [h'00'] , [h'01'] ] /,


Question: MUST still contain the suit-authentication-wrapper element, but the content MUST be a list containing only the SUIT_Digest. <ins> The algorithms used in SUIT_Authentication are defined by the profiles declared in I-D.moran-suit-mti. </ins> 8.4. The manifest contains:

/ common-sequence / 4:h'880c0014a40150fa6b4a53d5ad5fdfbe9d e663e4d41ffe02501492af1425695e48bf429b2d51f2ab450382025820001122334455 66778899aabbccddeeff0123456789abcdeffedcba98765432100e1987d001f602f6' / [ / directive-set-component-index / 12,0 , / directive-override-parameters / 20,{ / vendor-id / 1:h'fa6b4a53d5ad5fdfbe9de663e4d41ffe' / fa6b4a53-d5ad-5fdf- be9d-e663e4d41ffe /, / class-id / 2:h'1492af1425695e48bf429b2d51f2ab45' / 1492af14-2569-5e48-bf42-9b2d51f2ab45 /, / image-digest / 3:[ / algorithm-id / 2 / sha256 /, / digest-bytes / h'00112233445566778899aabbccddeeff0123456789abcdeffedcba9876543210' ], / image-size / 14:34768, } , / condition-vendor-identifier / 1,F6 / nil / , / condition-class-identifier / 2,F6 / nil / ] /, } /, (.) / load / 11:h'880c0113a1160016f603f6' / [ / directive-set-component-index / 12,1 , / directive-set-parameters / 19,{ / source-component / 22:0 / [h'00'] /, } , / directive-copy / 22,F6 / nil / , / condition-image-match / 3,F6 / nil / ] /,


Question: Specification Required policy to avoid collisions with HTTP/2 error codes. <del> Additionally, each code of the format "0x1f * N + 0x21" for non- negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA. </del> <ins> Each code of the format "0x1f * N + 0x21" for non-negative integer values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values. </ins> 11.2.4.

IANA's review wanted to know whether the 148 quadrillion GREASE values should be listed on the registry page as Reserved, and what note should be present if not. They should not, lest it be challenging to actually download the registry page within the lifetime of the human race. This rewords the restriction and clarifies that the restriction should be the note.
NAME Can you add the same text to 22.2 (Transport parameter registry) in the transport doc as well?
NAME said
We believe the note, updated based on IANA feedback during Last Call, is sufficient. Reserving 148 quadrillion values in the registry would cause the registry to be impossible to download in the lifetime of humanity; see . The purpose is described in , to exercise the requirement to ignore unknown frame types (a.k.a. GREASE). Proposal is to make no change; this was already covered during IANA review.
If IANA has agreed, then I am fine with it. BTW, I was not asking to make those zillions of reservations but leaving a note in the registry ;-)
It's a fair question but the WG and the responsible AD are satisfied with our IANA considerations at this stage, closing with no action.
Please see the for full context. This issue is tracking the following IANA question:
Copying my e-mail reply here: unknown values; having an explicit list encourages an explicitly defined reaction. This also applies to and , where the latter has better wording.
NAME replied to IANA . Closing this issue.
Actually, NAME said in response to the e-mail that this guidance should be in the document: Let's re-open to track. I don't think all instances of this question need separate issues, though.
So the related questions were: Should the GREASE values be listed in the registry as Reserved? No, because some rough estimation suggests it would take a few millennia to download the registry page if this were the case. Should there be a note indicating which values cannot be assigned? I'm of two minds, because while I really don't want people embedding the formula into their parsers, I do want people embedding the formula into their generators. says no Reserved listing, yes note.
I think this is proposal ready. Forwarding Mike's response to the list, to there is an archive to link to. Lars >


Question: 9. Please update the "Media Types" registry at <del> https://www.iana.org/assignments/media-types [1] for the media types </del> <ins> https://iana.org/assignments/media-types [1] for the media types </ins> "application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req), and "message/ohttp-res" (iana-res). <ins> Please update the "HTTP Problem Types" registry at https://iana.org/assignments/http-problem-types [2] for the types "date" (iana-problem-date) and "ohttp-key" (iana-problem-ohttp-key). </ins> 9.1. The "application/ohttp-keys" media type identifies a used by

We debated this at some length. This defines an optional-to-use signaling method for the gateway so that it can inform the client when the key configuration is not acceptable. Clients can use this as a prompt to refresh their configuration.
(Originally posted by NAME in URL): Any lifetime information that comes with a key is helpful, but in practice is insufficient for clients to drive key updates. Key rotation may not occur on a fixed schedule and it may not occur synchronously (some gateway instances might not get the key at the right time. This means that clients cannot distinguish between failures due to configuration mismatch or request tampering (or whatever else might cause the gateway to reply without an encapsulated response). If the client can't distinguish then the client's recovery implementation is a lot more complicated. Does it always try to forcibly update its configuration? Does it implement some sort of backoff? Can a relay abuse the client's recovery implementation to somehow put the client into a state where it is stuck with an old configuration? It seems vastly simpler to just be clear that the configuration is wrong as a signal to the client that it's time to update. This was done in ODoH with a 401 response code. proposed a new problem statement, which I think is the right way to deal with this. Yes, there are potential privacy problems based on automated updates, but those depend on the client's consistency story and is therefore not something new a signal would introduce.
This looks great -- thanks!


Question: D.ietf-taps-transport-security. As described above in equivalence, if a Transport Services system <del> races between two different Protocol Stacks, both SHOULD use the same security protocols and options.  However, a Transport Services system MAY race different security protocols, e.g., if the application explicitly specifies that it considers them equivalent. </del> <ins> races between two different Protocol Stacks, both need to use the same security protocols and options.  However, a Transport Services system can race different security protocols, e.g., if the application explicitly specifies that it considers them equivalent. </ins> Applications need to ensure that they use security APIs appropriately.  In cases where applications use an interface to

This proposal consolidates normative language into the section on design principles (now requirements), using the suggestions in .
Please review the latest updates!
Early art-art review of draft-ietf-taps-architecture My first observation and request is that the group rethink the separation of the architecture and interface documents. It is a warning-sign that the interface document is a normative reference for the architecture document. As the documents are currently constructed, a new reader cannot grasp the architecture without inferring some of it through reading the interface. Consider reformulating the architecture document as an overview - introduce principles, concepts, and terminology, but don't attempt to be normative. (There are signs that this may already be, or have been, a path the document was being pushed towards). If nothing else, rename it, and acknowledge that the actual architecture is specified using the interface definition. Note that the first sentence of the Overview in the interface document also highlights the current structural problem.
I don't entirely agree with this ART-ART comment: I think I might well agree with moving more of the description to this Arch document, but as discussed before, I also think it useful here to set the actual requirements for the architecture, and to define the architecture. It may need to be much clearer that this architecture consists of more the API.
For completeness, this is the first statement of the interface document review: This document reads fairly well. I have some structural concerns (see the early review of the architecture document). In particular I think this document contains the actual definition of the architecture and some of that is inferential.
Discussion at September 2021 interim: pass through this document with a view toward making it a high level introduction, not an architecture definition: "An Introduction to the Transport Services Architecture". remove normative language from this document (moving it to API, where necessary). move details not useful in a high level intro to API.
I disagree with this conclusion at first pass—we did a specific analysis and pass on this over a year ago, with PR . The normative language and the standards-track aspect was very intentional and something the WG had consensus on. The point is that the API is a specific incarnation of the TAPS architecture, but there are overarching architectural properties that go beyond a specific abstract API.
I completely agree with Tommy here, and recommend we fix this in . We should also of course check for any stray text or missing concepts.


Question: D.ietf-taps-transport-security. As described above in equivalence, if a Transport Services system <del> races between two different Protocol Stacks, both SHOULD use the same security protocols and options.  However, a Transport Services system MAY race different security protocols, e.g., if the application explicitly specifies that it considers them equivalent. </del> <ins> races between two different Protocol Stacks, both need to use the same security protocols and options.  However, a Transport Services system can race different security protocols, e.g., if the application explicitly specifies that it considers them equivalent. </ins> Applications need to ensure that they use security APIs appropriately.  In cases where applications use an interface to

I think it would also be useful to somehow better explain that in figure 3 the API function is ONE part of the system.
See linked PR first please to see if this resolves this?
A PR was merged that addressed important text issues with separation of requirements and overview, and should more clearly set out that the requirements are for the system. The question of whether the overall TAPS systems requirements belong in this ID; the API; or a separate RFC needs some discussion based on the review, before this can be closed.
Many good text improvements in the PR NAME but I noticed two smaller updates in the PR that I think were incorrect. Fixed in
The review comment showed were many places where the wording of architecture can be improved. There are some high level principles that I think should remain in the architecture document. The decision in today's interim is to review the architecture to get this more into a shape that is valuable as a reference, and then check the updated draft.
I now suggest the issues are addressed and we close this issue without moving text between documents
I agree with that; closing.
Overall review: I think we need to keep the normative language for the key features that differentiate the API. I'd really like to use REQUIRED, RECOMMENDED, rather MUST and SHOULD - because these are not protocol operation requirements, but are implementation requirements to conform. This includes requirements based on Minset - where the WG dervied this API: This is after all why the WG worked on Minset as the basis of the API. I suggest we group all the requirements on architecture as short one or two sentence blocks (preferably as a bullet or definition list) collected into a single subsection, so they are easy to find and read and we say that these are the key architectural requirements. We insert this new requirements text either their own section, or in section 1.3 (although I am open to other places where we can call-out the architectural requirements). The following are key requirements, that define the TAPS architecture: It is RECOMMENDED that functionality that is common across multiple transport protocols is made accessible through a unified set of TAPS interface calls. As a baseline, a Transport Services system interface is REQUIRED to allow access to the minimal set of features offered by transport protocols {{?I-D.ietf-taps-minset}}.


Question: D.ietf-taps-transport-security. As described above in equivalence, if a Transport Services system <del> races between two different Protocol Stacks, both SHOULD use the same security protocols and options.  However, a Transport Services system MAY race different security protocols, e.g., if the application explicitly specifies that it considers them equivalent. </del> <ins> races between two different Protocol Stacks, both need to use the same security protocols and options.  However, a Transport Services system can race different security protocols, e.g., if the application explicitly specifies that it considers them equivalent. </ins> Applications need to ensure that they use security APIs appropriately.  In cases where applications use an interface to

A Transport Services system automates the selection of protocols and features and network, based on a set of Properties supplied through the TAPS interface. It is RECOMMENDED that a Transport Services system offers Properties that are common to multiple transport protocols. Specifying common Properties enables a system to appropriately select between protocols that offer equivalent features. This design permits evolution of the transport protocols and functions without affecting the programs using the system. Specifying common Properties enables a Transport Services system to appropriately select an appropriate network interface. It is RECOMMENDED that a system offers Properties that are common to a variety network layer interfaces and paths. This design permits racing of different network paths without affecting the programs using the system. Applications using the Transport Services system interface are REQUIRED to be robust to the automated selection provided by the system, including the possibility to express requirements and preferences that constrain the choices that can be made by the system. If two different Protocol Stacks can be safely swapped, or raced in parallel (see Section 4.2.2), by the Transport Services system then they are considered to be "equivalent". Equivalent Protocol Stacks need to meet the requirements for racing specified in section XX. Applications using a Transport Services system MAY explicitly require or prevent the use of specific transport features (and transport protocols) and XXXinterfaces using the "REQUIRED" and "PROHIBIT" preferences. This allows an application to constrain the set of protocols and features that will be selected for the transport service. It is RECOMMENDED that the default usage by applications does not necessarily restrict this selection, so that the system can make informed choices (e.g., based on the availability of interfaces or set of transport protocols available for the specified remote endpoint). When a Transport Services system races between two different Protocol Stacks, both SHOULD use the same security protocols and options. However, a Transport Services system MAY race different security protocols, e.g., if the application explicitly specifies that it considers them equivalent. Transport Services systems MUST NOT automatically fall back from secure protocols to insecure protocols, or to weaker versions of secure protocols. A Transport Services system MAY allow applications to specify that fallback to a specific other version of a protocol is allowed. It is RECOMMENDED that in normal use, a Transport Services system is designed so that all selection decisions result in consistent choices for the same network conditions when they have the same set of preferences.


Question: D.ietf-taps-transport-security. As described above in equivalence, if a Transport Services system <del> races between two different Protocol Stacks, both SHOULD use the same security protocols and options.  However, a Transport Services system MAY race different security protocols, e.g., if the application explicitly specifies that it considers them equivalent. </del> <ins> races between two different Protocol Stacks, both need to use the same security protocols and options.  However, a Transport Services system can race different security protocols, e.g., if the application explicitly specifies that it considers them equivalent. </ins> Applications need to ensure that they use security APIs appropriately.  In cases where applications use an interface to

This is intended to provide predictable outcomes to the application using the transport service. I would then suggest to use lower case within other parts of the document - except were pointed to from here, (we could refer to the requirements subsection, if we thought necessary).
for discussion at the interim, but IMO we could start the interim with a PR based on these suggestions and work from there.
I suspect that we need more protocol-specific properties to be able to talk to various kinds of native protocol peers (other than TCP and UDP: these should already work fine with what we have, I believe). A concrete example: we're hiding stream numbers. In NEAT, we needed to make them configurable though, because we wanted a NEAT client to be able to talk to a native SCTP server, where an application may expect certain type of data to arrive via a certain stream number. I suspect that we may need something similar for a QUIC peer. Should we address this? (I'd say yes) How .. is it a protocol-specific (per-Message) property? (I'd say yes... and perhaps a per-Connection property too, with text explaining that the per-Message one automatically becomes the Connection default unless otherwise specified) What other such things are we missing... what other expectations may e.g. a native QUIC or SCTP application have that we just cannot fulfil with our current system?


Question: 5.4. <del> Entangled Connections can be created using the Clone Action: Calling Clone on a Connection yields a group of Connections: the parent Connection on which Clone was called, and a resulting cloned Connection.  The new Connection is actively openend, and it will send a Ready Event or an EstablishmentError Event.  The Connections within a group are "entangled" with each other, and become part of a Connection Group.  Calling Clone on any of these Connections adds another Connection to the Connection Group, and so on.  "Entangled" Connections share all Connection Properties except "Connection Priority" (see conn-priority) .  Like all other Properties, Connection Priority is copied to the new Connection when calling Clone(), but it is not entangled: Changing Connection Priority on one Connection does not change it on the other Connections in the same Connection Group. The stack of Message Framers associated with a Connection are also copied to the cloned Connection when calling Clone.  In other words, a cloned Connection has the same stack of Message Framers as the Connection from which they are Cloned, but these Framers may internally maintain per-Connection state. </del> <ins> Connection Groups can be created using the Clone Action: Calling Clone on a Connection yields a Connection Group containing two Connections: the parent Connection on which Clone was called, and a resulting cloned Connection.  The new Connection is actively openend, and it will send a Ready Event or an EstablishmentError Event.  Calling Clone on any of these Connections adds another Connection to the Connection Group.  Connections in a Connection Group share all Connection Properties except "Connection Priority" (see conn-priority), and these Connection Properties are entangled: Changing one of the Connection Properties on one Connection in the Connection Group automatically changes the Connection Property for all others.  For example, changing "Timeout for aborting Connection" (see conn-timeout) on one Connection in a Connection Group will automatically make the same change to this Connection Property for all other Connections in the Connection Group.  Like all other Properties, "Connection Priority" is copied to the new Connection when calling Clone(), but in this case, a later change to the "Connection Priority" on one Connection does not change it on the other Connections in the same Connection Group. Message Properties are also not entangled.  For example, changing "Lifetime" (see msg-lifetime) of a Message will only affect a single Message on a single Connection. A new Connection created by Clone can have a Message Framer assigned via the optional "framer" parameter of the Clone Action.  If this parameter is not supplied, the stack of Message Framers associated with a Connection is copied to the cloned Connection when calling Clone.  Then, a cloned Connection has the same stack of Message Framers as the Connection from which they are Cloned, but these Framers may internally maintain per-Connection state. </ins> It is also possible to check which Connections belong to the same Connection Group.  Calling GroupedConnections() on a specific

This changes the use of the term "entanglement" as discussed in , and moves some text around in this section for better clarity and less repetition. Also, addressing , it introduces a framer as an optional parameter to the Clone call.
NAME I incorporated all of your suggestions, thanks!
This is not fully clear from section 5.4., however, if connections in a group are each QUIC streams, I think it should be possible to use different framers on each stream. So it might be okay that a framers is copied when clone is called but changing a framer on one connection should not change the framer on the other connection in a group...?
Also an related editorial comment (that could be addressed in the same PR eventually): this section on groups only at the very end has a paragraph starting with "Note that calling Clone() can result in on-the-wire signaling..." which kind of explains that groups are supposed to be used for multistream protocol but can also be mapped to separate connection if the protocol doesn't not support multiplexing of stream on one connection. I think this information should be added at the very beginning of this section.
Actually, now looking at the framer section, I guess you would rather like to already set the new framer before you clone a connection...?
I agree with everything you say here; about your last suggestion, maybe a framer should be an optional argument of the clone call?
I don’t actually understand the difference between a connection in a Connection Group and an “entangled connection” ? Both terms are used in API, but in different ways (possibly by different authors) - do we really really need the word “entangled”?? if we do we need, can we define and explain this.
I think that having the word is good as it indicates a deeper relationship than mere "grouping". Just based on terms, I'd (correctly) imagine that I can define priorities between members of a group, and that they somehow belong together... as in: Close with a common call, etc. ... but I don't think that I would expect, just from this term, that changing a property on one of them affects all the others. Hence the phrasing: "The connections within a group are 'entangled' with each other". However, I agree that in most other places, we should talk about "groups" instead.


Question: 5.4. <del> Entangled Connections can be created using the Clone Action: Calling Clone on a Connection yields a group of Connections: the parent Connection on which Clone was called, and a resulting cloned Connection.  The new Connection is actively openend, and it will send a Ready Event or an EstablishmentError Event.  The Connections within a group are "entangled" with each other, and become part of a Connection Group.  Calling Clone on any of these Connections adds another Connection to the Connection Group, and so on.  "Entangled" Connections share all Connection Properties except "Connection Priority" (see conn-priority) .  Like all other Properties, Connection Priority is copied to the new Connection when calling Clone(), but it is not entangled: Changing Connection Priority on one Connection does not change it on the other Connections in the same Connection Group. The stack of Message Framers associated with a Connection are also copied to the cloned Connection when calling Clone.  In other words, a cloned Connection has the same stack of Message Framers as the Connection from which they are Cloned, but these Framers may internally maintain per-Connection state. </del> <ins> Connection Groups can be created using the Clone Action: Calling Clone on a Connection yields a Connection Group containing two Connections: the parent Connection on which Clone was called, and a resulting cloned Connection.  The new Connection is actively openend, and it will send a Ready Event or an EstablishmentError Event.  Calling Clone on any of these Connections adds another Connection to the Connection Group.  Connections in a Connection Group share all Connection Properties except "Connection Priority" (see conn-priority), and these Connection Properties are entangled: Changing one of the Connection Properties on one Connection in the Connection Group automatically changes the Connection Property for all others.  For example, changing "Timeout for aborting Connection" (see conn-timeout) on one Connection in a Connection Group will automatically make the same change to this Connection Property for all other Connections in the Connection Group.  Like all other Properties, "Connection Priority" is copied to the new Connection when calling Clone(), but in this case, a later change to the "Connection Priority" on one Connection does not change it on the other Connections in the same Connection Group. Message Properties are also not entangled.  For example, changing "Lifetime" (see msg-lifetime) of a Message will only affect a single Message on a single Connection. A new Connection created by Clone can have a Message Framer assigned via the optional "framer" parameter of the Clone Action.  If this parameter is not supplied, the stack of Message Framers associated with a Connection is copied to the cloned Connection when calling Clone.  Then, a cloned Connection has the same stack of Message Framers as the Connection from which they are Cloned, but these Framers may internally maintain per-Connection state. </ins> It is also possible to check which Connections belong to the same Connection Group.  Calling GroupedConnections() on a specific

I can try to fix this.
Sounds good - we should add that explanation upfront in the definitions then also?
[Yes, I think so.] EDIT: no, now I don't think so anymore. (see )
I have addressed this in PR . Note that the text interchangeably talked about both Connections and Connection Properties as being "entangled". I have now written this such that the term "entanglement" applies to Connection Properties only, whereas Connections in a group are, well, members of the same Connection Group.
Looks good to me.


Question: Clients MUST discard Retry packets that contain an Original Destination Connection ID field that does not match the Destination Connection ID from its Initial packet.  This prevents an off-path <del> attacker from injecting a Retry packet. </del> <ins> attacker from injecting a Retry packet.  A client MUST discard a Retry packet with a zero-length Retry Token field. </ins> The client responds to a Retry packet with an Initial packet that includes the provided Retry Token to continue connection

The Retry packet can be discarded.
The Retry packet currently allows sending an empty token. The Retry token is defined as an opaque blob where "indicates that x is variable-length", which also includes zero-length values. On the wire, an Initial packet with a zero-length token is identical to an Initial without a token. However, there's a difference on the client side, since a client will perform at most a single Retry.
Tagging this editorial. This was clearly intended to be considered non-zero length.


Question: candidates of the Media Server.  The Media Server MAY use ICE lite, while the WHIP client MUST implement full ICE. <del> The WHIP client MAY perform trickle ICE or ICE restarts RFC8863 by sending an HTTP PATCH request to the WHIP resource URL with a body containing a SDP fragment with MIME type "application/trickle-ice- sdpfrag" as specified in RFC8840.  When used for trickle ICE, the body of this PATCH message will contain the new ICE candidate; when used for ICE restarts, it will contain a new ICE ufrag/pwd pair. </del> <ins> The WHIP client MAY perform trickle ICE or ICE restarts as per RFC8838 by sending an HTTP PATCH request to the WHIP resource URL with a body containing a SDP fragment with MIME type "application/ trickle-ice-sdpfrag" as specified in RFC8840.  When used for trickle ICE, the body of this PATCH message will contain the new ICE candidate; when used for ICE restarts, it will contain a new ICE ufrag/pwd pair. </ins> Trickle ICE and ICE restart support is OPTIONAL for a WHIP resource. If the WHIP resource supports either Trickle ICE or ICE restarts, but

NAME ping?
Section 4.1 “The WHIP client MAY perform trickle ICE or ICE restarts ] by sending an HTTP PATCH request…” Why is there a reference to RFC8863, which specifies ICE PAC, here? In general a reference to ICE PAC is useful, because this draft allows an offer without any candidates. So maybe that reference should go at the end of: “The initial offer by the WHIP client MAY be sent after the full ICE gathering is complete with the full list of ICE candidates, or it MAY only contain local candidates (or even an empty list of candidates).”
I think it was a typo.
I created a PR to fix the tricke ice reference and add the pac one as suggested.


Question: Note that the same limitation applies to other data sent by the server protected by the 1-RTT keys. <del> 13.2.8. </del> <ins> 13.2.7. </ins> Packets containing PADDING frames are considered to be in flight for congestion control purposes QUIC-RECOVERY.  Packets containing only

It's no longer normative and it's in a single section. I only moved text so far, and not as far as NAME suggested. I can go farther here or in a follow-up PR.
NAME I would like to merge this. WDYT?
Can we merge this soon. I'm worried about it developing conflicts.
Yep, NAME lost the chance to fix the PR. We are - of course - still open for editorial improvements in the form of new pull requests though.
calls them "exemplary" but 13.2.4 has MUST in it.
For reference, this refers to and in the editor's copy. I'm in favour of striking the exemplary note and saying that while the recovery draft is advisory, this document depends on implementations following something like what is recommended.
The specific MUSTs aren't really about the ACK algorithm per se, but about state endpoints will have to maintain for other reasons that are typically folded into your loss recovery code. If an implementation is unable to do duplicate detection for a packet number range, it MUST fail toward rejecting all packets, not toward accepting potential duplicates. An implementation must track the greatest packet number ever received, for use in recovering future packet numbers. In fact, the first requirement is discussed in 12.3 and could probably be dropped here. The second isn't actually called out (MUST) in 17.1, but could easily be moved there.
I think I'm inclined towards reorganizing the text and putting all the 'exemplary' parts into one section(ie: "Limiting ACK Ranges") and moving the normative text either into "Managing ACK Ranges" or elsewhere in the draft.
I thought I could clean this up fairly quickly, but I think a fair number of paragraphs need to move, including some of NAME suggestions. I'm happy to try to improve this in a few days if no one else has beaten me to it.
Anyone want to help NAME out and take this on?
Sorry about dropping this one. I'm fine with it, and happy to make editorials one later.Thanks Ian. When you lay it out like this, it seems so obvious. I checked that we don't have citations for {{ack-tracking}}, so this works nicely. If you care about the "MAY", then we can fix that in another PR.


Question: 12.3.23. <del> Control Property [TODO: Discuss] Integer Preconnection, Connection This property specifies how long to wait before aborting a Connection during establishment, or before deciding that a Connection has failed after establishment.  It is given in seconds. </del> <ins> Integer Connection Property - see </ins> 12.3.24. <del> Protocol Property (Generic) / Control Property [TODO: Discuss] Enum Preconnection, Connection This property specifies which scheduler should be used among Connections within a Connection Group, see groups.  The set of schedulers can be taken from I-D.ietf-tsvwg-sctp-ndata. </del> <ins> Enum Connection Property - see </ins> 12.3.25. <del> Protocol Property (Generic) Integer Connection (read only) This property represents the maximum Message size that can be sent before or during Connection establishment, see also msg-idempotent. It is given in Bytes.  This property is read-only. </del> <ins> Integer Connection Property (read-only) - see </ins> 12.3.26. <del> Protocol Property (Generic) Integer Connection (read only) This property, if applicable, represents the maximum Message size that can be sent without incurring network-layer fragmentation or transport layer segmentation at the sender.  This property is read- only. </del> <ins> Integer Connection Property (read-only) - see </ins> 12.3.27. <del> Protocol Property (Generic) Integer Connection (read only) This property represents the maximum Message size that can be sent. This property is read-only. </del> <ins> Integer Connection Property (read-only) - see </ins> 12.3.28. <del> Protocol Property (Generic) Integer Connection (read only) This numeric property represents the maximum Message size that can be received.  This property is read-only. </del> <ins> Integer Connection Property (read-only) - see </ins> 12.3.29.

This is the second step towards applying our new Properties Classification. It moves up the Connection Properties and annotates most places with stuff to do.
As discussed in
Thanks for moving this forward! I only found a few nits. Also, I have a question about whether two of these Properties should maybe be changed to be Selection Properties, but that's more of a discussion and not something that needs to be done in this URL modulo NAME commentsI carefully checked it, but I find it very hard to be sure that this is 100% ok (as is usually the case IMO with diff's about text blocks being moved around). My suggestion is to land it and see.


Question: applicability, and issues that application developers must consider when using QUIC as a transport for their application. <del> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> 2. QUIC uses UDP as a substrate.  This enables both userspace

note: don't merge yet, still need to make the pass on applicability but working on the CI issue at the moment
done. mergeable if ok.
There are a few instances that might be read as normative statements. Is that really wise? Examples: cannot? Maybe this isn't something that this document needs to say. It could just say that fallback to unencrypted TCP might not be a desirable outcome. There is also a bunch of "MUST"-level statements in the 0-RTT section, but I've proposed a rewrite that (I hope) eliminates them.
Fixed in : removed all 2119 language.
Not clear if these documents should use normative language at all. The applicability statement also sometimes uses normative language to recommend the implementation of certain interfaces; I don't think this is the right document for that but as we also don't have another document, we should decide if we want to do that or not!
Manageability is a user's guide to the wire image, as such there's no sense to normative language (though I suppose some might like to add MUST NOT observe packets). Since applicability is in part a set of recommendations to application designers, normative language might make sense there... but the document is informational, so normative language here has to reference or be trivially derived from normative language in one of the base drafts. To simplify things, I'd just scrub all the SHOULDs, MAYs, and MUSTs.


Question: performance of the QUIC handshake and use shorter timers for acknowledgement. <del> Packets that contain only ACK frames do not count toward congestion control limits and are not considered in-flight. </del> <ins> Packets containing frames besides ACK or CONNECTION_CLOSE frames count toward congestion control limits and are considered in- flight. </ins> PADDING frames cause packets to contribute toward bytes in flight without directly causing an acknowledgment to be sent.

At the moment, we state that a QUIC packet that contains frames other than ACK and PADDING (), but I wonder if that is true for CONNECTIONCLOSE frame. A CONNECTIONCLOSE frame never elicits an acknowledgment. IIUC, it is not meant to be governed by the congestion controller. Considering the aspects, I think we should add CONNECTION_CLOSE to the list of non-ACK-eliciting frames.
That also ensures the congestion controller never inadvertently blocks sending a CONNECTIONCLOSE, which is consistent with the intent. If we make this change, I believe APPLICATIONCLOSE needs to be on the list as well. Now that we discuss ack-eliciting in transport, I think we'd need to change both transport and recovery and mark this design. So I think this would be a slight improvement, but I an also imagine people claiming that CONNECITON_CLOSE is already special, so there's no need for a change.
APPLICATION_CLOSE is no more. This seems like a fine change.
This seems sensible.
Discussed in Cupertino. Obvious correction.
Seems right to me. Editorial tweaks suggested.


Question: The key and nonce used for the Retry Integrity Tag (QUIC-TLS) change to: <ins> The secret is the sha256sum of "QUICv2 retry secret".  The key and nonce are derived from this secret with the labels "quicv2 key" and "quicv2 iv", respectively. </ins> 4. QUIC version 2 is not intended to deprecate version 1.  Endpoints

As requested, all new version number, salts, etc. for QUICv2. Verification of the test vectors would be especially valuable.
Woof. Thank you very much for quickly checking, and sorry I botched every part of that. All fixed now, I hope.
The new test vectors works well with my QUIC implementation in Haskell.
Thanks Kazu!
WFM. Not validated with a real build, but a script. See URL for the script that I used.


Question: Comparison expressions are available for comparisons between primitive values (that is, numbers, strings, "true", "false", and <del> "null").  These can be obtained via literal values; Singular Queries, </del> <ins> "null").  These can be obtained via literal values; singular queries, </ins> each of which selects at most one node the value of which is then used; or function expressions (see fnex) of type "ValueType".

Sometimes the spec uses "Singular Query" and sometimes "singular query". We should be consistent. (If we decide to use lower case, it's probably best to address this issue after PR has been merged, since that PR adds some usages of "Singular Query".) Also, there is one instance of "Logical context", which I think would be better uncapitalised ("logical context").
After merging in my changes from main, it appears some Singular Queries still need fixing.


Question: A research challenge would be the optimization of the NFV service function chaining, considering a virtualized infrastructure and other SATCOM specific functions, to guarantee an efficient radio usage and <del> easy-to-deploy SATCOM services. </del> <ins> easy-to-deploy SATCOM services.  Moreover, another challenge related to a virtualized SATCOM terminals is the management of limited buffered equipments. </ins> 5.3.

I have no idea what this section means. Virtualised antennas? virtualised reflectors? Good luck with that. chin-nfvrg-cloud-5g-core-structure-yang referring to an expired -00 internet-draft does not add credibility.
MJM : But on the virtualization comment: we had presentations in the group on NFV (network virtualization) with NC for satellites. I am sure that the authors of this work could add to Lloyd’s comments on that section.
We have added a research challenge and changed the title of section in PR . The section aims at identifying research challenge related to the interaction between NC and virtualization (function chaining, buffer management, etc).


Question: basis.  The number of out of order packets that can be processed also impacts the latency of a flow. <ins> The latency impact on the system resources needed to support a specific DetNet flow will need to be evaluated by the controller plane based on that flow's traffic specification.  An example traffic specification that can be used with MPLS with Traffic Engineering (MPLS-TE) can be found in RFC2212. DetNet uses flow-specific requirements (e.g., maximum number of out- of-order packets, maximum latency of the flow) for configuration of POF-related buffers.  POF implementation details are out-of-scope for this document and POF configuration parameters are implementation specific.  The Controller Plane determines and sets the POF configuration parameters.  If PEF is combined with POF, then their configurations need to be coordinated to ensure the combined functionality. </ins> 4.2.3. F-Labels support the DetNet forwarding sub-layer.  F-Labels are used

Proposed changes: 0, fixing Roman Danyliw comment 1, change introduction to highlight additional functions of data plane and the focus of the draft 2, highlight that implementation of PREOF is out of scope, pointing to related IEEE work (i.e., 802.1CB) 3, fixing the POF section and its configuration via controller plane


Question: Abstract <del> The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for enabling real-time communications within user-agents using web technologies (commonly called "WebRTC").  This document defines the security architecture for WebRTC. </del> <ins> This document defines the security architecture for WebRTC, a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". </ins> 1.

Pretty sure we'll get a GEN-ART reviewing say to not refer to the WG by name because it will get closed at some point. I basically stole the intro from overview and modified it slightly.


Question: QUIC DATAGRAM frames do not provide a means to demultiplex application contexts.  This document describes how to use QUIC DATAGRAM frames when the application protocol running over QUIC is <del> HTTP/3.  It defines logical flows identified by a non-negative integer that are present at the start of the DATAGRAM frame payload. Flows are associated with HTTP messages using the Datagram-Flow-Id header field, allowing endpoints to match unreliable DATAGRAMS frames to the HTTP messages that they are related to. </del> <ins> HTTP/3.  It associates datagrams with client-initiated bidirectional streams and defines an optional additional demultiplexing layer. </ins> Discussion of this work is encouraged to happen on the MASQUE IETF mailing list (masque@ietf.org [1]) or on the GitHub repository which

This PR aims to take the design discussions we had at the last interim, and propose a potential solution. This PR should in theory contain enough information to allow folks to implement this new design. That will allow us to perform interop testing and confirm whether the design is sound.
I'm confused by this pull request (probably because I was out of the loop for a while). My understanding, at least when I first read the proposal a month ago was that we would separate multiplexing streams and multiplexing contexts into different layers, so that methods that need context would get it (CONNECT-UDP), and features that don't (WebTransport/extended CONNECT) could use stream-associated datagrams directly.
NAME you're referring to which this PR isn't trying to address. That'll happen in a subsequent PR.
In , capsules, contexts and context IDs are explicitly defined as end-to-end and there are requirements for intermediaries to not modify them, and to not even parse them. The motivation for this was to ensure that we retain the ability to deploy extensions end-to-end without having to modify intermediaries. NAME mentioned that these requirements might be too strict, as he would like to have his intermediary be able to parse the context ID, for logging purposes.
Part of the comment from the PR is also about consistency of interface for generic HTTP libraries that can be used to build either endpoints or intermediaries. If the context ID is always present, it's overly prescriptive to say that an intermediary can't parse it, and such a requirement couldn't be enforced anyways. If context IDs are negotiated on/off, whether this is possible depends on the negotiation mechanism.
I think its fine for a component that has bytes passing through it to look at those bytes. The import thing to do is set expectations on what that means for the protocol behaviour we are defining. We don't expect intermediaries to do anything with a context ID; they should not enforce the protocol semantic rules (odd, even, reuse etc). H2 and H3 somewhat solve this problem by decoupling frame parsing from frame payload interpretation. E.g. if the form of a request or response is invalid, an intermediary shouldn't pass it on. DATAGRAM is different because it isn't defined as an actual HTTP/3 frame with frame headers and frame payload.


Question: QUIC DATAGRAM frames do not provide a means to demultiplex application contexts.  This document describes how to use QUIC DATAGRAM frames when the application protocol running over QUIC is <del> HTTP/3.  It defines logical flows identified by a non-negative integer that are present at the start of the DATAGRAM frame payload. Flows are associated with HTTP messages using the Datagram-Flow-Id header field, allowing endpoints to match unreliable DATAGRAMS frames to the HTTP messages that they are related to. </del> <ins> HTTP/3.  It associates datagrams with client-initiated bidirectional streams and defines an optional additional demultiplexing layer. </ins> Discussion of this work is encouraged to happen on the MASQUE IETF mailing list (masque@ietf.org [1]) or on the GitHub repository which

Something that might work is to formalise that quarter stream ID is part of the envelope that intermediaries have to be able to handle the syntax of, but context ID is part of content and separate.
Unless you encrypt capsules end-to-end, I don't think any text in the spec can in practice prevent intermediaries from inspecting and modifying capsules. You can send something like GREASE capsules, though.
In , we introduce the CLOSEDATAGRAMCONTEXT capsule which allows endpoints to close a context. That message currently only contains the context ID to close. NAME suggests that we may want to add more information there. Should we differentiate between "context close" and "context registration rejected"? Should we add an error code? In particular, do folks have use cases for these features?
My first concern is with infinite loops. If the context was "garbage collected" by the recipient, the sender can simply re-create it if they still want it. However, if it was closed due to incompatibility (i.e. rejected) or hitting a resource limit (e.g. max # of contexts), reopening it in response will produce a tight infinite loop. This could be maybe be avoided by some kind of heuristic, but an explicit indication of what's going on seems better.
This issue assumes that decide to go with the two-layer design described in . Given that design, some applications might not need the multiplexing provided by context IDs. We have multiple options here: Make context ID mandatory Applications that don't need it waste a byte per datagram Negotiate the presence of context IDs using an HTTP header Context IDs would still be mandatory to implement on servers because the client might send that header Have the method determine whether context IDs are present or not This would prevent extensibility on those methods Create a REGISTERNOCONTEXT message This assumes we use the Message design from We add a register message that means that this stream does not use context IDs This allows avoiding the byte overhead without sacrificing extensibility
Making the context ID mandatory is simple, although slightly wasteful. For the variations where it is optional, I prefer the one that uses a header. It could work with a variant of where we do Header + Message, and the Header determines whether or not you have contexts, and whether or not they can be dynamic.
What are the benefits of message over header to make it optional?


Question: QUIC DATAGRAM frames do not provide a means to demultiplex application contexts.  This document describes how to use QUIC DATAGRAM frames when the application protocol running over QUIC is <del> HTTP/3.  It defines logical flows identified by a non-negative integer that are present at the start of the DATAGRAM frame payload. Flows are associated with HTTP messages using the Datagram-Flow-Id header field, allowing endpoints to match unreliable DATAGRAMS frames to the HTTP messages that they are related to. </del> <ins> HTTP/3.  It associates datagrams with client-initiated bidirectional streams and defines an optional additional demultiplexing layer. </ins> Discussion of this work is encouraged to happen on the MASQUE IETF mailing list (masque@ietf.org [1]) or on the GitHub repository which

To me it seems like header is sufficient, because the context IDs are end-to-end, and should not affect intermediaries, making the header a natural place to put it. I think having the context ID be the default behavior and the header is to opt-out is the right decision if we were to allow removing it.
This is a bit of a bike-shed, but why would it default to having context-IDs instead of not having them?
I think the second option "Negotiate the presence of context IDs using an HTTP header" is the best personally. In terms of: "Context IDs would still be mandatory to implement on servers because the client might send that header", I assume server in this context is the final application server, not a proxy? Even so, I'd argue it's applications which decide if they need this functionality, so if a server only implemented one application and it didn't use Context-IDs, then I don't see why it would need to implement it.
Ian, in your comment, are you talking about an intermediary when you say "proxy"? If so, then an intermediary need not implement anything based on the payload of than H3 DATAGRAM, it only has to pass the data along. That may be worth a clarification.
Having context ID optional has a nice future-proof property - other uses of datagrams in HTTP/3 can decide if they want the second layer or not. I wouldn't even state it as application needing multiplexing or not. Other applications might find it very useful to include a second ((third, fourth, fifth) layer of frame header. I think its fine for us to state as much in this in the spec, while also defining an explicit second layer for multiplexing.
Yes, by proxy I meant intermediary. And I agree about what intermediaries need to do, I just wanted to ensure I understood what server meant when David used it above. Yup, whenever all this gets written up, we can make it clear that intermediaries can ignore much of this.
The method defines the semantics of datagrams for a particular request, thus I think the third option makes most sense.


Question: QUIC DATAGRAM frames do not provide a means to demultiplex application contexts.  This document describes how to use QUIC DATAGRAM frames when the application protocol running over QUIC is <del> HTTP/3.  It defines logical flows identified by a non-negative integer that are present at the start of the DATAGRAM frame payload. Flows are associated with HTTP messages using the Datagram-Flow-Id header field, allowing endpoints to match unreliable DATAGRAMS frames to the HTTP messages that they are related to. </del> <ins> HTTP/3.  It associates datagrams with client-initiated bidirectional streams and defines an optional additional demultiplexing layer. </ins> Discussion of this work is encouraged to happen on the MASQUE IETF mailing list (masque@ietf.org [1]) or on the GitHub repository which

I don't see a point in using explicit negotiation, since in the two cases I can think of the top of the head, the answer is always clear from the method (CONNECT-IP seems to always want context IDs, WebTransport does not ever want context IDs). If some method starts out without context, but wants to add context later, it can add its own negotiation.
One set of use cases for which the method approach(3) is best are those where there are multiple context IDs but they're predefined by the method and don't need negotiation. My strawman is WebRTC.
During the 2021-04 MASQUE Interim, we discussed multiple options for registering context IDs. Without going into the specific of the encoding, there are two broad classes of solutions: "Header" design Once-at-setup registration This happens during the HTTP request/response Simplest solution is to use an HTTP header such as (encoding TBD) Example use-case: CONNECT-UDP without extensions "Message" design Mid-stream registration This can happen at any point during the lifetime of the request stream This would involve some sort of "register" message (encoding TBD, see separate issue) Example use-case: CONNECT-IP on-the-fly compression (this can't be done at tunnel setup time because the bits top be compressed aren't always known at that time) It's possible to implement once-at-setup registration using the Message design, but it isn't possible to implement mid-stream registration. Therefore I think we should go with the Message design. It would also be possible to implement both but I don't think that provides much value.
I'd like to here some more from the WebTransport use case on the issue. My understanding is that the Requests are used to create WebTransport sessions and that creation of datagram flows(contexts) could be a lot more ad-hoc / server generated after the request phase, when compared to the CONNECT-UDP case. Cc NAME
Personally, I'd vote for either "message" or "message + header" (a la priorities), but not just "header". Mid-stream annotation of context/flow/etc is quite useful.
I prefer "Message" only, since the dynamic use case seems like a fairly compelling use of sub-flows(contexts?).


Question: QUIC DATAGRAM frames do not provide a means to demultiplex application contexts.  This document describes how to use QUIC DATAGRAM frames when the application protocol running over QUIC is <del> HTTP/3.  It defines logical flows identified by a non-negative integer that are present at the start of the DATAGRAM frame payload. Flows are associated with HTTP messages using the Datagram-Flow-Id header field, allowing endpoints to match unreliable DATAGRAMS frames to the HTTP messages that they are related to. </del> <ins> HTTP/3.  It associates datagrams with client-initiated bidirectional streams and defines an optional additional demultiplexing layer. </ins> Discussion of this work is encouraged to happen on the MASQUE IETF mailing list (masque@ietf.org [1]) or on the GitHub repository which

I'm not sure there are many cases when one allocates all sub-flows up front AND needs to use a header to do that in a flexible way. If an application needs multiple sub-flows, but they're fixed in number/format(ie: data and control), I don't think there's a need for a header or a "Message", since the application can consider that part of its internal format.
During the 2021-04 MASQUE Interim, we discussed having the ability to accept or reject registration of context IDs. An important motivation for this is the fact that context ID registrations take up memory (for example it could be a compression context which contains the data that is elided) and therefore we need to prevent endpoints from arbitrarily making their peer allocate memory. While we could flow control context ID registration, a much simpler solution would be to have a way for endpoints to close/shutdown a registration.
IIUC there's an opposing view that the constraints can be negotiated apiori. Either statically (such as defining an extension which states that there can only be N contenxts of a given type) or dynamically using something like a HTTP header. Failure to meet these constraints could lead to an HTTP/3 stream or connection error rather than a flow rejection.
NAME I've filed to discuss whether to register/negotiate at request start or mid-stream.
I think that if there is the ability to register mid-stream (), we need the ability to close/de-register/reject mid-stream as well. If we don't have mid-stream changes, then no need to negotiate. However, someone trying to register something needs to be able to know whether or not the thing they registered will be accepted.
I agree that notification of the registration status is particularly important if we allow mid-stream registration.
In draft-ietf-masque-h3-datagram-00, flow IDs are bidirectional. During the 2021-04 MASQUE Interim, we discussed the possibility of making them unidirectional. Here are the differences: Bidirectional single shared namespace for both endpoints (even for client, odd for server) it's easier to refer to peer's IDs, which makes negotiation easier Unidirectional one namespace per direction every bidirectional use needs to associate both directions somehow I'm personally leaning towards keeping them bidirectional.


Question: QUIC DATAGRAM frames do not provide a means to demultiplex application contexts.  This document describes how to use QUIC DATAGRAM frames when the application protocol running over QUIC is <del> HTTP/3.  It defines logical flows identified by a non-negative integer that are present at the start of the DATAGRAM frame payload. Flows are associated with HTTP messages using the Datagram-Flow-Id header field, allowing endpoints to match unreliable DATAGRAMS frames to the HTTP messages that they are related to. </del> <ins> HTTP/3.  It associates datagrams with client-initiated bidirectional streams and defines an optional additional demultiplexing layer. </ins> Discussion of this work is encouraged to happen on the MASQUE IETF mailing list (masque@ietf.org [1]) or on the GitHub repository which

Unlike QUIC streams, these do not have a state machine or flow control credits, so there is no cost to only using a single direction of a bidirectional flow for unidirectional use-cases.
There's another option where flows are unidirectional but they share a namespace (cleint even/server odd). I'm undecided. And I also don't know how important it is to choose. The 2 layer design means that DATAGRAMs always have a bidirectional tie via the stream ID. On balance, I think bidirectional would be good enough today but I would be receptive to extension use cases that make a strong point of unidirectional.
Bidirectional is my personal preference, but either way could work ultimately. It seems to me that any extension that wants unidirectional can just only use this context/flow/etc ID for one direction if it wants.
I think bidirectional flows are likely overcomplicated and unnecessary. For example, if either peer can "close" a flow, this requires a much more complex state machine. In my experience, half-closed states are hard to get right. Closing unidirectional flows seems much easier to reason about. Many, perhaps most, of our use cases for flows are really unidirectional. For example, DSCP marking likely only makes sense from client to server, while timestamps for congestion control tuning likely only make sense from server to client. QUIC connection IDs are different in each direction, so QUIC header compression may be easiest to understand with unidirectional flows.
Bidirectional doesn't imply half-close states. I'm thinking of a bidirectional flow that can only be closed atomically as a whole. I don't think that's true. The default extension-less CONNECT-UDP is bidirectional. So is ECN, and so would a timestamp extension.
I would prefer bidirectional without support for half-close. I feel that having unidirectional flow/context IDs adds overhead we don't need; peers now need to track those associations and it's unclear what the benefits of having them separated out are.
This issue is conflating consent (unilateral/bilateral) with scope (unidirectional/bidirectional). IIUC there are two questions here: 1) Can I send a flow-id forever once declared, or can the endpoint tell me to stop without killing the whole stream (consent)?


Question: QUIC DATAGRAM frames do not provide a means to demultiplex application contexts.  This document describes how to use QUIC DATAGRAM frames when the application protocol running over QUIC is <del> HTTP/3.  It defines logical flows identified by a non-negative integer that are present at the start of the DATAGRAM frame payload. Flows are associated with HTTP messages using the Datagram-Flow-Id header field, allowing endpoints to match unreliable DATAGRAMS frames to the HTTP messages that they are related to. </del> <ins> HTTP/3.  It associates datagrams with client-initiated bidirectional streams and defines an optional additional demultiplexing layer. </ins> Discussion of this work is encouraged to happen on the MASQUE IETF mailing list (masque@ietf.org [1]) or on the GitHub repository which

2) Can the receiver of a flow-id assignment use that same flow-id when sending datagrams, or could this mean something completely different? I think the answer to (1) is "yes, it can tell me to stop" (i.e. it is negotiated while allowing speculative sending). For (2), I lean toward bidirectional, but not strongly. There are plenty of codepoints, so it seems wasteful for each endpoint to define the same semantic explicitly.
NAME the intent of this issue wan't to conflate those two things. This issue is about scope. For consent, see issue .
Conceptually, I like unidirectional better. I tell the peer that when I send with context-ID=X, it has a given semantic. For bidirectional the sender is saying both that and that if the peer sends on that ID the original sender will interpret with the same semantic. That might not even make sense. Is it possible to associate datagrams with a unidirectional stream (push?). If so, does allowing for bidirectional context imply that even though the receiver cannot send frames on the stream, it can send datagrams? Every negotiation does run the risk of loss/reordering resulting in a drop or buffering event at the receiver. The appeal of bidirectional is that it removes half of this risk in the cases where the bidirectionality is used.
To second NAME I would also prefer bidirectional without support for half-close. Given you can always not send something in one direction, and there's none of the overhead of streams(ie: flow control, etc) I can't see any benefits of unidirectional over bidirectional in this case. Associating h3-datagrams with a server push seems like unnecessary complexity to me, but you're right that it should be clarified.
During the 2021-04 MASQUE Interim, we discussed a design proposal from NAME to replace the one-layer flow ID design with a two-layer design. This design replaces the flow ID with two numbers: a stream ID and a context ID.


Question: QUIC DATAGRAM frames do not provide a means to demultiplex application contexts.  This document describes how to use QUIC DATAGRAM frames when the application protocol running over QUIC is <del> HTTP/3.  It defines logical flows identified by a non-negative integer that are present at the start of the DATAGRAM frame payload. Flows are associated with HTTP messages using the Datagram-Flow-Id header field, allowing endpoints to match unreliable DATAGRAMS frames to the HTTP messages that they are related to. </del> <ins> HTTP/3.  It associates datagrams with client-initiated bidirectional streams and defines an optional additional demultiplexing layer. </ins> Discussion of this work is encouraged to happen on the MASQUE IETF mailing list (masque@ietf.org [1]) or on the GitHub repository which

The contents of the QUIC DATAGRAM frame would now look like: While the flow ID in the draft was per-hop, the proposal has better separation: the stream ID is per-hop, it maps to an HTTP request the context ID is end-to-end, it maps to context information inside that request Intermediaries now only look at stream IDs and can be blissfully ignorant of context IDs. In the room at the 2021-04 MASQUE Interim, multiple participants spoke in support of this design and no one raised objections. This issue exists to ensure that we have consensus on this change - please speak up if you disagree.
I am fine with the 2-layer design for CONNECT-UDP, but I am not sure if the second identifier should be in H3 DATAGRAM or should be specific to CONNECT-UDP. As I indicated to the list, webtrans and httpbis might weigh in on this with broader consideration of other use cases.
Hi NAME the topic of the optionality of context IDs is discussed in issue .
I think this is a good design, because it minimizes the core functionality of the draft, but avoids every application that needs multiple dynamically created sub-flows from re-inventing a different mechanism. Nit: I would not call this a 'Frame', since it's not an HTTP(TLV) frame.
I think this is a good change. Thanks! There are some things that I think we should still discuss, but we shouldn't hold up this change on those details.


Question: The ":method" pseudo-header field SHALL be "CONNECT". <del> The ":protocol" pseudo-header field SHALL be "masque-udp". </del> <ins> The ":protocol" pseudo-header field SHALL be "connect-udp". </ins> The ":authority" pseudo-header field SHALL contain the authority of the proxy.

Should the upgrade token be "connect-udp" or "masque-udp" ? (issue based on by NAME
I vote for or something along those lines. "MASQUE" is good as a working group name, but I don't think it's helpful in the protocol to help people understand what the variant of CONNECT does.


Question: PRK_exporter is derived from PRK_out: where hash_length denotes the output size in bytes of the EDHOC hash <del> algorithm of the selected cipher suite. PRK_exporter MUST be derived anew from PRK_out if EDHOC-KeyUpdate is used, see keyupdate. </del> <ins> algorithm of the selected cipher suite.  Note that PRK_exporter changes every time EDHOC-KeyUpdate is used, see keyupdate. </ins> The (label, context) pair used in EDHOC-Exporter must be unique, i.e., a (label, context) MUST NOT be used for two different purposes.

Should be checked for conflicts with
I think fixing the comments above resolves conflict with , so can then be replaced by this.
This proposal for update in the key derivation description also addresses the clarifications requested in , thus replacing . We merge this to include it in -15 and enable further reviews.
This is not correct. How to derive and store PRKexporter is completely up to the implementation. One can derive PRKexporter everytime Exporter is called. This make it look like PRKout is overwritten. This should be formulated with and like TLS 1.3 or with and or something. How long to save the old keying material (PRKout, PRK_Exported, any derived keys) is likely up to the application. The importand thing is that they need to be deleted to give FS.
There was a request from someone that more guidance on the use of KeyUpdate should be expanded. Maybe not clear how you are supposed to alternate KeyUpdate and Exporter to get FS.
As you are considering making the KeyUpdate more detailed, I have a general design question. Are there use cases where one would expect Post-Compromise Security? That is, if one of the participant's PRK_out is compromised, a successful KeyUpdate mechanism between the two honest parties would heal them and lock out the attacker That is typically what is met by the double ratchet from the Signal app. The classical way to achieve that is roughly to have each party send out for the update fresh DH ephemeral shares, and add the corresponding DH secret inside the key derivation. (it would of course require more care than that in the details)
I think part of the plan is to make it less detailed and leave some stuff to the implementation/application :) The current KeyUpdate mechanism only gives forward secrecy. If you exchange some nonces and use them as a context you might get protection against an attacker is not monitoring all your traffic. I think details of this should be specified outside of EDHOC like in the OSCORE KeyUpdate draft in the CORE WG. The double ratchet was discussed in LAKE WG at an earlier point. The conclusion was that it added to much complexity to specify that as part of EDHOC. To get this kind of security an application has to rerun EDHOC frequently (like TLS 1.3).


Question: PRK_exporter is derived from PRK_out: where hash_length denotes the output size in bytes of the EDHOC hash <del> algorithm of the selected cipher suite. PRK_exporter MUST be derived anew from PRK_out if EDHOC-KeyUpdate is used, see keyupdate. </del> <ins> algorithm of the selected cipher suite.  Note that PRK_exporter changes every time EDHOC-KeyUpdate is used, see keyupdate. </ins> The (label, context) pair used in EDHOC-Exporter must be unique, i.e., a (label, context) MUST NOT be used for two different purposes.

Signal uses the Diffie-Hellman ratchet very often which makes it understandable to have on optimized Diffie-Hellman ratchet post-handshake. Contrained use cases of EDHOC can not do Diffie-Hellman as often as Signal so it was determined that requiring rerun of the full EDHOC was the best tradeoff. Should the EDHOC specification say more about the benefits of frequently rerunning Diffie-Hellman? I don't remember how much it says. I recently wrote a paragraph about this that was accepted to RFC8446bis.
This is not correct. PRKout does not need to be stored. An implementation can derive the application keys directly and never store PRKout. An implementation can also store PRK_exporter if they don't use EDHOC-KeyUpdate.
This is not enough. You need to be sure that the old key is not needed more.
I merged which addresses some points raised in this issue. Please review and comment if there is anything missing.
No comments received, so I assume this is fine. (KeyUpdate is now in an appendix.)


Question: 6.4.1. Fundamentally, the IdP proxy is just a piece of HTML and JS loaded by <del> the browser, so nothing stops a Web attacker o from creating their own IFRAME, loading the IdP proxy HTML/JS, and requesting a signature.  In order to prevent this attack, we require that all signatures be tied to a specific origin ("rtcweb://...") which cannot be produced by content JavaScript.  Thus, while an attacker can instantiate the IdP proxy, they cannot send messages from an appropriate origin and so cannot create acceptable assertions.  I.e., the assertion request must have come from the browser.  This origin check is enforced on the relying party side, not on the authenticating party side.  The reason for this is to take the burden of knowing which origins are valid off of the IdP, thus making this mechanism extensible to other applications besides WebRTC.  The IdP simply needs to gather the origin information (from the posted message) and attach it to the assertion. </del> <ins> the browser, so nothing stops a Web attacker from creating their own IFRAME, loading the IdP proxy HTML/JS, and requesting a signature. In order to prevent this attack, we require that all signatures be tied to a specific origin ("rtcweb://...") which cannot be produced by content JavaScript.  Thus, while an attacker can instantiate the IdP proxy, they cannot send messages from an appropriate origin and so cannot create acceptable assertions.  I.e., the assertion request must have come from the browser.  This origin check is enforced on the relying party side, not on the authenticating party side.  The reason for this is to take the burden of knowing which origins are valid off of the IdP, thus making this mechanism extensible to other applications besides WebRTC.  The IdP simply needs to gather the origin information (from the posted message) and attach it to the assertion. </ins> Note that although this origin check is enforced on the RP side and not at the IdP, it is absolutely imperative that it be done.  The

I've found a few typos and fixed some sentences that didn't quite make sense. I don't think the meaning has been changed in any significant way.


Question: The method the client instance uses to send an access token depends on whether the token is bound to a key, and if so which proofing method is associated with the key.  This information is conveyed in <del> the "key" and "proof" parameters in response-token-single. </del> <ins> the "bound" and "key" parameters in response-token-single and response-token-multiple responses. </ins> <del> If the "key" value is the boolean "false", the access token is a bearer token sent using the HTTP Header method defined in RFC6750. </del> <ins> If the "bound" value is the boolean "true" and the "key" is absent, the access token MUST be sent using the same key and proofing mechanism that the client instance used in its initial request (or its most recent rotation). </ins> <del> The form parameter and query parameter methods of RFC6750 MUST NOT be used. </del> <ins> If the "bound" value is the boolean "true" and the "key" value is an object as described in key-format, the access token MUST be sent using the key and proofing mechanism defined by the value of the "proof" field within the key object. </ins> <del> If the "key" value is the boolean "true", the access token MUST be sent using the same key and proofing mechanism that the client instance used in its initial request (or its most recent rotation). </del> <ins> The access token MUST be sent using the HTTP "Authorization" request header field and the "GNAP" authorization scheme along with a key proof as described in binding-keys for the key bound to the access token.  For example, a "jwsd"-bound access token is sent as follows: </ins> <del> If the "key" value is an object as described in key-format, the value of the "proof" field within the key indicates the particular proofing mechanism to use.  The access token is sent using the HTTP authorization scheme "GNAP" along with a key proof as described in binding-keys for the key bound to the access token.  For example, a "jwsd"-bound access token is sent as follows: </del> <ins> If the "bound" value is the boolean "false", the access token is a bearer token that MUST be sent using the "Authorization Request Header Field" method defined in RFC6750. The "Form-Encoded Body Parameter" and "URI Query Parameter" methods of RFC6750 MUST NOT be used. </ins> [[ See issue #104 [47] ]] <ins> The client software MUST reject as an error a situation where the "bound" value is the boolean "false" and the "key" is present. </ins> 7.3. Any keys presented by the client instance to the AS or RS MUST be

Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit a5ab40750ac9435b370bab7ded6dbdc60b35b01a https://deploy-preview-208--gnap-core-protocol-editors-URL
It may make sense to change the order to something like == && is present == && is absent == == && is present
I did changes for URL There are lots of other things that, I believe, could be improved & changed for the "Presenting Access Tokens" section and they will be addressed in separate PRs in the future.
Thank you, this is great! Aligns with the language in


Question: path via the attacker.  This places the attacker on path, giving it the ability to observe or drop all subsequent packets. <del> Unlike the attack described in on-path-spoofing, the attacker can ensure that the new path is successfully validated. </del> This style of attack relies on the attacker using a path that is approximately as fast as the direct path between endpoints.  The attack is more reliable if relatively few packets are sent or if

This text could be read to imply that an off-path attacker is more capable than an on-path attacker, which is rarely true. What it was meant to point out was that it is easier to move traffic onto a path that you are on. What it fails to acknowledge is that it is also easier to move traffic off a path that you are on. In other words, the treatment of this in 21.12 is more thorough and we don't need to talk about limitations. Mike suggested that there is some duplication between this attack and the more comprehensive analysis in 21.12. That is true, but these serve different purposes. This is to describe attacks and the normative requirements on endpoints necessary to avoid them. The other section is a thorough and hollistic analysis. I couldn't see any truly straightforward changes. That doesn't mean that we won't find a way to clean this up, or that it would be undesirable to have fewer words, but I've not the time for that right now.
I find the text in 9.3.3 confusing, because it says: Unlike the attack described in {{on-path-spoofing}}, the attacker can ensure that the new path is successfully validated. This is odd because on-path attackers are generally regarded as stronger than on-path attackers. Why can't an on-path attacker complete this attack.
I think you're right that the text is confusing, if not quite incorrect. An on-path attacker can rewrite a source address, causing an apparent migration, but can't cause path validation to succeed with that source address unless it is actually on-path from both endpoints to the spoofed addresses as well. An off-path attacker which can race packets successfully can cause migration with successful path validation to a path which includes it, becoming a limited on-path attacker. This also feels slightly duplicative of 21.12.3; it might be worth condensing some text between these sections.


Question: whether a threshold has been met and an acknowledgement is to be sent in response. <del> 5. </del> <ins> 6. </ins> An endpoint can send multiple ACK-FREQUENCY frames, and each one of them can have different values.

This PR changes a few things: Introduces a TP for negotiating extension use Changes to Makes the fields required Specifies invalid values
I'm merging this, let's address issues in later PRs.
I think it'll be easier to make both parameters required. Not doing so saves 1 to 2 bytes, which is really not much in a frame I expect will be sent a few times a connection. Also, I think 0 should be an invalid value for both params, and 1 should be invalid for the number of packets, though I can see someone arguing that point.
addresses these issues, with the exception that 1 is allowed for packet tolerance. I think that's actually useful for some startup schemes, so we shouldn't disallow it.