Re: [AVTCORE] AD Evaluation of draft-ietf-avtcore-multiplex-guidelines-08 - substantive comments part

[Bo Burman <[e-mail]>]

Long overdue, this is a response to the AD review, commenting on the substantive part inline below.
My response to the editorial comments will follow in a separate mail.
Cheers,
/Bo

> -----Original Message-----
> From: Ben Campbell <[e-mail]>
> Sent: den 27 mars 2019 15:26
> To: [e-mail]
> Cc: Barry Leiba <[e-mail]>
> Subject: AD Evaluation of draft-ietf-avtcore-multiplex-guidelines-08
> 
> Hi,
> 
> This is my AD evaluation of draft-ietf-avtcore-multiplex-guidelines-08.
> 
> I have a few material comments and a number of editorial comments. I don’t
> think any of these need block IETF LC. They can be handled along with any
> other IETF LC feedback.
> 
> Also, Barry will become the responsible AD after today, so the resolution of
> my comments will be at his discretion.
> 
> Thanks!
> 
> Ben.
> 
> ————————————————
> 
> *** Substantive Comments ***
> 
> § 3.4.1: Please don’t quote that much material. It’s better to reference it,
> especially since RFC 3550 predates the current IPR rules.
[BoB] That probably makes sense, but on the other hand makes it harder to follow what the quoted arguments from RFC 3550 are that we are discussing. Would it be a workable middle-way to include shortened versions of the bullets in RFC 3550 with the same numbering that provides the reader with at least some context before commenting on them?

> 
> §3.4.3, last paragraph: This paragraph recommends going against a 3550
> recommendation. I realize this is an informational draft offering opinions
> rather than normative text, but did the WG consider an update to 3550?
[BoB] Not entirely sure what is suggested, but will assume it doesn't suggest we change _this_ document to update RFC 3550, but rather if the WG has considered creating a small standards track RFC changing just that recommendation? I cannot recall the WG considering that.
Does the WG believe such update is needed?

> 
> §3.4.4: "Those receivers that are not seeing packet loss don’t need to join
> the multicast group with the FEC data, and so avoid the overhead of receiving
> unnecessary FEC packets, for example.”
> 
>  Does this require the receiver to predict in advance whether packet loss may
> occur during the session?
[BoB] That was not the intent, but it could wait to join the FEC data group until observed loss rate is considered too high, or it could choose to leave if observed loss rate is very low.

> 
> §4.1.3: "For applications that uses any security mechanism, e.g., in the form
> of SRTP, the gateway needs to be able to decrypt incoming packets and re-
> encrypt them in the other application’s security context.”
> 
> It seems like this should also talk about authentication/signing, at least for
> when modifications to the packets occur.
[BoB] What about re-phrasing to "For applications that use any security mechanism, e.g., in the form of SRTP, the gateway needs to be able to decrypt and verify source integrity of the incoming packets, and re-encrypt, integrity protect, and sign the packets as peer in the other application’s security context"?

> 
> §4.3.2: It’s not clear to me that this section is specific to multiplexing.
[BoB] Agree. Suggest to clarify that better, e.g. changing the first sentence to "The capabilities of the key-management combined with the RTP multiplexing choices affects the resulting security properties, control over the secured media, and who have access to it". Also suggest to add a sentence on how PERC (draft-ietf-perc-private-media-framework) provides yet another trust model, which happened since this text was originally written.

> 
> §10.2: The following references need to be normative since they are needed
> to fully understand guidance or security considerations:
> 
> ietf-avtcore-multi-media-rtp-session
> [I-D.ietf-mmusic-rid]
> [I-D.ietf-mmusic-sdp-bundle-negotiation]
> [I-D.ietf-mmusic-sdp-simulcast]
> [I-D.ietf-perc-srtp-ekt-diet]
> RFC 3551
> RFC 3711
> RFC 3830
> RFC 4585
> RFC 5760
> RFC 5761
> RFC 5776
> RFC 7667
[BoB] OK (5776 above should likely be 5576, though)

> 
> - Appendix A: "To use payload type as the single discriminator for multiple
> streams implies that all the different RTP streams are being sent with the
> same SSRC, thus using the same timestamp and sequence number space.”
> 
> That doesn’t seem to make sense. How could discriminating on PT mean that
> all streams use the same PT?
[BoB] I think this was either misread (the text says "same SSRC", not "same PT"), or alternatively didn't consider that PT is assumed to be "single discriminator", which means that SSRC indeed is the same for all packets. I don’t see that any change would be necessary.