Re: [Crisp] Re: Last Call Comments on XPC
Andrew Newton <andy@hxr.us> Thu, 24 August 2006 16:24 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGI0e-0005ZI-UA; Thu, 24 Aug 2006 12:24:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGI0d-0005Y7-Qy; Thu, 24 Aug 2006 12:24:47 -0400
Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGI0Y-0002rG-Jq; Thu, 24 Aug 2006 12:24:47 -0400
Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Thu, 24 Aug 2006 11:44:26 -0400 id 0158835F.44EDC95A.00006A38
Message-ID: <44EDC955.30405@hxr.us>
Date: Thu, 24 Aug 2006 11:44:21 -0400
From: Andrew Newton <andy@hxr.us>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [Crisp] Re: Last Call Comments on XPC
References: <OF9CDAAF1B.D1563283-ONC12571D4.003411FA-C12571D4.00353813@notes.denic.de>
In-Reply-To: <OF9CDAAF1B.D1563283-ONC12571D4.003411FA-C12571D4.00353813@notes.denic.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: Marcos Sanz/Denic <sanz@denic.de>, iesg@ietf.org, crisp@ietf.org
X-BeenThere: crisp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Cross Registry Information Service Protocol <crisp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/crisp>, <mailto:crisp-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:crisp@ietf.org>
List-Help: <mailto:crisp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/crisp>, <mailto:crisp-request@ietf.org?subject=subscribe>
Errors-To: crisp-bounces@ietf.org
Marcos Sanz/Denic wrote: > Hi Sam, > >> First, you don't specify enough about SASL for an interoperable >> implementation. PLease see the application protocol requirements in >> RFC 4222 for what you need to specify. My preference is that you >> reference RFC 4222 not 2222. > > Ok, first of all I am not the author of the draft, it's Andy. But anyway > I'll take a look at 4422 (it's pretty new) and review XPC with that new > light. OH! 4422! I starting reading a BCP on OSPF and couldn't figure out what it had to do with this. First, I sent email to one of the authors of 4422 last year asking for review, and got an "I'm busy" response. Though he did say he thought we were on the right track. I've looked at 4422, and have identified several areas where XPC needs either better documentation or revision. However, I'd appreciate more than just a vague, "you need to do more". After all, there's a good chance I might miss something in those 33 pages. That being said, I do have a couple of very specific questions: 1) I understand what the Authorization Identity String (Section 3.4.1) is, I'm just unsure where it is to be used. I was under the impression that where it is to be used was specific to each SASL mechanism. 2) Section 3.4 notes that one of the purposes of the challenges and response is "authenticate the server to the client". Does a client have to request this authentication? It isn't clear to me that I need to specific protocol interactions for this particular use case or if that is covered in the general requirements for a protocol (as listed in Section 4). 3) Section 4, number 1 says that a "service" name must be specified. I didn't readily understand in which protocol operation it is to be specified. Also, would this be different than the identifier we have already picked to identify the protocol in the version information: iris.xpc1. -andy _______________________________________________ Crisp mailing list Crisp@ietf.org https://www1.ietf.org/mailman/listinfo/crisp
- [Crisp] Re: Last Call Comments on XPC Marcos Sanz/Denic
- Re: [Crisp] Re: Last Call Comments on XPC Andrew Newton
- Re: [Crisp] Re: Last Call Comments on XPC Andrew Newton