Negotiating Media Multiplexing Using the Session Description Protocol (SDP)
draft-ietf-mmusic-sdp-bundle-negotiation-54
Yes
(Ben Campbell)
No Objection
(Alissa Cooper)
(Alvaro Retana)
(Deborah Brungard)
(Ignas Bagdonas)
(Martin Vigoureux)
(Suresh Krishnan)
Note: This ballot was opened for revision 48 and is now closed.
Warren Kumari
No Objection
Comment
(2018-04-18 for -49)
Unknown
Adam Roach Former IESG member
Yes
Yes
(2018-04-17 for -49)
Unknown
Thanks to everyone who spent time over the past seven years getting this document complete and out the door. --------------------------------------------------------------------------- Abstract: Please indicate that the document updates RFC 7941. --------------------------------------------------------------------------- §1: > This specification updates RFC 3264 [RFC3264], to allow assigning a > zero port value to a "m=" section without meaning that the media > described by the "m=" section is disabled or rejected. This needs further qualification: the exception is very narrow, while this paragraph makes it sound like the meaning of "0" to reject a media section has been removed altogether. --------------------------------------------------------------------------- §10.2: > Applications can implement RTP stacks in many different ways. The > algorithm below details one way that RTP streams can be associated > with "m=" sections, but is not meant to be prescriptive about exactly > how an RTP stack needs to be implemented. ... > To prepare to associate RTP streams with the correct "m=" section, > the following steps MUST be followed for each BUNDLE group: This "MUST" seems to be at odds with the text about not being prescriptive. Please clarify whether the steps following this statement are prescriptive (normative) or not. --------------------------------------------------------------------------- §10.2: > Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=PSFB, > FMT=TBD). Please replace "TBD" with "10" (cf https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-9) --------------------------------------------------------------------------- §11.1: > NOTE: The following ICE-related media-level SDP attributes are > defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidate', 'remote- > candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice- > pacing'. This seems to leave "ice-options" out. --------------------------------------------------------------------------- §15.2: > applications SHALL avoid generating > the identification-tag using a pattern that enables user- or > application identification. Without some kind of recommended MID-generation algorithm, application identification will be nearly a foregone conclusion. RID makes a concrete suggestion to start with "1" and go up from there. You may want to consider doing the same thing, or at least something similar. This has an impact on §17 as well. =========================================================================== Nits =========================================================================== General: I agree with EKR that the use of "address:port" is cumbersome. For the places where this is not a stand-in for the term "'m=' section", I would suggest that the well-known term "3-tuple" would serve the purpose in a much more readable way. --------------------------------------------------------------------------- §1: > As defined in RFC 4566 [RFC4566], the semantics of assigning the same > transport address (IP address and port) to multiple "m=" sections are > undefined, and there is no grouping defined by such means. Instead, > an explicit grouping mechanism needs to be used to express the > intended semantics. This specification provides such an extension. This reads as if the present document is going to define semantics associated with having the same port and address associated with a multiple m-lines. I think this was true of BUNDLE at some point in its history, but the present mechanism uses port=0/bundle-only rather than duplicate port numbers. The preceding paragraph probably needs to be heavily edited or -- more likely -- removed. --------------------------------------------------------------------------- §3: Please consider updating to use RFC 8174 boilerplate. --------------------------------------------------------------------------- §6: > The offerer and answerer assign a zero > port value and includes an SDP 'bundle-only' attribute to every other > bundled "m=" section. "...and include..." --------------------------------------------------------------------------- §8.3.4: > it MUST first check the following criteria: "...criterion:" > If the criteria above is fulfilled, the answerer can not reject the "If the criterion..." --------------------------------------------------------------------------- §8.3.5: > o=bob 2808844564 2808844564 IN IP6 2001:db8::3 ... > c=IN IP6 2001:db8::3 As this is supposed to be an answer to the offer in §8.2.2, please select a different address for the answerer than the offerer. --------------------------------------------------------------------------- §11.1: > When an answerer assigns a BUNDLE address to an "m=" section within a > BUNDLE group (the "m=" section represented by the answerer BUNDLE- > tag), the answerer onlys include SDP 'candidate' attributes (and Nit: "...only includes..." --------------------------------------------------------------------------- §12: > o If the DTLS client supports DTLS-SRTP [RFC5764] it MUST include > the 'use_srtp' extension [RFC5764] in the DTLS ClientHello message > [RFC5764]. The client MUST include the extension even if the > usage of DTLS-SRTP is not negotiated as part of the multimedia > session (e.g., SIP session [RFC3261]. Fix missing closing paren. --------------------------------------------------------------------------- §14.3 & §14.4: The update described by these sections appears unnecessary, as the original text does not preclude the additional meaning assigned to port=0 by this document. If this has already been discussed, I don't want to revisit WG consensus; but, if not, I would recommend removing these sections as superfluous. ---------------------------------------------------------------------------
Ben Campbell Former IESG member
Yes
Yes
(for -48)
Unknown
Spencer Dawkins Former IESG member
Yes
Yes
(2018-04-16 for -49)
Unknown
Thanks for doing this work. It's important. I wonder if it's worth adding a mention of https://tools.ietf.org/html/rfc7657 as an Informational reference, because bundling makes it easier for you to shoot yourself in the foot by using different DSCP codepoints for different packets carried on a single 5-tuple. If there's a better document to point that out to people who are considering using bundling for their applications, that's a fine answer ...
Alexey Melnikov Former IESG member
No Objection
No Objection
(2018-04-16 for -49)
Unknown
8.1. Multiplex Category Considerations When a BUNDLE group is initially negotiated, and a unique address:port is assigned to each bundled "m=" section (excluding any bundle-only "m=" section) in the initial offer [Section 8.2], any IDENTICAL and TRANSPORT mux category SDP attributes included in the BUNDLE group MUST explicitly be included in each bundled "m=a€œ section (excluding any bundle-only "m=" sections). HTML encoding is not really readable in plain text. Please add a reference on first mention of UTF-8.
Alissa Cooper Former IESG member
No Objection
No Objection
(for -49)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -49)
Unknown
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2018-04-13 for -49)
Unknown
Should the NOTE in Section 8.5.2 explicitly reaffirm that only one m= section within the BUNDLE group can have the offerer BUNDLE address:port, regardless of whether it is a new or preexisting address:port? That is, that you cannot use an existing BUNDLE address:port and offer a new one in the same BUNDLE group. When we talk about how the offerer must move a section out of one BUNDLE group and then generate a second offer where that section is added to the other BUNDLE group (this occurs in several places, IIRC), do we need to say anything about the offer that moves the section out of the first BUNDLE group must be accepted before the second offer is offered? In Section 10.2, page 23, I appreciate the description of the payload type/m= mapping used by legacy implementations, but I worry that there may not be sufficient description of when an SDP participant should take the care to ensure the uniqueness of the mapping (versus when the legacy considerations can be ignored). Does the first paragraph of Section 10.3.1.2 imply that an implementation of BUNDLE must also implement rtcp-mux-only? Should the RTP SDES header extension URI be mentioned somewhere other than the IANA considerations? In Section 17: The security considerations of "RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items" [RFC7941] requires that when RTCP is confidentiality protected, and that any SDES RTP header extension carrying an SDES item, such as the MID RTP header extension, is also protected using commensurate strength algorithms. "that when [...], and that" seems the wrong construction here; I think that just "that when [...]," is the intended meaning.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -49)
Unknown
Eric Rescorla Former IESG member
(was Discuss)
No Objection
No Objection
(2018-05-19 for -51)
Unknown
Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3382 This is really vastly better. Thanks for making the changes. I have made a few notes of things that I still think are problematic, but I am clearing my DISCUSS. IMPORTANT S 7.3.5. > a zero port value to, the video "m=" section. > > SDP Answer > > v=0 > o=bob 2808844564 2808844564 IN IP6 2001:db8::1 This doesn't sound right. You can't use the existing address:port, because if the peer rejects BUNDLE but accepts the m= section then it's broken. S 9.3.1.2. > > 9.3.1.2. Generating the SDP Answer > > When an answerer generates an answer, if the answerer supports RTP- > based media, and if a bundled "m=" section in the corresponding offer > contained an SDP 'rtcp-mux' attribute, the answerer MUST enable usage This does not define how to interact with trickle ICE. COMMENTS > > Negotiating Media Multiplexing Using the Session Description Protocol > (SDP) > draft-ietf-mmusic-sdp-bundle-negotiation-51.txt > > Abstract This document is quite a bit improved from when I read it before, but it's still very confusing. The primary problem here is the repeated use of "address;port" as synechdoche for the m= section which is the "head" of the BUNDLE group (i.e., that which is indicated by the BUNDLE-tag). That's not what's going on and it's misplaced concreteness. I would invent some new term ("head" is actually not bad) and then use it throughout for this concept. S 1.2. > transport) for sending and receiving media (bundled media) described > by multiple SDP media descriptions ("m=" sections). The address:port > combination used by an endpoint for sending and receiving bundled > media is referred to as the BUNDLE address:port. The set of SDP > attributes that are applied to each "m=" section within a BUNDLE > group is referred to as BUNDLE attributes. The same BUNDLE transport Nit: "pair"? S 1.2. > group is referred to as BUNDLE attributes. The same BUNDLE transport > is used for sending and receiving bundled media, which means that the > symmetric Real-time Transport Protocol (RTP) mechanism [RFC4961] is > always used for RTP-based bundled media. > > This specification defines a new SDP Grouping Framework [RFC5888] Why is one of these called "address" and the other "address:port"? S 1.2. > Interactive Connectivity Establishment (ICE) > [I-D.ietf-ice-rfc5245bis] candidates for the whole BUNDLE group. > > A given BUNDLE address:port MUST only be associated with a single > BUNDLE group. If an SDP offer or answer contains multiple BUNDLE > groups, the procedures in this specification apply to each group 1. Bundle lets you have multiple SDP m= sections on a single 5-tuple 2. The underling mechanism here is that you put those m= sections in the same BUNDLE group 3. In order to facilitate demuxing, we define a new RTP extension for MID. 4. It is sometimes desirable to say that an m= section should only be negotiated if it can be bundled. This is done with port=0 and a =bundle-only. S 1.2. > Interactive Connectivity Establishment (ICE) > [I-D.ietf-ice-rfc5245bis] candidates for the whole BUNDLE group. > > A given BUNDLE address:port MUST only be associated with a single > BUNDLE group. If an SDP offer or answer contains multiple BUNDLE > groups, the procedures in this specification apply to each group This section is kind of a laundry list. I think it would be helpful to break it out conceptually. Specifically. 1. 2. 3. S 1.3. > SDES header extension that can be used to associate RTP streams > with "m=" sections. > > o The specification updates [RFC7941], by adding an exception, for > the MID RTP header extension, to the requirement regarding > protection of an SDES RTP header extension carrying an SDES item Was this intended to be a bullet? S 2. > > o BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category > SDP attributes. Once a BUNDLE group has been created, the > attribute values apply to each bundled "m=" section within the > BUNDLE group. > This is a very idiosyncratic definition, because it's *not* the first offer in the session, but the one where the BUNDLE group is introduced. Given that 3264 has a different meaning for this same term, and the difference is critical, I would strongly urge you to pick a different term. S 2. > o Bundle-only "m=" section: A bundled "m=" section that contains an > SDP 'bundle-only' attribute. > > o Bundled media: All media associated with a given BUNDLE group. > > o Initial offer: The first offer, within an SDP session (e.g. a SIP This appears still not to be resolved. Here is the 3264 definition " Protocol operation begins when one agent sends an initial offer to another agent. An offer is initial if it is outside of any context that may have already been established through the higher layer protocol." I'm not making this part of my DISCUSS, but I think it's very confusing and I would strongly urge the AD to address it. S 2. > BUNDLE group is created once the answerer sends the initial > answer. > > o Subsequent offer: An offer which contains a BUNDLE group that has > been created as part of a previous offer/answer exchange. > How about "is part of" instead of "associated with" S 2. > been created as part of a previous offer/answer exchange. > > o Subsequent answer: An answer to a subsequent offer. > > o Identification-tag: A unique token value that is used to identify > an "m=" section. The SDP 'mid' attribute [RFC5888] in an "m=" Again "part of" S 5. > a semantics value [RFC5888] of "BUNDLE". An identification-tag is > assigned to each bundled "m=" section, and each identification-tag is > listed in the SDP 'group:BUNDLE' attribute identification-tag list. > Each "m=" section whose identification-tag is listed in the > identification-tag list is associated with a given BUNDLE group. > I would put some of this text up before the attribute definition to explain why the attribute exists. S 7. > rejected by the answerer, the previously negotiated addresses:ports, > SDP parameters and characteristics (including those associated with a > BUNDLE group) apply. Hence, if an offerer generates an offer in > order to negotiate a BUNDLE group, and the answerer rejects the > offer, the BUNDLE group is not created. > Multiplexing? S 7. > "m=" line proto value assigned to a bundled "m=" section. Section 9 > defines additional considerations for RTP based media. Section 6 > defines additional considerations for the usage of the SDP 'bundle- > only' attribute. Section 10 defines additional considerations for > the usage of Interactive Connectivity Establishment (ICE) > [I-D.ietf-ice-rfc5245bis] mechanism. Something bad happened here with your editor. S 7. > the usage of Interactive Connectivity Establishment (ICE) > [I-D.ietf-ice-rfc5245bis] mechanism. > > Offers and answers can contain multiple BUNDLE groups. The > procedures in this section apply independently to a given BUNDLE > group. This is pretty opaque. It's not that the address:port pair have been selected but rather that BUNDLE has been negotiated for that m= section (though of course the address:port being selected is a side effect of this). S 7.1.1. > attribute values have been assigned to each bundled "m=" section. > > 7.1.1. Connection Data (c=) > > The "c=" line nettype value [RFC4566] associated with a bundled "m=" > section MUST be 'IN'. It seems like you should define bundled "m=" section. I believe it's one that appears in a bundle tag? S 7.1.1. > > 7.1.1. Connection Data (c=) > > The "c=" line nettype value [RFC4566] associated with a bundled "m=" > section MUST be 'IN'. > Huh? This is section 8.1. This whole paragraph is a mess. I would say "One consequence of these rules is that because SDP attributes which are appropriate only to some other m= section may appear in the m= section indicated by the BUNDLE-tag. For instance, the BUNDLE-tag may indicate a data channel but contain the 'rtcp-mux' attribute because that applies to an RTP m= section that is part of the BUNDLE group" S 7.1.2. > with each "m=" section. > > NOTE: Extensions to this specification can specify usage of the > BUNDLE mechanism for other nettype and addrtype values than the ones > listed above. > This sentence is ungrammatical. "In order to negotiate a BUNDLE group in an initial offer, the offerer MUST" S 7.1.3. > > An offerer and answerer MUST include SDP attributes in every bundled > "m=" section where applicable, following the normal offer/answer > procedures for each attribute, with the following exceptions: > > o In the initial offerer, the offerer MUST NOT include IDENTICAL and initial offer S 7.1.3. > "m=" section where applicable, following the normal offer/answer > procedures for each attribute, with the following exceptions: > > o In the initial offerer, the offerer MUST NOT include IDENTICAL and > TRANSPORT multiplexing category SDP attributes (BUNDLE attributes) > in bundle-only "m=" sections. The offerer MUST included such MUST include S 7.1.3. > attributes in all other bundled "m=" sections. In the initial > offer each bundled "m=" line can contain a different set of BUNDLE > attributes, and attribute values. Once the offerer tagged "m=" > section has been selected, the BUNDLE attributes contained in the > offerer tagged "m=" section will apply to each bundled "m=" > section within the BUNDLE group. I would reorder these, because the zero port is the main semantic. S 7.1.3. > tagged "m=" section). The offerer and answerer MUST NOT include > such attributes in any other bundled "m=" section. The BUNDLE > attributes contained in the tagged "m=" section will apply to each > bundled "m=" section within the BUNDLE group. > > o In an offer (initial or subsequent), or in an answer (initial or Why is this an "If"? There are only two choices: "unique" and "zero". Just put this graf up before the discussion of bundle-only and you can remove the conditional S 7.2. > within the BUNDLE group does describe RTP-based media). > > 7.2. Generating the Initial SDP Offer > > When an offerer generates an initial offer, in order to negotiate a > BUNDLE group, it MUST: I would say "believes" rather than "assumes" S 7.2. > within the negotiated BUNDLE group, the offerer MUST: > > o Include an SDP 'bundle-only' attribute [Section 7.2.1] in the "m=" > section; and > > o Assign a zero port value to the "m=" section. Line breaks between the m= sections would help here. S 7.2. > section, but does not include an SDP 'bundle-only' attribute in the > "m=" section, it is an indication that the offerer wants to disable > the "m=" section [Section 7.5.3]. > > [Section 7.2.2] and [Section 17.1] show an example of an initial > offer. Comma not needed here. Also, this negative phrasing is hard to follow. I would say "MUST only ... if" here and below S 7.2.1. > In the initial offer, the bundled "m=" section indicated by the > offerer BUNDLE-tag is the suggested offerer tagged "m=" section. The > address:port combination associated with the "m=" section will be > used by the offerer for sending and receiving bundled media if the > answerer selects the "m=" section as the offerer tagged "m=" section > [Section 7.3.1]. In addition, if the answerer selects the "m=" This bullet is unnecessary as it immediately follows from the preoceeding bukllet. S 7.2.1. > section as the offerer tagged "m=" section, the BUNDLE attributes > included in the "m=" section will be applied to each "m=" section > within the negotiated BUNDLE group. > > The offerer MUST NOT suggest a bundle-only "m=" section as the > offerer tagged "m=" section. This isn't right, because each BUNDLE group has its own address:port, so instead "For each BUNDLE group" contained in the offer. More importantly, it's not the address:port that the answerer chooses, but rather the m= section. I.e., o Determine the first m= section in the BUNDLE group which will be BUNDLEd in the answer o Select an answerer BUNDLE address:port S 7.3. > a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid > > 7.3. Generating the SDP Answer > > When an answerer generates an answer (initial or subsequent) that > contains a BUNDLE group the following general SDP grouping framework Again, this isn't selecting the address:port but rather the m=section S 7.3. > section using the procedures in Section 7.3.1. In case of a > subsequent answer, the offerer tagged "m=" section is indicated in > the corresponding subsequent offer, and MUST NOT be changed by the > answerer; and > > o Select the answerer tagged "m=" section [Section 7.3.2]; and This repeats text in S 8.3. S 7.3. > > o Include SDP attributes in the bundled "m=" sections following the > rules in [Section 7.1.3]; and > > o Include an SDP 'group:BUNDLE' attribute in the answer; and > This text is baffling. As far as I can see, the first condition is "don't pick it as the head m= section if you intend to move it out". The second is some entirely different case. Can you rewrite it so it makes sense. S 7.3. > group, it MUST: > > o Move the "m=" section out of the BUNDLE group [Section 7.3.3]; or > > o Reject the "m=" section [Section 7.3.4]. > No comma S 7.3.1. > value, but the "m=" section does not contain an SDP 'bundle-only' > attribute, it is an indication that the offerer wants to disable the > "m=" section [Section 7.5.3]. > > 7.3.1. Answerer Selection of Offerer tagged 'm=' section > This is the third time you have said this. If you want to say it here, say "Because ..., if" S 7.3.1. > o The answerer will not reject the "m=" section [Section 7.3.4]; and > > o The "m=" section does not contain a zero port value. > > If all of the criteria above are fulfilled, the answerer MUST select > the "m=" section as the offerer tagged "m=" section. Same comment here as above. These are entirely different conditions. S 7.3.1. > o The "m=" section does not contain a zero port value. > > If all of the criteria above are fulfilled, the answerer MUST select > the "m=" section as the offerer tagged "m=" section. > > If one or more of the criteria are not fulfilled, the answerer MUST "criteria... are" S 7.3.1. > indicated by that identification-tag. If there are no more > identification-tags in the identification-tag list, the answerer MUST > NOT create the BUNDLE group. Unless the answerer rejects the whole > offer, the answerer MUST apply the answerer procedures for moving an > "m=" section out of a BUNDLE group [Section 7.3.3] or rejecting an > "m=" section within a BUNDLE group [Section 7.3.4] to every bundled No comma S 7.3.2. > 7.3.2. Answerer Selection of Answerer tagged 'm=' section > > The answerer MUST select the "m=" section in that corresponds to the > selected offerer tagged "m=" section in the corresponding offer > [Section 7.3.1] as the answerer tagged "m=" section. In the answer > the answerer BUNDLE-tag indicates the answerer tagged "m=" section. I'm having trouble reading this paragraph. How do you select an m= section that correspond to the selected m= section. S 7.3.3. > has been negotiated, a bundled "m=" section can not be moved out of > the BUNDLE group in an answer. Instead an offer is needed. > > When the answerer generates an answer, in which it moves a bundled > "m=" section out of a BUNDLE group, the answerer: > Please put line breaks in between m= sections here too S 7.3.3. > > o MUST include any applicable SDP attribute in the "m=" section, > using the normal offer/answer procedures for the each Attributes; > and > > o MUST NOT place the identification-tag associated with the "m=" address:port, again. It's the m=section that's relevant. S 7.3.3. > list associated with the BUNDLE group. > > o MUST NOT include an SDP 'bundle-only' attribute to the "m=" > section; and > > Because an answerer is not allowed to move an "m=" section from one "each" -> "an given" S 7.3.4. > another BUNDLE group [Section 7.5.1]. > > 7.3.4. Rejecting a Media Description in a BUNDLE Group > > When an answerer wants to reject a bundled "m=" section in an answer, > it MUST first check the following criterium: criterion would be more standard English. criterium generally refers to a bike race S 7.3.4. > the procedures in [RFC3264]; and > > o MUST NOT place the identification-tag associated with the "m=" > section in the SDP 'group:BUNDLE' attribute identification-tag > list associated with the BUNDLE group; and > Again it would make more sense to describe this as suggesting a new m= section. S 7.5. > > o Pick one bundled "m=" section as the offerer tagged "m=" section. > The offerer can either pick the "m=" section that was previously > selected by the answerer as the offerer tagged "m=" section, or > pick another bundled "m=" section within the BUNDLE group; and > Are you sure disable -> port 0, as opposed to "inactive" S 7.5.1. > > 7.5.1. Adding a Media Description to a BUNDLE group > > When an offerer generates a subsequent offer, in which it wants to > add a bundled "m=" section to a previously negotiated BUNDLE group, > the offerer follows the procedures in [Section 7.5]. The offerer You should make clear that it's not possible to have an added m= section that the peer can take as bundled or not. S 8.1. > correct protocols. > > 8.1. STUN, DTLS, SRTP > > Section 5.1.2 of [RFC5764] describes a mechanism to identify the > protocol of a received packet among the STUN, DTLS and SRTP protocols Nit "the correct" S 9.2. > If the RTCP packet is a feedback request that includes target > SSRC(s), for each target SSRC that is found in the outgoing SSRC > table, deliver a copy of the RTCP packet to the "m=" section > associated with that SSRC. PSFB and RTPFB types that are handled > in this way include: > associates -> includes S 9.3.1.2. > section, following the procedures for BUNDLE attributes > [Section 7.1.3]. In addition, if the "m=" section that is selected > as the offerer tagged "m=" section contained an SDP "rtcp-mux-only" > attribute, the answerer MUST include an SDP "rtcp-mux-only" attribute > in the answerer tagged "m=" section. > You should rewrite this graf and the one below to be about BUNDLED- ness not port assignment. I.e., if you are definitely bundled, willing to bundle, or not bundled. S 9.3.1.2. > > If the usage of RTP/RTCP multiplexing within a BUNDLE group has been > negotiated in a previous offer/answer exchange, the answerer MUST > include an SDP 'rtcp-mux' attribute in the answerer tagged "m=" > section . It is not possible to disable RTP/RTCP multiplexing within > a BUNDLE group. Same point here as above. Talking about address:port isn't helpful.
Ignas Bagdonas Former IESG member
No Objection
No Objection
(for -49)
Unknown
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -49)
Unknown
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2018-04-18 for -49)
Unknown
Maybe also briefly say in the abstract how/why RFC7941 is updated.
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -49)
Unknown