createOffer to generate new ICE credentials, for the purpose of forcing an ICE restart and kicking off a new gathering phase, in which the new servers will be used.  If the ICE candidate pool has <del> a nonzero size, any existing candidates will be discarded, and new candidates will be gathered from the new servers. </del>  Any change to the ICE candidate policy affects the next gathering phase.  If an ICE gathering phase has already started or

createOffer to generate new ICE credentials, for the purpose of forcing an ICE restart and kicking off a new gathering phase, in which the new servers will be used.  If the ICE candidate pool has  <ins> a nonzero size, and a local description has not yet been applied, any existing candidates will be discarded, and new candidates will be gathered from the new servers. </ins> Any change to the ICE candidate policy affects the next gathering phase.  If an ICE gathering phase has already started or


until a gathering phase occurs, and so any necessary filtering can still be done on any pooled candidates. <del> Any changes to the ICE candidate pool size take effect </del>  immediately; if increased, additional candidates are pre-gathered; if decreased, the now-superfluous candidates are discarded.

The pool is only used in the first offer/answer exchange. After applying a local description, the pool size is frozen and changing the ICE servers will not result in new candidates being pooled. After an answer is applied, any leftover candidates are discarded. This only happens when applying an answer so that candidates aren't prematurely discarded for use cases that involve pranswer, or multiple offers.
I can live with this as is. Want to read again if we end up making changes to address EKR comments
Updated PR and its description based on our discussion.

until a gathering phase occurs, and so any necessary filtering can still be done on any pooled candidates.  <ins> The ICE candidate pool size MUST NOT be changed after applying a local description.  If a local description has not yet been applied, any changes to the ICE candidate pool size take effect </ins> immediately; if increased, additional candidates are pre-gathered; if decreased, the now-superfluous candidates are discarded.


accordingly, as described in I-D.ietf-mmusic-sdp-bundle-negotiation, Section 8.2.  6. Note: The following algorithm does not yet have WG consensus but is

accordingly, as described in I-D.ietf-mmusic-sdp-bundle-negotiation, Section 8.2. <ins> If the description is of type "answer", and there are still remaining candidates in the ICE candidate pool, discard them. </ins> 6. Note: The following algorithm does not yet have WG consensus but is


but also will offer "a=rtcp-mux", thus allowing for compatibility with either multiplexing or non-multiplexing endpoints. <del> The JSEP implementation will only gather RTP candidates.  This halves the number of candidates that the offerer needs to gather. Applying a description with an m= section that does not contain an "a=rtcp-mux" attribute will cause an error to be returned. </del>  The default multiplexing policy MUST be set to "require". Implementations MAY choose to reject attempts by the application to

I applied the following principles, which unfortunately are somewhat inconsistent with the current mux-exclusive draft. You use a=rtcp-mux to negotiate mux a=rtcp-mux-only is used by the offerer to say "I really mean it" To that end, offers contain a=rtcp-mux-only if the policy is require. Answers don't contain it because you don't need it to negotiate mux.
Those principles are consistent with bundle-only, although I wrote the mux-only examples as if mux-only should always be included whenever a=rtcp-mux is present.
NAME back at you
NAME ping
LG

but also will offer "a=rtcp-mux", thus allowing for compatibility with either multiplexing or non-multiplexing endpoints.  <ins> The JSEP implementation will only gather RTP candidates and will insert an "a=rtcp-mux-only" indication into any offers it generates.  This halves the number of candidates that the offerer needs to gather.  Applying a description with an m= section that does not contain an "a=rtcp-mux" attribute will cause an error to be returned. </ins> The default multiplexing policy MUST be set to "require". Implementations MAY choose to reject attempts by the application to


An "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.3.  An "a=rtcp-rsize" line, as specified in RFC5506, Section 5. Lastly, if a data channel has been created, a m= section MUST be

An "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.3. <ins> If the RTP/RTCP multiplexing policy is "require", an "a=rtcp-mux- only" line, as specified in I-D.ietf-mmusic-mux-exclusive, Section 4. </ins> An "a=rtcp-rsize" line, as specified in RFC5506, Section 5. Lastly, if a data channel has been created, a m= section MUST be


The "a=rtcp-mux" line MUST only be added if present in the most recent answer. <del> The "a=rtcp-mux-only" line MUST only be added if present in the most recent answer. </del> The "a=rtcp-rsize" line MUST only be added if present in the most recent answer.

The "a=rtcp-mux" line MUST only be added if present in the most recent answer.  The "a=rtcp-rsize" line MUST only be added if present in the most recent answer.


attribute MUST NOT be specified. If the RTP/RTCP multiplexing policy is "require", each m= section <del> MUST contain an "a=rtcp-mux" attribute. </del>  If this session description is of type "pranswer" or "answer", the following additional checks are applied:

attribute MUST NOT be specified. If the RTP/RTCP multiplexing policy is "require", each m= section  <ins> MUST contain an "a=rtcp-mux" attribute.  If an "m=" section contains an "a=rtcp-mux-only" attribute then that section MUST also contain an "a=rtcp-mux" attribute. </ins> If this session description is of type "pranswer" or "answer", the following additional checks are applied:


TRANSPORT categories for bundled m= sections, as described in I- D.ietf-mmusic-sdp-bundle-negotiation, Section 8.1.  The "a=group:BUNDLE" attribute MUST include the MID identifiers specified in the bundle group in the most recent answer, minus any m= sections that have been marked as rejected, plus any newly added or

attributes. As far as I can tell this can happen: On re-offers On any answer because nothing requires the offerer to generate bundle tags in the same order as m= lines (even though the data channel m= line is last) See: URL
NAME PTAL
Say you have a session where only a data channel is created. SDP looks like [session boilerplate] a=group:BUNDLE d1 m=X application UDP/DTLS/SCTP webrtc-datachannel a=mid:d1 ... Now, a media m= section is added (i.e. after first o/a). SDP becomes: [session boilerplate] a=group:BUNDLE d1 a1 m=X application UDP/DTLS/SCTP webrtc-datachannel a=mid:d1 a=ice-ufrag:ABCD ... m=X audio UDP/TLS/RTP/SAVPF 0 a=mid:a1 [no ice-ufrag or TRANSPORT attrs, since bundled] Now, where does a=rtcp-mux go? It can't go into because of the language that states Thoughts on how to resolve?
Could generating a session description be split into two parts? First, generate media-level attributes for each "m=" section, then transport-level attributes for the BUNDLE group and each non-bundled "m=" section.
That would be my preference, i.e., jam it into the BUNDLE group m= section, regardless of media type, as that's conceptually simplest, and easily handled here in JSEP. Either way, I suspect this will require changes upstream in the bundle spec.
So ... is it really not allowed in the d1 section. Unknown attributes are allowed in the d1 section, they are just ignored if they have no meaning for the data channel. Agree this sounds like something that will hit bundle.
Couldn't you do a=group:BUNDLE a1 d1 I would have thought this was prohibited, but is it really? URL
I think that's legal, but that approach doesn't work in the general case, where "m=" section A has TRANSPORT attributes that only it uses, and section B has TRANSPORT attributes that only it uses. BUNDLE just needs to allow an "m=" section to contain attributes that it normally wouldn't contain if it wasn't bundled. (If this isn't already allowed).
NAME any action needed here?
I think what we want in this scenario is to put "a=rtcp-mux" and "a=rtcp-rsize" in the data channel section. The simplest way would be to say: Which I guess could only happen in subsequent offers.
Let's go with what NAME suggests, although this makes it a bundle problem.
What would you say is needed on the BUNDLE side? Just clarification that the offerer BUNDLE-tag m= section should contain the union of all TRANSPORT and IDENTICAL attributes used by the BUNDLE group?
talked to chairs and advice from chairs on this and similar things that depend on mmusic outcomes. We put in JSEP now what our best guess is of how mmusic will end up and publish JSEP. At the same time we log a bug to check if we need to make any changes to line up with what mmusic decides. We can take changes to line up with mmusic as Last Call comments later on.
+1 with Taylor proposal to put RTP related things in data m= section if it is first and good with making this be bundles problem
NAME NAME I assume that you think that on initial offers this cannot happen because data comes last?
NAME Right. I can't think of a scenario where it wouldn't go last in an initial offer.
Agreed.
Oh, except that you aren't required to make the bundle group in order So you can have
I don't think the question whether you are allowed or not to place an RTP attribute in a non-RTP m= section is a pure BUNDLE issue. One needs to check what the specs defining those attributes say.
every SDP spec has to accept (and ignore) lines it does not understand ...
I looked into the a=rtcp-mux and a=rtcp-rsize specs, and I didn't see anything that prohibited their inclusion into a non-media section. Generally, I think BUNDLE can define the rules for this sort of thing, without fear that it will somehow contradict some other spec.
NAME NAME You may want to chime in on the current MMUSIC thread. I agree with you, but it seems to be going in the direction of "you can't do this".

I looked into the a=rtcp-mux and a=rtcp-rsize specs, and I didn't see anything that prohibited their >inclusion into a non-media section. It may not be explicitly stated, but since the semantics is about RTP and RTCP I think it is implicit. Having said that, I personally have no problem with allowing the attributes in non-RTP m- sections. I just want to verify that there is no text that has to be modified somewhere, and/or whether there is some text that has to be added somewhere :)
Resolved by
Looks good.

TRANSPORT categories for bundled m= sections, as described in I- D.ietf-mmusic-sdp-bundle-negotiation, Section 8.1. <ins> Note that if media m= sections are bundled into a data m= section, then certain TRANSPORT and IDENTICAL attributes may appear in the data m= section even if they would otherwise only be appropriate for a media m= section (e.g., "a=rtcp-mux").  This cannot happen in initial offers because in the initial offer JSEP implementations always list media m= sections (if any) before the data m= section (if any), and at least one of those media m= sections will not have the "a=bundle-only" attribute.  Therefore, in initial offers, any "a=bundle-only" m= sections will be bundled into a preceding non-bundle-only media m= section. </ins> The "a=group:BUNDLE" attribute MUST include the MID identifiers specified in the bundle group in the most recent answer, minus any m= sections that have been marked as rejected, plus any newly added or


If a data channel m= section has been offered, a m= section MUST also be generated for data.  The <media> field MUST be set to "application" and the <proto> and "fmt" fields MUST be set to exactly <del> match the fields in the offer. </del>  Within the data m= section, an "a=mid" line MUST be generated and included as described above, along with an "a=sctp-port" line

If a data channel m= section has been offered, a m= section MUST also be generated for data.  The <media> field MUST be set to "application" and the <proto> and "fmt" fields MUST be set to exactly  <ins> match the fields in the offer.  Note that if media m= sections are bundled into a data m= section, then certain TRANSPORT and IDENTICAL attributes may appear in the data m= section even if they would otherwise only be appropriate for a media m= section (e.g., "a=rtcp- mux"). </ins> Within the data m= section, an "a=mid" line MUST be generated and included as described above, along with an "a=sctp-port" line


excluded by subsequent calls to createOffer and createAnswer, in which case the corresponding media formats in the associated m= section will be excluded.  The codec preferences cannot add media <del> formats that would otherwise not be present.  This includes codecs that were not negotiated in a previous offer/answer exchange that included the transceiver. </del>  The codec preferences of an RtpTransceiver can also determine the order of codecs in subsequent calls to createOffer and createAnswer,

LGTM and if Justin wants to tie in the stuff from my comment a bit more that is great
NAME PTAL
seems like it's generally right,LGTM

excluded by subsequent calls to createOffer and createAnswer, in which case the corresponding media formats in the associated m= section will be excluded.  The codec preferences cannot add media  <ins> formats that would otherwise not be present. </ins> The codec preferences of an RtpTransceiver can also determine the order of codecs in subsequent calls to createOffer and createAnswer,


For each offered m= section, if any of the following conditions are true, the corresponding m= section in the answer MUST be marked as rejected by setting the port in the m= line to zero, as indicated in <del> RFC3264, Section 6., and further processing for this m= section can be skipped: </del>  The associated RtpTransceiver has been stopped. <del> No supported codec is present in the offer. </del>  The bundle policy is "max-bundle", and this is not the first m= section or in the same bundle group as the first m= section.

For each offered m= section, if any of the following conditions are true, the corresponding m= section in the answer MUST be marked as rejected by setting the port in the m= line to zero, as indicated in  <ins> RFC3264, Section 6, and further processing for this m= section can be skipped: </ins> The associated RtpTransceiver has been stopped.  <ins> None of the offered media formats are supported and, if applicable, allowed by codec preferences. </ins> The bundle policy is "max-bundle", and this is not the first m= section or in the same bundle group as the first m= section.


for the corresponding m= line in the offer. If codec preferences have been set for the associated transceiver, <del> media formats MUST be generated in the corresponding order, and MUST exclude any codecs not present in the codec preferences or not present in the offer.  Note that non-JSEP endpoints are not subject to this restriction, and might add media formats in the answer that are not present in the offer, as specified in RFC3264, Section 6.1.  Therefore, JSEP implementations MUST be prepared to receive such answers. Unless excluded by the above restrictions, the media formats MUST include the mandatory audio/video codecs as specified in RFC7874, Section 3, and RFC7742, Section 5. </del>  The m= line MUST be followed immediately by a "c=" line, as specified in RFC4566, Section 5.7.  Again, as no candidates are available yet,

for the corresponding m= line in the offer. If codec preferences have been set for the associated transceiver,  <ins> media formats MUST be generated in the corresponding order, regardless of what was offered, and MUST exclude any codecs not present in the codec preferences. Otherwise, the media formats on the m= line MUST be generated in the same order as those offered in the current remote description, excluding any currently unsupported formats.  Any currently available media formats that are not present in the current remote description MUST be added after all existing formats. In either case, the media formats in the answer MUST include at least one format that is present in the offer, but MAY include formats that are locally supported but not present in the offer, as mentioned in RFC3264, Section 6.1.  If no common format exists, the m= section is rejected as described above. </ins> The m= line MUST be followed immediately by a "c=" line, as specified in RFC4566, Section 5.7.  Again, as no candidates are available yet,


must instead match what was supplied in the offer, as described above. <del> Unless codec preferences have been set for the associated transceiver, the media formats on the m= line MUST be generated in the same order as in the current local description. </del> Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless the m= section is restarting, in which case new ICE credentials must be created as specified in RFC5245, Section 9.2.1.1.  If the

must instead match what was supplied in the offer, as described above.  Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless the m= section is restarting, in which case new ICE credentials must be created as specified in RFC5245, Section 9.2.1.1.  If the


local answers, "recvonly" for remote answers, or "sendrecv" for either type of answer), choose the media format to send as the most preferred media format from the remote description that is <del> also present in the answer, as described in RFC3264, Sections 6.1 and 7, and start transmitting RTP media once the underlying transport layers have been established.  If an SSRC has not already been chosen for this outgoing RTP stream, choose a random one.  If media is already being transmitted, the same SSRC SHOULD be used unless the clockrate of the new codec is different, in which case a new SSRC MUST be chosen, as </del>  specified in RFC7160, Section 3.1. The payload type mapping from the remote description is used to

local answers, "recvonly" for remote answers, or "sendrecv" for either type of answer), choose the media format to send as the most preferred media format from the remote description that is  <ins> also locally supported, as discussed in RFC3264, Sections 6.1 and 7, and start transmitting RTP media using that format once the underlying transport layers have been established.  If an SSRC has not already been chosen for this outgoing RTP stream, choose a random one.  If media is already being transmitted, the same SSRC SHOULD be used unless the clockrate of the new codec is different, in which case a new SSRC MUST be chosen, as </ins> specified in RFC7160, Section 3.1. The payload type mapping from the remote description is used to


If the RTP/RTCP multiplexing policy is "require", each m= section MUST contain an "a=rtcp-mux" attribute.  If an m= section contains <del> an "a=rtcp-mux-only" attribute then that section MUST also contain an "a=rtcp-mux" attribute. </del>  <del> If this m= section was present in the previous answer then the state of RTP/RTCP multiplexing MUST match what was previously negotiated. </del>  If this session description is of type "pranswer" or "answer", the following additional checks are applied:

I agree with justin here. my bad for missing that.
The 4th bullet on page 64 is ambiguous at "this m= section". It looks like this bullet should just be merged with the previous bullet.
I'm not sure what the problem is here, but I'm not against merging it. NAME
The bullet point in question is the one that reads If this m= section was present in the previous answer then the state of RTP/RTCP multiplexing MUST match what was previously negotiated.
LGTM

If the RTP/RTCP multiplexing policy is "require", each m= section MUST contain an "a=rtcp-mux" attribute.  If an m= section contains  <ins> an "a=rtcp-mux-only" attribute, that section MUST also contain an "a=rtcp-mux" attribute. </ins>  <ins> If an m= section was present in the previous answer, the state of RTP/RTCP multiplexing MUST match what was previously negotiated. </ins> If this session description is of type "pranswer" or "answer", the following additional checks are applied:


If present, "a=msid" attributes MUST be parsed as specified in I- D.ietf-mmusic-msid, Section 3.2, and their values stored, ignoring <del> any "appdata" field. </del>  Any "a=imageattr" attributes MUST be parsed as specified in RFC6236, Section 3, and their values stored.

Fixed
also tagging NAME (who might be unhappy with 'default' which matches Chrome behaviour but not Firefox behaviour (it generates a uuid)
ping NAME NAME
NAME NAME PTAL - Barring any objections this one ought to get merged.
Folks, I think this one is pretty uncontroversial - planning to land this next week if there are no objections.
Take this simplified SDP offer from a remote endpoint (in parts taken from : A single audio and video stream. No a=mid (there is quite some text taking care of that) but no a=msid line either. URL shows a live example. Both Chrome (without unified-plan) and Firefox will fire the ontrack event (or legacy onaddstream) with a single mediastream containing an audio and video track. This has been like that since... 2012-ish? Unified plan support in Chrome changes this behaviour: URL ontrack is fired with an empty set of media streams. onaddstream is not fired. This is quite a change in behaviour. And unexpected, I didn't expect any issues for this trivial case of a single audio/video track. As NAME webrtc-pc assumes/requires a=msid to be present and . In particular this says which means firing with no streams is technically correct. JSEP seems to assume it is present as well, but has this text about a=msid in Note the "If present". What if it is not present? The closest I could find in terms of guidance was this from the and its section about handling a=msid is supposed to be present in initial offer so we are talking about dealing with non-webrtc entities send an offer. Given that there is plenty of support for entities that do not support a=mid (an RFC published in 2010) in JSEP do we need backward compability for the case of a single audio/video track each but no msid? Interop between browsers is probably not affected, due to Chrome still interpreting and sending a=ssrc:123 msid:...
note that a proper webrtc client will include "no streams" as (maybe with a track) which allows differentiating between "no streams because I do not use any" and "msid???" Thanks NAME for another
aside: the interesting case you have trouble distinguishing between is "no msid because I haven't started sending a track yet" and "no msid because I don't support msid". It's one case where we still have trouble if RTP packets arrive ahead of signalling. But - yes, I think we are better off sticking with the 2012 behavior, default stream and all. We can handle the case above by changing the stream associations of the receiver if a new SDP (with msid) arrives after the RTP packets.
there used to be a a=msid-semantic line that would allow determining whether a party wants its offer to be treated assuming msid support. Browsers still send it :-)
How are non-signaled tracks supposed to be handled anyway? There's JSEP language about creating a track for it, but what about webrtc-pc? (If a track exists in the forest, and nobody is around to surface it to JavaScript, does it still exist?) "Run the following steps for each media description in description" means no ontrack will fire until we do have something signaled. If the track (and/or stream) only exists in some inaccessible way they're almost conceptual until the signaling does arrive. And when it does arrive, we know whether or not MediaStreams were signaled. So we should know what to do, same things as if we didn't receive early RTP packets? Does the distinction matter? I love that we can tell the difference between "no streams because I do not use any" and "no msid signaled" whether or not "a=msid:-" was present. I had not thought about that! Unless I'm confused about something, I suggest: If is present, do what Chrome does: don't create any stream. If the line is completely missing, do what Firefox (or Chrome Plan B) does: create a MediaStream with a random id. Does that work for people?
By the way I thought this was a webrtc-pc issue when I replied above, so I was thinking about what to do in JavaScript rather than talking about any JSEP change.
I suppose we need some JSEP language to handle the lack of any a=msid but i agree with what you propose above. We do have have a=msid:- and we need to handle that in webrtc-pc too. Will file an issue there.
All webrtc-pc says is "let msids be a list of the MSIDs that the media description indicates transceiver.[[Receiver]].[[ReceiverTrack]] is to be associated with. Otherwise, let msids be an empty list" And says "The special value "-" indicates "no MediaStream"." So that already takes care of the case correctly, I claim. I agree. We need to solve what the media description (JSEP) says about this. Right now : "If present, "a=msid" attributes MUST be parsed as specified in [I-D.ietf-mmusic-msid], Section 3.2, and their values stored." I think it needs to say what happens when it is not present. Something like: "If no a=msid is present, then in place of "msid-id", create a single "id" unique to this end-point, if one hasn't already been created for this connection."
"if one hasn't already been created for this connection"; so future tracks will share the same stream? There is always at most a single "default stream"?
NAME says he observed this is how Firefox and Chrome work. URL
See URL
LGTMreason I asked is that chrome generates a MediaStream with id "default" -- see URL while Firefox does not. (I do not see any reason to change the legacy behaviour of chrome even though it seems a bit odd that the RNG always emits the right bytes for "default")

If present, "a=msid" attributes MUST be parsed as specified in I- D.ietf-mmusic-msid, Section 3.2, and their values stored, ignoring  <ins> any "appdata" field.  If no "a=msid" attributes are present, a random msid-id value is generated for a "default" MediaStream for the session, if not already present, and this value is stored. </ins> Any "a=imageattr" attributes MUST be parsed as specified in RFC6236, Section 3, and their values stored.


The setConfiguration method allows the global configuration of the PeerConnection, which was initially set by constructor parameters, to <del> be changed during the session.  The effects of this method call </del>  depend on when it is invoked, and they will differ, depending on which specific parameters are changed: <del> This call may result in a change to the state of the ICE agent. </del>  4.1.17.

Several small updates: Issue 15: local media state, local resources correct, removed comment. - Issue 16: updated wording to use 'calling this method', removed comments, - Issue 17: changed stopTransceiver to stop, removed comments, - Issue 18: changed 'directional attribute' to 'direction attribute', removed comments,
LGTM once lands
18) [rfced] Section 4.2.5: We see "direction attribute" but not "directional attribute" in RFC 3264. Will this text be clear to readers? (We ask because we also see "A direction attribute, determined by applying the rules regarding the offered direction specified in [RFC3264], Section 6.1" in Section 5.3.1 of this document.) Original: More specifically, it indicates the [RFC3264] directional attribute of the associated m= section in the last applied answer (including provisional answers), with "send" and "recv" directions reversed if it was a remote answer.
This should indeed be , as that's the terminology used by 3264.
NAME please close this issue once you consider it resolved.
17) [rfced] Section 4.2.2: Will "stopTransceiver" be clear to readers? We could not find this string elsewhere in this document, anywhere else in this cluster of documents, in any published RFC, or in google searches. Original: The stopped property indicates whether the transceiver has been stopped, either by a call to stopTransceiver or by applying an answer that rejects the associated m= section.
This should be , rather than .
NAME please close this issue once you consider it resolved.
16) [rfced] Section 4.1.16: Should "The effects of this method call" be "The effects of calling this method," and should "This call" be "Calling this method"? Original: The effects of this method call depend on when it is invoked, and differ depending on which specific parameters are changed: ... This call may result in a change to the state of the ICE Agent.
SGTM
NAME please close this issue once you consider it resolved.
15) [rfced] Section 4.1.10: Please confirm that "local media state" and "local resources" (as opposed to remote) are correct in the context of setRemoteDescription. (We ask because we see identical wording in Section 4.1.9 ("setLocalDescription").) Original: This API changes the local media state; among other things, it sets up local resources for sending and encoding media.
yes, this is correct
NAME please close this issue once you consider it resolved.
12) [rfced] Section 4.1.8.1: We had trouble with this sentence. If neither suggestion below is correct, please clarify. Original: While this could also be done with a "sendonly" pranswer, followed by a "sendrecv" answer, the initial pranswer leaves the offer-answer exchange open, which means that the caller cannot send an updated offer during this time. Suggestion : While this could also be done with a "sendonly" pranswer, if followed by a "sendrecv" answer the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time. Suggestion : While this could also be done with a "sendonly" pranswer followed by a "sendrecv" answer, the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time.
suggestion seems right

The setConfiguration method allows the global configuration of the PeerConnection, which was initially set by constructor parameters, to  <ins> be changed during the session.  The effects of calling this method </ins> depend on when it is invoked, and they will differ, depending on which specific parameters are changed:  <ins> Calling this method may result in a change to the state of the ICE agent. </ins> 4.1.17.


4.2.2. The stopped property indicates whether the transceiver has been <del> stopped, either by a call to stopTransceiver or by applying an answer that rejects the associated "m=" section.  In either of these cases, it is set to "true" and otherwise will be set to "false". </del>  A stopped RtpTransceiver does not send any outgoing RTP or RTCP or process any incoming RTP or RTCP.  It cannot be restarted.

4.2.2. The stopped property indicates whether the transceiver has been  <ins> stopped, either by a call to stop or by applying an answer that rejects the associated "m=" section.  In either of these cases, it is set to "true" and otherwise will be set to "false". </ins> A stopped RtpTransceiver does not send any outgoing RTP or RTCP or process any incoming RTP or RTCP.  It cannot be restarted.


affects the direction property of the associated "m=" section on future calls to createOffer and createAnswer.  The permitted values for direction are "recvonly", "sendrecv", "sendonly", and "inactive", <del> mirroring the identically named directional attributes defined in </del>  RFC4566. When creating offers, the transceiver direction is directly reflected

affects the direction property of the associated "m=" section on future calls to createOffer and createAnswer.  The permitted values for direction are "recvonly", "sendrecv", "sendonly", and "inactive",  <ins> mirroring the identically named direction attributes defined in </ins> RFC4566. When creating offers, the transceiver direction is directly reflected


The currentDirection property indicates the last negotiated direction for the transceiver's associated "m=" section.  More specifically, it <del> indicates the directional attribute RFC3264 of the associated "m=" </del>  section in the last applied answer (including provisional answers), with "send" and "recv" directions reversed if it was a remote answer. <del> For example, if the directional attribute for the associated "m=" </del>  section in a remote answer is "recvonly", currentDirection is set to "sendonly".

The currentDirection property indicates the last negotiated direction for the transceiver's associated "m=" section.  More specifically, it  <ins> indicates the direction attribute RFC3264 of the associated "m=" </ins> section in the last applied answer (including provisional answers), with "send" and "recv" directions reversed if it was a remote answer.  <ins> For example, if the direction attribute for the associated "m=" </ins> section in a remote answer is "recvonly", currentDirection is set to "sendonly".


packets in response to Initial packets that don't include a valid token. <del> Both server and service must have access to Universal time, though tight synchronization is unnecessary. </del>  The tokens are protected using AES128-GCM AEAD, as explained in token-protection-with-aead.  All tokens, generated by either the

This is in response to a post NAME made on .
Thanks for the PR! So as an interoperability standard, if the retry service encodes "4000", what does the server do with that? Do we need to add a config parameter for the time_t that serves as time 0?
Timestamps should be absolute, not relative, in which case I'm not sure you need a 0. There's nothing special about midnight 1 January 1970.
Ah, so you're just suggesting declaring a later date to begin the epoch? Makes sense
Why do we need to have a sential time? If it's a precision vs. range issue then shifting the epoch makes sense.
Sorry, I don't know what "sential time" is. What are you proposing?
What I'm proposing is that we not treat any times differently. It's not clear to me why 4000 needed special treatment.
4000 is just an example. The intent of using the epoch was to have common agreement on when tokens expire without any QUIC-LB-specific coordination. The current draft uses 1970 as a timebase, which absolutely makes integers longer than it needs to be. IIUC the PR doesn't have any baseline so it's unclear how the server and retry service are supposed to interpret each other's expiration times. As we're probably speaking past each other: what, precisely, does the integer in this field indicate?
It's the end of the validity period for the token in some convenient timebase.
Alright, we agree on that. So this PR is being a little less precise on synchronization, which is fine, but isn't addressing the fact that we're counting from 1970. Fair enough. Dear QUIC WG, First a moment of unforgivable pedantry. Universal time is unfortunately not the right name for UTC, which is slightly different. It could also mean UT1 or some other variations It's also not clear what the future of computer timekeeping is and I know several places don't synchronize to UTC internally. I think the best way to handle this is to say something like "synchronized" and leave open as to exactly how that is done. I agree with the comments that there are too many options and should be fewer. Other then that I didn't see any problems but I'm probably too sleepy right now to spot them. Sincerely, Watson Ladd Astra mortemque praestare gradatim

packets in response to Initial packets that don't include a valid token.  <ins> Both server and service must have time synchronized with respect to one another to prevent tokens being incorrectly marked as expired, though tight synchronization is unnecessary. </ins> The tokens are protected using AES128-GCM AEAD, as explained in token-protection-with-aead.  All tokens, generated by either the


6. <del> For protocols where 4-tuple load balancing is sufficient, it is straightforward to deliver ICMP packets from the network to the correct server, by reading the echoed IP and transport-layer headers to obtain the 4-tuple.  When routing is based on connection ID, further measures are required, as most QUIC packets that trigger ICMP responses will only contain a client-generated connection ID that contains no routing information. To solve this problem, load balancers MAY maintain a mapping of Client IP and port to server ID based on recently observed packets. Alternatively, servers MAY implement the technique described in Section 14.4.1 of RFC9000 to increase the likelihood a Source Connection ID is included in ICMP responses to Path Maximum Transmission Unit (PMTU) probes.  Load balancers MAY parse the echoed packet to extract the Source Connection ID, if it contains a QUIC long header, and extract the Server ID as if it were in a Destination CID. </del>  7.

Definitely an edge case, but the LB will spray stateless resets everywhere because the CID is random. If the LB tracks fourtuples, though, it shouldn't be a problem.
Maybe make this part of a thing about stateless LBs.
So, what's the plan ?
NAME raises an interesting point about stateless LBs in .

6.  <ins> QUIC-LB requires no per-connection state at the load balancer.  The load balancer can extract the server ID from the connection ID of each incoming packet and route that packet accordingly. However, once the routing decision has been made, the load balancer MAY associate the 4-tuple with the decision.  This has two advantages: The load balancer only extracts the server ID once per incoming 4-tuple.  When the CID is encrypted, this substantially reduces computational load. Incoming Stateless Reset packets and ICMP messages are easily routed to the correct origin server. In addition to the increased state requirements, however, load balancers cannot detect the CONNECTION_CLOSE frame to indicate the end of the connection, so they rely on a timeout to delete connection state.  There are numerous considerations around setting such a timeout. In the event a connection ends, freeing an IP and port, and a different connection migrates to that IP and port before the timeout, the load balancer will misroute the different connection's packets to the original server.  A short timeout limits the likelihood of such a misrouting. Furthermore, if a short timeout causes premature deletion of state, the routing is easily recoverable by decoding an incoming Connection ID.  However, a short timeout also reduces the chance that an incoming Stateless Reset is correctly routed. Servers MAY implement the technique described in Section 14.4.1 of RFC9000 in case the load balancer is stateless, to increase the likelihood a Source Connection ID is included in ICMP responses to Path Maximum Transmission Unit (PMTU) probes.  Load balancers MAY parse the echoed packet to extract the Source Connection ID, if it contains a QUIC long header, and extract the Server ID as if it were in a Destination CID. </ins> 7.


verification) or make sure there is common context for the server to verify the address using a service-generated token.  There are two different mechanisms to allow offload of DoS mitigation to a trusted network service.  One requires no shared state; the server need only be configured to trust a retry service, though this

After thinking it through, various XOR schemes were extremely vulnerable to manipulation, so I went with a brute force approach.
The server now needs to include this field. For the no-shared state service, we just need language that the Retry service needs to encode enough information validate the packet DCID as well and drop if it fails validation. If it does, the server MUST use the packet DCID in the retrysourceconnection_id TP. For the shared state service, the retry source connection ID is going to have to be in the token. We might be able to compress this by xoring some fields; I'll think about it.

verification) or make sure there is common context for the server to verify the address using a service-generated token. <ins> The service must also communicate the source connection ID of the Retry packet to the server so that it can include it in a transport parameter for client verification. </ins> There are two different mechanisms to allow offload of DoS mitigation to a trusted network service.  One requires no shared state; the server need only be configured to trust a retry service, though this


triggering Initial packet.  This is in cleartext to be readable for the server, but authenticated later in the token.  Original Destination Connection ID: This also in cleartext and authenticated later.  Opaque Data: This data MUST contain encrypted information that allows the retry service to validate the client's IP address, in accordance <del> with the QUIC specification.  It MUST also encode a secure hash of the original destination connection ID field to verify that this field has not been edited. </del>  Upon receipt of an Initial packet with a token that begins with '0', the retry service MUST validate the token in accordance with the QUIC <del> specification.  It must also verify that the secure hash of the Connect ID is correct.  If incorrect, the token is invalid. </del>  In active mode, the service MUST issue Retry packets for all Client initial packets that contain no token, or a token that has the first bit set to '1'.  It MUST NOT forward the packet to the server.  The service MUST validate all tokens with the first bit set to '0'.  If successful, the service MUST forward the packet with the token <del> intact.  If unsuccessful, it MUST drop the packet. </del>  Note that this scheme has a performance drawback.  When the retry service is in active mode, clients with a token from a NEW_TOKEN

triggering Initial packet.  This is in cleartext to be readable for the server, but authenticated later in the token. <ins> RSCIL: The retry source connection ID length. </ins> Original Destination Connection ID: This also in cleartext and authenticated later. <ins> Retry Source Connection ID: This also in cleartext and authenticated later. </ins> Opaque Data: This data MUST contain encrypted information that allows the retry service to validate the client's IP address, in accordance  <ins> with the QUIC specification.  It MUST also provide a cryptographically secure means to validate the integrity of the entire token. </ins> Upon receipt of an Initial packet with a token that begins with '0', the retry service MUST validate the token in accordance with the QUIC  <ins> specification. </ins> In active mode, the service MUST issue Retry packets for all Client initial packets that contain no token, or a token that has the first bit set to '1'.  It MUST NOT forward the packet to the server.  The service MUST validate all tokens with the first bit set to '0'.  If successful, the service MUST forward the packet with the token  <ins> intact.  If unsuccessful, it MUST drop the packet.  The Retry Service MAY send an Initial Packet containing a CONNECTION_CLOSE frame with the INVALID_TOKEN error code when dropping the packet. </ins> Note that this scheme has a performance drawback.  When the retry service is in active mode, clients with a token from a NEW_TOKEN


receives an Initial Packet with the first bit to '0', it is a Retry token and the server MUST NOT attempt to validate it.  Instead, it MUST assume the address is validated and MUST extract the Original <del> Destination Connection ID, assuming the format described in nss- service-requirements. </del>  6.3.

receives an Initial Packet with the first bit to '0', it is a Retry token and the server MUST NOT attempt to validate it.  Instead, it MUST assume the address is validated and MUST extract the Original  <ins> Destination Connection ID and Retry Source Connection ID, assuming the format described in nss-service-requirements. </ins> 6.3.


ODCIL: The original destination connection ID length.  Tokens in NEW_TOKEN frames MUST set this field to zero. <del> Original Destination Connection ID: This is copied from the field in the client Initial packet. </del>  Client IP Address: The source IP address from the triggering Initial packet.  The client IP address is 16 octets.  If an IPv4 address, the

ODCIL: The original destination connection ID length.  Tokens in NEW_TOKEN frames MUST set this field to zero.  <ins> RSCIL: The retry source connection ID length.  Tokens in NEW_TOKEN frames MUST set this field to zero. Original Destination Connection ID: The server or Retry Service copies this from the field in the client Initial packet. Retry Source Connection ID: The server or Retry service copies this from the Source Connection ID of the Retry packet. </ins> Client IP Address: The source IP address from the triggering Initial packet.  The client IP address is 16 octets.  If an IPv4 address, the


retry tokens marked as being a few seconds in the future, due to possible clock synchronization issues. <del> A server MUST NOT send a Retry packet in response to an Initial packet that contains a retry token. </del>  7.

retry tokens marked as being a few seconds in the future, due to possible clock synchronization issues.  <ins> After decrypting the token, the server uses the corresponding fields to populate the original_destination_connection_id transport parameter, with a length equal to ODCIL, and the retry_source_connection_id transport parameter, with length equal to RSCIL. As discussed in QUIC-TRANSPORT, a server MUST NOT send a Retry packet in response to an Initial packet that contains a retry token. </ins> 7.


4.4.2. <del> Upon receipt of a QUIC packet that is not of type Initial or 0-RTT, the load balancer extracts as many of the earliest octets from the destination connection ID as necessary to match the nonce length. The server ID immediately follows. </del>  The load balancer decrypts the nonce and the server ID using the following three pass algorithm:

I will probably delete the Stream Cipher algorithm entirely, but consider this an intermediate step.
Merging to enable the next round of edits

4.4.2.  <ins> Upon receipt of a QUIC packet, the load balancer extracts as many of the earliest octets from the destination connection ID as necessary to match the nonce length.  The server ID immediately follows. </ins> The load balancer decrypts the nonce and the server ID using the following three pass algorithm:


encrypted-nonce) Pass 2: The load balancer decrypts the nonce octets using 128-bit <del> AES Electronic Codebook (ECB) mode, much like QUIC header protection, using the server-id intermediate as "nonce" for this </del>  pass.  The server-id intermediate octets are zero-padded to 16 octets.  AES-ECB encrypts this padded server-id intermediate using its key to generate a mask which it applies to the encrypted

encrypted-nonce) Pass 2: The load balancer decrypts the nonce octets using 128-bit  <ins> AES ECB mode, using the server-id intermediate as "nonce" for this </ins> pass.  The server-id intermediate octets are zero-padded to 16 octets.  AES-ECB encrypts this padded server-id intermediate using its key to generate a mask which it applies to the encrypted


nonce = encrypted_nonce ^ AES-ECB(key, padded-server_id_intermediate) Pass 3: The load balancer decrypts the server ID using 128-bit AES <del> Electronic Codebook (ECB) mode, much like QUIC header protection. The nonce octets are zero-padded to 16 octets.  AES-ECB encrypts this nonce using its key to generate a mask which it applies to the intermediate server id.  This provides the dercypted server ID. </del>  server_id = server_id_intermediate ^ AES-ECB(key, padded-nonce) <del> This three pass algorithm is a simplified version of the FFX </del>  algorithm.  It has the same connection ID length requirements as the Stream Cipher CID Algorithm, with the additional property that each encrypted nonce value depends on all server ID bits, and each

nonce = encrypted_nonce ^ AES-ECB(key, padded-server_id_intermediate) Pass 3: The load balancer decrypts the server ID using 128-bit AES  <ins> ECB mode.  The nonce octets are zero-padded to 16 octets.  AES-ECB encrypts this nonce using its key to generate a mask which it applies to the intermediate server id.  This provides the decrypted server ID. </ins> server_id = server_id_intermediate ^ AES-ECB(key, padded-nonce)  <ins> This three-pass algorithm is a simplified version of the FFX </ins> algorithm.  It has the same connection ID length requirements as the Stream Cipher CID Algorithm, with the additional property that each encrypted nonce value depends on all server ID bits, and each


When generating a routable connection ID, the server writes arbitrary bits into its nonce octets, and its provided server ID into the server ID octets.  Servers MAY opt to have a longer connection ID <del> beyond the nonce and server ID.  The nonce and additional bits MAY encode additional information, but SHOULD appear essentially random to observers. </del>  The server encrypts the server ID using exactly the algorithm as described in triple-stream-cipher-load-balancer-actions, performing

When generating a routable connection ID, the server writes arbitrary bits into its nonce octets, and its provided server ID into the server ID octets.  Servers MAY opt to have a longer connection ID  <ins> beyond the nonce and server ID.  The additional bits MAY encode additional information, but SHOULD appear essentially random to observers. If the decrypted nonce bits increase monotonically, that guarantees that nonces are not reused between connection IDs from the same server. </ins> The server encrypts the server ID using exactly the algorithm as described in triple-stream-cipher-load-balancer-actions, performing


4.2. <del> The Obfuscated CID Algorithm makes an attempt to obscure the mapping of connections to servers to reduce linkability, while not requiring true encryption and decryption.  The format is depicted in the figure </del>  below. 4.2.1. <del> The configuration agent selects an arbitrary set of bits of the server connection ID that it will use to route to a given server, called the "routing bits".  The number of bits MUST have enough entropy to have a different code point for each server, and SHOULD have enough entropy so that there are many codepoints for each server. The configuration agent MUST NOT select a routing mask with more than 136 routing bits set to 1, which allows for the first octet and up to 2 octets for server purposes in a maximum-length connection ID. The configuration agent selects a divisor that MUST be larger than the number of servers.  It SHOULD be large enough to accommodate reasonable increases in the number of servers.  The divisor MUST be an odd integer so certain addition operations do not always produce an even number. The configuration agent also assigns each server a "modulus", an integer between 0 and the divisor minus 1.  These MUST be unique for each server, and SHOULD be distributed across the entire number space between zero and the divisor. 4.2.2. Upon receipt of a QUIC packet, the load balancer extracts the selected bits of the Server CID and expresses them as an unsigned integer of that length.  The load balancer then divides the result by the chosen divisor.  The modulus of this operation maps to the modulus for the destination server. Note that any Server CID that contains a server's modulus, plus an arbitrary integer multiple of the divisor, in the routing bits is routable to that server regardless of the contents of the non-routing bits.  Outside observers that do not know the divisor or the routing bits will therefore have difficulty identifying that two Server CIDs route to the same server. Note also that not all Connection IDs are necessarily routable, as the computed modulus may not match one assigned to any server.  These DCIDs are non-compliant as described above. 4.2.3. The server chooses a connection ID length.  This MUST contain all of the routing bits and MUST be at least 9 octets to provide adequate entropy. When a server needs a new connection ID, it adds an arbitrary nonnegative integer multiple of the divisor to its modulus, without exceeding the maximum integer value implied by the number of routing bits.  The choice of multiple should appear random within these constraints. The server encodes the result in the routing bits.  It MAY put any other value into bits that used neither for routing nor config rotation.  These bits SHOULD appear random to observers. 4.3. The Stream Cipher CID algorithm provides true cryptographic protection, rather than mere obfuscation, at the cost of additional per-packet processing at the load balancer to decrypt every incoming connection ID.  The CID format is depicted below. 4.3.1. </del> The configuration agent assigns a server ID to every server in its pool, and determines a server ID length (in octets) sufficiently large to encode all server IDs, including potential future servers.

by popular demand in .
As discussed at IETF 108. Split from .
Thanks for filing this. I agree that this was the feedback, but I'll take it from the list to be sure.
Removing this seems fine to me.
Yes, do it.
Seems fine.
Do it.
Do it.
Nick Harper concurred on the list
Yes, that works. Minor comment.

4.2.  <ins> The Stream Cipher CID algorithm provides cryptographic protection at the cost of additional per-packet processing at the load balancer to decrypt every incoming connection ID.  The CID format is depicted </ins> below. 4.2.1.  The configuration agent assigns a server ID to every server in its pool, and determines a server ID length (in octets) sufficiently large to encode all server IDs, including potential future servers.


MUST be at least 8 octets and no more than 16 octets.  The nonce length and server ID length MUST sum to 19 or fewer octets. <del> 4.3.2. </del>  Upon receipt of a QUIC packet, the load balancer extracts as many of the earliest octets from the destination connection ID as necessary

MUST be at least 8 octets and no more than 16 octets.  The nonce length and server ID length MUST sum to 19 or fewer octets.  <ins> 4.2.2. </ins> Upon receipt of a QUIC packet, the load balancer extracts as many of the earliest octets from the destination connection ID as necessary


The output of the decryption is the server ID that the load balancer uses for routing. <del> 4.3.3. </del>  When generating a routable connection ID, the server writes arbitrary bits into its nonce octets, and its provided server ID into the

The output of the decryption is the server ID that the load balancer uses for routing.  <ins> 4.2.3. </ins> When generating a routable connection ID, the server writes arbitrary bits into its nonce octets, and its provided server ID into the


described in stream-cipher-load-balancer-actions, performing the three passes in reverse order. <del> 4.4. </del>  The Block Cipher CID Algorithm, by using a full 16 octets of plaintext and a 128-bit cipher, provides higher cryptographic

described in stream-cipher-load-balancer-actions, performing the three passes in reverse order.  <ins> 4.3. </ins> The Block Cipher CID Algorithm, by using a full 16 octets of plaintext and a 128-bit cipher, provides higher cryptographic


it also requires connection IDs of at least 17 octets, increasing overhead of client-to-server packets. <del> 4.4.1. </del>  The configuration agent assigns a server ID to every server in its pool, and determines a server ID length (in octets) sufficiently

it also requires connection IDs of at least 17 octets, increasing overhead of client-to-server packets.  <ins> 4.3.1. </ins> The configuration agent assigns a server ID to every server in its pool, and determines a server ID length (in octets) sufficiently


The configuration agent also selects an 16-octet AES-ECB key to use for connection ID decryption. <del> 4.4.2. </del>  Upon receipt of a QUIC packet, the load balancer reads the first octet to obtain the config rotation bits.  It then decrypts the

The configuration agent also selects an 16-octet AES-ECB key to use for connection ID decryption.  <ins> 4.3.2. </ins> Upon receipt of a QUIC packet, the load balancer reads the first octet to obtain the config rotation bits.  It then decrypts the


in that order.  The load balancer uses the server ID octets for routing. <del> 4.4.3. </del>  When generating a routable connection ID, the server MUST choose a connection ID length between 17 and 20 octets.  The server writes its

in that order.  The load balancer uses the server ID octets for routing.  <ins> 4.3.3. </ins> When generating a routable connection ID, the server MUST choose a connection ID length between 17 and 20 octets.  The server writes its


routing bytes.  The Server ID is unique to each server, and the routing bytes are global. <del> For Obfuscated CID Routing, this consists of the Routing Bits, Divisor, and Modulus.  The Modulus is unique to each server, but the others MUST be global. </del> For Stream Cipher CID Routing, this consists of the Server ID, Server ID Length, Key, and Nonce Length.  The Server ID is unique to each server, but the others MUST be global.  The authentication token MUST

routing bytes.  The Server ID is unique to each server, and the routing bytes are global.  For Stream Cipher CID Routing, this consists of the Server ID, Server ID Length, Key, and Nonce Length.  The Server ID is unique to each server, but the others MUST be global.  The authentication token MUST


map to the same server.  It could then apply analytical techniques to try to obtain the server encoding. <del> The Stream and Block Cipher CID algorithms provide robust entropy to making any sort of linkage.  The Obfuscated CID obscures the mapping and prevents trivial brute-force attacks to determine the routing parameters, but does not provide robust protection against sophisticated attacks. </del>  Were this analysis to obtain the server encoding, then on-path observers might apply this analysis to correlating different client

map to the same server.  It could then apply analytical techniques to try to obtain the server encoding.  <ins> The Stream and Block Cipher CID algorithms provide robust protection against any sort of linkage.  The Plaintext CID algorithm makes no attempt to protect this encoding. </ins> Were this analysis to obtain the server encoding, then on-path observers might apply this analysis to correlating different client


To avoid this, the configuration agent SHOULD issue QUIC-LB configurations to mutually distrustful servers that have different <del> keys (for the block cipher or stream cipher algorithms) or routing masks and divisors (for the obfuscated algorithm).  The load balancers can distinguish these configurations by external IP address, or by assigning different values to the config rotation bits (config-rotation).  Note that either solution has a privay impact; see multiple-configs. </del>  These techniques are not necessary for the plaintext algorithm, as it does not attempt to conceal the server ID.

To avoid this, the configuration agent SHOULD issue QUIC-LB configurations to mutually distrustful servers that have different  <ins> keys for encryption algorithms.  The load balancers can distinguish these configurations by external IP address, or by assigning different values to the config rotation bits (config-rotation).  Note that either solution has a privacy impact; see multiple-configs. </ins> These techniques are not necessary for the plaintext algorithm, as it does not attempt to conceal the server ID.


6.3.2.1. This sub-tree defines the L2VPN service type, according to the <del> several signalling options to exchange membership information between </del>  PEs of an L2VPN.  The following signaling options are supported: <del> Refers to the BGP control plane as described in RFC4761 and RFC6624. Refers to the BGP control plane as described in RFC7432 and RFC7209. </del>  <del> Refers to LDP-signaled pseudowires RFC6074. </del>  <del> Refers to L2TP-signaled pseudowires RFC6074. </del>  6.3.2.2.

Adding a description to signaling options to improve readability. I have pending to update L2TP after the other issue is solved URL
Thanks, Victor. Does the text reflect the latest version of signaling/discovery split?
leaf l2tp-type { type identityref { base t-ldp-pwe-type; } description "T-LDP PWE type."; }
The type should be taken from this registry: URL
A new IANA-maintained module is created to fix this issue.

6.3.2.1. This sub-tree defines the L2VPN service type, according to the  <ins> several signaling options to exchange membership information between </ins> PEs of an L2VPN.  The following signaling options are supported:  <ins> The service is a Multipoint VPLSs that use a BGP control plane as described in RFC4761 and RFC6624.  For this L2VPN service, the model allows configuring the Route Distinguisher, the Route Targets, the PWE encapsulation type and the MTU configurations to allow MTU mismatch. The service is a Multipoint VPLSs that use also a BGP control plane but also includes the additional features and related parameters RFC7432 and RFC7209.  The model allows the configuration of the EVPN service interface type, the local and remote VPWS Service Instance (VSI) RFC8214, the EVPN policies for handling MAC addresses and the Ethernet Segment Identifier (ESI) information. </ins>  <ins> A Multipoint VPLSs that use a mesh of LDP-signaled Pseudowires RFC6074.  The model allows configuring the T-LDP PWE type, MTU mismatch and the list of AC and PW bindings. </ins>  <ins> The L2 VPN uses L2TP-signaled Pseudowires as described in RFC6074. The model allows configuring TBC. </ins> 6.3.2.2.


of the element and to ensure correct serialization for integrity and authenticity checks.  8.2. The Envelope contains each of the other primary constituent parts of

adds a missing digest parameter corrects CDDL for suit-text removes dangling
I have discovered this because the EAT build process pulls the SUIT CDDL in for validation using the cddl tool.
NAME posted to the list the following: I think I found a little typo in the draft-ietf-suit-manifest-14 ... At the "Appendix A. A. Full CDDL" of the "SUITSeverableMembersChoice", the last two members are pointing to "SUITCommand_Sequence" are probably typos as following,
In draft-ietf-suit-manifest-04 In the example manifest image-digest parameter is set for component 0 in common sequence. The load sequence sets component-index to 1 and after directive-copy it specifies image-match condition. However, the image-digest parameter has not been set for component-index 1 causing the condition to fail as . Is it expected that parameters are implicitly copied from source component when copy-directive is executed? Should the image-digest be also specified for component-index 1 or perhaps for all components? Another observation in the example is that vendor-id and class-id parameters and corrsponding condition checks are specified for component 0, which seems to be the "external storage". Wouldn't it be better to specify the VID and CID globally for the entire device or for the component 1, which seems to be the one running the image? / common / 3:h'a2024782814100814101045856880c0014a40150fa6b4a5 3d5ad5fdfbe9de663e4d41ffe02501492af1425695e48bf429b2d51f2ab45038202582 000112233445566778899aabbccddeeff0123456789abcdeffedcba98765432100e198 7d001f602f6' / { / components / 2:h'82814100814101' / [ [h'00'] , [h'01'] ] /, / common-sequence / 4:h'880c0014a40150fa6b4a53d5ad5fdfbe9d e663e4d41ffe02501492af1425695e48bf429b2d51f2ab450382025820001122334455 66778899aabbccddeeff0123456789abcdeffedcba98765432100e1987d001f602f6' / [ / directive-set-component-index / 12,0 , / directive-override-parameters / 20,{ / vendor-id / 1:h'fa6b4a53d5ad5fdfbe9de663e4d41ffe' / fa6b4a53-d5ad-5fdf- be9d-e663e4d41ffe /, / class-id / 2:h'1492af1425695e48bf429b2d51f2ab45' / 1492af14-2569-5e48-bf42-9b2d51f2ab45 /, / image-digest / 3:[ / algorithm-id / 2 / sha256 /, / digest-bytes / h'00112233445566778899aabbccddeeff0123456789abcdeffedcba9876543210' ], / image-size / 14:34768, } , / condition-vendor-identifier / 1,F6 / nil / , / condition-class-identifier / 2,F6 / nil / ] /, } /, (...) / load / 11:h'880c0113a1160016f603f6' / [ / directive-set-component-index / 12,1 , / directive-set-parameters / 19,{ / source-component / 22:0 / [h'00'] /, } , / directive-copy / 22,F6 / nil / , / condition-image-match / 3,F6 / nil / ] /,

of the element and to ensure correct serialization for integrity and authenticity checks. <ins> All CBOR maps in the Manifest and manifest envelope MUST be encoded with the canonical CBOR ordering as defined in RFC8949. </ins> 8.2. The Envelope contains each of the other primary constituent parts of


MUST still contain the suit-authentication-wrapper element, but the content MUST be a list containing only the SUIT_Digest.  8.4. The manifest contains:

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


explanation for the overall connection rate drop is that hairpinning failed in some cases. <del> One potential mitigation, as discussed in privacy, is to not conceal candidates created from RFC4941 IPv6 addresses.  This permits connectivity even in large internal networks or where mDNS is disabled.  Future versions of this document will include experimental data regarding this option. </del> 5.2. As noted in description, ICE agents using the mDNS technique are

Let's remove this sentence and add more information when we will have this additional experimental data
This area probably needs more experimentation in general. For instance, it is unclear how much we could partition such IPv6 addresses by origin like we ask for mDNS names. Given we already talk about this approach in the privacy section, these sentences do not feel mandatory to keep. No strong feelings either way though.
I looked at the current text more closely and I see what you are saying, especially regarding different origins. We should probably talk about the separation of origins or browsing contexts more in the introduction though. Currently it only refers to the fingerprinting threat, which could be construed to simply mean a long-term identifier.
I don't think we needed to nuke this whole section, just the future version of the document sentence.

explanation for the overall connection rate drop is that hairpinning failed in some cases.  5.2. As noted in description, ICE agents using the mDNS technique are


This document uses the Augmented BNF defined in RFC5234 and updated by RFC7405. <del> 1.2. The OpenAPI Specification Media Types convey OpenAPI Specification (OAS) files as defined in oas for version 3.0.0 and above. Those files can be serialized in JSON or yaml.  Since there are multiple OpenAPI Specification Specifications versions, those media- types support the "version" parameter. The following examples conveys the desire of a client to receive an OpenAPI Specification resource preferably in the following order: openapi 3.1 in yaml openapi 3.0 in yaml any openapi version in json </del> 2. <del> Security requirements for both media type and media type suffix registrations are discussed in Section 4.6 of MEDIATYPE. </del>  <del> 3. </del>  <del> This specification defines the following new Internet media types MEDIATYPE. 3.1. </del>  Type name: application

introduce numbered sections for YAML NAME since each media type is defined in its IANA consideration, would it be ok for you if we just add a section for YAML? Feel free to PR with another proposal.
NAME could you PTAL ? :)
to be honest, i prefer definitions to have URIs and not just registrations. but if we have URIs, that's already a lot better than not having URIs! thanks!
it's maybe just OCD (and because it's very useful for URL to have linkable references) but i think it's nice to have numbered sections for everything that's being defined in the spec. in this case, i suggest to have a numbered section for each of the four media types, and to have a brief explanation of what it identifies. that way, each definition is self-contained and can be easily referenced when necessary. NAME NAME

This document uses the Augmented BNF defined in RFC5234 and updated by RFC7405.  2.  <ins> This section describes the information required to register the above media types. </ins>  <ins> 2.1. </ins>  <ins> The following information serves as the registration form for the "application/yaml" media type. </ins> Type name: application


Change controller: n/a <del> 3.2. </del>  Type name: application

Change controller: n/a  <ins> 2.2. The OpenAPI Specification Media Types convey OpenAPI document (OAS) files as defined in oas for version 3.0.0 and above. Those files can be serialized in JSON or yaml.  Since there are multiple OpenAPI Specification versions, those media-types support the "version" parameter. The following examples conveys the desire of a client to receive an OpenAPI Specification resource preferably in the following order: openapi 3.1 in yaml openapi 3.0 in yaml any openapi version in json 2.2.1. The following information serves as the registration form for the "application/openapi+json" media type. </ins> Type name: application


Change controller: n/a <del> 3.3. </del>  Type name: application

Change controller: n/a  <ins> 2.2.2. The following information serves as the registration form for the "application/openapi+yaml" media type. </ins> Type name: application


Change controller: n/a <del> 4.  References </del>  <del> 4.1.  URIs </del>  [1] https://mailarchive.ietf.org/arch/browse/httpapi/ [2] https://github.com/ioggstream/draft-polli-rest-api-mediatypes

Change controller: n/a  <ins> 3. Security requirements for both media type and media type suffix registrations are discussed in Section 4.6 of MEDIATYPE. </ins>  <ins> 4. This specification defines the following new Internet media types MEDIATYPE. IANA has updated the "Media Types" registry at https://www.iana.org/assignments/media-types [3] with the registration information provided below. 5.  References 5.1.  URIs </ins> [1] https://mailarchive.ietf.org/arch/browse/httpapi/ [2] https://github.com/ioggstream/draft-polli-rest-api-mediatypes <ins> [3] https://www.iana.org/assignments/media-types </ins>


service, defines the types of credentials which may be used in a deployment and provides methods for: <del> Issuing new credentials, </del>  <del> Validating a credential against a reference identifier, and </del>  Validating whether or not two credentials represent the same <del> client. </del>  A *Delivery Service*, described fully in delivery-service, provides methods for:

WGLC comments on Operation Requirements section. Added several overlooked requirements
Discussed on 12/8 interim, and folks seemed fine with this. I.e., it's ready to merge.

service, defines the types of credentials which may be used in a deployment and provides methods for:  <ins> Issuing new credentials with a relevant credential lifetime, </ins>  <ins> Validating a credential against a reference identifier, </ins> Validating whether or not two credentials represent the same  <ins> client, and Optionally revoking credentials which are no longer authorized. </ins> A *Delivery Service*, described fully in delivery-service, provides methods for:


Delivering Welcome messages to new members of a group. <del> Downloading KeyPackages for specific clients, and uploading new KeyPackages for a user's own clients. </del>  Additional services may or may not be required depending on the application design:

Delivering Welcome messages to new members of a group.  <ins> Uploading new KeyPackages for a user's own clients. Downloading KeyPackages for specific clients.  Typically, KeyPackages are used once and consumed. </ins> Additional services may or may not be required depending on the application design:


set of acceptable behavior in a group.  These policies must be consistent between deployments for them to interoperate:  A policy on when to send proposals and commits in plaintext instead of encrypted.

set of acceptable behavior in a group.  These policies must be consistent between deployments for them to interoperate: <ins> A policy on which ciphersuites are acceptable. A policy on any mandatory or forbidden MLS extensions. </ins> A policy on when to send proposals and commits in plaintext instead of encrypted.


When, and under what circumstances, a reinitialization proposal is allowed. <del> When proposals from external senders are allowed. </del>  <del> When external joiners are allowed. </del>  A policy for when two credentials represent the same client.  Note that many credentials may be issued authenticating the same

When, and under what circumstances, a reinitialization proposal is allowed.  <ins> When proposals from external senders are allowed and how to authorize those proposals. When external joiners are allowed and how to authorize those external commits. Which other proposal types are allowed. A policy of when members should commit pending proposals in a group. </ins>  <ins> A policy of how to protect and share the GroupInfo objects needed for external joins. </ins> A policy for when two credentials represent the same client.  Note that many credentials may be issued authenticating the same


We need an IANA considerations section even if we make no requests of them. It's just part of the process and the section can be removed during the final publication phase.

Finally, Clients should not be able to perform DoS attacks denial-of- service. <ins> 5. This document makes no requests of IANA. </ins>


setting, HSMs and secure enclaves can be used to protect signature keys.  7.  This document makes no requests of IANA.

This PR adds a short paragraph referencing the various academic works that has gone into MLS. The references to the various works still need to be cleaned up, which I will do once the list is complete. In particular, each reference needs to be checked for correctness (eprint version vs. publicized version) and then included as informal reference in the yaml header of the document.
Is there another RFC you can point to that links academic papers on the protocol? I'd expect TLS 1.3 to be a good example of this, but I don't see them do this. The references should be cited properly if we do include it (ie, added as citations at the top of the file)
The references are in the appendices. For instance URL The reader should refer to the following references for analysis of the TLS handshake: [DFGS15], [CHSV16], [DFGS16], [KW16], [Kraw16], [FGSW16], [LXZFH16], [FG17], and [BBK17].
TLS 1.3 as cited by NAME was indeed the inspiration for this. The idea was to just have a small paragraph to point the reader in the right direction and then have the full bibliographic entry in the "Informal References" section. As noted above, I intend to properly format all the references once we agree on what references to include, as formatting them into the right yaml is a bit of a pain.
Thanks Konrad!

setting, HSMs and secure enclaves can be used to protect signature keys. <ins> 6.6. Various academic works have analyzed MLS and the different security guarantees it aims to provide.  The security of large parts of the protocol has been analyzed by [BBN19] (draft 7), [ACDT21] (draft 11) and [AJM20] (draft 12). Individual components of various drafts of the MLS protocol have been analyzed in isolation and with differing adversarial models, for example, [BBR18], [ACDT19], [ACCKKMPPWY19], [AJM20] and [ACJM20] analyze the ratcheting tree as the sub-protocol of MLS that facilitates key agreement, while [BCK21] analyzes the key derivation paths in the ratchet tree and key schedule.  Finally, [CHK19] analyzes the authentication and cross-group healing guarantees provided by MLS. </ins> 7. <ins> ACDT19: https://eprint.iacr.org/2019/1189 ACCKKMPPWY19: https://eprint.iacr.org/2019/1489 ACJM20: https://eprint.iacr.org/2020/752 AJM20: https://eprint.iacr.org/2020/1327 ACDT21: https://eprint.iacr.org/2021/1083 AHKM21: https://eprint.iacr.org/2021/1456 CHK19: https://eprint.iacr.org/2021/137 BCK21: https://eprint.iacr.org/2021/137 BBR18: https://hal.inria.fr/hal-02425247 BBN19: https://hal.laas.fr/INRIA/hal-02425229 8. </ins> This document makes no requests of IANA.


node for which this node has a private key * Decrypt the secret value for the parent of the copath node using the private key from the resolution node * Derive secret values for ancestors of that <del> node using the KDF keyed with the decrypted secret </del>  Merge the updated secrets into the tree * Replace the public keys for nodes on the direct path with the received public keys * For

Adding this check would be the first step in recognizing that an Update operation may have maliciously excluded a person from the group.
This would go better in the "Ratchet Tree Updates" section, right after "Derive secret values for ancestors of that node using the KDF keyed with the decrypted secret". That would align better with where in the code you want the checks to be. Other than that, LGTM.
Fixed
Thanks Michael !
Here's the Weekly Digest for : - - Last week 4 issues were created. Of these, 1 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 4 comments. - - Last week, 9 pull requests were created, updated or merged. Last week, 8 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 4 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .

node for which this node has a private key * Decrypt the secret value for the parent of the copath node using the private key from the resolution node * Derive secret values for ancestors of that  <ins> node using the KDF keyed with the decrypted secret * The recipient SHOULD verify that the received public keys agree with the public keys derived from the new node_secret values </ins> Merge the updated secrets into the tree * Replace the public keys for nodes on the direct path with the received public keys * For


9.1. <del> [[ OPEN ISSUE: Direct initialization is currently undefined.  A client can create a group by initializing its own state to reflect a group including only itself, then adding the initial members.  This has computation and communication complexity O(N log N) instead of the O(N) complexity of direct initialization. ]] </del>  9.2.

This is something we've been meaning to do for a while, and just haven't gotten around to. The Init message directly creates a group with a specified member list. The cost of group creation is O(N) DH operations for the sender, and O(1) for receivers.
This now has an OPEN ISSUE regarding the fact that we'll need to add PKE encryption for that message, as agreed out of band, let's merge this and add encryption in the next iteration.
Here's the Weekly Digest for : This week, 8 issues were created. Of these, 4 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :heart: , by :heart: , by :heart: , by The issue most discussed this week has been: :speaker: , by It received 9 comments. This week, no pull requests has been proposed by the users. This week, 4 users have contributed to this repository. They are , , , and . This week, no user has starred this repository. This week, there have been 4 commits in the repository. These are: :hammerandwrench: Merge pull request from rozbb/mlsplaintext-signature Multiple clarifications around Framing by :hammerandwrench: Merge pull request from rozbb/hpke-encrypt Clarify how HPKE ciphertexts are computed by :hammerandwrench: by :hammerand_wrench: by # RELEASES This week, no releases were published. That's all for this week, please watch :eyes: and star :star: to receive next weekly updates. :smiley:
Here's the Weekly Digest for : - - Last week 5 issues were created. Of these, 1 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by - - Last week, 9 pull requests were created, updated or merged. Last week, 3 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 5 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 8 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
We have a long-standing OPEN ISSUE on creating a group with a single Init message instead of N Add messages, which would change the work of initialization from O(N log N) to O(N). I would propose roughly the following: Then the processing would be: Find the welcome that's for you Initialize a one-member tree from the Welcome Use the UserInitKeys to populate the leaves of the tree Use the DirectPath to populate the creator's direct path (as in Update)
Fixed by URL
Similarly to the for a new member, this is a PKE operation: the encryption of this message is missing from the description. This message needs to be encrypted to each client otherwise it leaks all public keys of the tree which would otherwise be protected under the common framing. A secondary question appears as a consequence. There is static key reuse for the leaves until they update, we designed HPKE so that it should be fine but I would still add an [OPEN ISSUE] for it.

9.1.  <ins> A group can always be created by initializing a one-member group and using adding members individually.  For cases where the initial list of members is known, the Init message allows a group to be created more efficiently. The creator of the group constructs an Init message as follows: Fetch a UserInitKey for each member (including the creator) Identify a protocol version and cipher suite that is supported by all proposed members. Construct a ratchet tree with its leaves populated with the public keys and credentials from the UserInitKeys of the members, and all other nodes blank. Generate a fresh leaf key pair for the first leaf Compute its direct path in this ratchet tree Each member of the newly-created group initializes its state from the Init message as follows: Note the group ID, protocol version, and cipher suite in use Construct a ratchet tree as above Update the cached ratchet tree by replacing nodes in the direct path from the first leaf using the direct path Update the cached ratchet tree by replacing nodes in the direct path from the first leaf using the information contained in the "path" attribute The update secret for this interaction, used with an all-zero init secret to generate the first epoch secret, is the "path_secret[i+1]" derived from the "path_secret[i]" associated to the root node.  The members learn the relevant path secrets by decrypting one of the encrypted path secrets in the DirectPath and working back to the root (as in normal DirectPath processing). [[ OPEN ISSUE: This approach leaks the initial contents of the tree to the Delivery Service, unlike the sequential-Add case. ]] [[ OPEN ISSUE: It might be desireable for the group creator to be able to "pre-warm" the tree, by providing values for some nodes not on its direct path.  This would violate the tree invariant, so we would need to figure out what mitigations would be necessary. ]] </ins> 9.2.


information about a client that any existing member can use to add this client to the group asynchronously. <del> A ClientInitKey object specifies what ciphersuites a client supports, as well as providing public keys that the client can use for key derivation and signing.  The client's identity key is intended to be stable throughout the lifetime of the group; there is no mechanism to change it.  Init keys are intended to be used a very limited number of times, potentially once. (see init-key-reuse).  ClientInitKeys also contain an identifier chosen by the client, which the client MUST assure uniquely identifies a given ClientInitKey object among the set of ClientInitKeys created by this client. The init_keys array MUST have the same length as the cipher_suites array, and each entry in the init_keys array MUST be a public key for the asymmetric encryption scheme defined in the cipher_suites array and used in the HPKE construction for TreeKEM. The whole structure is signed using the client's identity key.  A ClientInitKey object with an invalid signature field MUST be considered malformed.  The input to the signature computation comprises all of the fields except for the signature field. </del>  8.

Here's the Weekly Digest for : - - Last week 3 issues were created. Of these, 1 issues have been closed and 2 issues are still open. :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 1 comments. - - Last week, 6 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 4 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 6 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week, no issues were created. - - Last week, 3 pull requests were created, updated or merged. Last week, 2 pull requests were updated. :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there was 1 commit. :hammerandwrench: by - - Last week there was 1 contributor. :bustin_silhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week 2 issues were created. Of these, 0 issues have been closed and 2 issues are still open. :greenheart: , by :greenheart: , by - - Last week, 2 pull requests were created, updated or merged. Last week, 2 pull requests were opened. :greenheart: , by :greenheart: , by - - Last week there were no commits. - - Last week there were no contributors. - - Last week there were 2 stagazers. :star: :star: You all are the stars! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .

information about a client that any existing member can use to add this client to the group asynchronously.  <ins> A ClientInitKey object specifies a ciphersuite that the client supports, as well as providing a public key that others can use for key agreement.  The client's identity key is intended to be stable throughout the lifetime of the group; there is no mechanism to change it.  Init keys are intended to be used a very limited number of times, ideally only once.  (See init-key-reuse).  Clients MAY generate and publish multiple ClientInitKey objects to support multiple ciphersuites, or to reduce the likelihood of init key reuse. ClientInitKeys contain an identifier chosen by the client, which the client MUST assure uniquely identifies a given ClientInitKey object among the set of ClientInitKeys created by this client. The value for init_key MUST be a public key for the asymmetric encryption scheme defined by cipher_suite.  The whole structure is signed using the client's identity key.  A ClientInitKey object with an invalid signature field MUST be considered malformed.  The input to the signature computation comprises all of the fields except for the signature field. </ins> 8.


The creator of the group constructs an Init message as follows: <del> Fetch a ClientInitKey for each member (including the creator) </del>  Identify a protocol version and cipher suite that is supported by all proposed members.

The creator of the group constructs an Init message as follows:  <ins> Fetch one or more ClientInitKeys for each member (including the creator) </ins> Identify a protocol version and cipher suite that is supported by all proposed members.


needs to initialize a GroupContext object that can be updated to the current state using the Add message.  This information is encrypted for the new member using HPKE.  The recipient key pair for the HPKE <del> encryption is the one included in the indicated ClientInitKey, corresponding to the indicated ciphersuite.  The "add_key_nonce" field contains the key and nonce used to encrypt the corresponding Add message; if it is not encrypted, then this field MUST be set to the null optional value. </del>  In the description of the tree as a list of nodes, the "credential" field for a node MUST be populated if and only if that node is a leaf

needs to initialize a GroupContext object that can be updated to the current state using the Add message.  This information is encrypted for the new member using HPKE.  The recipient key pair for the HPKE  <ins> encryption is the one included in the indicated ClientInitKey.  The "add_key_nonce" field contains the key and nonce used to encrypt the corresponding Add message; if it is not encrypted, then this field MUST be set to the null optional value. </ins> In the description of the tree as a list of nodes, the "credential" field for a node MUST be populated if and only if that node is a leaf


direct path of the new node Set the leaf node in the tree at position "index" to a new node <del> containing the public key from the ClientInitKey in the Add corresponding to the ciphersuite in use, as well as the credential under which the ClientInitKey was signed </del>  The "update_secret" resulting from this change is an all-zero octet string of length Hash.length.

direct path of the new node Set the leaf node in the tree at position "index" to a new node  <ins> containing the public key from the ClientInitKey in the Add, as well as the credential under which the ClientInitKey was signed </ins> The "update_secret" resulting from this change is an all-zero octet string of length Hash.length.


A credential (only for leaf nodes)  The conditions under which each of these values must or must not be present are laid out in views.

It seems like there's a major thing missing here, namely how the sender of a Commit transmits the new node signatures to the other members of the group. We need something like that before this lands. The most obvious approach would be to add a field to DirectPathNode, as you have with RatchetNode.
It would also be handy to include in the intermediate node an indication of which leaf signed it. Otherwise you have to do "trial verifications" (cf. trial decryption), which is expensive.
Was this addressed? it's mentioned that the signature should be transmitted in "Synchronizing Views of the Tree" but there's no signature in the transmitted DirectPathNode
NAME changes the strategy for signing the tree, everything should be sorted out there.
Here's the Weekly Digest for : - - Last week 8 issues were created. Of these, 0 issues have been closed and 8 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :speaker: , by It received 1 comments. - - Last week, 6 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 3 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 10 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week 4 issues were created. Of these, 0 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by - - Last week, 14 pull requests were created, updated or merged. Last week, 8 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 6 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 10 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 3 contributors. :bustinsilhouette: :bustinsilhouette: :bustinsilhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week 11 issues were created. Of these, 1 issues have been closed and 10 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 2 comments. - - Last week, 11 pull requests were created, updated or merged. Last week, 6 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by Last week, 4 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 2 commits. :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - Last week there were 2 stagazers. :star: :star: You all are the stars! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .

A credential (only for leaf nodes) <ins> A signature over the content of the node </ins> The conditions under which each of these values must or must not be present are laid out in views.


Zero or more encrypted copies of the path secret corresponding to the node  The path secret value for a given node is encrypted for the subtree corresponding to the parent's non-updated child, i.e., the child on the copath of the leaf node.  There is one encrypted path secret for

Zero or more encrypted copies of the path secret corresponding to the node <ins> A signature over the node content </ins> The path secret value for a given node is encrypted for the subtree corresponding to the parent's non-updated child, i.e., the child on the copath of the leaf node.  There is one encrypted path secret for


ratchet tree and the members' ClientInitKeys. The hash of a tree is the hash of its root node, which we define <del> recursively, starting with the leaves.  The hash of a leaf node is the hash of a "LeafNodeHashInput" object: </del>  <del> The content within the leaf of a ratchet tree is composed of a "ClientInitKey" when the leaf is populated.  The "info" field is equal to the null optional value when the leaf is blank (i.e., no member occupies that leaf). </del>  <del> The intermediate nodes contain less information, the hash of a parent node (including the root) is the hash of a "ParentNodeHashInput" struct: </del>  The "left_hash" and "right_hash" fields hold the hashes of the node's <del> left and right children, respectively.  The "public_key" field holds the hash of the public key stored at this node, represented as an "optional<HPKEPublicKey>" object, which is null if and only if the node is blank. </del>  7.4.

ratchet tree and the members' ClientInitKeys. The hash of a tree is the hash of its root node, which we define  <ins> recursively, starting with the leaves. While hashes at the nodes are used to check the integrity of the subtrees, signatures are required to provide authentication and group agreement.  Siganatures are especially important in the case of newcomers and MUST be verified when joining.  All nodes in the tree MUST be signed to provide authentication and group agreement. </ins>  <ins> Elements of the ratchet tree are called "RatchetNode" objects and contain optionally a "ClientInitKey" when at the leaves or an optional "ParentNode" above. </ins>  <ins> When computing the hash of a parent node AB the "ParentNodeHash" structure is used: </ins> The "left_hash" and "right_hash" fields hold the hashes of the node's  <ins> left (A) and right (B) children, respectively.  The signature within the "ParentNode" is computed over the its prefix within the serialized "ParentNodeHash" struct to cover all information about the sub-tree.  The "committer_index" is required for a member to determine the signing key needed to perform the signature verification. To compute the hash of a leaf node is the hash of a "LeafNodeHash" object: Note that unlike a ParentNode, a ClientInitKey already contains a signature. </ins> 7.4.