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

Commentary: Addresses . 
  fail 
 Yeah I ca n’t wait to diagnose what xml problem I introduced - sigh . 
 From Cullen 's review : The refs to draft - muthu - behave - consent - freshness should be to RFC7675 
 Addressed by .
Paragraph (version A):
The one remaining security property we need to establish is "consent
freshness", i.e., allowing Alice to verify that Bob is still prepared
to receive her communications so that Alice does not continue to send
large traffic volumes to entities which went abruptly offline.  ICE
specifies periodic STUN keepalives but only if media is not flowing.
Because the consent issue is more difficult here, we require WebRTC
implementations to periodically send keepalives.  As described in
Section 5.3, these keepalives MUST be based on the consent freshness
mechanism specified in I-D.muthu-behave-consent-freshness.  If a
keepalive fails and no new ICE channels can be established, then the
session is terminated.
Paragraph (version B):
The one remaining security property we need to establish is "consent
freshness", i.e., allowing Alice to verify that Bob is still prepared
to receive her communications so that Alice does not continue to send
large traffic volumes to entities which went abruptly offline.  ICE
specifies periodic STUN keepalives but only if media is not flowing.
Because the consent issue is more difficult here, we require WebRTC
implementations to periodically send keepalives.  As described in
Section 5.3, these keepalives MUST be based on the consent freshness
mechanism specified in RFC7675.  If a keepalive fails and no new ICE
channels can be established, then the session is terminated.
Paragraph (version A):
While continuing consent is required, the ICE RFC5245; Section 10
keepalives use STUN Binding Indications which are one-way and
therefore not sufficient.  The current WG consensus is to use ICE
Binding Requests for continuing consent freshness.  ICE already
requires that implementations respond to such requests, so this
approach is maximally compatible.  A separate document will profile
the ICE timers to be used; see I-D.muthu-behave-consent-freshness.
Paragraph (version B):
While continuing consent is required, the ICE RFC5245; Section 10
keepalives use STUN Binding Indications which are one-way and
therefore not sufficient.  The current WG consensus is to use ICE
Binding Requests for continuing consent freshness.  ICE already
requires that implementations respond to such requests, so this
approach is maximally compatible.  A separate document will profile
the ICE timers to be used; see RFC7675.
Draft: draft-ietf-rtcweb-security-arch

Commentary: Pretty sure we 'll get a GEN - ART reviewing say to not refer to the WG by name because it will get closed at some point . I basically stole the intro from overview and modified it slightly .
Paragraph (version A):
The Real-Time Communications on the Web (RTCWEB) working group is
tasked with standardizing protocols for enabling real-time
communications within user-agents using web technologies (commonly
called "WebRTC").  This document defines the security architecture
for WebRTC.
Paragraph (version B):
This document defines the security architecture for WebRTC, a
protocol suite intended for use with real-time applications that can
be deployed in browsers - "real time communication on the Web".
Draft: draft-ietf-rtcweb-security-arch

Commentary: I also cleaned up the requirements that follow on from this . I think that those changes are editorial only . 
 Tickling this issue . Not clear to me if it is resolved or not . Current text ( -12 ): < blockquoteAll implementations MUST implement DTLS 1.0 , with the cipher suite  with the the P-256 curve [ FIPS186 ] . The DTLS - SRTP protection profile SRTPAES128CMHMACSHA180 MUST be supported for SRTP . Implementations SHOULD implement DTLS 1.2 with the TLSECDHEECDSAWITHAES128GCM_SHA256 cipher suite . Implementations MUST favor cipher suites which support PFS over non- PFS cipher suites and SHOULD favor AEAD over non - AEAD cipher suites . < /blockquote(Original text of this comment turned out to be a misunderstanding . The draft linked as " editor 's draft " from the project 's master page is older than the published -12 version . ) 
 I think that the actual editors draft is OK , ekr merged a while ago .
Paragraph (version B):
All implementations MUST implement DTLS 1.0, with the cipher suite
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the FIPS186.  The DTLS-
SRTP protection profile SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported
for SRTP.  Implementations SHOULD implement DTLS 1.2 with the
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite.
Implementations MUST favor cipher suites which support PFS over non-
PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher suites.
Paragraph (version B):
The API MUST generate a new authentication key pair for every new
call by default.  This is intended to allow for unlinkability.
Paragraph (version B):
The API MUST provide a means to reuse a key pair for calls.  This
can be used to enable key continuity-based authentication, and
could be used to amortize key generation costs.
Draft: draft-ietf-rtcweb-security-arch

Commentary: This is the companion to w3c / webrtc - pc A move to JS realms and so forth removes the need for a " protocol " in this document . Instead , I 've tried to focus here on what information needs to pass between the browser and the IdP , rather than be prescriptive . I did n't reindent anything , so it 's a mess . I also did n't move Section 5.6 up a level , as I am sorely tempted to do . Hopefully these changes are easy enough to review as they are .
Paragraph (version A):
A calling site is then able to load the provided URL in an IFRAME in
order to trigger the required user interactions.  Once any user
interactions are complete, the IFRAME MUST send a WebMessaging to the
calling site indicating that login has completed.  Any message is
sufficient for this purpose, the "source" parameter identifies the
originating IFRAME.
Paragraph (version B):
The application can then load the provided URL to enable the user to
enter credentials.  The communication between the application and the
IdP is described in webrtc-api.
Draft: draft-ietf-rtcweb-security-arch

Commentary: This makes our consensus decision to require encryption absolutely explicit .
Paragraph (version A):
All media channels MUST be secured via SRTP.  Media traffic MUST NOT
be sent over plain (unencrypted) RTP.  DTLS-SRTP MUST be offered for
every media channel.  WebRTC implements MUST NOT offer SDES or select
it if offered.
Paragraph (version B):
All media channels MUST be secured via SRTP.  Media traffic MUST NOT
be sent over plain (unencrypted) RTP; that is, implementations MUST
NOT negotiate cipher suites with NULL encryption modes.  DTLS-SRTP
MUST be offered for every media channel.  WebRTC implements MUST NOT
offer SDES or select it if offered.