IETF conflict review for draft-boucadair-mmusic-altc
conflict-review-boucadair-mmusic-altc-00

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

Comment (2013-01-22)
No email
send info
- 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.

(Brian Haberman) No Objection

(Russ Housley) No Objection

(Barry Leiba) No Objection

(Pete Resnick) No Objection

(Robert Sparks) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection