[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dhcwg] dhc WG last call ondraft-ietf-dhc-dhcpv6-bulk-leasequery-00
Mark:
The draft looks fine.
For some of the new text, not sure if should/SHOULD or may/MAY should
have been used (lower case was generally used) - such as in 5.5 (Status
Codes).
--
An item that I missed earlier ... for the QUERY_BY_RELAYID or
QUERY_BY_REMOTE_ID, I wonder whether it is necessary to indicate that
for multi-hop relayed client requests, the server SHOULD look through
the full chain of RELAY-FORW for a match (not just the "last" or "first"
hop).
--
I guess now a question to the DHC WG chairs ... What is the status of
this document? Is the last-call completed and did it "pass"? Will it go
to the IESG or is there more to be done on it before it can move
forward?
- Bernie
-----Original Message-----
From: dhcwg-bounces at ietf.org [mailto:dhcwg-bounces at ietf.org] On Behalf
Of Bernie Volz (volz)
Sent: Friday, May 23, 2008 11:58 AM
To: Mark Stapp (mjs)
Cc: DHC WG
Subject: Re: [dhcwg] dhc WG last call
ondraft-ietf-dhc-dhcpv6-bulk-leasequery-00
Great - I'll take a look over the next few [working] days.
Yes, the status code is of marginal value in terms of the actions that
the LQ client would take - it would need to retry in either case. But I
think it can make a difference in terms of debugging/logging/reporting.
If the connection just drops, that could mean any number of things and
doesn't help someone monitoring the LQ client to determine what is going
wrong. So, I think it has significant value in terms of being able to
understand why the connection did drop before the transaction completed.
The LQ client would be able to report two different errors:
- LQ connection to server ... was lost for an unknown reason.
- LQ connection to server ... was lost because server reported "<text
message>".
Think of it this way, programs could always just report "Sorry, a
failure has occurred" or they could tell you why there was a failure --
which would you prefer as a user?
- Bernie
-----Original Message-----
From: Mark Stapp (mjs)
Sent: Friday, May 23, 2008 11:47 AM
To: Bernie Volz (volz)
Cc: DHC WG
Subject: Re: [dhcwg] dhc WG last call on
draft-ietf-dhc-dhcpv6-bulk-leasequery-00
Hi Bernie,
thank you for all of the comments. I've published a new revision that
incorporates pretty much all of them. I did have a couple of responses
inline...
Bernie Volz (volz) wrote:
[...]
> Here are my review comments:
>
> - Abstract
>
> I question whether this is an "extension to the Leasequery Protocol".
> This is a new protocol and I think we should declare it as such.
>
I guess I think it 'extends' RFC5007 because it uses the same messaging,
and the same new options. I've tweaked that text slightly, using
"expands" instead - see what you think.
[...]
>
> - 5.5. Status Codes
>
> TODO: are any new status codes needed - to indicate a connection or
> resource problem e.g.?
>
> This section is obviously incomplete. I think we should define one new
> status code:
>
> QueryTerminated (11) - Indicates that the server is unable to perform
a
> query or has prematurely terminated the query for some reason (which
> should be communicated in the text message). This may be because the
> server is short on resources or is being shut down. The requester may
> retry the query at a later time (the requestor should wait at least a
> short interval before retrying). Note that while a server may simply
> prematurely close its end of the connection, it is preferrable that a
> server send a LEASEQUERY-REPLY or LEASEQUERY-DONE with this
status-code
> to notify the requestor of the condition.
>
I have added this new status code, because there did seem to be at least
of couple of others who supported the suggestion. But for my own part, I
don't really buy it. from the client's end, the connection goes down,
and it doesn't really matter "why". about the best the client can do is
to try other servers, if possible, or wait until it can reconnect.
Thanks again,
Mark
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg