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

Hi,

A couple of additional comments on this. I will also submit a new
version due to the many changes that will make it more easily for
everyone to review the proposed changes. 


On Fri, 2019-07-12 at 13:14 +0000, Bo Burman wrote:
> 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 <[email protected]>
> > Sent: den 27 mars 2019 15:26
> > To: [email protected]
> > Cc: Barry Leiba <[email protected]>
> > 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?
> 

I think we need to at least cite the bullets. However, maybe we can
move each bullet to just before each discussion of that point. 

I have implemented this and I think I should submit that so you see how
it looks.


> > 
> > §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?

No, I don't think we really have discussed changing this. One reason is
that I think layered encoding across multiple RTP sessions has not be a
particular common case and thus not this issue has not surfaced within
the IETF. 

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

Let us reformualte this text to something clearer.

A receiver can based on measurment of experienced packet loss decide to
join a multicast group with the suitable FEC data repair capabilities.

Does this resolve the issue?

> 
> > 
> > §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"?

I think this resolves the issue. 

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

My view is that this works. 
> 
> > 
> > §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.
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email protected]
> https://www.ietf.org/mailman/listinfo/avt


Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email protected]
----------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Core Maintenance
[email protected]
https://www.ietf.org/mailman/listinfo/avt