Thanks Harald. More info below. -Scott-
> -----Original Message----- > From: Harald Alvestrand [mailto:[EMAIL PROTECTED] > Sent: Friday, November 10, 2006 1:30 PM > To: [email protected]; 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 protected] https://www1.ietf.org/mailman/listinfo/gen-art
