Subject: Re: [AVT] draft-ietf-avt-hdrext-12

From: Colin Perkins <[email-masked]>
Date: Wed, 1 Aug 2007 11:25:51 +0100

Hi,

[Not as chair]

I don't especially care if we end up with one draft or two. That will  
depend on how similar the proposals are, in terms of header fields,  
and how the namespace is managed.

I do think, however, that we need to document both versions (since  
both are in use), and we need to include a strong recommendation on  
which SHOULD be used for new implementations, and which is for  
backwards compatibility with pre-standards use and SHOULD NOT be used.

Colin

On 31 Jul 2007, at 13:24, Magnus Westerlund wrote:
> Hi,
>
> IETF standards track documents are strong recommendations on how to  
> solve a problem. In many case that doesn't rule out the existence  
> of other solutions. However, it may hurt interoperability and/or  
> complicate  implementations. There is no protocol police that goes  
> ut and stop usage that doesn't follow IETF. In addition the header  
> extension mechanism in RTP is free to use by anyone. So 8+8 is  
> definitely conformant to RFC 3550. One has only to be aware of the  
> limitations they result in. But the desirable future is that anyone  
> in the future that needs this functionality will use RFC XXX (what  
> ever the number will be for draft-ietf-avt-hdrext).
>
> As I see it the best we can do for the future is to select one  
> solution and go forward. And hope that most future users out there  
> uses that single solution. That is in my view the best way and will  
> maximize interoperability in the future. I can also hope that some  
> that uses their own extension mechanism will move to the IETF  
> defined one.
>
>> Which is why I think I would like to document them in one document,
> > with 4+4 support required and 8+8 documented and mentioned and
> > support for it optional.
>
> I hope that it is clearer why I propose to select only a single one  
> and stick with that. I don't want to have two of them in the  
> document because that will result in that everyone will have to  
> implement both. IETF has become worse and worse at selecting a  
> single solution and sticking with it. I asked the question about  
> deployement, because as I see it there are some difference in the  
> technical tradeoff but if you had a large deployement that would  
> still be compatible with the tag value mechanism in the current WG  
> document then I think it would have been reasonable to switch to  
> the 8+8 tradeoff. However, as you aren't forthcomming with that  
> information there is no data to for determinging that 8+8 would be  
> a more reasonable choice then 4+4. I am also worried about the ID  
> numberspace and control over that.
>
> I am worried about the 8+8 ID namespace that may make it difficult  
> to adopt. draft-ietf-avt-hdrext contains a larger namespace that is  
> mapped onto the ID values. This as 16 values would never last. But  
> the same is also true for 256 values. Thus the same rule could be  
> applied. However, that requires that IETF gets full control of at  
> least a substantial block of the field values. There must be full  
> agreement between the original definers and IETF that control is  
> transfered. In addition it must be known which values are used and  
> already handed out. The only alternative for a 8+8 solutio would be  
> to go with another header extension identifier.
>
> Because of that I would propose that we go forward with a document  
> that only provides the 4+4 solution.
>
> Dave Singer skrev:
>> If that is a problem, how about we add a sentence to the 4+4 spec.  
>> saying "A variant of this design, using 8-bit length and tag  
>> fields, also exists, using a different value for the field that  
>> takes the value 0xBEDE here."?
>
> There might be value in pointing out that there exist similar but  
> not IETF defined solutions for the header extension field. However,  
> I wonder if it would confuse more then any benefit it gives. But my  
> attempt is the following:
>
> "At least one similar solution is known to exist for solving the  
> first drawback.  That solution uses different field lengths, but  
> also another 16-bit identifier value, thus no risk of misstake  
> between them exist. The resolution of the second drawback and  
> slightly differnt tradebacks resulted in the solution present in  
> this document."
>
> The above is written based on that the solution you documents did  
> not try to resolve the namespace issues to provide an basically  
> unlimited number of header extensions.
>
> I might have not given the impression before that there is benefit  
> in document the 8+8 solutions that are in use. I think it would be  
> best that it is documented in an informational RFC. However, I  
> would like to see good wording in there that this is a  
> documentation of something that is used, but that it is prefered to  
> use draft-ietf-avt-hdrext.
>
> 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: [email-masked]
> ----------------------------------------------------------------------
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt

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

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt