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