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

["Ben Campbell" <[e-mail]>]

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.)

>>
>> -- 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 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 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.)

>
>>
>> -- 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.)

>
>
>>
>> -- 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..."


>
>>
>> -- 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.

>
>>
>> -- 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. :-)

[...]