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

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 10 Nov 2006 13:59:14 -0500

Thanks Harald.  More info below.

-Scott- 

> -----Original Message-----
> From: Harald Alvestrand [mailto:[email-masked]] 
> Sent: Friday, November 10, 2006 1:30 PM
> To: [email-masked]; Ted Hardie; Hollenbeck, Scott
> Subject: Gen-ART review of draft-hollenbeck-epp-rfc3730bis-03
> 
> 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

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.

> - 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.

I figured that a description of the tested implementations belongs in
the implementation report.  It seemed out of place in the -bis document.

> 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.

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.

> The document seems otherwise fine to me.

Thanks for the review!

-Scott-

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

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 10 Nov 2006 16:53:29 -0800

> response is correctly identified with the ack command.

Good.

> the implementation report.  It seemed out of place in the -bis document.

Yes, that's where I think it belongs.

> 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