There are cases when policy requirements require an epp server
implementation to treat an OPTIONAL request element as mandatory. If
such OPTIONAL element is not provided the server could return 2308
error code ("Data management policy violation").
Is such a treatment of an OPTIONAL element a violation of epp protocol?
Janusz Sienkiewicz
> -----Original Message-----
> From: janusz sienkiewicz [mailto:janusz <at> libertyrms.info]
> Sent: Thursday, October 09, 2003 11:06 AM
> To: ietf-provreg <at> cafax.se
> Subject: [ietf-provreg] optional elements and server policy
>
>
> There are cases when policy requirements require an epp server
> implementation to treat an OPTIONAL request element as mandatory. If
> such OPTIONAL element is not provided the server could return 2308
> error code ("Data management policy violation").
>
> Is such a treatment of an OPTIONAL element a violation of
> epp protocol?
Personally, I don't think so. The 2308 error code exists to make the
situation you described obvious.
-Scott-
I just spent a few minutes writing client and server software in perl to send and receive EPP <check> commands and responses. It's very doable. Does anyone think that they might find it useful to have a documented way to use EPP over UDP for domain availability checking? I'm thinking that registries might find it useful to provide a UDP service for high-volume, no-session-required domain checking. People that want only availability information might find a UDP-based client more useful than whois. -Scott-
Hollenbeck, Scott wrote: >I just spent a few minutes writing client and server software in perl to >send and receive EPP <check> commands and responses. It's very doable. >Does anyone think that they might find it useful to have a documented way to >use EPP over UDP for domain availability checking? > >I'm thinking that registries might find it useful to provide a UDP service >for high-volume, no-session-required domain checking. People that want only >availability information might find a UDP-based client more useful than >whois. > >-Scott- > > Sure, but this does also simplify DoS attacks against registries that have to perform availability checks using their SQL backend. But it cannot hurt to have such a spec handy, even if for internal purposes onlyBest regards, -jens
First, one has to presume that this is external to the PROVREG WG effort. (The charter would forbid it on a number of grounds.) Nevertheless, this ought to be considered - and recall that this list will outlive the WG. (It's not a matter of scope for the list.) Congestion control was one of the issues that we (PROVREG WG) got hit with (in the IESG comments). But with this being UDP, I don't think that congestion is a concern. (UDP is UDP, no retransmission. Unless something else is screwed up in design - no amplification of traffic load.) Who gets to be the client? I would assume there are a lot more who would want this data than just the registrars. How does this fit next to what the CRISP WG is chartered to do? The difference between transports (UDP vs. connection oriented) is significant. On Mon, 2003-10-20 at 12:38, Jens Wagner wrote: > Hollenbeck, Scott wrote: > > >I just spent a few minutes writing client and server software in perl to > >send and receive EPP <check> commands and responses. It's very doable. > >Does anyone think that they might find it useful to have a documented way to > >use EPP over UDP for domain availability checking? > > > >I'm thinking that registries might find it useful to provide a UDP service > >for high-volume, no-session-required domain checking. People that want only > >availability information might find a UDP-based client more useful than > >whois.(Continue reading)
Ed Lewis wrote: > > How does this fit next to what the CRISP WG is chartered to do? The > difference between transports (UDP vs. connection oriented) is > significant. I have asked for time to present a udp transport for IRIS in the CRISP working group in Minneapolis. One of the uses could be for domain availability. -andy
> First, one has to presume that this is external to the PROVREG WG > effort. (The charter would forbid it on a number of grounds.) > Nevertheless, this ought to be considered - and recall that this list > will outlive the WG. (It's not a matter of scope for the list.) Right -- I just figured that there are people on the list who might have an interest in the topic. > Who gets to be the client? I would assume there are a lot more who > would want this data than just the registrars. > > How does this fit next to what the CRISP WG is chartered to do? The > difference between transports (UDP vs. connection oriented) is > significant. This is something that would need to be looked at. Andy and I had a chance to talk live yesterday; I think we both believe that there might be some use cases that avoid an intersection with CRISP. There _might_ be for a registry that wants to deploy both protocols. At a minimum, a light EPP UDP <check> might be a useful feature for a registry that wants to deploy EPP, but not the CRISP protocol. Anyway, it's something to talk about over a beer in Minneapolis. -Scott-
RSS Feed29 | |
|---|---|
61 | |
44 | |
27 | |
42 | |
72 | |
7 | |
16 | |
6 | |
73 | |
1 | |
2 | |
39 | |
82 | |
26 | |
161 | |
35 | |
8 | |
27 | |
17 | |
64 | |
20 | |
19 | |
3 | |
1 | |
9 | |
4 | |
3 | |
7 | |
2 | |
15 | |
48 | |
108 | |
16 | |
35 | |
34 | |
1 | |
11 | |
8 | |
33 | |
30 | |
5 | |
6 | |
4 | |
2 | |
5 | |
3 | |
13 | |
16 | |
1 | |
36 | |
7 | |
19 | |
9 | |
11 | |
4 | |
2 | |
15 | |
28 | |
32 | |
4 | |
5 | |
18 | |
5 | |
52 | |
30 | |
68 | |
27 | |
2 | |
1 | |
1 | |
7 | |
20 | |
2 | |
3 | |
1 | |
4 | |
24 | |
16 | |
10 | |
24 | |
7 | |
7 | |
4 | |
2 | |
15 | |
10 | |
28 | |
132 | |
135 | |
37 | |
87 | |
106 | |
95 | |
121 | |
68 | |
114 | |
87 | |
47 | |
21 | |
25 |
