IETF Logo Mail Archive

Re: [Gen-art] Gen-ART LC Review of draft-ietf-dhc-relay-id-suboption-11

Ted Lemon <Ted.Lemon@nominum.com> Fri, 21 December 2012 14:27 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4085221F8CEC; Fri, 21 Dec 2012 06:27:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.576
X-Spam-Level:
X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5-M1IimCRLw; Fri, 21 Dec 2012 06:27:24 -0800 (PST)
Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDE421F8C93; Fri, 21 Dec 2012 06:27:24 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUNRxyxyV6ezR4sIheTm/JB5fY/f81T6O@postini.com; Fri, 21 Dec 2012 06:27:24 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A8FDB1B812D; Fri, 21 Dec 2012 06:27:23 -0800 (PST)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 9F1D1190052; Fri, 21 Dec 2012 06:27:23 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Fri, 21 Dec 2012 06:27:17 -0800
From: Ted Lemon <Ted.Lemon@nominum.com>
To: RAMAKRISHNADTV <RAMAKRISHNADTV@infosys.com>
Thread-Topic: Gen-ART LC Review of draft-ietf-dhc-relay-id-suboption-11
Thread-Index: AQHN3i33Q3+/pWXDrEC14WiRxtRL+pgjvKCAgAAbrIA=
Date: Fri, 21 Dec 2012 14:27:17 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474418FF@mbx-01.win.nominum.com>
References: <BE996F07-CFB7-47F5-8B17-FA651C294FA3@nostrum.com> <F2B120E98374B2448745C1117BDA1854238F281F@BLRKECMBX23.ad.infosys.com>
In-Reply-To: <F2B120E98374B2448745C1117BDA1854238F281F@BLRKECMBX23.ad.infosys.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.1.10]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <59F9D6FCA56827488D2004B1DB7EA177@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "gen-art@ietf.org Review Team" <gen-art@ietf.org>, Bharat Joshi <bharat_joshi@infosys.com>, "ietf@ietf.org List" <ietf@ietf.org>, "draft-ietf-dhc-relay-id-suboption.all@tools.ietf.org" <draft-ietf-dhc-relay-id-suboption.all@tools.ietf.org>
Subject: Re: [Gen-art] Gen-ART LC Review of draft-ietf-dhc-relay-id-suboption-11
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Dec 2012 14:27:25 -0000

On Dec 21, 2012, at 7:48 AM, RAMAKRISHNADTV <RAMAKRISHNADTV@infosys.com> wrote:
> As Ted mentioned, our draft only proposes a new sub-option for relay-agent 
> option which was originally created as part of RFC3046. So, the security 
> considerations for RFC3046 apply to our draft as well. RFC3046 deployments may
> use RFC4030 as explained above. So, we indicated in our draft to refer to 
> both RFC3046 and RFC4030. But there are no specific security issues in the 
> new relay-id sub-option itself to make RFC4030 a MUST.

To put it a bit differently, changing the security considerations for RFC3046 is out of scope for this document.   It could certainly be argued that the security considerations for RFC3046 are too weak, but if that is an argument that someone wants to make, the argument should be made in the context of updating RFC3046, not in the context of adding a new DHCP relay option.

v2.23.0 | Report a Bug | By Email