[Dime] [Technical Errata Reported] RFC6733 (4808)

RFC Errata System <rfc-editor@rfc-editor.org> Thu, 22 September 2016 09:01 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 615BA12DA4B for <dime@ietfa.amsl.com>; Thu, 22 Sep 2016 02:01:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.918
X-Spam-Status: No, score=-104.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id OYkT2NJ5JraW for <dime@ietfa.amsl.com>; Thu, 22 Sep 2016 02:01:55 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DB9812DA9B for <dime@ietf.org>; Thu, 22 Sep 2016 02:01:55 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 502D3B81064; Thu, 22 Sep 2016 02:01:55 -0700 (PDT)
To: vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com, jouni.nospam@gmail.com, lionel.morand@orange.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20160922090155.502D3B81064@rfc-editor.org>
Date: Thu, 22 Sep 2016 02:01:55 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/52lwxYlbu19CzwaZWbNVnqJqoX8>
X-Mailman-Approved-At: Thu, 22 Sep 2016 08:14:21 -0700
Cc: zbigniew.rapnicki@computaris.com, dime@ietf.org, rfc-editor@rfc-editor.org
Subject: [Dime] [Technical Errata Reported] RFC6733 (4808)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Sep 2016 09:01:59 -0000

The following errata report has been submitted for RFC6733,
"Diameter Base Protocol".

You may review the report below and at:

Type: Technical
Reported by: Zbigniew Rapnicki <zbigniew.rapnicki@computaris.com>

Section: 1.1.3

Original Text
This document obsoletes RFC 3588 but is fully backward compatible
   with that document.

Corrected Text
This document obsoletes RFC 3588.

When comparing the BNF for the answer messages CEA, DPA, DWA, RAA, STA and ASA it can be seen that FAILED-AVP avp is no longer marked with the * which means it can be present only once in the diameter message.
Previous specification (rfc3588) defines multiple FAILED-AVP avp usage in a single diameter message.
Similar case is for Vendor-Specific-Application-Id AVP definition. 
Previous specification allows multiple usage of Vendor-Id avp in a single message while the new specification defines it as a single mandatory AVP:
<Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
                                     1* [ Vendor-Id ]
                                     0*1{ Auth-Application-Id }
                                     0*1{ Acct-Application-Id }

<Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
                                           { Vendor-Id }
                                           [ Auth-Application-Id ]
                                           [ Acct-Application-Id ]
How this facts applies to the sentence about fully backward compatibility in the section 1.1.3?

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. 

RFC6733 (draft-ietf-dime-rfc3588bis-33)
Title               : Diameter Base Protocol
Publication Date    : October 2012
Author(s)           : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed.
Category            : PROPOSED STANDARD
Source              : Diameter Maintenance and Extensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG