Subject: [Gen-art] Gen-ART review of draft-hollenbeck-epp-rfc3730bis-03

From: Harald Alvestrand <[email-masked]>
Date: Fri, 10 Nov 2006 10:30:11 -0800

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-hollenbeck-epp-rfc3730bis-03
Reviewer: Harald Tveit Alvestrand
Review Date: 2006-11-10
IETF LC End Date: 2006-11-11
Summary: One question about a protocol change, otherwise OK

Since this document is going to Draft, I did not review the base 
technology, or the unchanged parts of the documents. I focused on the 
changes from the RFC version and the implementation report.

The "changes from RFC 3730" section seems a clear and complete list of the 
changes found by using a diff tool; this is very good.

The changelist documents one protocol change: the <poll> acknowledgement 
response changed the value of the message ID by 1 - from "the next message 
available" to "the message that has been acknowledged". I would be happier 
about this if two things had been stated:

- The reason for the change (in the draft), and whether or not it affects 
interoperability with old implementations
- That the tested implementations actually implement the changed protocol, 
not the RFC 3730 protocol (in the implementation report).

The last is implicit in the fact that the implementation reports refer to 
the -bis documents, so this may be OK. IESG's call.

There is one feature that has only been tested for one client/server pair: 
<response><extValue>. It seems an easy value to support, so I would not 
think it worrisome - but it's a departure from the formal requirements.

The document seems otherwise fine to me.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 23 Nov 2006 10:20:06 -0500

OK, thanks for the clarification, Brian.

-Scott-

 -----Original Message-----
From: 	Brian E Carpenter [mailto:[email-masked]]
Sent:	Thursday, November 23, 2006 04:38 AM Eastern Standard Time
To:	Hollenbeck, Scott
Cc:	Harald Alvestrand; [email-masked]; Ted Hardie
Subject:	Re: [Gen-art] RE: Gen-ART review of draft-hollenbeck-epp-rfc3730bis-03

I will certainly not make this a DISCUSS. It is one of the
things left vague in 2026 (see draft-carpenter-rfc2026-critique-02
for my own thoughts on this topic).

    Brian

Hollenbeck, Scott wrote:
> Ted,
> 
> How do you wish to approach the "two implementation" issue?  I've
> documented successful testing with one client and one server for the
> feature Harald noted.  Should I try to discover who else has implemented
> the feature, or is this adequate to meet the "two independent
> implementations" requirement?
> 
> -Scott-
> 
> 
>>-----Original Message-----
>>From: Harald Alvestrand [mailto:[email-masked]] 
>>Sent: Friday, November 10, 2006 7:53 PM
>>To: Hollenbeck, Scott; [email-masked]; Ted Hardie
>>Subject: RE: Gen-ART review of draft-hollenbeck-epp-rfc3730bis-03
>>
>>
>>
>>--On 10. november 2006 13:59 -0500 "Hollenbeck, Scott" 
>><[email-masked]> wrote:
>>
>>
>>>Thanks Harald.  More info below.
>>>
>>>Sure, I can add the reason in the appendix.  Reality is that
>>>implementations have been doing what's now specified 
>>
>>instead of what's
>>
>>>in the old RFC because the spec was wrong.  The msgID isn't 
>>
>>needed to
>>
>>>retrieve a message, only to ack and dequeue it, so it 
>>
>>doesn't need to be
>>
>>>returned in the response.  The current text confirms that an ack
>>>response is correctly identified with the ack command.
>>
>>Good.
>>
>>
>>>I figured that a description of the tested implementations 
>>
>>belongs in
>>
>>>the implementation report.  It seemed out of place in the 
>>
>>-bis document.
>>
>>Yes, that's where I think it belongs.
>>
>>
>>>I was working under the assumption that the requirement was 
>>
>>met because
>>
>>>the client and server implementations were developed 
>>
>>independently.  Two
>>
>>>server implementations and 2 client implementations would 
>>
>>have been four
>>
>>>implementations in total.
>>
>>We've discussed this a number of times; the MIB criteria, for 
>>instance, are 
>>explicit about 2 server implementations, but don't mandate 2 
>>clients, since 
>>any MIB-walker can be used to verify that information is 
>>present. But I 
>>think the consensus has tended to end up with 2 clients, 2 
>>servers, since 
>>they actually perform different roles - in this case, we have 
>>only one 
>>generation code and one parsing code for the element in question.
>>
>>Good point for clarification if we ever get around to 
>>revisiting that text.
>>
>>I'd be happier with at least 2 servers that generate the 
>>value. But I'll 
>>leave that to the IESG; I don't see it as a big deal.
>>
>>              Harald
>>
>>
>>
>>
> 
>