Question:
Talk about what to do with header extensions in a remote description Expand discussion of how to handle payload types in a remote description Fail things we don’t know about in an answer ,
LGTM
NAME PTAL at my responses
URL If any indicated payload type is unknown, it MUST be ignored. [TODO: should fail on answers] (q: does this logic need to also include processing for other lines - extmap, rtcp-fb, etc - that weren't present in the offer?)
Fixed by
URL 2) * For each specified payload type that is also supported by the local implementation, establish a mapping between the payload type ID and the actual media format. [TODO - Justin to add more to explain mapping.]
Relevant to as well
Fixed by
URL 1) If the media section proto value indicates use of RTP: [TODO: header extensions]
LGTM

If the media section proto value indicates use of RTP: <ins> If the media section references any media formats, RTP header extensions, or RTCP feedback mechanisms that were not present in the corresponding media section in the offer, this indicates a negotiation problem and MUST result in an error. </ins> If the media section has RTCP mux enabled, discard any RTCP component, and begin or continue muxing RTCP over the RTP component, as specified in RFC5761, Section 5.1.3.  Otherwise,


Question:
Talk about what to do with header extensions in a remote description Expand discussion of how to handle payload types in a remote description Fail things we don’t know about in an answer ,
LGTM
NAME PTAL at my responses
URL If any indicated payload type is unknown, it MUST be ignored. [TODO: should fail on answers] (q: does this logic need to also include processing for other lines - extmap, rtcp-fb, etc - that weren't present in the offer?)
Fixed by
URL 2) * For each specified payload type that is also supported by the local implementation, establish a mapping between the payload type ID and the actual media format. [TODO - Justin to add more to explain mapping.]
Relevant to as well
Fixed by
URL 1) If the media section proto value indicates use of RTP: [TODO: header extensions]
LGTM

the RTCP transmission for this media section to use reduced- size RTCP, as specified in RFC5506. <ins> [TODO: enable appropriate rtcp-fb mechanisms] </ins> If the directional attribute in the answer is of type "sendrecv" or "sendonly", prepare to start transmitting media <del> using the specified primary SSRC and one of the selected payload types, once the underlying transport layers have been established.  If RID values are specified, include the RID header extension in the RTP streams, as indicated in I-D.ietf- mmusic-rid, Section 4).  If simulcast is negotiated, send the number of Source RTP Streams as specified in I-D.ietf-mmusic- sdp-simulcast, Section 6.2.2.  If the directional attribute is of type "recvonly" or "inactive", stop transmitting RTP media, although RTCP should still be sent, as described in RFC3264, Section 5.1. </del> <ins> using the most preferred media format from the remote description that is also present in the answer, as described in RFC3264, Sections 6.1 and 7, once the underlying transport layers have been established.  [TODO: add discusssion of RED/FEC/RTX/CN] The payload type mapping from the remote description is used to determine payload types for the outgoing RTP streams.  Any RTP header extensions that were negotiated should be included in the outgoing RTP streams, using the extension mapping from the remote description; if the RID header extension has been negotiated, and RID values are specified, include the RID header extension in the outgoing RTP streams, as indicated in I-D.ietf-mmusic-rid, Section 4).  If simulcast is negotiated, send the number of Source RTP Streams as specified in I-D.ietf-mmusic-sdp-simulcast, Section 6.2.2. If the directional attribute is of type "recvonly" or "inactive", stop transmitting RTP media, although RTCP should still be sent, as described in RFC3264, Section 5.1. </ins> If the media section proto value indicates use of SCTP:


Question:
This is OK with me
S 5.2.2 says: If the initial offer was applied using setLocalDescription, but an answer from the remote side has not yet been applied, meaning the PeerConnection is still in the "local-offer" state, an offer is generated by following the steps in the "stable" state above, along with these exceptions: o The "s=" and "t=" lines MUST stay the same. o Each "a=mid" line MUST stay the same. o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same. However, Section 5.2.3.4 says: If the "IceRestart" constraint is specified, with a value of "true", the offer MUST indicate an ICE restart by generating new ICE ufrag and pwd attributes, as specified in RFC5245, Section 9.1.1.1. If this constraint is specified on an initial offer, it has no effect (since a new ICE ufrag and pwd are already generated).
Yes, if this is an ICE restart, then ufrag/pwd need to change.
Discussed in DC: restart requires a change of credentials. Might want to add text that notes the dangers in doing this (i.e., don't do this).

Each "a=mid" line MUST stay the same. <del> Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same. </del> <ins> Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same unless the "IceRestart" option (sec.options-handling was specified.  Note that it's not clear why you would actually want to do this, since at this point ICE has not yet started and is thus unlikely to need a restart. </ins> For MediaStreamTracks that are still present, the "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST stay the same.


Question:
Provisional answers, on the other hand, do no such deallocation results as a result, multiple dissimilar provisional answers can be received and applied during call setup.
Fixe by

resources allocated by the caller can be released, now that the exact session configuration is known.  These "resources" can include things like extra ICE components, TURN candidates, or video decoders. <del> Provisional answers, on the other hand, do no such deallocation results; as a result, multiple dissimilar provisional answers can be received and applied during call setup. </del> <ins> Provisional answers, on the other hand, do no such deallocation; as a result, multiple dissimilar provisional answers can be received and applied during call setup. </ins> In RFC3264, the constraint at the signaling level is that only one offer can be outstanding for a given session, but at the media stack


Question:
Fixes issue .
Section 4.2.3: The setDirection method sets the direction of a transceiver, which affects the direction attribute of the associated m= section on future calls to createOffer and createAnswer. [BA] "sets the direction of a transceiver" is a bit confusing because setDirection() doesn't immediately change whether an RtpSender can send or an RtpReceiver can receive. Since setDirection does immediately change the value of the transceiver.direction attribute you might say "sets the transceiver.direction attribute" instead. Also, an application may want to determine the current direction (e.g. whether an RtpSender can send or an RtpReceiver can receive) as opposed to the pending direction (provided by transceiver.direction). Taylor agreed to create a WebRTC 1.0 PR to add the concept of current direction (e.g. by adding a currentDirection attribute). It would therefore be useful to add some text to Section 4.2.3 explaining the distinction. For example: "Note that while setDirection sets the transceiver.direction attribute immediately, this pending direction does not immediately affect whether an RtpSender will send or RtpReceiver will receive. After calls to setLocal/setRemoteDescription, the direction currently in effect is represented by transceiver.currentDirection (the attribute Taylor will be defining)."
As for naming: which of these makes the most sense? "direction"/"currentDirection" "pendingDirection"/"currentDirection" "preferredDirection"/"currentDirection" "preferredDirection"/"negotiatedDirection" I like "preferredDirection" (or something of that nature); "pending" is a bit of a misnomer here because it's possible the set direction may never end up negotiated.
NAME My personal preference would be "direction"/"currentDirection". While "pendingDirection" might be more accurate than "direction", I'm a bit scared of all the spec changes that might be result from changing the attribute name.
Agree with NAME
LGTM (direction + currentDirection).
NAME can this now be closed?
I don't think Bernard's concern was addressed, which is that "sets the direction of a transceiver" is too ambiguous. Now that we have a "currentDirection" to reference, I'll add some clarifying text like he suggested.
Resolved by .

transceiver direction is intersected with the offered direction, as explained in the sec.generating-an-answer section below. <ins> Note that while setDirection sets the direction attribute of the transceiver immediately (sec.transceiver-direction), this attribute does not immediately affect whether the transceiver's RtpSender will send or its RtpReceiver will receive.  The direction in effect is represented by the currentDirection attribute, which is only updated when an answer is applied. </ins> 4.2.4. The direction method returns the last value passed into setDirection.


Question:
LGTM
If RTCP mux is indicated, prepare to demux RTP and RTCP from the RTP ICE component, as specified in [RFC5761], Section 5.1.1. If RTCP mux is not indicated, but was indicated in a previous description, this MUST result in an error. I note that there can be difference here between an offer and an answer if the RTCP mux indication may have changed or not between these two description.
Agreed. If we offered rtcp-mux, but it wasn't accepted, the next offer would be without mux. It should only be an error if we accepted mux and already discarded the RTCP ICE component.

If RTCP mux is indicated, prepare to demux RTP and RTCP from the RTP ICE component, as specified in RFC5761, Section 5.1.1. <del> If RTCP mux is not indicated, but was indicated in a previous description, this MUST result in an error. </del> <ins> If RTCP mux is not indicated, but was previously negotiated, i.e., the RTCP ICE component no longer exists, this MUST result in an error. </ins> For each specified RTP header extension, establish a mapping between the extension ID and URI, as described in section 6 of


Question:
NAME don't love the way the bit about the pool turned out but I don't have better text. Fixed. Consensus here was this is fine. No, this seems fairly clear. URL Done. Done. Do you mean RTP here? If so, I'm feeling OK about this. Done.
Merging and will tweak post-merge

local description is supplied, and the number of transports currently in use does not match the number of transports needed by the local description, the PeerConnection will create transports as needed and <del> begin gathering candidates for them. </del> <ins> either withdraw an appropriate number of ICE candidates from the candidate pool or begin gathering candidates if sufficient pre- gathered candidates are not available. </ins> If setRemoteDescription was previously called with an offer, and setLocalDescription is called with an answer (provisional or final),


Question:
NAME don't love the way the bit about the pool turned out but I don't have better text. Fixed. Consensus here was this is fine. No, this seems fairly clear. URL Done. Done. Do you mean RTP here? If so, I'm feeling OK about this. Done.
Merging and will tweak post-merge

The 50 is based on 50 packets per second, the 40 is based on an estimate of total header size, the 1000 changes the unit from kbps to bps (as required by TIAS), and the 0.95 is to allocate <del> 5% to RTCP.  If more accurate control of bandwidth is needed, "TIAS" should be used instead of "AS". </del> <ins> 5% to RTCP.  "TIAS" is used in preference to "AS" because it provides more accurate control of bandwidth. </ins> For any "RR" or "RS" bandwidth values, handle as specified in RFC3556, Section 2.


Question:
NAME don't love the way the bit about the pool turned out but I don't have better text. Fixed. Consensus here was this is fine. No, this seems fairly clear. URL Done. Done. Do you mean RTP here? If so, I'm feeling OK about this. Done.
Merging and will tweak post-merge

If the media section has been rejected (i.e. port is set to zero in the answer), stop any reception or transmission of media for <del> this section, and discard any associated ICE components, as </del> <ins> this section, and, if there was no accepted media section bundled with this media section, discard any associated ICE components, as </ins> described in Section 9.2.1.3 of RFC5245. If the remote DTLS fingerprint has been changed or the dtls-id has


Question:
Originally raised by Christer Section 3.2 says: "JSEP also allows for an answer to be treated as provisional by the application. Provisional answers provide a way for an answerer to communicate initial session parameters back to the offerer, in order to allow the session to begin, while allowing a final answer to be specified later. This concept of a final answer is important to the offer/answer model; when such an answer is received, any extra resources allocated by the caller can be released, now that the exact session configuration is known." 1) I would like explicit text saying that this is a deviation from RFC 3264, where there is no such thing as a provisional answer. I would like to have a dedicated ³Deviations to RFC3264² (or something similar) section. 2) I would like explicit text saying that the final answer may be completely different (in terms of candidates, codecs, accepted m- line etc) from the provisional answer. 3) Related to 2), the final answer may also require NEW resources to be allocated.
We discussed this and we don't think text is needed for 1) or 3); the offerer doesn't release resources until the final answer. For 2), what kind of text did you have in mind?
Few notes to cullen from talking wtih Christer Christer proposals ... adding section "SDP Offer/Nswer Usage" document variation we make on SAVPF stuff explain how ANSWE / PR answer are used withen paringin multiple to single offer Points to section for details ... follwo proccedures in 3264
Cullen, I think I improved this. PTAL

session configuration is known.  These "resources" can include things like extra ICE components, TURN candidates, or video decoders. Provisional answers, on the other hand, do no such deallocation; as a <del> result, multiple dissimilar provisional answers can be received and applied during call setup. </del> <ins> result, multiple dissimilar provisional answers, with their own codec choices, transport parameters, etc., can be received and applied during call setup.  Note that the final answer itself may be different than any received provisional answers. </ins> In RFC3264, the constraint at the signaling level is that only one offer can be outstanding for a given session, but at the media stack


Question:
All the xref I removed are used elsewhere in spec other than the one which I added to where it is used.
Fixed as Justin suggested and ready for re review
NAME - have a look - I think I got all the changes
I tweaked the discussion of unknown a=; now LGTM

JSEP implementations must comply with the specifications listed below that govern the creation and processing of offers and answers. <del> The first set of specifications is the "mandatory-to-implement" set. All implementations must support these behaviors, but may not use all of them if the remote side, which may not be a JSEP endpoint, does not support them. The second set of specifications is the "mandatory-to-use" set.  The local JSEP endpoint and any remote endpoint must indicate support for these specifications in their session descriptions. </del> 5.1.1. <del> Implementations of JSEP MUST conform to I-D.ietf-rtcweb-rtp-usage. This list of mandatory-to-implement specifications is derived from the requirements outlined in that document and from I-D.ietf-rtcweb- security-arch. RFC4566 is the base SDP specification and MUST be implemented. RFC5764 MUST be supported for signaling the UDP/TLS/RTP/SAVPF RFC5764, TCP/DTLS/RTP/SAVPF RFC7850, "UDP/DTLS/SCTP" I-D.ietf- mmusic-sctp-sdp, and "TCP/DTLS/SCTP" I-D.ietf-mmusic-sctp-sdp RTP profiles. RFC5245 MUST be implemented for signaling the ICE credentials and candidate lines corresponding to each media stream.  The ICE implementation MUST be a Full implementation, not a Lite implementation. RFC5763 MUST be implemented to signal DTLS certificate fingerprints. RFC5888 MUST be implemented for signaling grouping information, and MUST be used to identify m= lines via the a=mid attribute. I-D.ietf-mmusic-msid MUST be supported, in order to signal associations between RTP objects and W3C MediaStreams and MediaStreamTracks in a standard way. The bundle mechanism in I-D.ietf-mmusic-sdp-bundle-negotiation MUST be supported to signal the ability to multiplex RTP streams on a single UDP port, in order to avoid excessive use of port number resources. The SDP attributes of "sendonly", "recvonly", "inactive", and "sendrecv" from RFC4566 MUST be implemented to signal information about media direction. RFC5576 MUST be implemented to signal RTP SSRC values and grouping semantics. RFC4585 MUST be implemented to signal RTCP based feedback. RFC5761 MUST be implemented to signal multiplexing of RTP and RTCP. RFC5506 MUST be implemented to signal reduced-size RTCP messages. RFC4588 MUST be implemented to signal RTX payload type associations. RFC3556 MUST be supported for control of RTCP bandwidth limits. The SDES SRTP keying mechanism from RFC4568 MUST NOT be implemented, as discussed in I-D.ietf-rtcweb-security-arch. As required by RFC4566, Section 5.13, JSEP implementations MUST ignore unknown attribute (a=) lines. 5.1.2. </del> All session descriptions handled by JSEP implementations, both local and remote, MUST indicate support for the following specifications. If any of these are absent, this omission MUST be treated as an


Question:
All the xref I removed are used elsewhere in spec other than the one which I added to where it is used.
Fixed as Justin suggested and ready for re review
NAME - have a look - I think I got all the changes
I tweaked the discussion of unknown a=; now LGTM

DTLS RFC6347 or DTLS-SRTP RFC5763, MUST be used, as appropriate for the media type, as specified in <del> 5.1.3. </del> <ins> The SDES SRTP keying mechanism from RFC4568 MUST NOT be used, as discussed in I-D.ietf-rtcweb-security-arch. 5.1.2. </ins> <del> For media m= sections, JSEP implementations MUST support both the "UDP/TLS/ RTP/SAVPF" and "TCP/DTLS/RTP/SAVPF" profiles and MUST indicate one of these two profiles for each media m= line they produce in an offer.  For data m= sections, implementations MUST support both the "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP" profiles and MUST indicate one of these two profiles for each data m= line they </del> <ins> For media m= sections, JSEP implementations MUST support the "UDP/TLS/RTP/SAVPF" profile specified in RFC7850, and MUST indicate this profile for each media m= line they produce in an offer.  For data m= sections, implementations MUST support the "UDP/DTLS/SCTP" profile and MUST indicate this profile for each data m= line they </ins> produce in an offer.  Because ICE can select either TCP or UDP <del> transport depending on network conditions, both advertisements are </del> <ins> transport depending on network conditions, this advertisement is </ins> consistent with ICE eventually selecting either either UDP or TCP. Unfortunately, in an attempt at compatibility, some endpoints


Question:
All the xref I removed are used elsewhere in spec other than the one which I added to where it is used.
Fixed as Justin suggested and ready for re review
NAME - have a look - I think I got all the changes
I tweaked the discussion of unknown a=; now LGTM

Any "a=extmap" lines are parsed as specified in RFC5285, Section 5, and their values are stored. <ins> As required by RFC4566, Section 5.13, unknown attribute lines MUST be ignored. </ins> Once all the session-level lines have been parsed, processing continues with the lines in m= sections.


Question:
All the xref I removed are used elsewhere in spec other than the one which I added to where it is used.
Fixed as Justin suggested and ready for re review
NAME - have a look - I think I got all the changes
I tweaked the discussion of unknown a=; now LGTM

as specified in I-D.ietf-mmusic-sctp-sdp, Section 6, and the value stored.  Otherwise, use the specified default. <ins> As required by RFC4566, Section 5.13, unknown attribute lines MUST be ignored. </ins> 5.7.3. Assuming parsing completes successfully, the parsed description is


Question: o If the m= section is not bundled into another m= section, an "a=rtcp" attribute line MUST be added with of the default RTCP candidate, as indicated in [RFC5761], Section 5.1.3.

section is bundled into another m= section, it still MUST NOT contain any ICE credentials. <del> If the m= section is not bundled into another m= section, an "a=rtcp" attribute line MUST be added with of the default RTCP candidate, as indicated in RFC5761, Section 5.1.3. </del> <ins> If the m= section is not bundled into another m= section, its "a=rtcp" attribute line MUST be filled in with the port and address of the default RTCP candidate, as indicated in RFC5761, Section 5.1.3.  If no RTCP candidates have yet been gathered, dummy values MUST be used, as described in the initial offer section above. </ins> If the m= section is not bundled into another m= section, for each candidate that has been gathered during the most recent gathering


Question:
In Section 5.4, JSEP says: " The SDP returned from createOffer or createAnswer MUST NOT be changed before passing it to setLocalDescription." However in Section 5.8, it says: "First, the parsed parameters are checked to ensure that they are identical to those generated in the last call to createOffer/ createAnswer, and thus have not been altered, as discussed in Section 5.4; otherwise, processing MUST stop and an error MUST be returned." [BA] So is any change to URL unacceptable (e.g. must be byte for byte identical)? Or is the text trying to say that the parsed representation must be the same (e.g. "a=" lines appearing in a different order shouldn't matter)?
I believe the expectation was that the description is entirely immutable. Verifying isomorphism in the face of minor modifications seems like something that is not entirely trivial, and TBH I don't quite understand why it would be needed.
Thanks. PR URL assumes that URL is immutable.
I will update 5.8 accordingly.

If the type is not correct for the current state, processing MUST stop and an error MUST be returned. <ins> The SessionDescription is then checked to ensure that its contents are identical to those generated in the last call to createOffer/ createAnswer, and thus have not been altered, as discussed in sec.modifying-sdp; otherwise, processing MUST stop and an error MUST be returned. </ins> Next, the SessionDescription is parsed into a data structure, as described in the sec.parsing-a-desc section below.  If parsing fails for any reason, processing MUST stop and an error MUST be


Question:
In Section 5.4, JSEP says: " The SDP returned from createOffer or createAnswer MUST NOT be changed before passing it to setLocalDescription." However in Section 5.8, it says: "First, the parsed parameters are checked to ensure that they are identical to those generated in the last call to createOffer/ createAnswer, and thus have not been altered, as discussed in Section 5.4; otherwise, processing MUST stop and an error MUST be returned." [BA] So is any change to URL unacceptable (e.g. must be byte for byte identical)? Or is the text trying to say that the parsed representation must be the same (e.g. "a=" lines appearing in a different order shouldn't matter)?
I believe the expectation was that the description is entirely immutable. Verifying isomorphism in the face of minor modifications seems like something that is not entirely trivial, and TBH I don't quite understand why it would be needed.
Thanks. PR URL assumes that URL is immutable.
I will update 5.8 accordingly.

a local description.  If an error is returned, the session MUST be restored to the state it was in before performing these steps. <del> First, the parsed parameters are checked to ensure that they are identical to those generated in the last call to createOffer/ createAnswer, and thus have not been altered, as discussed in sec.modifying-sdp; otherwise, processing MUST stop and an error MUST be returned. </del> Next, m= sections are processed.  For each m= section, the following steps MUST be performed; if any parameters are out of bounds, or cannot be applied, processing MUST stop and an error MUST be


Question:
I fixed the grammar and added some text about "subsequent verification"
Also see URL
What's the issue?
Someone thought we should talk about how to parse SDP with more than one identity line and handle that. I did not look, we may already have whatever we need in the draft but I just opened this so we would at least go check.
JSEP practice is just to put in placeholders and link to the defining draft, so we should punt the actual semantics in security-arch.
See email to rtcweb from Stefan Håkansson subject "Identity in the SDP"
Sayeth Stefan: >[2] URL

An "a=ice-options" line with the "trickle" option MUST be added, as specified in I-D.ietf-ice-trickle, Section 4. <ins> If WebRTC identity is being used, an "a=identity" line as described in I-D.ietf-rtcweb-security-arch, Section 5. </ins> The next step is to generate m= sections, as specified in RFC4566 Section 5.14.  An m= section is generated for each RtpTransceiver that has been added to the PeerConnection, excluding any stopped


Question:
I fixed the grammar and added some text about "subsequent verification"
Also see URL
What's the issue?
Someone thought we should talk about how to parse SDP with more than one identity line and handle that. I did not look, we may already have whatever we need in the draft but I just opened this so we would at least go check.
JSEP practice is just to put in placeholders and link to the defining draft, so we should punt the actual semantics in security-arch.
See email to rtcweb from Stefan Håkansson subject "Identity in the SDP"
Sayeth Stefan: >[2] URL

If present, a single "a=dtls-id" line is parsed as specified in I- D.ietf-mmusic-dtls-sdp Section 5, and the dtls-id value is stored. <ins> Any "a=identity" lines are parsed and the identity values stored for subsequent verification, as specified I-D.ietf-rtcweb- security-arch, Section 5. </ins> Any "a=extmap" lines are parsed as specified in RFC5285, Section 5, and their values are stored.


Question:
Note that the use of CVO in webrtc is described in URL
NAME feel free to rewrite however and merge. I just wanted to get the xref in.
We mention it in the imageattr section. This is required regardless of whether the receiver supports performing receive-side rotation (e.g., through CVO), as it significantly simplifies the matching logic.
NAME , can you look into this? Not WGLC2 blocking.
will do - I seem to recall it is a 3GPP ref but will try and track down.

appropriate).  Note that when considering a MediaStreamTrack that is producing rotated video, the unrotated resolution MUST be used.  This is required regardless of whether the receiver supports performing <del> receive-side rotation (e.g., through CVO), as it significantly simplifies the matching logic. </del> <ins> receive-side rotation (e.g., through CVO TS26.114), as it significantly simplifies the matching logic. </ins> For the purposes of resolution negotiation, only size limits are considered.  Any other values, e.g. picture or sample aspect ratio,


Question:
I was reading this draft and noticed a couple of minor wording issues that made the text not as clear as it could be. I don't believe the changes are controversial, or change the intention of the draft.
These changes look good - I agree the rewrite of the offer/answer paragraph is a nice improvement.
Looks fine to me

mechanism (e.g., WebSockets); upon receipt of that offer, the remote party installs it using the setRemoteDescription() API. <del> When the call is accepted, the callee uses the createAnswer() API to generate an appropriate answer, applies it using setLocalDescription(), and sends the answer back to the initiator over the signaling channel.  When the offerer gets that answer, it installs it using setRemoteDescription(), and initial setup is complete.  This process can be repeated for additional offer/answer exchanges. </del> <ins> To complete the offer/answer exchange, the remote party uses the createAnswer() API to generate an appropriate answer, applies it using the setLocalDescription() API, and sends the answer back to the initiator over the signaling channel.  When the initiator gets that answer, it installs it using the setRemoteDescription() API, and initial setup is complete.  This process can be repeated for additional offer/answer exchanges. </ins> Regarding ICE RFC5245, JSEP decouples the ICE state machine from the overall signaling state machine, as the ICE state machine must remain


Question:
I was reading this draft and noticed a couple of minor wording issues that made the text not as clear as it could be. I don't believe the changes are controversial, or change the intention of the draft.
These changes look good - I agree the rewrite of the offer/answer paragraph is a nice improvement.
Looks fine to me

The basic operations that the applications can have the media engine do are: <del> Start exchanging media to a given remote peer, but keep all the </del> <ins> Start exchanging media with a given remote peer, but keep all the </ins> resources reserved in the offer. Start exchanging media with a given remote peer, and free any


Question:
I was reading this draft and noticed a couple of minor wording issues that made the text not as clear as it could be. I don't believe the changes are controversial, or change the intention of the draft.
These changes look good - I agree the rewrite of the offer/answer paragraph is a nice improvement.
Looks fine to me

4.1.4. Session description objects (RTCSessionDescription) may be of type <del> "offer", "pranswer", and "answer".  These types provide information as to how the description parameter should be parsed, and how the media state should be changed. </del> <ins> "offer", "pranswer", or "answer".  These types provide information as to how the description parameter should be parsed, and how the media state should be changed. </ins> "offer" indicates that a description should be parsed as an offer; said description may include many possible media configurations.  A


Question:
I was reading this draft and noticed a couple of minor wording issues that made the text not as clear as it could be. I don't believe the changes are controversial, or change the intention of the draft.
These changes look good - I agree the rewrite of the offer/answer paragraph is a nice improvement.
Looks fine to me

This API changes the local media state; among other things, it sets up local resources for sending and encoding media. <del> If setRemoteDescription was previously called with an offer, and setLocalDescription is called with an answer (provisional or final), </del> <ins> If setLocalDescription was previously called with an offer, and setRemoteDescription is called with an answer (provisional or final), </ins> and the media directions are compatible, and media are available to send, this will result in the starting of media transmission.


Question: Page 62 has a bullet ending "If this is a local description, the 'ice-lite' attribute MUST NOT be specified." This sentence is leftover from before SDP munging was prohibited and should be removed.

"a=rid" lines. Each m= section is also checked to ensure prohibited features are <del> not used.  If this is a local description, the "ice-lite" attribute MUST NOT be specified. </del> <ins> not used. </ins> If the RTP/RTCP multiplexing policy is "require", each m= section MUST contain an "a=rtcp-mux" attribute.  If an "m=" section


Question:
Section 3.3, paragraph 3 is an example of text that should have been removed with SDP munging. Please remove it.
Munging remote SDP is still allowed, but I agree that we don't need to get into the mechanics of how to do it. Agree this para should be removed, and the last para reworked accordingly.

have to keep pace with the changes to SDP, at least until the time that this new encoding eclipsed SDP in popularity. <del> However, to simplify Javascript processing, and provide for future flexibility, the SDP syntax is encapsulated within a SessionDescription object, which can be constructed from SDP, and be serialized out to SDP.  If future specifications agree on a JSON format for session descriptions, we could easily enable this object to generate and consume that JSON. Other methods may be added to SessionDescription in the future to simplify handling of SessionDescriptions from Javascript.  In the meantime, Javascript libraries can be used to perform these manipulations. Note that most applications should be able to treat the </del> <ins> However, to provide for future flexibility, the SDP syntax is encapsulated within a SessionDescription object, which can be constructed from SDP, and be serialized out to SDP.  If future specifications agree on a JSON format for session descriptions, we could easily enable this object to generate and consume that JSON. As detailed below, most applications should be able to treat the </ins> SessionDescriptions produced and consumed by these various API calls as opaque blobs; that is, the application will not need to read or change them.


Question:
Fixes URL
See comment in
Alright, try this version
Section 5.8 contains the sentence: "If there is no RtpTransceiver associated with this m= section (which will only happen when applying an offer)..." -- it is grammatically ambiguous whether this says that the absence of an RtpTranceiver can only happen with an offer, or if the presence of an RtpTranceiver can only happen with an offer. Suggest rephrasing as: "If applying an offer and there is no RtpTransceiver associated with this m= section, find one..."
NAME can you take a look at this?
I'm not sold on this approach, since it then invites the question, what should one do if this condition happens when applying an answer? My suggestion would be to still call this out explicitly, but try to avoid the ambiguity noted above by changing the parenthetical to its own sentence at the end of the paragraph, e.g. "Note that this situation will only occur when applying an offer."
I changed it to that.
LGTM

If the m= section proto value indicates use of RTP: <del> If there is no RtpTransceiver associated with this m= section (which will only happen when applying an offer), find one and associate it with this m= section according to the following steps: </del> <ins> If there is no RtpTransceiver associated with this m= section, find one and associate it with this m= section according to the following steps.  Note that this situation will only occur when applying an offer. </ins> Find the RtpTransceiver that corresponds to this m= section, using the mapping between transceivers and m= section


Question:
Section 3.6.2 would ideally include a disclaimer, like we have for many other features, indicating that -- despite normative statements in this section -- the remote side might not honor imageattr because of legacy behavior, and that implementations MUST be prepared to handle such situations.
Sure. This should probably go into 3.6 or 3.6.1, since those govern sent imageattr attribs.
LGTM

use the "a=imageattr" SDP attribute RFC6236 to indicate what video frame sizes it is capable of receiving.  A receiver may have hard limits on what its video decoder can process, or it may have some <del> maximum set by policy. </del> <ins> maximum set by policy.  By specifying these limits in an "a=imageattr" attribute, JSEP endpoints can attempt to ensure that the remote sender transmits video at an acceptable resolution. However, when communicating with a non-JSEP endpoint that does not understand this attribute, any signaled limits may be exceeded, and the JSEP implementation MUST handle this gracefully, e.g., by discarding the video. </ins> Note that certain codecs support transmission of samples with aspect ratios other than 1.0 (i.e., non-square pixels).  JSEP


Question:
This seems like a normative change. I'm not saying I'm against this, but what's the rationale?
Adam's argument in , which I found to be convincing.

hardware decoder capababilities, local policy) to determine the absolute minimum and maximum sizes it can receive.  If there are no known local limits, the "a=imageattr" attribute SHOULD be omitted. <ins> If these local limits preclude receiving any video, i.e., the degenerate case of no permitted resolutions, the "a=imageattr" attribute MUST be omitted, and the m= section MUST be marked as sendonly/inactive, as appropriate. </ins> Otherwise, an "a=imageattr" attribute is created with "recv" direction, and the resulting resolution space formed from the aforementioned intersection is used to specify its minimum and <del> maximum x= and y= values.  If the intersection is the null set, i.e., the degenerate case of no permitted resolutions, this MUST be represented by x=0 and y=0 values. </del> <ins> maximum x= and y= values. </ins> The rules here express a single set of preferences, and therefore, the "a=imageattr" q= value is not important.  It SHOULD be set to


Question:
This seems like a normative change. I'm not saying I'm against this, but what's the rationale?
Adam's argument in , which I found to be convincing.

by allowing receipt of arbitrarily small resolutions, perhaps via fallback to a software decoder. <del> In the special case of a maximum resolution of [0, 0], as described above, the sender MUST NOT transmit the encoding. </del> 3.7. JSEP supports simulcast transmission of a MediaStreamTrack, where


Question:
In the last paragraph of section 8 at "programmer MUST recognize". That is not an appropriate use of 2119. I suggest "needs to be aware" instead of "MUST recognize".
This seems right

guarantee that applications do so.  The JSEP implementation MUST be prepared for the JS to pass in bogus data instead. <del> Conversely, the application programmer MUST recognize that the JS </del> <ins> Conversely, the application programmer needs to be aware that the JS </ins> does not have complete control of endpoint behavior.  One case that bears particular mention is that editing ICE candidates out of the SDP or suppressing trickled candidates does not have the expected


Question:
Section 1.2 second paragraph - "This was rejected based on a feeling". Can you write something that speaks to consensus here? "Based on a feeling" isn't quite right. Maybe "using the argument"?
Sure.
LGTM

A second approach that was considered but not chosen was to decouple the management of the media control objects from session descriptions, instead offering APIs that would control each component <del> directly.  This was rejected based on a feeling that requiring </del> <ins> directly.  This was rejected based on the argument that requiring </ins> exposure of this level of complexity to the application programmer would not be beneficial; it would result in an API where even a simple example would require a significant amount of code to


Question:
Second paragraph of 3.2, last sentence: at "these parameters or reject them" - "these" and "them" have ambiguous antecedents. It's not clear if you are trying to point to the parameters that don't follow the earlier stated rule, or all parameters. The sentence is complex. Splitting it up and finding a way to avoid the need for the semicolon will likely make it easier to say what you mean.
I agree that this is messy. Editorial.
LGTMLG with comment

of codecs sent to a remote party indicates what the local side is willing to receive, which, when intersected with the set of codecs the remote side supports, specifies what the remote side should send. <del> However, not all parameters follow this rule; for example, the fingerprints RFC8122 sent to a remote party are calculated based on the local certificate(s) offered; the remote party MUST either accept these parameters or reject them altogether, with no option to choose different values. </del> <ins> However, not all parameters follow this rule; some parameters are declarative and the remote side MUST either accept them or reject them altogether.  An example of such a parameter is the DTLS fingerprints RFC8122, which are calculated based on the local certificate(s) offered, and are not subject to negotiation. </ins> In addition, various RFCs put different conditions on the format of offers versus answers.  For example, an offer may propose an


Question:
From "Opsdir last call review of draft-ietf-rtcweb-jsep-21" A minor observation, not even a nit, is that the text in the Security Considerations "While formally the JSEP interface is an API, it is better to think of it is an Internet protocol, with the JS being untrustworthy from the perspective of the endpoint. " could be more clear.
I have no idea what to do with this. Obviously I thought it was clear when wrote it, and still do.
This is the only place in the document where we use "JS". I think it would be good to spell out "JavaScript", and potentially use "application JavaScript" in the first usage. Finally, I think we should use "implementation" rather than "endpoint" in this para.
LGTM

security considerations for this document. While formally the JSEP interface is an API, it is better to think of <del> it is an Internet protocol, with the JS being untrustworthy from the perspective of the endpoint.  Thus, the threat model of RFC3552 applies.  In particular, JS can call the API in any order and with any inputs, including malicious ones.  This is particularly relevant when we consider the SDP which is passed to setLocalDescription(). While correct API usage requires that the application pass in SDP which was derived from createOffer() or createAnswer(), there is no guarantee that applications do so.  The JSEP implementation MUST be prepared for the JS to pass in bogus data instead. Conversely, the application programmer needs to be aware that the JS does not have complete control of endpoint behavior.  One case that bears particular mention is that editing ICE candidates out of the SDP or suppressing trickled candidates does not have the expected behavior: implementations will still perform checks from those candidates even if they are not sent to the other side.  Thus, for instance, it is not possible to prevent the remote peer from learning your public IP address by removing server reflexive candidates. Applications which wish to conceal their public IP address should instead configure the ICE agent to use only relay candidates. </del> <ins> it is an Internet protocol, with the application JavaScript being untrustworthy from the perspective of the JSEP implementation.  Thus, the threat model of RFC3552 applies.  In particular, JavaScript can call the API in any order and with any inputs, including malicious ones.  This is particularly relevant when we consider the SDP which is passed to setLocalDescription().  While correct API usage requires that the application pass in SDP which was derived from createOffer() or createAnswer(), there is no guarantee that applications do so. The JSEP implementation MUST be prepared for the JavaScript to pass in bogus data instead. Conversely, the application programmer needs to be aware that the JavaScript does not have complete control of endpoint behavior.  One case that bears particular mention is that editing ICE candidates out of the SDP or suppressing trickled candidates does not have the expected behavior: implementations will still perform checks from those candidates even if they are not sent to the other side.  Thus, for instance, it is not possible to prevent the remote peer from learning your public IP address by removing server reflexive candidates.  Applications which wish to conceal their public IP address should instead configure the ICE agent to use only relay candidates. </ins> 9.


Question:
lgtm
I think the dummy candidates should be v4 not v6 as many things just don't do v6 but other than that looks reasonable. You don't really need to specify the address at all the the lines when you don't know the port can just look like a=rtcp:9 With no IP address or family
NAME The IP6 vs IP4 is described in URL, so this isn't a JSEP thing. Given that this is part of the trickle spec, and only trickle endpoints will get these candidates, I don't see any problem. As to whether a=rtcp can just have the port, consider the case where RTP candidates have been gathered, but no RTCP candidates have yet been gathered. In that case, we certainly need to have the full a=rtcp:9 IP6 ::, so I think it makes sense to include it in all cases where RTCP candidates have not yet been gathered.
I don't care much about this so fine if not change is made. I agree it is a trickle-ice draft issue. However, when I read that, it seems that it would be fine with "a=rtcp:9" with no address. It seems the reason we used 9 was to provide something that stuff that did not implement trickle ICE would not barf on. I have no tested but an address of "IP6 ::" seems like something that has high odds of stuff barfing on. Anyways, no big deal with me one way or the other. On Sep 12, 2014, at 7:49 PM, Justin Uberti EMAIL wrote:
Only trickle endpoints will even receive an offer with these dummy addresses and ports, so compatibility with old non-trickle stuff is not an issue. LMK if you have any further concerns, otherwise I will merge later today.
I concur that we should merge this. , Justin Uberti EMAIL wrote:
On Sep 18, 2014, at 9:34 AM, Justin Uberti EMAIL wrote: ah - my bad - makes sense Merge it !

header extension defined in I-D.ietf-mmusic-sdp-bundle- negotiation, Section 11. <ins> An "a=rtcp" line, as specified in RFC3605, Section 2.1, containing the dummy value "9 IN IP6 ::", because no candidates have yet been gathered. </ins> An "a=msid" line, as specified in I-D.ietf-mmusic-msid, Section 2. An "a=sendrecv" line, as specified in RFC3264, Section 5.1.


Question:
lgtm
I think the dummy candidates should be v4 not v6 as many things just don't do v6 but other than that looks reasonable. You don't really need to specify the address at all the the lines when you don't know the port can just look like a=rtcp:9 With no IP address or family
NAME The IP6 vs IP4 is described in URL, so this isn't a JSEP thing. Given that this is part of the trickle spec, and only trickle endpoints will get these candidates, I don't see any problem. As to whether a=rtcp can just have the port, consider the case where RTP candidates have been gathered, but no RTCP candidates have yet been gathered. In that case, we certainly need to have the full a=rtcp:9 IP6 ::, so I think it makes sense to include it in all cases where RTCP candidates have not yet been gathered.
I don't care much about this so fine if not change is made. I agree it is a trickle-ice draft issue. However, when I read that, it seems that it would be fine with "a=rtcp:9" with no address. It seems the reason we used 9 was to provide something that stuff that did not implement trickle ICE would not barf on. I have no tested but an address of "IP6 ::" seems like something that has high odds of stuff barfing on. Anyways, no big deal with me one way or the other. On Sep 12, 2014, at 7:49 PM, Justin Uberti EMAIL wrote:
Only trickle endpoints will even receive an offer with these dummy addresses and ports, so compatibility with old non-trickle stuff is not an issue. LMK if you have any further concerns, otherwise I will merge later today.
I concur that we should merge this. , Justin Uberti EMAIL wrote:
On Sep 18, 2014, at 9:34 AM, Justin Uberti EMAIL wrote: ah - my bad - makes sense Merge it !

Each "m=" and c=" line MUST be filled in with the port and address of the default candidate for the m= section, as described in <del> RFC5245, Section 4.3.  If no candidates have yet been gathered, the dummy values MUST be used, as described above.  [TODO: update profile UDP/TCP per default candidate] </del> <ins> RFC5245, Section 4.3.  Each "a=rtcp" attribute line MUST also be filled in with the port and address of the appropriate default candidate, either the default RTP or RTCP candidate, depending on whether RTCP multiplexing is currently active or not.  Note that if RTCP multiplexing is being offered, but not yet active, the default RTCP candidate MUST be used, as indicated in RFC5761, section 5.1.3.  In each case, if no candidates of the desired type have yet been gathered, dummy values MUST be used, as described above.  [TODO: update profile UDP/TCP per default candidate] </ins> Each "a=mid" line MUST stay the same.


Question:
lgtm
I think the dummy candidates should be v4 not v6 as many things just don't do v6 but other than that looks reasonable. You don't really need to specify the address at all the the lines when you don't know the port can just look like a=rtcp:9 With no IP address or family
NAME The IP6 vs IP4 is described in URL, so this isn't a JSEP thing. Given that this is part of the trickle spec, and only trickle endpoints will get these candidates, I don't see any problem. As to whether a=rtcp can just have the port, consider the case where RTP candidates have been gathered, but no RTCP candidates have yet been gathered. In that case, we certainly need to have the full a=rtcp:9 IP6 ::, so I think it makes sense to include it in all cases where RTCP candidates have not yet been gathered.
I don't care much about this so fine if not change is made. I agree it is a trickle-ice draft issue. However, when I read that, it seems that it would be fine with "a=rtcp:9" with no address. It seems the reason we used 9 was to provide something that stuff that did not implement trickle ICE would not barf on. I have no tested but an address of "IP6 ::" seems like something that has high odds of stuff barfing on. Anyways, no big deal with me one way or the other. On Sep 12, 2014, at 7:49 PM, Justin Uberti EMAIL wrote:
Only trickle endpoints will even receive an offer with these dummy addresses and ports, so compatibility with old non-trickle stuff is not an issue. LMK if you have any further concerns, otherwise I will merge later today.
I concur that we should merge this. , Justin Uberti EMAIL wrote:
On Sep 18, 2014, at 9:34 AM, Justin Uberti EMAIL wrote: ah - my bad - makes sense Merge it !

Section 9.1.  The "mid" value MUST match that specified in the offer. <ins> An "a=rtcp" line, as specified in RFC3605, Section 2.1, containing the dummy value "9 IN IP6 ::", because no candidates have yet been gathered. </ins> If a local MediaStreamTrack has been associated, an "a=msid" line, as specified in I-D.ietf-mmusic-msid, Section 2.


Question:
Various fixes for 60.2: Removed parens from API names, removed comment. - put the term stable in quotes, removed comment. - put the term sess-id in angle brackets to match SDP spec, removed comment. - made the tls-id attribute consistent with other SDP attributes, removed comment. - removed quotes from IceRestart option, removed comment.

"IceRestart" option / IceRestart option Justin: LGTM
tls-id value / "a=tls-id" value Justin: The source RFC seems to prefer "tls-id" when discussing values.
During the editing of the Cluster 238 docs, it was decided that it's author's choice when formatting SDP attributes. Although RFC 8842 uses the format '"tls-id" attribute', this document more consistently uses "a=attribute-name" format for SDP attributes, which is the format that the SDP spec [RFC8866] uses. I'll update this document to consistently use "a=tls-id"
sess-id / (Section 5.2.1, second bullet item) Justin: LGTM
the stable state (1 instance) / the "stable" state (3 instances) >(Also, should 'the previous stable state' be 'a previous stable state' (per Section 5.7) or 'the previous "stable" state'?) Justin: The quoted form is preferred, including the case of "previous stable state".
[Breaking up issue /60 into smaller bites] The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. Justin: There seems to be a pretty clear preponderance for the non-parenthetical form, so let's keep that. W3C also does not use (). Jean: We'll remove the parens (camelCase is sufficient formatting).

JSEP's handling of session descriptions is simple and straightforward.  Whenever an offer/answer exchange is needed, the <del> initiating side creates an offer by calling a createOffer() API.  The </del> <ins> initiating side creates an offer by calling a createOffer API.  The </ins> application then uses that offer to set up its local config via the <del> setLocalDescription() API.  The offer is finally sent off to the remote side over its preferred signaling mechanism (e.g., WebSockets); upon receipt of that offer, the remote party installs it using the setRemoteDescription() API. </del> <ins> setLocalDescription API.  The offer is finally sent off to the remote side over its preferred signaling mechanism (e.g., WebSockets); upon receipt of that offer, the remote party installs it using the setRemoteDescription API. </ins> To complete the offer/answer exchange, the remote party uses the <del> createAnswer() API to generate an appropriate answer, applies it using the setLocalDescription() API, and sends the answer back to the </del> <ins> createAnswer API to generate an appropriate answer, applies it using the setLocalDescription API, and sends the answer back to the </ins> initiator over the signaling channel.  When the initiator gets that <del> answer, it installs it using the setRemoteDescription() API, and </del> <ins> answer, it installs it using the setRemoteDescription API, and </ins> initial setup is complete.  This process can be repeated for additional offer/answer exchanges.


Question:
Various fixes for 60.2: Removed parens from API names, removed comment. - put the term stable in quotes, removed comment. - put the term sess-id in angle brackets to match SDP spec, removed comment. - made the tls-id attribute consistent with other SDP attributes, removed comment. - removed quotes from IceRestart option, removed comment.

"IceRestart" option / IceRestart option Justin: LGTM
tls-id value / "a=tls-id" value Justin: The source RFC seems to prefer "tls-id" when discussing values.
During the editing of the Cluster 238 docs, it was decided that it's author's choice when formatting SDP attributes. Although RFC 8842 uses the format '"tls-id" attribute', this document more consistently uses "a=attribute-name" format for SDP attributes, which is the format that the SDP spec [RFC8866] uses. I'll update this document to consistently use "a=tls-id"
sess-id / (Section 5.2.1, second bullet item) Justin: LGTM
the stable state (1 instance) / the "stable" state (3 instances) >(Also, should 'the previous stable state' be 'a previous stable state' (per Section 5.7) or 'the previous "stable" state'?) Justin: The quoted form is preferred, including the case of "previous stable state".
[Breaking up issue /60 into smaller bites] The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. Justin: There seems to be a pretty clear preponderance for the non-parenthetical form, so let's keep that. W3C also does not use (). Jean: We'll remove the parens (camelCase is sufficient formatting).

using SIP for signaling, if one offer is sent and is then canceled using a SIP CANCEL, another offer can be generated even though no answer was received for the first offer.  To support this, the JSEP <del> media layer can provide an offer via the createOffer() method whenever the JavaScript application needs one for the signaling.  The answerer can send back zero or more provisional answers and then finally end the offer/answer exchange by sending a final answer.  The state machine for this is as follows: </del> <ins> media layer can provide an offer via the createOffer method whenever the JavaScript application needs one for the signaling.  The answerer can send back zero or more provisional answers and then finally end the offer/answer exchange by sending a final answer.  The state machine for this is as follows: </ins> Aside from these state transitions, there is no other difference between the handling of provisional ("pranswer") and final ("answer")


Question:
Various fixes for 60.2: Removed parens from API names, removed comment. - put the term stable in quotes, removed comment. - put the term sess-id in angle brackets to match SDP spec, removed comment. - made the tls-id attribute consistent with other SDP attributes, removed comment. - removed quotes from IceRestart option, removed comment.

"IceRestart" option / IceRestart option Justin: LGTM
tls-id value / "a=tls-id" value Justin: The source RFC seems to prefer "tls-id" when discussing values.
During the editing of the Cluster 238 docs, it was decided that it's author's choice when formatting SDP attributes. Although RFC 8842 uses the format '"tls-id" attribute', this document more consistently uses "a=attribute-name" format for SDP attributes, which is the format that the SDP spec [RFC8866] uses. I'll update this document to consistently use "a=tls-id"
sess-id / (Section 5.2.1, second bullet item) Justin: LGTM
the stable state (1 instance) / the "stable" state (3 instances) >(Also, should 'the previous stable state' be 'a previous stable state' (per Section 5.7) or 'the previous "stable" state'?) Justin: The quoted form is preferred, including the case of "previous stable state".
[Breaking up issue /60 into smaller bites] The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. Justin: There seems to be a pretty clear preponderance for the non-parenthetical form, so let's keep that. W3C also does not use (). Jean: We'll remove the parens (camelCase is sufficient formatting).

in RFC5888.  addTrack attempts to minimize the number of transceivers as follows: if the PeerConnection is in the "have-remote-offer" state, the track will be attached to the first compatible transceiver <del> that was created by the most recent call to setRemoteDescription() and does not have a local track.  Otherwise, a new transceiver will be created, as described in sec.addTransceiver. </del> <ins> that was created by the most recent call to setRemoteDescription and does not have a local track.  Otherwise, a new transceiver will be created, as described in sec.addTransceiver. </ins> 4.1.3.


Question:
Various fixes for 60.2: Removed parens from API names, removed comment. - put the term stable in quotes, removed comment. - put the term sess-id in angle brackets to match SDP spec, removed comment. - made the tls-id attribute consistent with other SDP attributes, removed comment. - removed quotes from IceRestart option, removed comment.

"IceRestart" option / IceRestart option Justin: LGTM
tls-id value / "a=tls-id" value Justin: The source RFC seems to prefer "tls-id" when discussing values.
During the editing of the Cluster 238 docs, it was decided that it's author's choice when formatting SDP attributes. Although RFC 8842 uses the format '"tls-id" attribute', this document more consistently uses "a=attribute-name" format for SDP attributes, which is the format that the SDP spec [RFC8866] uses. I'll update this document to consistently use "a=tls-id"
sess-id / (Section 5.2.1, second bullet item) Justin: LGTM
the stable state (1 instance) / the "stable" state (3 instances) >(Also, should 'the previous stable state' be 'a previous stable state' (per Section 5.7) or 'the previous "stable" state'?) Justin: The quoted form is preferred, including the case of "previous stable state".
[Breaking up issue /60 into smaller bites] The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. Justin: There seems to be a pretty clear preponderance for the non-parenthetical form, so let's keep that. W3C also does not use (). Jean: We'll remove the parens (camelCase is sufficient formatting).

"offer" indicates that a description should be parsed as an offer; said description may include many possible media configurations.  A description used as an "offer" may be applied any time the <del> PeerConnection is in a stable state or applied as an update to a </del> <ins> PeerConnection is in a "stable" state or applied as an update to a </ins> previously supplied but unanswered "offer". "pranswer" indicates that a description should be parsed as an


Question:
Various fixes for 60.2: Removed parens from API names, removed comment. - put the term stable in quotes, removed comment. - put the term sess-id in angle brackets to match SDP spec, removed comment. - made the tls-id attribute consistent with other SDP attributes, removed comment. - removed quotes from IceRestart option, removed comment.

"IceRestart" option / IceRestart option Justin: LGTM
tls-id value / "a=tls-id" value Justin: The source RFC seems to prefer "tls-id" when discussing values.
During the editing of the Cluster 238 docs, it was decided that it's author's choice when formatting SDP attributes. Although RFC 8842 uses the format '"tls-id" attribute', this document more consistently uses "a=attribute-name" format for SDP attributes, which is the format that the SDP spec [RFC8866] uses. I'll update this document to consistently use "a=tls-id"
sess-id / (Section 5.2.1, second bullet item) Justin: LGTM
the stable state (1 instance) / the "stable" state (3 instances) >(Also, should 'the previous stable state' be 'a previous stable state' (per Section 5.7) or 'the previous "stable" state'?) Justin: The quoted form is preferred, including the case of "previous stable state".
[Breaking up issue /60 into smaller bites] The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. Justin: There seems to be a pretty clear preponderance for the non-parenthetical form, so let's keep that. W3C also does not use (). Jean: We'll remove the parens (camelCase is sufficient formatting).

voicemail). "rollback" is a special session description type implying that the <del> state machine should be rolled back to the previous stable state, as described in sec.rollback.  The contents MUST be empty. </del> <ins> state machine should be rolled back to the previous "stable" state, as described in sec.rollback.  The contents MUST be empty. </ins> 4.1.8.1.


Question:
Various fixes for 60.2: Removed parens from API names, removed comment. - put the term stable in quotes, removed comment. - put the term sess-id in angle brackets to match SDP spec, removed comment. - made the tls-id attribute consistent with other SDP attributes, removed comment. - removed quotes from IceRestart option, removed comment.

"IceRestart" option / IceRestart option Justin: LGTM
tls-id value / "a=tls-id" value Justin: The source RFC seems to prefer "tls-id" when discussing values.
During the editing of the Cluster 238 docs, it was decided that it's author's choice when formatting SDP attributes. Although RFC 8842 uses the format '"tls-id" attribute', this document more consistently uses "a=attribute-name" format for SDP attributes, which is the format that the SDP spec [RFC8866] uses. I'll update this document to consistently use "a=tls-id"
sess-id / (Section 5.2.1, second bullet item) Justin: LGTM
the stable state (1 instance) / the "stable" state (3 instances) >(Also, should 'the previous stable state' be 'a previous stable state' (per Section 5.7) or 'the previous "stable" state'?) Justin: The quoted form is preferred, including the case of "previous stable state".
[Breaking up issue /60 into smaller bites] The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. Justin: There seems to be a pretty clear preponderance for the non-parenthetical form, so let's keep that. W3C also does not use (). Jean: We'll remove the parens (camelCase is sufficient formatting).

after setRemoteDescription, decides it does not want to accept the new parameters and sends a reject message back to the offerer.  Now, the offerer, and possibly the answerer as well, needs to return to a <del> stable state and the previous local/remote description.  To support </del> <ins> "stable" state and the previous local/remote description.  To support </ins> this, we introduce the concept of "rollback", which discards any proposed changes to the session, returning the state machine to the <del> stable state.  A rollback is performed by supplying a session </del> <ins> "stable" state.  A rollback is performed by supplying a session </ins> description of type "rollback" with empty contents to either setLocalDescription or setRemoteDescription.


Question:
Various fixes for 60.2: Removed parens from API names, removed comment. - put the term stable in quotes, removed comment. - put the term sess-id in angle brackets to match SDP spec, removed comment. - made the tls-id attribute consistent with other SDP attributes, removed comment. - removed quotes from IceRestart option, removed comment.

"IceRestart" option / IceRestart option Justin: LGTM
tls-id value / "a=tls-id" value Justin: The source RFC seems to prefer "tls-id" when discussing values.
During the editing of the Cluster 238 docs, it was decided that it's author's choice when formatting SDP attributes. Although RFC 8842 uses the format '"tls-id" attribute', this document more consistently uses "a=attribute-name" format for SDP attributes, which is the format that the SDP spec [RFC8866] uses. I'll update this document to consistently use "a=tls-id"
sess-id / (Section 5.2.1, second bullet item) Justin: LGTM
the stable state (1 instance) / the "stable" state (3 instances) >(Also, should 'the previous stable state' be 'a previous stable state' (per Section 5.7) or 'the previous "stable" state'?) Justin: The quoted form is preferred, including the case of "previous stable state".
[Breaking up issue /60 into smaller bites] The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. Justin: There seems to be a pretty clear preponderance for the non-parenthetical form, so let's keep that. W3C also does not use (). Jean: We'll remove the parens (camelCase is sufficient formatting).

5.2.3.1. <del> If the "IceRestart" option is specified, with a value of "true", the </del> <ins> If the IceRestart option is specified, with a value of "true", the </ins> offer MUST indicate an ICE restart by generating new ICE ufrag and pwd attributes, as specified in RFC8839.  If this option is specified on an initial offer, it has no effect (since a new ICE ufrag and pwd


Question:
Various fixes for 60.2: Removed parens from API names, removed comment. - put the term stable in quotes, removed comment. - put the term sess-id in angle brackets to match SDP spec, removed comment. - made the tls-id attribute consistent with other SDP attributes, removed comment. - removed quotes from IceRestart option, removed comment.

"IceRestart" option / IceRestart option Justin: LGTM
tls-id value / "a=tls-id" value Justin: The source RFC seems to prefer "tls-id" when discussing values.
During the editing of the Cluster 238 docs, it was decided that it's author's choice when formatting SDP attributes. Although RFC 8842 uses the format '"tls-id" attribute', this document more consistently uses "a=attribute-name" format for SDP attributes, which is the format that the SDP spec [RFC8866] uses. I'll update this document to consistently use "a=tls-id"
sess-id / (Section 5.2.1, second bullet item) Justin: LGTM
the stable state (1 instance) / the "stable" state (3 instances) >(Also, should 'the previous stable state' be 'a previous stable state' (per Section 5.7) or 'the previous "stable" state'?) Justin: The quoted form is preferred, including the case of "previous stable state".
[Breaking up issue /60 into smaller bites] The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. Justin: There seems to be a pretty clear preponderance for the non-parenthetical form, so let's keep that. W3C also does not use (). Jean: We'll remove the parens (camelCase is sufficient formatting).

A rollback may be performed if the PeerConnection is in any state except for "stable".  This means that both offers and provisional answers can be rolled back.  Rollback can only be used to cancel <del> proposed changes; there is no support for rolling back from a stable state to a previous stable state.  If a rollback is attempted in the "stable" state, processing MUST stop and an error MUST be returned. Note that this implies that once the answerer has performed setLocalDescription with its answer, this cannot be rolled back. </del> <ins> proposed changes; there is no support for rolling back from a "stable" state to a previous "stable" state.  If a rollback is attempted in the "stable" state, processing MUST stop and an error MUST be returned.  Note that this implies that once the answerer has performed setLocalDescription with its answer, this cannot be rolled back. </ins> The effect of rollback MUST be the same regardless of whether setLocalDescription or setRemoteDescription is called.


Question:
Various fixes for 60.2: Removed parens from API names, removed comment. - put the term stable in quotes, removed comment. - put the term sess-id in angle brackets to match SDP spec, removed comment. - made the tls-id attribute consistent with other SDP attributes, removed comment. - removed quotes from IceRestart option, removed comment.

"IceRestart" option / IceRestart option Justin: LGTM
tls-id value / "a=tls-id" value Justin: The source RFC seems to prefer "tls-id" when discussing values.
During the editing of the Cluster 238 docs, it was decided that it's author's choice when formatting SDP attributes. Although RFC 8842 uses the format '"tls-id" attribute', this document more consistently uses "a=attribute-name" format for SDP attributes, which is the format that the SDP spec [RFC8866] uses. I'll update this document to consistently use "a=tls-id"
sess-id / (Section 5.2.1, second bullet item) Justin: LGTM
the stable state (1 instance) / the "stable" state (3 instances) >(Also, should 'the previous stable state' be 'a previous stable state' (per Section 5.7) or 'the previous "stable" state'?) Justin: The quoted form is preferred, including the case of "previous stable state".
[Breaking up issue /60 into smaller bites] The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. Justin: There seems to be a pretty clear preponderance for the non-parenthetical form, so let's keep that. W3C also does not use (). Jean: We'll remove the parens (camelCase is sufficient formatting).

the threat model of RFC3552 applies.  In particular, JavaScript can call the API in any order and with any inputs, including malicious ones.  This is particularly relevant when we consider the SDP that is <del> passed to setLocalDescription().  While correct API usage requires that the application pass in SDP that was derived from createOffer() or createAnswer(), there is no guarantee that applications do so. The JSEP implementation MUST be prepared for the JavaScript to pass in bogus data instead. </del> <ins> passed to setLocalDescription.  While correct API usage requires that the application pass in SDP that was derived from createOffer or createAnswer, there is no guarantee that applications do so.  The JSEP implementation MUST be prepared for the JavaScript to pass in bogus data instead. </ins> Conversely, the application programmer needs to be aware that the JavaScript does not have complete control of endpoint behavior.  One


Question:
Emerging best practice is to use for new headers, so that parsing is well-defined. Arguments for sticking with a -like syntax: Consistence with (IMO a very poor justification) Reuse of parsers / other software (it's not well-defined, tho) ???
We could also talk about creating a SF version of (maybe ?).
Matching SF and headers would be appealing.
In the meantime (or maybe before ;) -- URL

BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> This document uses the Augmented BNF defined in HTTP to specify valid protocol elements.  Additionally, it uses the modified "parameter" rule from RFC5987 and the "URI-Template" rule from URI-TEMPLATE. </del> <ins> This specification uses the following terms from STRUCTURED-FIELDS: List, String, Parameter. </ins> 2. <del> The Link-Template header field provides a means for serialising one or more links into HTTP message metadata.  It is semantically equivalent to the Link header field defined in WEB-LINKING, except that it uses URI Templates URI-TEMPLATE to convey the structure of links. </del> <ins> The Link-Template header field is a Structured Field STRUCTURED- FIELDS that serializes one or more links into HTTP message metadata. It is semantically equivalent to the Link header field defined in WEB-LINKING, except that it uses URI Templates URI-TEMPLATE to convey the structure of links. Its value is a List of Strings.  Each String is a URI Template, and Parameters on it carry associated metadata. </ins> For example:


Question:
Emerging best practice is to use for new headers, so that parsing is well-defined. Arguments for sticking with a -like syntax: Consistence with (IMO a very poor justification) Reuse of parsers / other software (it's not well-defined, tho) ???
We could also talk about creating a SF version of (maybe ?).
Matching SF and headers would be appealing.
In the meantime (or maybe before ;) -- URL

Parameters on a templated-link have identical semantics to those of a Link header field.  This includes (but is not limited to) the use of the "rel" parameter to convey the relation type, the "anchor" <del> parameter to modify the context IRI, and so on. </del> <ins> parameter to modify the context IRI, and so on.  Parameter values MUST be Strings. </ins> Likewise, the requirements for parameters on templated-links are the <del> same as those for a Link header field; in particular, the "rel" parameter MUST NOT appear more than once, and if it does, the templated-link MUST be ignored by parsers. </del> <ins> same as those for a Link header field. </ins> This specification defines additional semantics for the "var-base" parameter on templated-links; see below.


Question:
and .
In light of , NAME concerns about the framework, and NAME declining interest in implementing, I think it's time to simply eliminate this from the document.
Thanks for all the hard work, but sorry to be the cause of it.
Fixed by
How does a dynamic framework survive an HA handover? It would seem to lose all the SID allocations and break all connections.

Load balancers SHOULD drop short header packets with unroutable DCIDs. <del> The routing of long headers with unroutable DCIDs depends on the server ID allocation strategy, described in sid-allocation.  However, the load balancer MUST NOT drop these packets, with one exception. </del> <ins> When forwarding a packet with a long header and unroutable DCID, load balancers MUST use a fallback algorithm as specified in fallback- algorithm. </ins> Load balancers MAY drop packets with long headers and unroutable DCIDs if and only if it knows that the encoded QUIC version does not


Question:
and .
In light of , NAME concerns about the framework, and NAME declining interest in implementing, I think it's time to simply eliminate this from the document.
Thanks for all the hard work, but sorry to be the cause of it.
Fixed by
How does a dynamic framework survive an HA handover? It would seem to lose all the SID allocations and break all connections.

4.3. <del> For any given configuration, the configuration agent must specify if server IDs will be statically or dynamically allocated.  Load Balancer configurations with statically allocated server IDs explicitly include a mapping of server IDs to forwarding addresses. The corresponding server configurations contain one or more unique server IDs. </del> <ins> Load Balancer configurations include a mapping of server IDs to forwarding addresses.  The corresponding server configurations contain one or more unique server IDs. </ins> <del> A dynamically allocated configuration does not have a pre-defined assignment, reducing configuration complexity.  However, it places limits on the maximum server ID length and requires more state at the load balancer.  In certain edge cases, it can force parts of the system to fail over to 5-tuple routing for a short time. In either case, the configuration agent chooses a server ID length for each configuration that MUST be at least one octet.  For Static Allocation, the maximum length depends on the algorithm.  For dynamic allocation, the maximum length is 7 octets. </del> <ins> The configuration agent chooses a server ID length for each configuration that MUST be at least one octet. </ins> A QUIC-LB configuration MAY significantly over-provision the server ID space (i.e., provide far more codepoints than there are servers) to increase the probability that a randomly generated Destination Connection ID is unroutable. <ins> The configuration agent SHOULD provide a means for servers to express the number of server IDs it can usefully employ, because a single routing address actually corresponds to multiple server entities (see lb-chains). </ins> Conceptually, each configuration has its own set of server ID allocations, though two static configurations with identical server ID lengths MAY use a common allocation between them.


Question:
and .
In light of , NAME concerns about the framework, and NAME declining interest in implementing, I think it's time to simply eliminate this from the document.
Thanks for all the hard work, but sorry to be the cause of it.
Fixed by
How does a dynamic framework survive an HA handover? It would seem to lose all the SID allocations and break all connections.

A server encodes one of its assigned server IDs in any CID it generates using the relevant configuration. <del> 4.3.1. In the static allocation method, the configuration agent assigns at least one server ID to each server. When forwarding a packet with a long header and unroutable DCID, load balancers MUST forward packets with long headers and unroutable DCIDs using an fallback algorithm as specified in fallback-algorithm. 4.3.2. In the dynamic allocation method, the load balancer assigns server IDs dynamically so that configuration does not require fixed server ID assignment.  This reduces linkability and simplifies configuration.  However, it also limits the length of the server ID and requires the load balancer to lie on the path of outbound packets.  As the server mapping is no longer part of the configuration, standby load balancers need an out-of-band mechanism to synchronize server ID allocations in the event of failures of the primary device. To summarize, the load balancer forwards incoming Initial packets arbitrarily and both load balancer and server are sometimes able to infer a potential server ID allocation from the CID in the packet. The server can signal acceptance of that allocation by using it immediately, in which case both entities add it to their permanent table.  Usually, however, the server will reject the allocation by not using it, in which case it is not added to the permanent assignment list. 4.3.2.1. The configuration agent does not assign server IDs, but does configure a server ID length.  The server ID MUST be at least one and no more than seven octets.  See sid-limits for other considerations if also using the Plaintext CID algorithm. 4.3.2.2. The load balancer maintains a mapping of assigned server IDs to routing information for servers, initialized as empty.  This mapping is independent for each operating configuration. Note that when the load balancer's tables for a configuration are empty, all incoming DCIDs corresponding to that configuration are unroutable by definition. The load balancer processes a long header packet as follows: If the config rotation bits do not match a known configuration, the load balancer routes the packet using a fallback algorithm (see fallback-algorithm).  It does not extract a server ID. If there is a matching configuration, but the CID is not long enough to apply the algorithm, the load balancer pads the connection ID with zeros to the required length. Otherwise, the load balancer extracts the server ID in accordance with the configured algorithm and parameters. If the load balancer extracted a server ID already in its mapping, it routes the packet accordingly.  If the server ID is not in the mapping, it routes the packet according to a fallback algorithm and awaits the first long header the server sends in response. If the load balancer extracted an unassigned server ID and observes that the first long header packet the server sends has a Source Connection ID that encodes the same server ID, it adds that server ID to the mapping.  Otherwise, it takes no action. 4.3.2.3. Each server maintains a list of server IDs assigned to it, initialized empty. Upon receipt of a packet with a client-generated DCID, the server MUST follow these steps in order: If the config rotation bits do not correspond to a known configuration, do not attempt to extract a server ID. If the DCID is not long enough to decode using the configured algorithm, pad it with zeros to the required length and extract a server ID. If the DCID is long enough to decode, extract the server ID. If the server ID is not already in its list, the server MUST decide whether or not to immediately use it to encode a CID on the new connection.  If it chooses to use it, it adds the server ID to its list.  If it does not, it MUST NOT use the server ID in future CIDs. The server SHOULD NOT use more than one CID, unless it is close to exhausting the nonces for an existing assignment.  Note also that the load balancer may observe a single entity claiming multiple server IDs because that entity actually represents multiple servers devices or processors. The server MUST generate a new connection ID if the client-generated CID is of insufficient length for the configuration. The server then processes the packet normally. When a server needs a new connection ID, it uses one of the server IDs in its list to populate the server ID field of that CID.  It MAY vary this selection to reduce linkability within a connection. After loading a new configuration, a server may not have any available SIDs.  This is because an incoming packet may not contain the config rotation bits necessary to extract a server ID in accordance with the algorithm above.  When required to generate a CID under these conditions, the server MUST generate CIDs using the 5-tuple routing codepoint (see config-failover.  Note that these connections will not be robust to client address changes while they use this connection ID.  For this reason, a server SHOULD retire these connection IDs and replace them with routable ones once it receives a client-generated CID that allows it to acquire a server ID.  As, statistically, one in every four such CIDs can provide a server ID, this is typically a short interval. </del> 4.4. All connection IDs use the following format:


Question:
and .
In light of , NAME concerns about the framework, and NAME declining interest in implementing, I think it's time to simply eliminate this from the document.
Thanks for all the hard work, but sorry to be the cause of it.
Fixed by
How does a dynamic framework survive an HA handover? It would seem to lose all the SID allocations and break all connections.

QUIC-LB requires common configuration to synchronize understanding of encodings and guarantee explicit consent of the server. <del> The load balancer and server MUST agree on a routing algorithm, server ID allocation method, and the relevant parameters for that algorithm. </del> <ins> The load balancer and server MUST agree on a routing algorithm and the relevant parameters for that algorithm. </ins> All algorithm configurations can have a server ID length, nonce length, and key.  However, for Plaintext CID, there is no key. <del> If server IDs are statically allocated, the load balancer MUST receive the full table of mappings, and each server must receive its assigned SID(s), from the configuration agent. </del> <ins> The load balancer MUST receive the full table of mappings, and each server must receive its assigned SID(s), from the configuration agent. </ins> Note that server IDs are opaque bytes, not integers, so there is no notion of network order or host order.


Question:
and .
In light of , NAME concerns about the framework, and NAME declining interest in implementing, I think it's time to simply eliminate this from the document.
Thanks for all the hard work, but sorry to be the cause of it.
Fixed by
How does a dynamic framework survive an HA handover? It would seem to lose all the SID allocations and break all connections.

fewer than 2^40 tokens are generated with a single key, the risk of collisions is lower than 0.001%. <del> 11.8. When using Dynamic SID allocation, the load balancer's SID table can be as large as 2^56 entries, which is prohibitively large.  To constrain the size of this table, servers are encouraged to accept as few SIDs as possible, so that the remainder do not enter the load balancer's table. </del> 12. There are no IANA requirements.


Question: The CID format figure has been removed since draft-ietf-quic-load-balancers-08

The Stream Cipher CID algorithm provides cryptographic protection at the cost of additional per-packet processing at the load balancer to <del> decrypt every incoming connection ID.  The CID format is depicted below. </del> <ins> decrypt every incoming connection ID. </ins> 5.2.1.


Question:
URL is probably not your intent, but that is what you get with this phrasing. I think that the point is that the values are not predictable to entities other than the one generating it. This appears in several places in the document.
Well URL uses "indistinguishable from random" :-) But OK, I'll seek a new formulation.

octet of the Connection ID are reserved to express the length of the following connection ID, not including the first octet. <del> A server not using this functionality SHOULD make the six bits appear to be random. </del> <ins> A server not using this functionality SHOULD choose the six bits so as to have no observable relationship to previous connection IDs issued for that connection. </ins> 2.4.


Question:
URL is probably not your intent, but that is what you get with this phrasing. I think that the point is that the values are not predictable to entities other than the one generating it. This appears in several places in the document.
Well URL uses "indistinguishable from random" :-) But OK, I'll seek a new formulation.

respective fields. If there is no key in the configuration, the server MUST fill the <del> Nonce field with bytes that appear to be random.  If there is a key, the server fills the nonce field with a nonce of its choosing.  See cid-entropy for details. </del> <ins> Nonce field with bytes that have no observable relationship to the field in previously issued connection IDs.  If there is a key, the server fills the nonce field with a nonce of its choosing.  See cid- entropy for details. </ins> The server MAY append additional bytes to the connection ID, up to the limit specified in that version of QUIC, for its own use.  These


Question:
URL is probably not your intent, but that is what you get with this phrasing. I think that the point is that the values are not predictable to entities other than the one generating it. This appears in several places in the document.
Well URL uses "indistinguishable from random" :-) But OK, I'll seek a new formulation.

two connection IDs to the same connection, client, or server.  In particular, all servers using a configuration MUST consistently add the same length to each connection ID, to preserve the linkability <del> objectives of QUIC-LB.  Any additional bytes SHOULD appear random unless individual servers are not distinguishable (e.g. any server using that configuration appends identical bytes to every connection ID). </del> <ins> objectives of QUIC-LB.  Any additional bytes SHOULD NOT provide any observable correlation to previous connection IDs for that connection (e.g., the bytes can be chosen at random). </ins> If there is no key in the configuration, the Connection ID is complete.  Otherwise, there are further steps, as described in the


Question:
URL is probably not your intent, but that is what you get with this phrasing. I think that the point is that the values are not predictable to entities other than the one generating it. This appears in several places in the document.
Well URL uses "indistinguishable from random" :-) But OK, I'll seek a new formulation.

Whether or not it implements the counter method, the server MUST NOT reuse a nonce until it switches to a configuration with new keys. <del> If the nonce is sent in plaintext, servers MUST generate nonces so that they appear to be random.  Observable correlations between plaintext nonces would provide trivial linkability between individual connections, rather than just to a common server. </del> <ins> Servers are forbidden from generating linkable plaintext nonces, because observable correlations between plaintext nonces would provide trivial linkability between individual connections, rather than just to a common server. </ins> For any algorithm, configuration agents SHOULD implement an out-of- band method to discover when servers are in danger of exhausting


Question:
Attempt to , . Examples and test vectors not yet updated. PTAL at the description. Is the algorithm accurately described Are things clearer or not
NAME Thanks for all the formatting suggestions. It's cleaned up a bit, although I wasn't able to get aasvg to work. PTAL
Correction. I got aasvg to work but it did not look good at all, probably due to user incompetence. If you would like to submit a PR after this that is prettier, I would welcome it.
Stefan Kolbl points out this problem with the 4-pass method: Indeed, there are ways to avoid ugly and error-prone bit shifting while avoiding this property. In particular, we can always use expand-left, but just padding odd-bytes with zeros to preserve byte boundaries and avoid bit-shifting.
Fixed by
Several problems here: A lot of the description relies on examples rather than normative language. The split of a CID that has an odd length produces HEX sequences with an odd number of characters, which in many circumstances will be interpreted as being (left-)padded with 4 zero bits. If that happened, then bad things would occur. You really need to retain the number of bits. Step 3 passes two arguments to , when it has three. The encryption doesn't bind to the configuration that is in use; instead the high bits of the first octet are set to 0. The formatting of the operations wraps awkwardly. The operators that this uses (^ and primarily) aren't defined. The third input to seems to increment without explanation. Given the examples, I could no doubt work this all out satisfactorily, but that shouldn't be necessary.
Fixed by
A lot.
Yes, the new text seems clear, and correct.

shifting necessary in the event that there are an odd number of octets. <del> The expand_left() function outputs 16 octets, with its first argument in the most significant bits, its second argument in the least significant byte, its third argument in the second least significant byte, and zeros in all other positions.  Thus, </del> <ins> When configured with both a key, and a nonce length and server ID length that sum to any number other than 16, the server MUST follow the algorith below to encrypt the connection ID. </ins> <del> expand_right() is similar, except that the second argument is in the most significant byte, the third is in the second most significant byte, and the first argument is in the least significant bits. Therefore, </del> <ins> 4.3.2.1. </ins> <del> Similarly, truncate_left() and truncate_right() take the most significant and least significant bits, respectively, from a ciphertext.  For example, to take 28 bits of a ciphertext: </del> <ins> The 4-pass algorithm is a four-round Feistel Network with the round function being AES-ECB.  Most modern applications of Feistel Networks have more than four rounds.  The implications of this choice, which is meant to limit the per-packet compute overhead at load balancers, are discussed in distinguishing-attacks. The server concatenates the server ID and nonce into a single field, which is then split into equal halves.  In successive passes, one of these halves is expanded into a 16B plaintext, encrypted with AES- ECB, and the result XORed with the other half.  The diagram below shows the conceptual processing of a plaintext server ID and nonce into a connection ID.  'FO' stands for 'First Octet'. 4.3.2.2. Two functions are useful to define: The expand(length, pass, input_bytes) function concatenates three arguments and outputs 16 zero-padded octets. The first argument 'length' is an 8-bit integer that reports the sum of the configured nonce length and server id length in octets, and forms the most significant octet of the output.  The 'length' argument MUST NOT exceed 28. The second argument is an 8-bit integer that is the 'pass' of the algorithm, and forms the second-most significant octet of the output. The third argument is a variable-length stream of octets, which is copied into the third-most significant octet of the output and beyond.  The length of this octet stream is half the 'length', rounded up.  All remaining octets of the output are zero. For example, Similarly, truncate(input, n) returns the first n octets of 'input'. Let 'half_len' be equal to 'plaintext_len' / 2, rounded up. 4.3.2.3. </ins> The example at the end of this section helps to clarify the steps described below. The server concatenates the server ID and nonce to create <del> plaintext_CID. </del> <ins> plaintext_CID.  The length of the result in octets is plaintext_len. </ins> The server splits plaintext_CID into components left_0 and right_0 <del> of equal length, splitting an odd octet in half if necessary.  For example, 0x7040b81b55ccf3 would split into a left_0 of 0x7040b81 and right_0 of 0xb55ccf3. </del> <ins> of equal length half_len.  If plaintext_len is odd, right_0 clears its first four bits, and left_0 clears its last four bits.  For example, 0x7040b81b55ccf3 would split into a left_0 of 0x7040b810 and right_0 of 0x0b55ccf3. </ins> <del> Encrypt the result of expand_left(left_0, index)) to obtain a ciphertext, where 'index' is one octet: the two most significant bits of which are 0b00, and the six least significant bits are the length of the resulting connection ID in bytes, cid_len. </del> <ins> Encrypt the result of expand(plaintext_len, 1, left_0) using an AES-ECB-128 cipher to obtain a ciphertext. </ins> <del> XOR the least significant bits of the ciphertext with right_0 to form right_1. </del> <ins> XOR the first half_len octets of the ciphertext with right_0 to form right_1.  Steps 3 and 4 can be summarized as </ins> <del> Thus steps 3 and 4 can be expressed as "right_1 = right_0 ^ truncate_right( AES_ECB(key, expand_left(left_0, cid_len, 1)), len(right_0)) " </del> <ins> If the plaintext_len is odd, clear the first four bits of right_1. </ins> Repeat steps 3 and 4, but use them to compute left_1 by expanding <del> and encrypting right_1 with the most significant octet as the concatenation of 0b01 and cid_len, and XOR the results with </del> <ins> and encrypting right_1 with pass = 2, and XOR the results with </ins> left_0. <del> "left_1 = left_0 ^ truncate_left( AES_ECB(key, expand_right(right_1, cid_len, 2)), len(left_0)) " </del> <ins> If the plaintext_len is odd, clear the last four bits of left_1. </ins> Repeat steps 3 and 4, but use them to compute right_2 by expanding <del> and encrypting left_1 with the least significant octet as the concatenation of 0b10 and cid_len, and XOR the results with </del> <ins> and encrypting left_1 with pass = 3, and XOR the results with </ins> right_1. <del> "right_2 = right_1 ^ truncate_right( AES_ECB(key, expand_left(left_1, cid_len, 3), len(right_1)) " </del> <ins> If the plaintext_len is odd, clear the first four bits of right_2. </ins> Repeat steps 3 and 4, but use them to compute left_2 by expanding <del> and encrypting right_2 with the most significant octet as the concatenation of 0b11 ands cid_len, and XOR the results with </del> <ins> and encrypting right_2 with pass = 4, and XOR the results with </ins> left_1. <del> "left_2 = left_1 ^ truncate_left( AES_ECB(key, expand_right(right_2, cid_len, 4), len(left_1)) " </del> <ins> If the plaintext_len is odd, clear the last four bits of left_2. </ins> The server concatenates left_2 with right_2 to form the ciphertext <del> CID, which it appends to the first octet. </del> <ins> CID, which it appends to the first octet.  If plaintext_len is odd, the four least significant bits of left_2 and four most significant bits of right_2, which are all zero, are stripped off before concatenation to make the resulting ciphertext the same length as the original plaintext. 4.3.2.4. </ins> The following example executes the steps for the provided inputs. Note that the plaintext is of odd octet length, so the middle octet