[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] draft-ietf-avt-hdrext-12
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: magnus.westerlund at ericsson.com
----------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt