Subject: [MMUSIC] SDP QoS Mechanism Identification

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 06 Oct 2006 10:13:52 +0300

Hi,

last time we presented this draft, Flemming had some concerns about its
semantics. We have just submitted a new revision of the draft that tries
and addresses Flemming's concerns. Now the result of the offer/answer
exchange is a hint of which QoS mechanisms can be used because they are
supported by the remote endpoint. However, it does not keep the
endpoints from trying different mechanisms that may not be supported by
the endpoint but may be supported by the network (e.g., thru an RSVP proxy).

Until the draft appears in the official archives, you can fetch it from:

http://users.piuha.net/gonzalo/temp/draft-polk-mmusic-qos-mechanism-identification-02.txt

Let us know if this revision addresses your concerns.

Cheers,

Gonzalo

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 Oct 2006 09:27:22 -0400

I don't have any conceptual problems with this draft. But I did find 
some technical/editorial issues with it:

Ref [2] (sdp-new) is now RFC4566

There are problems meshing the syntax with that in 4566, at least in 
part because 4566 is pretty sloppy about how it defines syntax of 
attributes. Redefining 'attribute' as done here seems wrong. I defer to 
somebody more involved with SDP on the "right" way to do this. The best 
I can see is to give a syntax that doesn't reuse symbols from 4566, and 
concentrate on getting the iana considerations right.

sec 4.2 implies that one might include a *set* of tokens for mechanisms 
and sec 5 shows examples of this. But they syntax only allows one per 
a-line.

It seems likely that the same mechanisms would be used in both 
directions. It might be helpful to have a qos-mech-sendrecv that could 
be used when this is the case.

In the iana considerations section, I gather the goal is to register the 
two attribute-field names, and then to register a single sub registry 
for qos mechanism tokens that applies to both fields. But I don't find 
anything in the registration for the attribute fields that links them to 
this new sub registry. Once again I find 4566 to be a bit sloppy in 
specifying the iana procedures for registration of attribute fields and 
values, so there is little guidance on how to do this correctly.

	Paul