Subject: SDP: comment from IESG

From: Mark Handley <[email-masked]>
Date: Tue, 27 Jan 1998 12:33:19 -0500

I just got the following comment back from a member of the IESG.  I
think the point is valid.  The IP address dates from when SDP was only
used for session announcements.  Today SDP is used in SIP and RTSP,
and so encountering a NAT is quite likely.  

Two questions:

1. Would anyone object to the text being changed to permit either an
address or a fully qualified domain name?  

2. Does anyone think that we should change the spec to permit only
fully qualified domain names?

Personally I prefer 1. Please let me know your opinion ASAP.

Cheers,
	Mark

------- Forwarded Message

Sorry, but I have to object to the IP address appearing in the o= field.
You can make a case that in the c= line that is the IP address taht will
appear in the packet, and people need it to find the session.  It is
somewhat NAT unfriendly, but I can live with it.
The o= line requires an IP address as a uniqueness generator.  It does not
permit a  DNS name.  It says it must be the "globally unique address where
the advertisement originates".  What if that does not exist?  I could
easily imagine organizing a session from behind a firewall, and then
arranging the for the right things to happen later.

No, I do not like firewalls/NATs.  But they are there, and stuff
should think about them.  Another way of thinking about this objection
is that protocols should not directly encode IP addresses unless they
need them.  The c= line needs it.  The o= line doesn't.

------- End of Forwarded Message

---

From: "Michael F. Speer" <[email-masked]>
Date: Tue, 27 Jan 1998 10:35:02 -0800 (PST)

Mark:

I prefer option #1, but with the appropriate text where option #1 might
break because of NAT translation.

Michael

---

From: "Michael A. Dolan" <[email-masked]>
Date: Wed, 28 Jan 1998 09:20:55 -0800

Mark-

This sounds a bit odd perhaps, but as a general rule, there is no DNS
service in our network that could resolve a domain name to an IP address.
So if a domain name is permitted, then in our network, the domain string
itself would have to be used in the uniqueness set, and nothing about the
spec should require it to be resolved into an IP address.

If domain names are REQUIRED, then this is a bit of an implementation
challenge in our network, as strings were not contemplated in the lookup
process, so proposal (2) is not very appealing at all.

I don't know if I get a vote, but proposal (1) would work fine, and by
convention we would probably continue to use IP addresses.

	Mike

>------- End of Forwarded Message
---------------------------------------------------------------------------
Michael A. Dolan  TerraByte Technology  (619)445-9070    FAX: (619)445-8864
PO Box 1673 Alpine, CA 91903, Overnight: 20239 Japatul Rd, Alpine, CA 91901
URL:http://www.tbt.com

---

From: Mark Handley <[email-masked]>
Date: Wed, 28 Jan 1998 12:35:21 -0500

>convention we would probably continue to use IP addresses.

I've had quite a few comments sent to me personally, roughly half in
favour of option 1 and half in favour of option 2.  No-one said that
they'd prefer no change.  For reasons including those you listed, I
decided in favour of option 1, and I've changed the wording to:

  Origin
 
  o=<username>  <session  id>  <version>  <network  type>  <address  type>
  <address>

  The ``o='' field gives the originator of the session (their username and
  ....
  <address
  type>  is  a  text  string  giving the type of the address that follows.
  Initially ``IP4'' and ``IP6'' are defined.  <address>  is  the  globally
  unique  address  of the machine from which the session was created.  For
  an address type of IP4, this is either the fully-qualified  domain  name
  of the machine, or the dotted-decimal representation of the IP version 4
  address of the machine.  For an address type of IP6, this is either  the
  fully-qualified  domain  name  of the machine, or the compressed textual
  representation of the IP version 6 address of the machine.  For both IP4
  and  IP6,  the  fully-qualified  domain  name is the form that SHOULD be
  given unless this is unavailable, in  which  case  the  globally  unique
  address  may be substituted.  A local IP address MUST NOT be used in any
  context where the SDP description might leave the  scope  in  which  the
  address is meaningful.

I hope this is OK.  

BTW, the 06 draft just appeared in the archives, which contains the
IANA registration guidelines, but does not contain the above change
and also some other minor wording changes that have been requested by
the IESG.

I've accumulated these changes in
  http://north.east.isi.edu/sdp.current.tex
If any more changes are requested, they'll be reflected there, and if
they may affect implementations, I'll send mail to the list.

Cheers,
	Mark

--------

---

From: Stephen Casner <[email-masked]>
Date: Wed, 28 Jan 1998 10:39:54 -0800 (Pacific Standard Time)

Mark,

> For reasons including those you listed, I
> decided in favour of option 1

I agree with this decision.

>  and I've changed the wording to:
...
>   For both IP4
>   address  may be substituted.

We have debated this same question with respect to the CNAME in RTP.
The key phrase is "unless this is unavailable".  Several people have
argued, Van Jacobson perhaps most strongly, that determining the
answer to this question robustly and without incurring a long delay
may be difficult on many platforms.  Henning Schulzrinne has suggested
a number of techniques for doing it.  I have not personally tried to
test this question on different platforms, but among those attending
the AVT meeting where we last discussed this (I think it was Memphis),
the general consensus was that we should favor the numeric form.  This
question still needs to be finalized for the RTP spec and profile
revisions, and the IESG may push on the issue there, too.  The problem
is somewhat harder for RTP because we'd like not just uniqueness for a
particular host but also that the same choice be made by all
applications used together in a session on that host.

Michael Dolan said that in his environment a DNS lookup was not
possible.  Even in other environments, it should be noted that it may
not be possible to look up the FQDN received on a o= line into the
equivalent address if that address is not globlal.  Fortunately, for
this use in SDP, conversion is not necessary.

I have another question related to these recent SDP additions and RTP.
The new wording for "bwtype" (bandwidth specifiers) says:

    A proliferation of bandwidth specifiers is strongly discouraged.

    New bandwidth specifiers may be registered with IANA.   The  submis-
    sion  MUST  reference a standards-track RFC specifying the semantics
    of the bandwidth specifier precisely, and indicating when it  should
    be used, and why the existing registered bandwidth specifiers do not
    suffice.

In AVT we agreed to allow the RTCP bandwidth for receive-only
participants and sender participants in an RTP session to be specified
as separate parameters of the session, with the default being that the
overall RTCP bandwith is 5% with (the usually small number of) senders
getting 25% and all the receivers getting 75%.

Do you consider the addition of bandwidth specifiers for RTCP receiver
and sender bandwidths to fit these guidelines, and that specifying it
in the revised RTP profile would be appropriate/sufficient?

							-- Steve

---

From: Mark Handley <[email-masked]>
Date: Wed, 28 Jan 1998 14:26:29 -0500

>in the revised RTP profile would be appropriate/sufficient?

Yes, I do consider this appropriate use of a bandwidth specifier.
Specifying it in the revised RTP profile is exactly the sort of
specification I intended when I wrote the guidelines.  

Of course you could also use an attribute.  In this case, the choice
between using an attibute and a bandwidth identifier is not clear cut,
but I think I would favour using a bandwidth specifier.

Cheers,
	Mark