Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-rtp-usage-24: (with COMMENT)

[Magnus Westerlund <[e-mail]>]

Hi,

Inline

Ben Campbell skrev den 2015-06-09 16:32:
> On 9 Jun 2015, at 3:51, Magnus Westerlund wrote:
>
>> Hi Ben,
>>
>> Thanks for the review, some inline comments. Will address these after
>> Thursday when we know the rest of IESGs views.
>>
>
> Thanks for the response. Comments inline.
>
> [...]
>
>>> Substantive:
>>>
>>> -- 4.9: The discussion of RTCPeerConnection in this section seems to
>>> need
>>> a normative reference to [W3C.WD-webrtc-20130910] (or a local
>>> explanation, if there are issues normatively referencing that doc.)
>>
>> Do I understand that you want a reference in the second paragraph at
>> the mentioning of RTCPeerConnection? As it is reference in the
>> previous paragraph, I assumed that people would not be confused on
>> what we talk about.
>>
>
> I'm okay with the reference where it is--my comment was more about
> normativity (see comment to next paragraph)
>
>> I guess the second issue is that the reference is classified as
>> informative and should be normative. Changing the classification is
>> simple, it will however create a need to ensure that the publication
>> of this document is held until the W3C document reaches Recommendation
>> status if I understand the rules and recommendations correctly.
>>
>
> I think the reader will at least need a high level understanding of the
> meaning of RTCPeerConnection to implement the normative requirements in
> this section. If the W3C doc is not going to be sufficiently mature in
> the immediate future, it might be good enough to put a couple of
> sentences in this doc about the meaning of RTCPeerConnection. (The full
> interface spec is probably not needed.)

I think might have to up level this discussion a bit. We always know 
that we where going to need to put in normative references somewhere 
between the IETF RFCs and the W3C WebRTC specifications. I think it is 
time we realize the implications of that. And I think this document, 
JSEP, and Overview at least are going to need to have correct references 
to the W3C specifications. Thus, I would suggest that we convert them to 
normative references and then let them hang in missref until the are 
ready to publish. The W3C WebRTC spec currently have a lot of normative 
references to drafts in the rtcweb wg, including this. So RFC-editor and 
W3C equivalent will need to have a coordination step.

My suggestion is that we do change the W3C references to normative.

>
>>>
>>> -- 5.1: This section seems to need a normative reference to
>>> topologies-update. There is normative language here to the effect of
>>> “Don’t do these things” where it seems like one needs to read that
>>> doc to
>>> understand what the “things” mean.
>>
>> I do understand the reasoning behind your comment. I personally do not
>> agree the need for using normative references for documents that
>> import a term for a concept. We already had this discussion around the
>> topologies document's status.
>
> (I'm not sure if you meant "do _not_ understand", but I expected you to
> disagree :-)  )

I actually mean I do understand some of the thinking, I simply think it 
is flawed and has downsides making me have another view on what is to be 
considered normative references.

>
> I realize there is not universal agreement on whether BCP 97 applies to
> terminology. I think it can in some cases. But in this case, I think we
> are going beyond just terminology. The topology doc describes structure
> and behavior associated with each topology. I assume it is informational
> because it is descriptive rather than prescriptive.

I will agree with you that the topology will be used in such way that it 
is often normative.

>
>>
>> I have no issue with reclassifying the reference, but I do note that
>> we will have to re-run the IETF last call as this will now be a down-ref.
>
> Yes, that is an issue. You will note I made this a comment, not a
> discuss :-)  I will leave it up to you guys and Alissa to decide if this
> is needed badly enough to go through another LC. (For the record,
> there's some work going on to update 97 to allow more discretion around
> this sort of thing without triggering pointlessly repeated last calls.)

Lets get the downref last call out of the way as soon as we have updated 
the draft. That way the WG (and rest of IETF) will have two weeks to 
review the changes.


>
>>
>>>
>>> -- 7.1, first paragraph: "applications MUST also implement congestion
>>> control to
>>> allow them to adapt to changes in network capacity."
>>>
>>> Is that the aformentioned not-yet-standardized congestion control
>>> algorithm, or something else?
>>
>> As we have no standardized congestion control yet, we can't point to
>> anything. But, an implementation must implement something, even if
>> completely proprietary.
>
> It would be helpful to either clarify the "even if proprietary" part, or
> perhaps move this sentence closer to the bit about no standardized
> mechanism. (But this is not a show stopper.)

Ok,

I propose that we add this sentence: "The congestion control algorithm 
will have to be proprietary until a standardized congestion control 
algorithm is available." into the first paragraph in 7.1:

    WebRTC Endpoints MUST implement the RTP circuit breaker algorithm
    that is described in [I-D.ietf-avtcore-rtp-circuit-breakers].  The
    RTP circuit breaker is designed to enable applications to recognise
    and react to situations of extreme network congestion.  However,
    since the RTP circuit breaker might not be triggered until congestion
    becomes extreme, it cannot be considered a substitute for congestion
    control, and applications MUST also implement congestion control to
    allow them to adapt to changes in network capacity.  The congestion
    control algorithm will have to be proprietary until a standardized
    congestion control algorithm is available.  Any future RTP congestion
    control algorithms are expected to operate within the envelope
    allowed by the circuit breaker.

Does this satisfies your concerns?

>
>>
>>
>>>
>>> -- 11, 2nd paragraph from end:
>>>
>>> It seems like the msid reference should be normative.
>>
>> Our intention was to keep this informative. Therefore the chosen style
>> of writing that sentence. The actual normative inclusion of MSID into
>> the WebRTC solution is done by JSEP.
>
> Okay. It might be helpful, but not required, to state this sentence in
> the form of "[jsep] specifies that..."
>

So what you want is that paragraph to read more like this?

    Javascript Session Establishment Protocol [I-D.ietf-rtcweb-jsep]
    specifies that the binding between the WebRTC MediaStreams,
    MediaStreamTracks and the SSRC is done as specified in "Cross Session
    Stream Identification in the Session Description Protocol"
    [I-D.ietf-mmusic-msid].  The MSID document [I-D.ietf-mmusic-msid]
    also defines, in section 4.1, how to map unknown source packet stream
    SSRCs to MediaStreamTracks and MediaStreams.


>
>>
>>>
>>> -- 12.1.3:
>>>
>>> seems like a mention of draft-ietf-dart-dscp-rtp might be in order now.
>>> IIRC, when I did a gen-art review on a much older version, the thought
>>> was that if draft-ietf-dart-dscp-rtp was far enough along when it was
>>> time to publish this draft, it would make sense to add a mention.
>>> It's in
>>> the RFC editor queue now, in MISSREF on a dependency that I think this
>>> draft shares.
>>
>> The TSVWG document referenced do normatively reference the DART
>> document. But, we could include the DART document in the same sentence
>> as the TSVWG document.
>
> I'm okay leaving it to the deeper conversation in the TSVWG doc. I
> mainly mentioned it because I had thought the intent was to add the
> mention here if the dart draft was sufficiently far along in the process
> when this draft was submitted.

Actually, I think I found a simple way of referencing it, and it is 
relevant in that discussion. So the sentence is proposed to read:

     However, depending on the QoS
    mechanism and what markings that are applied, this can result in not
    only different packet drop probabilities but also packet reordering,
    see [I-D.ietf-tsvwg-rtcweb-qos] and [I-D.ietf-dart-dscp-rtp] for
    further discussion.

>
>>
>>>
>>> -- 13: 3rd paragraph:
>>>
>>> Isn't that security solution MTU as well as MTI? If so, it might be
>>> worth
>>> mentioning it here.
>>
>> You mean Mandatory to Use, not Maximum Transmission Unit, don't you?
>> Yes, it is mandatory to use, we can make that clear.
>>
>
> Yes, mandatory to use. :-)
>

So text proposed to be changed to.

    A mandatory to implement and use
    media security solution is created by combining this secured RTP
    profile and DTLS-SRTP keying [RFC5764] as defined by Section 5.5 of
    [I-D.ietf-rtcweb-security-arch].




Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------