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

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 15 Nov 2006 07:31:04 -0500

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.
> >> - 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-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Nov 2006 10:37:23 +0100

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