[Gen-art] GEN-Art review of draft-ietf-dhc-relay-id-suboption-07

Sean Turner <turners@ieca.com> Tue, 06 October 2009 19:26 UTC

Return-Path: <turners@ieca.com>
X-Original-To: gen-art@core3.amsl.com
Delivered-To: gen-art@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2F8A3A6833 for <gen-art@core3.amsl.com>; Tue, 6 Oct 2009 12:26:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.946
X-Spam-Level:
X-Spam-Status: No, score=-2.946 tagged_above=-999 required=5 tests=[AWL=-0.347, 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 nSs6NeWHIKeE for <gen-art@core3.amsl.com>; Tue, 6 Oct 2009 12:26:56 -0700 (PDT)
Received: from smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by core3.amsl.com (Postfix) with SMTP id 8D3DE3A6806 for <gen-art@ietf.org>; Tue, 6 Oct 2009 12:26:56 -0700 (PDT)
Received: (qmail 28888 invoked from network); 6 Oct 2009 19:28:32 -0000
Received: from unknown (HELO thunderfish.local) (turners@96.231.119.126 with plain) by smtp106.biz.mail.re2.yahoo.com with SMTP; 6 Oct 2009 19:28:32 -0000
X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To-
X-YMail-OSG: xzkjgAMVM1nyVbAipvRfvu59kbbAQkKhJ8soiAu3E5V09Jjrzxbyz1WDZuBx87QdmMVxo7fQBGvQCUUFuFKzI_ZDVqiCtfeMDPBSNgXpCQ0.Fujy2v6_.eCvcPLsfnUanhgd_kyPerc7hIqr9pjAHfllpIzO9fFM6hWIj5CAIq857MqJkl798Lr0EiX0NIli7oORzwkXZCl6r905PB6DDDLGHIrD4OPaJT_WT9RD0TBM86mPVt4PPcCJhGAgal_N4ptWYmIjOsaiHsf5ruMZ5ICgyIbofTkKchuujMy7dtYRfxAm.gT9m7LpagpCCA99BfDzku.ehZY1Haa4rA8fVFiMUJiqdiVQYb7sbc9ArChDSGntPxReVFUcEfpAoHYD4_B4sFz.JTouE7hdo6_gmdGH0dL3uQ--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4ACB9A5F.4090300@ieca.com>
Date: Tue, 06 Oct 2009 15:28:31 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: draft-ietf-dhc-relay-id-suboption.all@tools.ietf.org, General Area Review Team <gen-art@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [Gen-art] GEN-Art review of draft-ietf-dhc-relay-id-suboption-07
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 06 Oct 2009 19:26:58 -0000

I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve
these comments along with any other Last Call comments you may receive.

Document: draft-ietf-dhc-relay-id-suboption-07
Reviewer: Sean Turner
Review Date: 2009-10-06
IETF LC End Date: 2009-10-16
IESG Telechat date: N/A

Summary: This draft is on the right track but has open issues, described
in the review

Major #1 It's not clear to me whether both relay identifier types MUST
be supported or whether implementations are free to pick which one(s)
they support?  If you add one of the following (or something similar) in
Section 5 then my concern is addressed:

Implementations MUST support both RELAY_IDENTIFIER_DUID and
RELAY_IDENTIFIER_ASCII.

Implementations MUST support RELAY_IDENTIFIER_DUID and [SHOULD or MAY]
support RELAY_IDENTIFIER_ASCII.

Implementations MUST support RELAY_IDENTIFIER_ASCII and [SHOULD or MAY]
support RELAY_IDENTIFIER_DUID.

Major #2  In the security considerations it says look to RFC 3046 and
RFC 4030 for security considerations and then says SHOULD use the relay
agent authentication option from RFC 4030.  RFC 3046 is targeted at
network infrastructures that are "trusted and secure" and RFC 4030
allows the relay agent to be part of this trusted and secure network.
If an implementation doesn't use the relay agent authentication option,
then the relay agent can't be part of the "trusted and secure" network.
  This makes me think that the relay agent authentication option from
RFC 4030 ought to be a MUST not a SHOULD?

spt