Christer Holmberg | 1 Oct 10:11 2007
Picon

Offer/answer questions on RFC 4585

Hi,
 
I have a couple of questions on RFC 4585, regarding the usage with offer/answer.
 
My FIRST question is: are there any TECHNICAL reasons (I know it's probably not allowed by RFC 3264) why a user receiving an AVPF offer, but doesn't support it, can't reply with AVP answer (instead of rejecting the stream)? My understanding is that if you offer AVPF you still have to be able to do AVP, so...
 
(The receiver of course needs to understand the "AVPF" string in the SDP)
 
 
My SECOND question is on example 3 in chapter 4.4. The RFC shows two m=video lines (one AVPF and one AVP) with the SAME port number (51372), and says that an appropriate grouping mechanism should be used to group the AVPF and AVP alternatives.
 
However, I believe that even if you use some grouping mechanism, you are still not allowed to use the same port number in two m= lines. There has been much discussion about this on the MMUSIC list, but as far as I know that rule hasn't been changed. I assume this would be only an editorial bug?
 
Regards,
 
Christer
_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt
Randell Jesup | 1 Oct 20:21 2007

Re: Offer/answer questions on RFC 4585

"Christer Holmberg" <christer.holmberg <at> ericsson.com> writes:
>I have a couple of questions on RFC 4585, regarding the usage with offer/answer.
> 
>My FIRST question is: are there any TECHNICAL reasons (I know it's
>probably not allowed by RFC 3264) why a user receiving an AVPF offer, but
>doesn't support it, can't reply with AVP answer (instead of rejecting the
>stream)? My understanding is that if you offer AVPF you still have to be
>able to do AVP, so... 
> 
>(The receiver of course needs to understand the "AVPF" string in the SDP)

That probably violates a number of the offer-answer MUSTs, but technically
it certainly can be handled.  From Section 5:

   AVP and AVPF are defined in a way that, from a robustness point of
   view, the RTP entities do not need to be aware of entities of the
   respective other profile: they will not disturb each other's
   functioning.  However, the quality of the media presented may
   suffer.

and the rest of section 5 in general addresses this point, though not head-on.
(Section 5 is obviously written with non-point-to-point uses in mind, where
each participant may have accepted one or the other).

>My SECOND question is on example 3 in chapter 4.4. The RFC shows two
>m=video lines (one AVPF and one AVP) with the SAME port number (51372),
>and says that an appropriate grouping mechanism should be used to group
>the AVPF and AVP alternatives. 
> 
>However, I believe that even if you use some grouping mechanism, you are
>still not allowed to use the same port number in two m= lines. There has
>been much discussion about this on the MMUSIC list, but as far as I know
>that rule hasn't been changed. I assume this would be only an editorial
>bug? 
> 

RFC 4566:

      The semantics of multiple "m=" lines using the same transport
      address are undefined.  This implies that, unlike limited past
      practice, there is no implicit grouping defined by such means and
      an explicit grouping framework (for example, [18]) should instead
      be used to express the intended semantics.

The "limited past practice" probably refers to people ad-hoc using
identical ports as a way of saying "accept a or b but not both".  The older
RFC for SDP didn't mention it.

--

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup <at> wgate.com
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

Dan Wing | 2 Oct 00:22 2007
Picon

RE: Offer/answer questions on RFC 4585

>"Christer Holmberg" <christer.holmberg <at> ericsson.com> writes:
>>I have a couple of questions on RFC 4585, regarding the usage with 
>>offer/answer.
>> 
>>My FIRST question is: are there any TECHNICAL reasons (I know it's
>>probably not allowed by RFC 3264) why a user receiving an AVPF offer, but
>>doesn't support it, can't reply with AVP answer (instead of rejecting the
>>stream)? My understanding is that if you offer AVPF you still have to be
>>able to do AVP, so... 
>> 
>>(The receiver of course needs to understand the "AVPF" string in the SDP)

> That probably violates a number of the offer-answer MUSTs, 
> but technically it certainly can be handled.  From Section 5:
> 
>    AVP and AVPF are defined in a way that, from a robustness point of
>    view, the RTP entities do not need to be aware of entities of the
>    respective other profile: they will not disturb each other's
>    functioning.  However, the quality of the media presented may
>    suffer.
> 
> and the rest of section 5 in general addresses this point, 
> though not head-on.  (Section 5 is obviously written with non-point-
> to-point uses in mind, where each participant may have accepted 
> one or the other).

The better way to handle this is to use SDP capability negotiation
(draft-ietf-mmusic-sdp-capability-negotiation) which doesn't require 
the answerer to understand the "F" of "AVPF" at all.  Using SDP
capability negotiation is more robust and allows much cleaner 
fallback.

> >My SECOND question is on example 3 in chapter 4.4. The RFC shows two
> >m=video lines (one AVPF and one AVP) with the SAME port 
> >number (51372),
> >and says that an appropriate grouping mechanism should be 
> >used to group the AVPF and AVP alternatives. 
> > 
> >However, I believe that even if you use some grouping 
> >mechanism, you are
> >still not allowed to use the same port number in two m= 
> >lines. There has
> >been much discussion about this on the MMUSIC list, but as 
> >far as I know
> >that rule hasn't been changed. I assume this would be only 
> >an editorial bug? 
> 
> RFC 4566:
> 
>       The semantics of multiple "m=" lines using the same transport
>       address are undefined.  This implies that, unlike limited past
>       practice, there is no implicit grouping defined by such 
> means and
>       an explicit grouping framework (for example, [18]) 
> should instead
>       be used to express the intended semantics.
> 
> The "limited past practice" probably refers to people ad-hoc using
> identical ports as a way of saying "accept a or b but not 
> both". 

I agree, that is probably what it was referring to.  However, its
reference to [18] (RFC3388) doesn't provide the escape clause that
the authors of RFC4566 intended.  Specifically, RFC3388 says this
about using the same transport address:

  "7.5.3 Same IP Address and Port Number

   If several codecs have to be sent to the same IP address and port,
   the traditional SDP syntax of listing several codecs in the same "m"
   line MUST be used.  FID MUST NOT be used to group "m" lines with the
   same IP address/port.  Therefore, an SDP like the one below MUST NOT
   be generated.

       v=0
       o=Laura 289083124 289083124 IN IP4 six.example.com
       t=0 0
       c=IN IP4 131.160.1.112
       a=group:FID 1 2
       m=audio 30000 RTP/AVP 0
       a=mid:1
       m=audio 30000 RTP/AVP 8
       a=mid:2

   The correct SDP for the session above would be the following one:

       v=0
       o=Laura 289083124 289083124 IN IP4 six.example.com
       t=0 0
       c=IN IP4 131.160.1.112
       m=audio 30000 RTP/AVP 0 8

   If two "m" lines are grouped using FID they MUST differ in their
   transport addresses (i.e., IP address plus port)."

-d

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

Even, Roni | 2 Oct 09:24 2007
Picon

RE: Offer/answer questions on RFC 4585

Christer,

Inline

 

From: Christer Holmberg [mailto:christer.holmberg <at> ericsson.com]
Sent: Monday, October 01, 2007 10:11 AM
To: avt <at> ietf.org
Subject: [AVT] Offer/answer questions on RFC 4585

 

Hi,

 

I have a couple of questions on RFC 4585, regarding the usage with offer/answer.

 

My FIRST question is: are there any TECHNICAL reasons (I know it's probably not allowed by RFC 3264) why a user receiving an AVPF offer, but doesn't support it, can't reply with AVP answer (instead of rejecting the stream)? My understanding is that if you offer AVPF you still have to be able to do AVP, so...

 

(The receiver of course needs to understand the "AVPF" string in the SDP)

 

[RE:]  I think that is this case the offer  will include a=rtcp-fb with rtcp-fb-vals. Since the receiver understands AVPF but do not support any feedback message it will remove all rtcp-fb-val in the answers.

To me that looks like support of AVP so why do you want to change the avpf to avp.

 

 

My SECOND question is on example 3 in chapter 4.4. The RFC shows two m=video lines (one AVPF and one AVP) with the SAME port number (51372), and says that an appropriate grouping mechanism should be used to group the AVPF and AVP alternatives

 

However, I believe that even if you use some grouping mechanism, you are still not allowed to use the same port number in two m= lines. There has been much discussion about this on the MMUSIC list, but as far as I know that rule hasn't been changed. I assume this would be only an editorial bug?

[RE:] Yes

 

Regards,

 

Christer

 

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt
Christer Holmberg | 2 Oct 14:13 2007
Picon

RE: Offer/answer questions on RFC 4585


Hi Roni,

>>I have a couple of questions on RFC 4585, regarding the usage with
offer/answer.
>>
>>My FIRST question is: are there any TECHNICAL reasons (I know it's
probably not allowed by RFC 3264) why a user receiving an AVPF offer,
but doesn't 
>>support it, can't reply with AVP answer (instead of rejecting the
stream)? My understanding is that if you offer AVPF you still have to be
able to do 
>>AVP, so...
>>(The receiver of course needs to understand the "AVPF" string in the
SDP)

>[RE:] I think that is this case the offer will include a=rtcp-fb with
rtcp-fb-vals. Since the receiver understands AVPF but do not support any
feedback 
>message it will remove all rtcp-fb-val in the answers.
>To me that looks like support of AVP so why do you want to change the
avpf to avp.

Ok, if it works that way.

So, if I have an MGCF/MGW I can do the following:

- The MGCF answers with AVPF, but without rtcp-fb-val

- The MGCF sends AVP down to the MGW (e.g using H.248)

Regards,

Christer

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

Colin Perkins | 2 Oct 17:03 2007

Re: Working group last call: draft-ietf-avt-rfc3119bis-05.txt

On 4 Sep 2007, at 10:47, Colin Perkins wrote:
> This is to announce a working group last call on the More Loss- 
> Tolerant RTP Payload Format for MP3 Audio (draft-ietf-avt- 
> rfc3119bis-05.txt). This draft corrects some minor mistakes in RFC  
> 3119 (see http://tinyurl.com/2c757d for details of the changes).
>
> Please send any final comments on this draft to the list by 17  
> September 2007. If no substantive issues are raised by that time,  
> we will request the IESG consider this for publication as a  
> Proposed Standard RFC, making RFC 3119 obsolete.

This working group last call has concluded. There were no objections,  
therefore we will send this document to the IESG for publication.

--

-- 
Colin Perkins
http://csperkins.org/

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

Tom Taylor | 4 Oct 04:02 2007

Open issue on hdrext draft

Before the header extension draft can be approved we have to settle two or three 
points that have been raised after the document passed WGLC. One of them is the 
view of the Working Group regarding registration requirements.

Is it the Working Group's intention that:

(a) any SDO can standardize and register a new RTP header extension without IETF
review or consent; or

(b) all RTP header extensions require review and agreement by an IETF expert
before they can be registered; or

(c) all RTP header extensions require IETF consensus before they can be registered.

David Singer had a clear view on this question when he wrote the document in the 
first place. I should let him speak for himself, but his basic idea was to 
encourage registration as an alternative to hard-to-get-rid-of experimental 
identifiers, by making registration a simple process. His preference was thus 
toward alternative (a).

Last time we didn't ask the question in quite these stark terms, and only Magnus 
replied. It's hard to read a consensus from that. Would other people care to 
comment?

Tom Taylor

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

Dave Singer | 4 Oct 06:14 2007
Picon

Re: Open issue on hdrext draft

I don't know if it helps, but in case it does, it might help if I 
'frame' the question and provide some history and rationale for the 
current state.

See below, after Tom's questions...

At 22:02  -0400 3/10/07, Tom Taylor wrote:
>Before the header extension draft can be approved we have to settle 
>two or three points that have been raised after the document passed 
>WGLC. One of them is the view of the Working Group regarding 
>registration requirements.
>
>Is it the Working Group's intention that:
>
>(a) any SDO can standardize and register a new RTP header extension 
>without IETF
>review or consent; or
>
>(b) all RTP header extensions require review and agreement by an IETF expert
>before they can be registered; or
>
>(c) all RTP header extensions require IETF consensus before they can 
>be registered.
>
>David Singer had a clear view on this question when he wrote the 
>document in the first place. I should let him speak for himself, but 
>his basic idea was to encourage registration as an alternative to 
>hard-to-get-rid-of experimental identifiers, by making registration 
>a simple process. His preference was thus toward alternative (a).
>
>Last time we didn't ask the question in quite these stark terms, and 
>only Magnus replied. It's hard to read a consensus from that. Would 
>other people care to comment?

The current RTP specification makes provision for header extensions. 
However, there is no process defined to identify them, or register 
identifiers.  Indeed, the 16-bit field that might be thought of as a 
label in the RTP packets is not clearly defined as such, and there is 
no registration or documentation process defined for it.  This has 
led some to believe that they can use it as they wish, and others to 
believe that it is unusable.

The header extension draft 
<http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-hdrext-13.txt> 
has been before this group since the latter part of 2005.  It defines 
a way to pack multiple header extensions into a packet, and defines a 
way for them to be labelled.  Initial drafts used reverse domain 
names (kind of like Java), and later ones moved to using URIs for the 
labelling.

The question has arisen as to what requirements there should be 
around the documentation and registration of header extensions. 
Currently the draft says that IANA will provide a registry, but only 
for IANA-form URNs, and that to use an IANA-form URN, the extension 
must be defined in a standards-track RFC.  This leaves open, of 
course, the ability of anyone who can make a URI (URL or URN) to 
define and use a header extension.

Historically, IETF specs (including those from this WG) have had 
features or fields defined by 'simple names' that are registered, 
often with provision for an experimental X- prefix.  I think we've 
all observed cases where X- names become by common usage, even with 
the risk of collision and lack of registration that they suffer from.

Clearly, in cases where interop is important, the use of formats or 
labels for which either the registration or documentation cannot be 
assured to be found is undesirable, to the point that specifications 
are usually written to discourage this state.

However, header extensions are defined in RTP (and this is 
re-inforced by the header extension draft) to be ignorable.  It is an 
absolute requirement that the interoperability of an RTP stream 
cannot be affected by the presence or absence of an extension 
(though, of course, its utility might, or it's hard to see what the 
extension is doing).

This led to the current design and status:  there would be 
'preferred, vetted' extensions, defined in RFCs, using IANA URN 
names. But those needing to experiment, or develop an extension for a 
more restricted environment etc., would be able to use other URIs to 
label them, without running risk of collision, and without running 
the risk of an interop problem with systems that were written either 
without knowledge of that extension, or indeed, without knowledge of 
this header extension mechanism at all (i.e. using only RFC 3550 or 
1889).  The author(s) saw this state as preferable to the 'x-' 
method, in this case.

So, I guess I'd like to know whether there are other considerations 
that should be taken into account.  Then, here are some more 
worked-out questions from Tom's various choices:

a) whether the current 'two tier' state, using URIs with an IANA 
registry for RFC-defined extensions is acceptable;

b.i) whether IANA should be asked to document the mapping from any 
URI to a publicly available specification;

b.ii) whether, in order to be entered into such a registry, some IETF 
process such as expert review should be required;

b.iii) whether the 'official' extensions should be considered only 
those registered at IANA;

b.iv) or whether we should move to a simple name system, with IANA 
registry only (presumably, explicitly or implicitly with the x- 
prefix being available);

c) whether the header extension space should be restricted to only 
those extensions defined in RFCs, requiring IETF consensus for any 
header extension.

As said above, the author(s) felt that, given that the header 
extension document constrains these extensions to be small and 
ignorable, that choice (a) provided a reasonable balance and set of 
options, with the other options being either more restrictive than 
needed or potentially problematic in other ways.  But there may be 
other considerations, or other preferences.

I think it would help, if you don't like the current state, you could 
indicate what considerations lead you to another preference.

--

-- 
David Singer
Apple/QuickTime

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

Imed.Bouazizi | 4 Oct 11:32 2007
Picon

RE: Open issue on hdrext draft

Hi,

An RTP gateway (translator/mixer) that for some reason does not
receive/parse the SDP and is then not aware of the mapping between the
RTP header extension and the ID will not be able to process the RTP
packet appropriately. This speaks for IETF agreed registration (option
c).
On the other hand, since the space for 1-byte header IDs is very limited
(14 values only), registration might exhaust the space rather quickly.
One possible solution is to introduce registration for 2-byte headers
and leave 1-byte headers for application-specific usage. However, this
has the limitation that you cannot mix registered and
application-specific extensions into a single RTP packet. It also
imposes length limitations on application-specific extensions.

BTW, am I right in the assumption that this I-D still discourages the
usage of RTP header extensions, as is the case in RFC3550? One might ask
why do we need to register some headers that are just for experimental
purposes?

Regards,
Imed

>-----Original Message-----
>From: ext Dave Singer [mailto:singer <at> apple.com] 
>Sent: 04 October, 2007 07:15
>To: Tom Taylor; IETF AVT WG
>Cc: Cullen Jennings; avt-chairs <at> tools.ietf.org
>Subject: Re: [AVT] Open issue on hdrext draft
>
>I don't know if it helps, but in case it does, it might help 
>if I 'frame' the question and provide some history and 
>rationale for the current state.
>
>See below, after Tom's questions...
>
>
>At 22:02  -0400 3/10/07, Tom Taylor wrote:
>>Before the header extension draft can be approved we have to 
>settle two 
>>or three points that have been raised after the document passed WGLC. 
>>One of them is the view of the Working Group regarding registration 
>>requirements.
>>
>>Is it the Working Group's intention that:
>>
>>(a) any SDO can standardize and register a new RTP header extension 
>>without IETF review or consent; or
>>
>>(b) all RTP header extensions require review and agreement by an IETF 
>>expert before they can be registered; or
>>
>>(c) all RTP header extensions require IETF consensus before 
>they can be 
>>registered.
>>
>>David Singer had a clear view on this question when he wrote the 
>>document in the first place. I should let him speak for himself, but 
>>his basic idea was to encourage registration as an alternative to 
>>hard-to-get-rid-of experimental identifiers, by making registration a 
>>simple process. His preference was thus toward alternative (a).
>>
>>Last time we didn't ask the question in quite these stark terms, and 
>>only Magnus replied. It's hard to read a consensus from that. Would 
>>other people care to comment?
>
>
>The current RTP specification makes provision for header extensions. 
>However, there is no process defined to identify them, or 
>register identifiers.  Indeed, the 16-bit field that might be 
>thought of as a label in the RTP packets is not clearly 
>defined as such, and there is no registration or documentation 
>process defined for it.  This has led some to believe that 
>they can use it as they wish, and others to believe that it is 
>unusable.
>
>The header extension draft
><http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-hdrext-13.txt>
>has been before this group since the latter part of 2005.  It 
>defines a way to pack multiple header extensions into a 
>packet, and defines a way for them to be labelled.  Initial 
>drafts used reverse domain names (kind of like Java), and 
>later ones moved to using URIs for the labelling.
>
>The question has arisen as to what requirements there should 
>be around the documentation and registration of header extensions. 
>Currently the draft says that IANA will provide a registry, 
>but only for IANA-form URNs, and that to use an IANA-form URN, 
>the extension must be defined in a standards-track RFC.  This 
>leaves open, of course, the ability of anyone who can make a 
>URI (URL or URN) to define and use a header extension.
>
>Historically, IETF specs (including those from this WG) have 
>had features or fields defined by 'simple names' that are 
>registered, often with provision for an experimental X- 
>prefix.  I think we've all observed cases where X- names 
>become by common usage, even with the risk of collision and 
>lack of registration that they suffer from.
>
>Clearly, in cases where interop is important, the use of 
>formats or labels for which either the registration or 
>documentation cannot be assured to be found is undesirable, to 
>the point that specifications are usually written to 
>discourage this state.
>
>However, header extensions are defined in RTP (and this is 
>re-inforced by the header extension draft) to be ignorable.  
>It is an absolute requirement that the interoperability of an 
>RTP stream cannot be affected by the presence or absence of an 
>extension (though, of course, its utility might, or it's hard 
>to see what the extension is doing).
>
>This led to the current design and status:  there would be 
>'preferred, vetted' extensions, defined in RFCs, using IANA 
>URN names. But those needing to experiment, or develop an 
>extension for a more restricted environment etc., would be 
>able to use other URIs to label them, without running risk of 
>collision, and without running the risk of an interop problem 
>with systems that were written either without knowledge of 
>that extension, or indeed, without knowledge of this header 
>extension mechanism at all (i.e. using only RFC 3550 or 1889). 
> The author(s) saw this state as preferable to the 'x-' 
>method, in this case.
>
>So, I guess I'd like to know whether there are other 
>considerations that should be taken into account.  Then, here 
>are some more worked-out questions from Tom's various choices:
>
>a) whether the current 'two tier' state, using URIs with an 
>IANA registry for RFC-defined extensions is acceptable;
>
>b.i) whether IANA should be asked to document the mapping from 
>any URI to a publicly available specification;
>
>b.ii) whether, in order to be entered into such a registry, 
>some IETF process such as expert review should be required;
>
>b.iii) whether the 'official' extensions should be considered 
>only those registered at IANA;
>
>b.iv) or whether we should move to a simple name system, with 
>IANA registry only (presumably, explicitly or implicitly with 
>the x- prefix being available);
>
>c) whether the header extension space should be restricted to 
>only those extensions defined in RFCs, requiring IETF 
>consensus for any header extension.
>
>
>As said above, the author(s) felt that, given that the header 
>extension document constrains these extensions to be small and 
>ignorable, that choice (a) provided a reasonable balance and 
>set of options, with the other options being either more 
>restrictive than needed or potentially problematic in other 
>ways.  But there may be other considerations, or other preferences.
>
>I think it would help, if you don't like the current state, 
>you could indicate what considerations lead you to another preference.
>
>--
>David Singer
>Apple/QuickTime
>
>_______________________________________________
>Audio/Video Transport Working Group
>avt <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/avt
>

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

Magnus Westerlund | 4 Oct 13:43 2007
Picon

Re: Open issue on hdrext draft

Imed.Bouazizi <at> nokia.com skrev:
> Hi,
> 
> An RTP gateway (translator/mixer) that for some reason does not
> receive/parse the SDP and is then not aware of the mapping between the
> RTP header extension and the ID will not be able to process the RTP
> packet appropriately. This speaks for IETF agreed registration (option
> c).

I think this is an irrelevant comment as any mixer or translator that
needs to understand the packet content anyway will require to be part of
the signalling context. Thus, I don't think there is a any benefit at
all with static mappings.

> On the other hand, since the space for 1-byte header IDs is very limited
> (14 values only), registration might exhaust the space rather quickly.
> One possible solution is to introduce registration for 2-byte headers
> and leave 1-byte headers for application-specific usage. However, this
> has the limitation that you cannot mix registered and
> application-specific extensions into a single RTP packet. It also
> imposes length limitations on application-specific extensions.

Exactly. There is also an implementation issue with increased complexity
to allow multiple mechanisms.

> 
> BTW, am I right in the assumption that this I-D still discourages the
> usage of RTP header extensions, as is the case in RFC3550? One might ask
> why do we need to register some headers that are just for experimental
> purposes?

Well, read the draft, or even David's mail properly. For experimentation
or proprietary extensions you only need a unique URI, any unique URI
representing your extension will do.

What we are discussing is what rules applies for the IETF URN space,
i.e. the header extensions that will look like they are blessed by IETF.
The current draft version was in fact a) as this specified
"Specification Required" from RFC 2434:

"      Specification Required - Values and their meaning must be
           documented in an RFC or other permanent and readily available
           reference, in sufficient detail so that interoperability
           between independent implementations is possible."

I think A is fine but would probably prefer this to be b) with explicit
rule requiring a publicly available specification. Having an expert look
at any registrations to ensure that they are not totally wacko is in my
book a good thing. But at the same time put minimal bar on the
registrations. Other SDOs should basically be able to send in an email
with a request containing a reference and things usually go through.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund <at> ericsson.com
----------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt


Gmane