[Dime] last review of RFC3588bis before the proto write-up - please comment

jouni korhonen <jouni.nospam@gmail.com> Wed, 21 July 2010 12:41 UTC

Return-Path: <jouni.nospam@gmail.com>
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2C1F3A689D for <dime@core3.amsl.com>; Wed, 21 Jul 2010 05:41:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkyEOKfPMaTd for <dime@core3.amsl.com>; Wed, 21 Jul 2010 05:41:55 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 8C7EA3A6A18 for <dime@ietf.org>; Wed, 21 Jul 2010 05:41:55 -0700 (PDT)
Received: by bwz7 with SMTP id 7so144601bwz.31 for <dime@ietf.org>; Wed, 21 Jul 2010 05:42:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=/GbcY+wbSbHtP+G27LMSyuvL+5uo6dkwy1wxkrrcUqo=; b=NYDzGNSHPPz1T6evAPNFAlmsoZDrayBjPPRNxfsiiAebfY8V99EGK/IZM6AUGut8BI jWU6gSHwTsr/dRiKF3rMsLwocxhdBUU9IIyx6Nec1MHrog9CZyjZDCMk5xhjX0njGXPs VjMNgnTf1u1AbUaEiVZCx/r3Au0aGBAZRIGcs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=xeZyFBulo6HoMTKGHpPkD0x6GXPekqapak/gnU1JkIshdQ8oz8BcyB3mCIsV3LtCXx bIGEgZP6lCC6OPfJWOjFQjKVQR36d1Cu6KaEUxmVhEPLifHoxx6Ux06CiIpDVkfpflPI 7t13q8F5Bypb6xetbUbfV9k72qTlDDjr+Lu4Q=
Received: by 10.204.142.205 with SMTP id r13mr44114bku.207.1279716128377; Wed, 21 Jul 2010 05:42:08 -0700 (PDT)
Received: from a88-114-171-65.elisa-laajakaista.fi (a88-114-171-65.elisa-laajakaista.fi [88.114.171.65]) by mx.google.com with ESMTPS id g11sm29063059bkw.22.2010.07.21.05.42.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 21 Jul 2010 05:42:08 -0700 (PDT)
From: jouni korhonen <jouni.nospam@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 21 Jul 2010 15:42:06 +0300
Message-Id: <92BBD1AA-5740-4057-85C7-66D16018FCA5@gmail.com>
To: dime@ietf.org
Mime-Version: 1.0 (Apple Message framework v1078)
X-Mailer: Apple Mail (2.1078)
Subject: [Dime] last review of RFC3588bis before the proto write-up - please comment
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Wed, 21 Jul 2010 12:41:56 -0000

Hello all,

[in chair mode]

During the process of writing the Proto Write-up for draft-ietf-dime-rfc3588bis-21.txt I made my last review to the document. I started to think few points that might still need some input from the WG.. sorry.

Purely editorial, could be done during AUTH48

 o Section 5.2 step 2. gives an impression that only NAPTR flag "s" is supported.
   However, this is not the case according to the referenced S-NAPTR RFC3958. We
   did "fix" this in one place i.e. examples in Appendix B. where "a" flags use
   is also illustrated. I would add a note regarding "a" flag to the Section 5.2. 

 o  Section 11.5 should explicitly mention the TLS/TCP port number here (before
    IANA actions marked as TBD like the rest of the document does).

 o (suggested by David L.) In Section 3 add a note that the message length is
   always a multiple of 4.

For the following I must to hear comments _before_ I proceed with the completion of the Proto Write-up:

 o RFC3588bis keeps version as 1 so a RFC3588 node does not really know if it is 
   connecting with another RFC3588 or RFC3588bis node, or vice versa. In Sections
   5.4.1, 5.4.2, 5.5.1, 5.5.2, and 7.2 we actually _change_ the existing command
   ABNFs that are more than just adding optional AVPs or sending less AVPs than
   before (for example adding *[AVP] to a request, which means the receiver may
   see AVPs that are beyond the ABNF it knows). According to the RFC3588bis
   Section 1.3.3 this could mean an allocation of a new command code, which again
   would require an allocation of a new application id for applications using the
   new command.. This would impact backwards compatibility with RFC3588.

   Can we expect then receiving errors like 5008 and 5009 when the other end is
   fully RFC3588 compliant and the other is RFC3588bis compliant? Is this unlikely
   to happen? Can a change to AVP multiplicity in ABNF considered such ABNF change
   that requires a new command code?


- Jouni