Draft: draft-ietf-rtcweb-jsep

Commentary: The verb " surfaced " appears three times in the document without support or definition . Can you replace them with simpler language ? 
 I do n't see a reason to change this . It seems like relatively straightforward langauge . 
 I do n't care . FWIW ... I asked a few developers what surfaced in an API meant and it did not seem a common term they used but given context they all read it the way we mean in spec .. 
 The first two , which are about errors , will be changed to " raised " The last one , which is about candidates will be changed to " made available " 
 LGTM
Paragraph (version A):
If the encoder resolution exceeds the maximum size permitted by
the attribute, and the encoder is allowed to adjust its
resolution, the encoder SHOULD apply downscaling in order to
satisfy the limits, although the downscaling MUST NOT change the
picture aspect ratio of the encoding.  For example, if the encoder
resolution is 1280x720, and the attribute specified a maximum of
640x480, the expected output resolution would be 640x360.  If
downscaling cannot be applied, the encoding MUST NOT be
transmitted, and an error SHOULD be surfaced to the application.
Paragraph (version A):
If the encoder resolution is less than the minimum size permitted
by the attribute, the encoding MUST NOT be transmitted, and an
error SHOULD be surfaced to the application; the encoder MUST NOT
apply upscaling.  JSEP implementations SHOULD avoid this situation
by allowing receipt of arbitrarily small resolutions, perhaps via
fallback to a software decoder.
Paragraph (version B):
If the encoder resolution exceeds the maximum size permitted by
the attribute, and the encoder is allowed to adjust its
resolution, the encoder SHOULD apply downscaling in order to
satisfy the limits, although the downscaling MUST NOT change the
picture aspect ratio of the encoding.  For example, if the encoder
resolution is 1280x720, and the attribute specified a maximum of
640x480, the expected output resolution would be 640x360.  If
downscaling cannot be applied, the encoding MUST NOT be
transmitted, and an error SHOULD be raised to the application.
Paragraph (version B):
If the encoder resolution is less than the minimum size permitted
by the attribute, the encoding MUST NOT be transmitted, and an
error SHOULD be raised to the application; the encoder MUST NOT
apply upscaling.  JSEP implementations SHOULD avoid this situation
by allowing receipt of arbitrarily small resolutions, perhaps via
fallback to a software decoder.
Paragraph (version A):
Any change to the ICE candidate policy affects the next gathering
phase.  If an ICE gathering phase has already started or
completed, the 'needs-ice-restart' bit will be set.  Either way,
changes to the policy have no effect on the candidate pool,
because pooled candidates are not surfaced to the application
until a gathering phase occurs, and so any necessary filtering can
still be done on any pooled candidates.
Paragraph (version B):
Any change to the ICE candidate policy affects the next gathering
phase.  If an ICE gathering phase has already started or
completed, the 'needs-ice-restart' bit will be set.  Either way,
changes to the policy have no effect on the candidate pool,
because pooled candidates are not made available to the
application until a gathering phase occurs, and so any necessary
filtering can still be done on any pooled candidates.