IETF conflict review for draft-boucadair-mmusic-altc
Note: This ballot was opened for revision 00 and is now closed.
Ballot question: "Is this the correct conflict review response?"
(Gonzalo Camarillo) Yes
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Benoît Claise) No Objection
(Ralph Droms) No Objection
(Wesley Eddy) No Objection
(Adrian Farrel) No Objection
(Stephen Farrell) No Objection
- I see there was some mail between the authors and Gonzalo saying the mmusic WG were going to or had looked at this. I assume that they're ok with it, but didn't see an explicit message that said that. - abstract: perhaps expand ANAT, and maybe other acronyms though ANAT was the one I didn't know. - security considerations: The altc attribute can contain addresses that are elsewhere in the SDP offer, right? That pattern can lead to authorization failures, where different bits of code grant or deny something based on the different fields assuming they have the same value, when in reality they don't. I think noting that in the security considerations might be good, especially if you can think of a case where it might be problematic. Note: I don't know if either of these fields are ever used as input to an authorization decision function, so maybe this is moot, but I can imagine someone writing a rule that says "only allow calls to <address-range>" and this pattern enabling a vulnerabilty that allows one to get around such a rule.