[Gen-art] Gen-ART last call review of draft-ietf-mile-rfc6046-bis-05

Alexey Melnikov <alexey.melnikov@isode.com> Sat, 14 January 2012 20:45 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5F54521F8525; Sat, 14 Jan 2012 12:45:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id UpBr7RpzkitK; Sat, 14 Jan 2012 12:45:30 -0800 (PST)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 83C8E21F850D; Sat, 14 Jan 2012 12:45:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1326573928; d=isode.com; s=selector; i=@isode.com; bh=OHudNGfO569PSkoh1cpT/aH0S0C7Ka15N5JPN6dCm/s=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=xErAAI8u0sf6hSIYiM6tV7vSmEiDrGVV7LvWJXGpdDR9EYfafH3fLQv+aOwxrIp5RmP+NC p5C5i1brQzoXhKkEqd+cA5bAaNYbYkDt641GqjbAm2lMdgPZros9xzKYynDvlOkR2IRcOJ r3Jj9ovyi56DNBRExVwj/nGCILPx1rs=;
Received: from [] ( []) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <TxHpZAAV58OI@rufus.isode.com>; Sat, 14 Jan 2012 20:45:27 +0000
Message-ID: <4F11E975.9070307@isode.com>
Date: Sat, 14 Jan 2012 20:45:41 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
To: Brian Trammell <trammell@tik.ee.ethz.ch>, Kathleen Moriarty <kathleen.moriarty@emc.com>, Sean Turner <turners@ieca.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-transfer-encoding: quoted-printable
Cc: gen-art@ietf.org, The IESG <iesg@ietf.org>
Subject: [Gen-art] Gen-ART last call review of draft-ietf-mile-rfc6046-bis-05
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: Sat, 14 Jan 2012 20:45:31 -0000

I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at 

Please resolve these comments along with any other Last Call comments 
you may receive.

Document: draft-ietf-mile-rfc6046-bis-05
Reviewer: Alexey Melnikov
Review Date: 2012–01–14
IETF LC End Date: 2012-01-17
IESG Telechat date: 2012-01-19

Summary: This draft is almost ready for publication as a Proposed 
Standard RFC.

Major issues:

In Section 3:

    The RID callback MUST contain a zero-length entity body
    and a 'RID-Callback-Token' entity header

[Minor issue] "header" --> "header field" (header is the collection of 
all header fields).

    , itself containing a unique
    token generated by the receiving RID system.

I am missing ABNF for the new header field.

    RID systems MUST use TLS version 1.1 [RFC4346] or higher with mutual
    authentication for transport confidentiality, identification, and

Do you mean that a RID client must use X.509 certificates?

    authentication, as in [RFC2818].

I find the whole sentence to be confusing. Note that the rules of RFC 
6125 for certificate verification are stricter than in RFC 2818 and this 
sentence can be read as conflicting with the paragraph below which 
requires use of RFC 6125. What are you trying to say here?

    RID systems MUST provide for the verification of the identity of a
    RID system peer presenting a valid and trusted certificate, by
    verifying the fully-qualified domain name and service name from the
    DNS SRV record, if available, against that stored in the certificate,

I am confused: this is the first time DNS SRV records are mentioned
(BTW, they need a Normative Reference). Earlier text seem to suggest 
that DNS SRV are not used to locate protocol endpoints. If RID is using 
DNS SRV, then information about how it is used is missing from the document.

    as in Section 6 of [RFC6125].

RFC 6125 allows for various options and this paragraph doesn't seem to 
cover all of them. I suggest you check Section of RFC 6120 
for an example of what should be specified (ignore XmppAddr identifier 
type, as it is very XMPP specific). For X.509 SANs which are disallowed, 
you should say so.

Minor issues: (ones issue listed above)

Nits/editorial comments: None