jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-rtcweb-jsep

Commentary: Section 3.2 has a paragraph starting " Lastly , while the actual media parameters are only know after an offer ... " ; the entire contents of this paragraph appear to be actually false if both ICE and DTLS are in use . I know there 's conversation underway on MMUSIC and the WebRTC mailing lists on this topic , but none of them have yet described a situation in which this paragraph is actually true . Please remove it or add a sequence diagram showing how it arises . 
 It may not be able to receive media ( due to lack of DTLS fingerprint ) , but it can certainly receive ICE checks . We should clarify accordingly .
Paragraph (version A):
Lastly, while the exact media parameters are only known only after an
offer and an answer have been exchanged, it is possible for the
offerer to receive media after they have sent an offer and before
they have received an answer.  To properly process incoming media in
this case, the offerer's media handler must be aware of the details
of the offer before the answer arrives.
Paragraph (version B):
Lastly, while the exact media parameters are only known only after an
offer and an answer have been exchanged, the offerer may receive ICE
checks, and possibly media (e.g., in the case of a re-offer after a
connection has been established) before it receives an answer.  To
properly process incoming media in this case, the offerer's media
handler must be aware of the details of the offer before the answer
arrives.
Paragraph (version A):
When creating offers, the transceiver direction is directly reflected
in the output, even for reoffers.  When creating answers, the
transceiver direction is intersected with the offered direction, as
explained in the sec.generating-an-answer section below.
Paragraph (version B):
When creating offers, the transceiver direction is directly reflected
in the output, even for re-offers.  When creating answers, the
transceiver direction is intersected with the offered direction, as
explained in the sec.generating-an-answer section below.
Draft: draft-ietf-rtcweb-jsep

Commentary: BLOCKER : The first bullet on page 37 says that port 9 " MUST be used , " which contradicts the behavior required of BUNDLE - only sections ( for which port 0 MUST be used ) . Clarify . 
 Yes - we need to indicate that bundle - only sections use 0 instead of 9 .
Paragraph (version A):
The port value is set to the port of the default ICE candidate for
this m= section, but given that no candidates are available yet,
the "dummy" port value of 9 (Discard) MUST be used, as indicated
in I-D.ietf-ice-trickle, Section 5.1.
Paragraph (version B):
If the m= section is marked as bundle-only, then the port value
MUST be set to 0.  Otherwise, the port value is set to the port of
the default ICE candidate for this m= section, but given that no
candidates are available yet, the "dummy" port value of 9
(Discard) MUST be used, as indicated in I-D.ietf-ice-trickle,
Section 5.1.
Draft: draft-ietf-rtcweb-jsep

Commentary: BLOCKER : The first bullet on page 70 exhibits the same error . 
 Maybe I am just dumb but I am not seeing this in the text . 
 Sorry , I mis - entered this one . This is regarding media directionality again . 
 PTAL and see if there 's anything from that we need to do here .
Paragraph (version A):
If the directional attribute is of type "recvonly" or
"inactive", stop transmitting all RTP media, but continue
sending RTCP, as described in RFC3264, Section 5.1.
Paragraph (version B):
If the directional attribute in the answer indicates that the
JSEP implementation should not be sending media ("recvonly" for
local answers, "sendonly" for remote answers, or "inactive" for
either type of answer) stop transmitting all RTP media, but
continue sending RTCP, as described in RFC3264, Section 5.1.
Draft: draft-ietf-rtcweb-jsep

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

Commentary: The bullets on page 45 use the construct " MUST only " three times . This is confusing , and likely to lead to implementors doing the wrong thing . Please rewrite in the form " The ' a = rtcp ' line MUST NOT be unless ... " 
 In the section " Subsequent Offers " we have the text o The RTCP feedback extensions MUST only include those that are present in the most recent answer . o The " a = rtcp " line MUST only be if the most recent answer did not include an " a = rtcp - mux " line . o The " a = rtcp - mux " line MUST only be if present in the most recent answer . Next step - Rewrite as adam suggested . 
 This works for me .
Paragraph (version A):
The "a=rtcp" line MUST only be added if the most recent answer did
not include an "a=rtcp-mux" line.
Paragraph (version A):
The "a=rtcp-mux" line MUST only be added if present in the most
recent answer.
Paragraph (version A):
The "a=rtcp-rsize" line MUST only be added if present in the most
recent answer.
Paragraph (version B):
The "a=rtcp" line MUST NOT be added if the most recent answer
included an "a=rtcp-mux" line.
Paragraph (version B):
The "a=rtcp-mux" line MUST NOT be added unless present in the most
recent answer.
Paragraph (version B):
The "a=rtcp-rsize" line MUST NOT be added unless present in the
most recent answer.
Draft: draft-ietf-rtcweb-jsep

Commentary: Section 3.3 , paragraph 3 is an example of text that should have been removed with SDP munging . Please remove it . 
 Munging remote SDP is still allowed , but I agree that we do n't need to get into the mechanics of how to do it . Agree this para should be removed , and the last para reworked accordingly .
Paragraph (version A):
However, to simplify Javascript processing, and provide for future
flexibility, the SDP syntax is encapsulated within a
SessionDescription object, which can be constructed from SDP, and be
serialized out to SDP.  If future specifications agree on a JSON
format for session descriptions, we could easily enable this object
to generate and consume that JSON.
Paragraph (version A):
Other methods may be added to SessionDescription in the future to
simplify handling of SessionDescriptions from Javascript.  In the
meantime, Javascript libraries can be used to perform these
manipulations.
Paragraph (version A):
Note that most applications should be able to treat the
SessionDescriptions produced and consumed by these various API calls
as opaque blobs; that is, the application will not need to read or
change them.
Paragraph (version B):
However, to provide for future flexibility, the SDP syntax is
encapsulated within a SessionDescription object, which can be
constructed from SDP, and be serialized out to SDP.  If future
specifications agree on a JSON format for session descriptions, we
could easily enable this object to generate and consume that JSON.
Paragraph (version B):
As detailed below, most applications should be able to treat the
SessionDescriptions produced and consumed by these various API calls
as opaque blobs; that is, the application will not need to read or
change them.
Draft: draft-ietf-rtcweb-jsep

Commentary: The bullet in the middle of page 66 ( starting " For each specified media format ... " ) states that unsupported media formats must be ignored . The following bullet specifies that " rtx " media formats that refer to " primary payload types [ that ] are not present " MUST result in an error . Read naïvely , implementors may very well discard a payload type for lack of understanding , and then discover an " rtx " for that discarded PT , and generate an error ( " it 's not present ! " ) . These bullets need additional text regarding how they interact with each other . 
 LGTM with comment
Paragraph (version A):
For each specified "rtx" media format, establish a mapping
between the RTX payload type and its associated primary payload
type, as described in RFC4588, Section 4.  If any referenced
primary payload types are not present, this MUST result in an
error.
Paragraph (version B):
For each specified "rtx" media format, establish a mapping
between the RTX payload type and its associated primary payload
type, as described in RFC4588, Section 4.  If any referenced
primary payload types are not present, this MUST result in an
error.  Note that RTX payload types may refer to primary
payload types which are not supported by the local media
implementation, in which case, the RTX payload type MUST also
be ignored.
Draft: draft-ietf-rtcweb-jsep

Commentary: Page 67 contains the acronym " DTX " without expanding it . Please expand it .
Paragraph (version B):
Silence suppression, also known as discontinuous transmission
("DTX"), can reduce the bandwidth used for audio by switching to a
special encoding when voice activity is not detected, at the cost of
some fidelity.
Paragraph (version A):
offer.  This option allows the endpoint to significantly reduce the
amount of audio bandwidth it receives, at the cost of some fidelity,
depending on the quality of the remote VAD algorithm.
Paragraph (version B):
offer.
Paragraph (version A):
For each specified "CN" media format, enable DTX for all
supported media formats with the same clockrate, as
described in RFC3389, Section 5, except for formats that
have their own internal DTX mechanisms.  DTX for such
formats (e.g., Opus) is controlled via fmtp parameters, as
discussed in sec.voiceactivitydetection1.
Paragraph (version B):
For each specified "CN" media format, enable silence
suppression for all supported media formats with the same
clockrate, as described in RFC3389, Section 5, except for
formats that have their own internal silence suppression
mechanisms.  Silence suppression for such formats (e.g.,
Opus) is controlled via fmtp parameters, as discussed in
sec.voiceactivitydetection1.
Draft: draft-ietf-rtcweb-jsep

Commentary: BLOCKER : The final bullet of page 68 refers to answer directionality of " sendrecv " and " sendonly . " These are incorrect when applying remote answers , for which these should be " sendrecv " and " recvonly . " Please rephrase in terms of whether media is to be sent , or fix in some other way that does n't get the sense reversed for remote answers .
Paragraph (version A):
If the directional attribute in the answer is of type
"sendrecv" or "sendonly", choose the media format to send as
the most preferred media format from the remote description
that is also present in the answer, as described in RFC3264,
Sections 6.1 and 7, 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
specified in RFC7160, Section 3.1.
Paragraph (version B):
If the directional attribute in the answer indicates that the
JSEP implementation should be sending media ("sendonly" for
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
also present in the answer, as described in RFC3264, Sections
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
specified in RFC7160, Section 3.1.
Draft: draft-ietf-rtcweb-jsep

Commentary: BLOCKER : The second bullet on page 43 ( " If an RtpTranceiver has been stopped and is associated ... " is normative and redundant with ( and slightly contradictory to ) the bullet on page 44 starting " If any RtpTranceiver has been slopped ... " ) which is also normative . Remove one . 
 Looks like an editorial oversight . I 'm inclined to remove the second instance . as FYI 
 BLOCKER : The bullet at the bottom of of page 42 ( " If any RtpTranceiver has been ... " ) is normative and redundant with the bullet in the middle of page 44 ( " If any RtpTranceiver has been ... " ) , which is also normative . Remove one . 
 Agreed . Let 's remove the second one . as FYI
Paragraph (version A):
If any RtpTransceiver has been added, and there exists an m=
section with a zero port in the current local description or the
current remote description, that m= section MUST be recycled by
generating an m= section for the added RtpTransceiver as if the m=
section were being added to the session description, placed at the
same index as the m= section with a zero port.
Paragraph (version B):
If any RtpTransceiver has been added, and there exists an m=
section with a zero port in the current local description or the
current remote description, that m= section MUST be recycled by
generating an m= section for the added RtpTransceiver as if the m=
section were being added to the session description (including a
new MID value), and placing it at the same index as the m= section
with a zero port.
Paragraph (version A):
If any RtpTransceiver has been stopped, the port MUST be set to
zero and all "a=msid" lines MUST be removed.
Paragraph (version A):
If any RtpTransceiver has been added, and there exists a m=
section with a zero port in the current local description or the
current remote description, that m= section MUST be recycled by
generating a m= section for the added RtpTransceiver as if the m=
section were being added to session description, except that
instead of adding it, the generated m= section replaces the m=
section with a zero port.  The new m= section MUST contain a new
MID.
Draft: draft-ietf-rtcweb-jsep

Commentary: Section 7 does not acknowledge IPv6 . The IAB statement on IPv6 a recommendation that all protocol specifications have IPv6 examples in them . Since we have a separate example document , and Suhas has indicated that he will be including some IPv6 examples in it , I think you can get away in this document by amending the final paragraph of section 7 as : " More examples of SDP for WebRTC call flows , including examples of IPv6 addresses , can be found in [ I - D.ietf - rtcweb - sdp ] . " I make no promise that other IESG members will find this sufficient , but I 'm personally okay with it .
Paragraph (version A):
More examples of SDP for WebRTC call flows can be found in I-
D.nandakumar-rtcweb-sdp.
Paragraph (version B):
More examples of SDP for WebRTC call flows, including examples with
IPv6 addresses, can be found in I-D.nandakumar-rtcweb-sdp.
Draft: draft-ietf-rtcweb-jsep

Commentary:  's concern here was that the local description could never be invalid , since it was generated by the implementation . 
 Correct . I think you need to either remove setLocal or do : parse and ( if setRemote , choke one error ) . 
 Editor discussion : this paragraph seems redundant so just remove it ? to look . 
 - ready for re - review 
 Section 5.7 , first paragraph : similar to above , change " setLocal / RemoteDescription " to " setRemoteDescription . " 
 Section Parsing a Session Description Text is When a SessionDescription of any type is supplied to setLocal/ RemoteDescription , the implementation must parse it and reject it if it is invalid . The exact details of this process are explained below . Fix as adam sugested
Paragraph (version A):
When a SessionDescription of any type is supplied to setLocal/
RemoteDescription, the implementation must parse it and reject it if
it is invalid.  The exact details of this process are explained
below.
Draft: draft-ietf-rtcweb-jsep

Commentary: Page 41 contains a statement reading " This promotes readability , " which might be read by some as promoting machine parsing rather than troubleshooting . I propose replacing " readability " with " troubleshooting . " 
 Full text : Attributes which SDP permits to either be at the session level or the media level SHOULD generally be at the media level even if they are identical . This promotes readability , especially if one of a set of initially identical attributes is subsequently changed . I 'm not sure that ' troubleshooting ' is the exact word we 're looking for here , but I think we can come up with something .
Paragraph (version A):
Attributes which SDP permits to either be at the session level or the
media level SHOULD generally be at the media level even if they are
identical.  This promotes readability, especially if one of a set of
initially identical attributes is subsequently changed.
Paragraph (version B):
Attributes which SDP permits to either be at the session level or the
media level SHOULD generally be at the media level even if they are
identical.  This assists development and debugging by making it
easier to understand individual media sections, especially if one of
a set of initially identical attributes is subsequently changed.
Draft: draft-ietf-rtcweb-jsep

Commentary: It seems like there are two implementation strategies here : a parsed version -parse . I think we probably could dispense with this sentence , but I do n't object to it , because I think of " lookup in cache " as " parse " . 
 Knowing how things go in the real world , I 'm a bit reluctant to make this change , but it should address  's concern .
Paragraph (version A):
Next, the SessionDescription is parsed into a data structure, as
described in the sec.parsing-a-desc section below.  If parsing
fails for any reason, processing MUST stop and an error MUST be
returned.
Paragraph (version B):
Next, the SessionDescription is parsed into a data structure, as
described in the sec.parsing-a-desc section below.
Draft: draft-ietf-rtcweb-jsep

Commentary: … eless . 
 Section 5.2.1 contains the statement " both ' o= ' and ' s= ' are meaningless " -- this should be qualified with " in JSEP . " These fields are not generally meaningless in all uses of SDP . 
 Sure .
Paragraph (version A):
The third SDP line MUST be a "s=" line, as specified in RFC4566,
Section 5.3; to match the "o=" line, a single dash SHOULD be used
as the session name, e.g. "s=-".  Note that this differs from the
advice in RFC4566 which proposes a single space, but as both "o="
and "s=" are meaningless, having the same meaningless value seems
clearer.
Paragraph (version B):
The third SDP line MUST be a "s=" line, as specified in RFC4566,
Section 5.3; to match the "o=" line, a single dash SHOULD be used
as the session name, e.g. "s=-".  Note that this differs from the
advice in RFC4566 which proposes a single space, but as both "o="
and "s=" are meaningless in JSEP, having the same meaningless
value seems clearer.
Draft: draft-ietf-rtcweb-jsep

Commentary:   has a bullet ending " If this is a local description , the ' ice - lite ' attribute MUST NOT be specified . " This sentence is leftover from before SDP munging was prohibited and should be removed .
Paragraph (version A):
Each m= section is also checked to ensure prohibited features are
not used.  If this is a local description, the "ice-lite"
attribute MUST NOT be specified.
Paragraph (version B):
Each m= section is also checked to ensure prohibited features are
not used.
Draft: draft-ietf-rtcweb-jsep

Commentary:   , bullet starting " For each supported RTCP feedback ... " : replace " an ' a = rtcp - fb ' mechanism " with " an ' a = rtcp - fb ' line " . 
 Section Initial Answers Text is For each supported RTCP feedback mechanism that is present in the offer , an " a = rtcp - fb " mechanism , as specified in [ RFC4585 ] , Section 4.2 . The list of RTCP feedback mechanisms that SHOULD/ MUST be supported is specified in [ I - D.ietf - rtcweb - rtp - usage ] , Section 5.1 . Fix trivial typo 
 Page 38 , second - to - last bullet refers to " an ' a = rtcp - fb ' mechanism " where it should say " an ' a = rtcp - fb ' line " . 
 Agreed
Paragraph (version A):
For each supported RTCP feedback mechanism, an "a=rtcp-fb"
mechanism, as specified in RFC4585, Section 4.2.  The list of RTCP
feedback mechanisms that SHOULD/MUST be supported is specified in
I-D.ietf-rtcweb-rtp-usage, Section 5.1.
Paragraph (version B):
For each supported RTCP feedback mechanism, an "a=rtcp-fb" line,
as specified in RFC4585, Section 4.2.  The list of RTCP feedback
mechanisms that SHOULD/MUST be supported is specified in I-D.ietf-
rtcweb-rtp-usage, Section 5.1.
Paragraph (version A):
For each supported RTCP feedback mechanism that is present in the
offer, an "a=rtcp-fb" mechanism, as specified in RFC4585,
Section 4.2.  The list of RTCP feedback mechanisms that SHOULD/
MUST be supported is specified in I-D.ietf-rtcweb-rtp-usage,
Section 5.1.
Paragraph (version B):
For each supported RTCP feedback mechanism that is present in the
offer, an "a=rtcp-fb" line, as specified in RFC4585, Section 4.2.
The list of RTCP feedback mechanisms that SHOULD/MUST be supported
is specified in I-D.ietf-rtcweb-rtp-usage, Section 5.1.
Draft: draft-ietf-rtcweb-jsep

Commentary: Proposal for how to clarify that when JSEP implementation generates an answer it needs to have the proto value identical to what is in the offer . 
 do you want to take a look at this one ? 
 BLOCKER : The first bullet on page 35 has a normative statement about the AVT profile strings that must be accepted , but uses an unspecified grammar to actually specify the string . If this is normative , it needs to be formal . Either specify the string using a formal and cited grammar , or provide an exhaustive list . 
 Proposal on editor 's call is to use POSIX extended regular expressions . I believe this would give us the expressions . ( UDP|TCP)/TLS / RTP / SAVPF ? and : RTP / S?AVPF ? 
 You 're sure you want to pull in another reference for regexes instead of just listing all eight valid values ? 
 I suggest we merge this without dealing with the formal grammar issue .
Paragraph (version A):
The profile in any "m=" line in any answer MUST exactly match the
profile provided in the offer.
Paragraph (version B):
Any profile in the offer matching the following patterns MUST be
accepted: "RTP/[S]AVP[F]" and "(UDP|TCP)/TLS/RTP/SAVP[F]".
Paragraph (version B):
The profile in any "m=" line in any generated answer MUST exactly
match the profile provided in the offer.