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

The following approval message was sent
From: The IESG
To: "Nevil Brownlee" , draft-boucadair-mmusic-altc@tools.ietf.org
Cc: The IESG , , 
Subject: Results of IETF-conflict review for draft-boucadair-mmusic-altc-08

The IESG has completed a review of draft-boucadair-mmusic-altc-08
consistent with RFC5742.


The IESG has no problem with the publication of 'Session Description
Protocol (SDP) Alternate Connectivity (ALTC) Attribute'
as an Informational RFC.


The IESG has concluded that this work is related to IETF work done in the
MMUSIC WG, but this relationship does not prevent publishing.

The IESG would also like the RFC-Editor to review the comments in the
datatracker related to this document and determine whether or not they
merit incorporation into the document. Comments may exist in both the
ballot and the history log.

The IESG review is documented at:
http://datatracker.ietf.org/doc/conflict-review-boucadair-mmusic-altc/

A URL of the reviewed Internet Draft is:
http://datatracker.ietf.org/doc/draft-boucadair-mmusic-altc/

The process for such documents is described at
http://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]

- 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 " and
this pattern enabling a vulnerabilty that allows one to get around
such a rule.

The draft draft-boucadair-mmusic-altc-06
is ready for publication from the Independent Stream.
Please ask IESG to review it, as set out in RFC 5742.

The following is some background for this draft, please forward it
to IESG along with this request ...

Its abstract says ...
"This document proposes a mechanism which allows to carry multiple IP
addresses, of different address families (e.g., IPv4, IPv6), in the
same SDP offer. The proposed attribute solves the backward
compatibility problem which plagued ANAT, due to its syntax."

It has IANA considerations, it registers a new tag in the SIP option
tag registry.

It was reviewed by Sue Hares and Marc Blanchet.
The mmusic chairs said this was OK as an INdependent Submission.

Thanks, Nevil (ISE)

--
Nevil Brownlee (ISE), rfc-ise@rfc-editor.org