The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework
draft-ietf-mmusic-anat-02

[Ballot discuss]
This document should use the IPv6 documentation prefix in the example:  2001:DB8::/32.  The document that defines this prefix is already in the RFC Editors queue for publication.  There is probably a similar address that should be used for IPv4 examples, but I can seem to find it.

Is it expected that IPv6 addresses could include zone IDs of the format described in the IPv6 scoped address architecture (

%)?

[Ballot discuss]
I apologize for entering this as a discuss comment, rather than responding to the last call; I started
to write this up for the last call, and I got overcome by events.  I really, really don't want to do
this now, as it is a classic late surprise, but I feel I have to put this forward.  If there is strong push
back, I will move to an abstain, but I *would* like to discuss it.

This document seems to be starting from the wrong place, and I believe it ends up in the wrong place as a result. It seems to intends to allow something useful (a dual-stack v4/v6 node to
advertise addresses in both families), but it is missing the point that address families in and
of themselves aren't sufficient to describe address types.  Addresses may have scopes; addresses may be associated with specific places in network topologies; addresses may be  connected to interfaces which may have vastly different capabilities.  On one level, this draft seems to recognize this; Section 5.1, for example, seems to recognize that specific addresses may be mapped to different interfaces with different characteristics.  But text like this:

  The ANAT semantics are intended to address scenarios that involve
  different network address types (e.g., different IP versions). They
  are not intended to provide alternative transport addresses with the
  same network type.

seems to indicate that one interface's link-local IPv6 address and a different
interface's globally unique IPv6 address would be the same type.  It seems
to further imply, but not quite state outright that v4 and v6 addresses
are the only "address types".  This needs to get said flat-out at some point
one way or the other.  And somehow this document needs to motivate the
limitation, because it seems arbitrary now (or related to a fear of overlap
with ICE, which seems like it could be dealt with in other ways).

For the readers in the IESG, this argument goes back to the message "A Crazy Idea of No Merit"
I sent out earlier, in which I argued that we were in fact using fairly complex routing
tuples, but were inferring the elements of the typical row in ways that hid that
fact.  Nothing in this document prohibits this being used for multiple interfaces,
and that means that lots of the elements in those tuples may vary--and the apparent
limitation in this document to "one per address family" doesn't cover the ground
appropriately in my opinion.

[Ballot discuss]
This document should use the IPv6 documentation prefix in the example:  2001:DB8::/32.  The document that defines this prefix is already in the RFC Editors queue for publication.  There is probably a similar address that should be used for IPv4 examples, but I can seem to find it.

[Ballot discuss]
It looks like either the text or the example in section 4 is broken.  The text says "In the example below, the m= line with mid=1 has a higher preference than the m line with mid=2", but the example given is "a=group:ANAT 1 2".

[Note]: 'This document defines a SIP option tag, and accordingly, per RFC3427 Section 2.1, it must be processed by the SIP WG.' added by Jon Peterson