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
