The IESG wrote:
> as a Proposed Standard
Some general questions about this draft:
1 - Has anybody implemented it ?
2 - If so, do test servers exist for client developers ?
3 - Why is LWZ limited to UDP, desperately trying to solve
various size issues with delated XML and other tricks ?
4 -
Frank Ellermann wrote:
Some general questions about this draft:
1 - Has anybody implemented it ?
Yes. See http://iris.verisignlabs.com/blojsom/blog/iris/
2 - If so, do test servers exist for client developers ?
Yes. See above. Additionally, see the archives of the CRISP wg.
3 - Why is
Frank,
> Some general questions about this draft:
>
> 1 - Has anybody implemented it ?
Yes, we have implemented it (as of ID-version 05). VeriSign, too. I've
heard there is at least another implementation.
> 2 - If so, do test servers exist for client developers ?
I can't provide (yet) with a
At 3:46 PM +0200 8/15/06, Frank Ellermann wrote:
>
>4 - Could a server just offer a whois interface and be done
>with it ?
Andy and Marcos seem to have tackled the other issues you
raise, but I'd like to point out the following from the charter:
>Specific topics that are NOT goals of this WG
I notice that this transport provides no authentication of the data
that is retrieved.
The security considerations needs to discuss the potential attacks if
an attacker modifies this public data. The security considerations
section also needs to point to best practice for avoiding UDP
reflectio
Marcos Sanz/Denic wrote:
> open source implementation: http://iris.verisignlabs.com/
Thanks, that should help client developers to figure it out.
>> 4 - Could a server just offer a whois interface and be done
>> with it ?
> I don't understand this question.
I'm not exactly happy with LW
Andrew Newton wrote:
>> 3 - Why is LWZ limited to UDP, desperately trying to solve
>> various size issues with delated XML and other tricks ?
> TCP is handled by XPC and BEEP.
But those are the (complex) protocols for more serious tasks
than only "whois" queries, updates / confidential data
Harald Alvestrand wrote:
There's nothing in the document that says "if you want to send 4000
requests, and 70 out of the first 100 get lost, you should slow down
your sending rate to that server".
I just checked the simple user-drive, cli client I wrote and it doesn't
retransmit at all (perha
Sam Hartman wrote:
I notice that this transport provides no authentication of the data
that is retrieved.
The security considerations needs to discuss the potential attacks if
an attacker modifies this public data. The security considerations
section also needs to point to best practice for av
> "Andrew" == Andrew Newton <[EMAIL PROTECTED]> writes:
Andrew> Sam,
Andrew> For the second case, you are referring to BCP 38, correct?
Andrew> This was mentioned on the wg list by William Leibzon, and
Andrew> should have been incorporated into the draft. Thanks for
Andre
On Wed, Aug 16, 2006 at 11:55:58AM -0400, Andrew Newton wrote:
> Harald Alvestrand wrote:
> >There's nothing in the document that says "if you want to send 4000
> >requests, and 70 out of the first 100 get lost, you should slow down
> >your sending rate to that server".
>
> I just checked the si
Hi,
On Aug 16, 2006, at 17:55, Andrew Newton wrote:
Harald Alvestrand wrote:
There's nothing in the document that says "if you want to send
4000 requests, and 70 out of the first 100 get lost, you should
slow down your sending rate to that server".
I just checked the simple user-drive, cli
Lars Eggert wrote:
I just checked the simple user-drive, cli client I wrote and it
doesn't retransmit at all (perhaps not the best UI experience).
the issue isn't with retransmissions. If - to use Harald's example - no
reply arrives for 70 out of 100 issued requests, this is a pretty strong
i
Andrew Newton wrote:
3 - Why is LWZ limited to UDP, desperately trying to solve
various size issues with delated XML and other tricks ?
TCP is handled by XPC and BEEP. But for very short and quick answers
(and lots of them, such as domain availability checks) UDP is better.
Don't know w
On Wed, 16 Aug 2006, Harald Alvestrand wrote:
Andrew Newton wrote:
3 - Why is LWZ limited to UDP, desperately trying to solve
various size issues with delated XML and other tricks ?
TCP is handled by XPC and BEEP. But for very short and quick answers (and
lots of them, such as domain a
ht UDP Transfer Protocol for the the
>Internet Registry Information Service' to Proposed Standard
>(draft-ietf-crisp-iris-lwz)
>
>Andrew Newton wrote:
>>> 3 - Why is LWZ limited to UDP, desperately trying to solve
>>> various size issues with delated XM
On Wed, Aug 16, 2006 at 02:20:51PM -0700, william(at)elan.net wrote:
> Tell us where 'retransmit', 'packet loss' and 'congestion' appear in DNS,
> DHCP or some other UDP-based protocol documents and I'm sure author of
> this spec will be happy to put something similar in his document.
There might
On Wed, Aug 16, 2006 at 02:34:38PM -0700, Ted Faber wrote:
> On Wed, Aug 16, 2006 at 02:20:51PM -0700, william(at)elan.net wrote:
> > Tell us where 'retransmit', 'packet loss' and 'congestion' appear in DNS,
> > DHCP or some other UDP-based protocol documents and I'm sure author of
> > this spec wi
Hi -
> From: "william(at)elan.net" <[EMAIL PROTECTED]>
> To: "Harald Alvestrand" <[EMAIL PROTECTED]>
> Cc:
> Sent: Wednesday, August 16, 2006 2:20 PM
> Subject: Re: Last Call: 'A Lightweight UDP Transfer Protocol for the the
> Internet Re
On Aug 16, 2006, at 6:47 PM, Randy Presuhn wrote:
One example would be STD 62, SNMP.
Specifically, clause 2.2 of RFC 3416.
Thanks. I've also looked at the advice in RFC 1035. After reading
both, I felt the advice to implementers amounted to "don't flood the
network with packets; it is b
On Wed, 16 Aug 2006, Harald Alvestrand wrote:
> Andrew Newton wrote:
>>> 3 - Why is LWZ limited to UDP, desperately trying to solve
>>> various size issues with delated XML and other tricks ?
>>
>> TCP is handled by XPC and BEEP. But for very short and quick answers (and
>> lots of them,
william(at)elan.net wrote:
my congestion control alarm went off.
after reviewing the document, it's still ringing.
There's nothing in the document that says "if you want to send 4000
requests, and 70 out of the first 100 get lost, you should slow down
your sending rate to that server".
The
Sam Hartman wrote:
I notice that this transport provides no authentication of the data
that is retrieved.
The security considerations needs to discuss the potential attacks if
an attacker modifies this public data. The security considerations
section also needs to point to best practice for avo
> "Mark" == Mark Townsley <[EMAIL PROTECTED]> writes:
Mark> Sam Hartman wrote:
>> I notice that this transport provides no authentication of the
>> data that is retrieved.
>>
>> The security considerations needs to discuss the potential
>> attacks if an attacker modifi
24 matches
Mail list logo