Re: [AVTCORE] [Technical Errata Reported] RFC3550 (4192)

[Julius Friedman <[e-mail]>]

Thanks for your response.

I do believe your incorect and plese keep in mind that it is also a
security issues to indicate what part of the payload changes due to
encryption.

The indication does not change only satisfied the required information
without bias for padding.

The data is more accurate as I indicated changed because the parties will
be able to track padding if required in their own counters and if they dont
they will never calculate more or less bytes then actually sent which is
possible with the current text if the payload required padding.

Please also keep in mind that if I didn't set padding because it wasn't
required then no change is required also if I forgot to set padding and
thus proves itself the change is warranted.

Individuals who choose to follow this old way of thinking invite themselves
to security issues and overhead of calculating redundantly included
information as the length of a rtcp packet already included padding for
that reason.

Think carefully about the above scenarios and also that the end rate you
specify would actually be more accurate.

I have also submitted erratta for rfc2435 and rfc2326 have they been
addressed?

Sincerely,
Julius Friedman
On Dec 5, 2014 1:40 PM, "Stephen Casner" <[e-mail]> wrote:

> I do not agree with the proposed change.  As stated in the referenced
> text, the sender's octet count was intended to be used to estimate the
> average payload data rate.  This is about the payload only, without
> any consideration of packetization.
>
>                                                         -- Steve
>
> On Wed, 3 Dec 2014, RFC Errata System wrote:
>
> > The following errata report has been submitted for RFC3550,
> > "RTP: A Transport Protocol for Real-Time Applications".
> >
> > --------------------------------------
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata_search.php?rfc=3550&eid=4192
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: Julius Friedman <[e-mail]>
> >
> > Section: 6.4.1
> >
> > Original Text
> > -------------
> > sender's octet count: 32 bits
> >       The total number of payload octets (i.e., not including header or
> >       padding) transmitted in RTP data packets by the sender since
> >       starting transmission up until the time this SR packet was
> >       generated.  The count SHOULD be reset if the sender changes its
> >       SSRC identifier.  This field can be used to estimate the average
> >       payload data rate.
> >
> > Corrected Text
> > --------------
> > sender's octet count: 32 bits
> >       The total number of payload octets
> >       transmitted in RTP data packets by the sender since
> >       starting transmission up until the time this SR packet was
> >       generated.  The count SHOULD be reset if the sender changes its
> >       SSRC identifier.  This field can be used to estimate the average
> >       payload data rate.
> >
> > Notes
> > -----
> > Where as payload octets is defined as the total number of data octets
> contained in a Rtp Packet minus the 12 Header octets for Rtp Packets.
> >
> > Padding octets as well as octets which occur in the contributing source
> list should also be included as they may differ on a per packet basis and
> would make the total calculation invalid.
> >
> > During TCP communication any application layer header should NOT be
> included in the total bytes count when including the header length.
> >
> > Any Rtcp packet counters should include the total length of the packet
> (header, padding and any other data).
> >
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party (IESG)
> > can log in to change the status and edit the report, if necessary.
> >
> > --------------------------------------
> > RFC3550 (draft-ietf-avt-rtp-new-12)
> > --------------------------------------
> > Title               : RTP: A Transport Protocol for Real-Time
> Applications
> > Publication Date    : July 2003
> > Author(s)           : H. Schulzrinne, S. Casner, R. Frederick, V.
> Jacobson
> > Category            : DRAFT STANDARD
> > Source              : Audio/Video Transport
> > Area                : Real-time Applications and Infrastructure
> > Stream              : IETF
> > Verifying Party     : IESG
> >
> >
>