OK, thanks for the clarification, Brian. -Scott-
-----Original Message----- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] Sent: Thursday, November 23, 2006 04:38 AM Eastern Standard Time To: Hollenbeck, Scott Cc: Harald Alvestrand; [email protected]; 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 PROTECTED] >>Sent: Friday, November 10, 2006 7:53 PM >>To: Hollenbeck, Scott; [email protected]; Ted Hardie >>Subject: RE: Gen-ART review of draft-hollenbeck-epp-rfc3730bis-03 >> >> >> >>--On 10. november 2006 13:59 -0500 "Hollenbeck, Scott" >><[EMAIL PROTECTED]> wrote: >> >> >>>Thanks Harald. More info below. >>> >>>>- 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. >> >>Good. >> >> >>>>- 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. >> >>Yes, that's where I think it belongs. >> >> >>>>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. >> >>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 >> >> >> >> > > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/gen-art >
_______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
