Re: [HOKEY] AD review of draft-ietf-hokey-arch-design

Glen Zorn <glenzorn@gmail.com> Mon, 31 October 2011 06:10 UTC

Return-Path: <glenzorn@gmail.com>
X-Original-To: hokey@ietfa.amsl.com
Delivered-To: hokey@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4AE021F8C7A for <hokey@ietfa.amsl.com>; Sun, 30 Oct 2011 23:10:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ij0YUT2JrgH2 for <hokey@ietfa.amsl.com>; Sun, 30 Oct 2011 23:10:27 -0700 (PDT)
Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3F04021F8C13 for <hokey@ietf.org>; Sun, 30 Oct 2011 23:10:27 -0700 (PDT)
Received: by pzk34 with SMTP id 34so16472078pzk.9 for <hokey@ietf.org>; Sun, 30 Oct 2011 23:10:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=fFOkOj36ChOZcW5iXKiZANSeMKqwMk8zbLRHSGLtXOU=; b=C4T6q6rMACUmiVU7d9jNKCwTAQy2VUMGWI6wqztIkXuTC+ed/BqM0scRbPFOyYbQij vZbQtA5ksU5MH5+bLMiNLEMNWJlJB66WHT+ngxnDetbO5fs0vQeWKoTA1gF0YYKckIMZ B3hzjb/76uewVZ35EbL8Top1GA0QG04Fuy0Z0=
Received: by 10.68.7.105 with SMTP id i9mr12362135pba.120.1320041413593; Sun, 30 Oct 2011 23:10:13 -0700 (PDT)
Received: from [192.168.1.99] (ppp-171-96-16-9.revip8.asianet.co.th. [171.96.16.9]) by mx.google.com with ESMTPS id y6sm36518251pbi.5.2011.10.30.23.10.09 (version=SSLv3 cipher=OTHER); Sun, 30 Oct 2011 23:10:11 -0700 (PDT)
Message-ID: <4EAE3BBD.2050706@gmail.com>
Date: Mon, 31 Oct 2011 13:10:05 +0700
From: Glen Zorn <glenzorn@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <4EA4463B.6000304@cs.tcd.ie> <4EAC1AF2.6060207@net-zen.net>
In-Reply-To: <4EAC1AF2.6060207@net-zen.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Glen Zorn <gwz@net-zen.net>, hokey@ietf.org
Subject: Re: [HOKEY] AD review of draft-ietf-hokey-arch-design
X-BeenThere: hokey@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: HOKEY WG Mailing List <hokey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hokey>, <mailto:hokey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hokey>
List-Post: <mailto:hokey@ietf.org>
List-Help: <mailto:hokey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hokey>, <mailto:hokey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Oct 2011 06:10:27 -0000

On 10/29/2011 10:25 PM, Glen Zorn wrote:
> On 10/23/2011 11:52 PM, Stephen Farrell wrote:
> 
> (pasted from the attachment)
> 
>> not quite nits:
>>
>> - I realise that this document references lots of others that define
>> things, but a bit of ascii art at the start would have been helpful.
>> Its not obvious where e.g. the "ER server" might live from the
>> current text.
> 
> Actually I removed the ASCII art that was there because I thought that
> it was way confusing.  I suppose that it can be put back.

Looking again at the ASCII art I removed, it doesn't appear to me to be
what you're asking for anyway; it it's necessary, it will take awhile
(i.e., > 1 hour to do...

...

>> - p8 - what is a "HOKEY server"?
> 
> I think that it is generic term for a server supporting hand-over keying
> -- could be a ER server or an AAK server, for example.
> 
>> should that be in the terminology
>> section?
> 
> Since it seems to appear only once, maybe we could just try to rephrase
> the sentence?

Here's a first cut:

OLD:
   To provide better deployment scalability, there should be no
   requirement for co-location of the HOKEY server and AAA servers or
   proxies.  Separation of these entities may cause problems with
   routing, but allows flexibility in deployment and implementation.

NEW:
   To provide better deployment scalability, there should be no
   requirement for co-location of entities proving handover keying
   services (e.g., ER servers) and AAA servers or proxies.  Separation
   of these entities may cause problems with routing, but allows greater
   flexibility in deployment and implementation.

...