RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Reported (1)

RFC 4570, "Session Description Protocol (SDP) Source Filters", July 2006

Source of RFC: mmusic (rai)

Errata ID: 5416
Status: Reported
Type: Editorial

Reported By: Simon Rankine
Date Reported: 2018-07-06

Section 3.2.5 says:

a=source-filter incl IN IP6 FF0E::11A 2001:DB8:1:2:240:96FF:FE25:8EC9

It should say:

a=source-filter: incl IN IP6 FF0E::11A 2001:DB8:1:2:240:96FF:FE25:8EC9

Notes:

Normative text in section 3 requires a colon after the source-filter attribute, but the ipv6 example in section 3.2.5 omits this colon.

Status: Rejected (3)

RFC 4570, "Session Description Protocol (SDP) Source Filters", July 2006

Source of RFC: mmusic (rai)

Errata ID: 55
Status: Rejected
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Rejected by: Ross Finlayson
Date Rejected: 2006-11-01

Section 6 says:

        Purpose:            See this document
        Reference:          This document
        Values:             See this document, and registrations below

It should say:

        Purpose:            See RFC 4632
        Reference:          RFC 4632
        Values:             See RFC 4632

Notes:

The filled out SDP attribute registration template in the IANA
Considerations (Section 6) on page 10 contains improper wording
-- either just being garbage (there are no 'registrations below'
in the RFC), or getting inappropriate when extracted from the RFC
and included in a stand-alone IANA document.

--VERIFIER COMMENT--
Thanks for the comments. It would have been nice if these very minor
errors could have been corrected prior to RFC publication. However,
I'm not convinced that they are significant enough to warrant a RFC
Errata note. (If, however, the RFC editor disagrees, then I could
certainly go ahead and do this.)

Errata ID: 802
Status: Rejected
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Rejected by: Ross Finlayson
Date Rejected: 2006-11-01

Section 1 says:

   Applications and hosts may also
   share the source-filter information with network elements (e.g., with
   routers using [IGMPv3]) so they can potentially perform the traffic
|  filtering operation further "upstream," closer to the source(s).

It should say:

   Applications and hosts may also
   share the source-filter information with network elements (e.g., with
   routers using [IGMPv3]) so they can potentially perform the traffic
|  filtering operation further "upstream", closer to the source(s).

Notes:

quoting style

from pending

--VERIFIER COMMENT--
Thanks for the comments. It would have been nice if these very minor
errors could have been corrected prior to RFC publication. However,
I'm not convinced that they are significant enough to warrant a RFC
Errata note. (If, however, the RFC editor disagrees, then I could
certainly go ahead and do this.)

Errata ID: 804
Status: Rejected
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Rejected by: Ross Finlayson
Date Rejected: 2006-11-01

Section 1 says:

   Use of source-filters do not
   corrupt the ASM semantics but provide more control for receivers, at
   their discretion.

It should say:

|  Use of source-filters does not
|  corrupt the ASM semantics but provides more control for receivers, at
   their discretion.

Notes:

from pending

--VERIFIER COMMENT--
Thanks for the comments. It would have been nice if these very minor
errors could have been corrected prior to RFC publication. However,
I'm not convinced that they are significant enough to warrant a RFC
Errata note. (If, however, the RFC editor disagrees, then I could
certainly go ahead and do this.)

Report New Errata