Hi Thomas, please see my comments in-line:
>From: Thomas Narten <[EMAIL PROTECTED]>
>Date: 2006/08/24 Thu AM 10:26:19 CDT
>To: [EMAIL PROTECTED]
>Cc: Ralph Droms <[EMAIL PROTECTED]>,
"Durand, Alain" <[EMAIL PROTECTED]>,
IETF IPv6 Mailing List <ipv6@ietf.org>
>Subject: Re: Prefix Delegation using ICMPv6
>> Hi Ralph, why is it hard to talk about the e-mail without "more detail"?
>
>> Do you believe that it is theoretically possible that DHCPv6 PD
>> would be "neither required nor desired"?
>
>Please make the case here (using technical justifications).
I'd like to clarify that "neither required nor desired" was meant to be from
the customer's point of view. Further info regarding customer requirements and
the rationale for them will be included in future versions of the draft.
Customer requirements, as well as technical reasons, are both valid types of
reasons. Do you agree?
Also, please first tell us what you think of the cases we made in the first
revision of the draft. With specifics on where folks see them lacking (both
technical and otherwise), we will be better equipped to provide answers (both
in subsequent draft revisions, and even on this list).
Basic the
>need for a new protocol on theoretical possibilities has repeatedly
>been problematic in the IETF.
Our proposal is not based on theoretical possibilites. Customers have expressed
interest in an alternative IPv6 PD mechanism.
>
>> It is here that I'd like to start this portion of our conversation.
>
>I would not. Starting off with the assertion that "its theoretically
>possible that the existing protocol isn't desired, therefore we should
>invent a new one" is a complete non-starter for the IETF.
Regrettably, it seems you've taken that question out of context. If one
considers the entire related e-mail thread as well as their reading of the
draft, they'll see a summary of motivating factors for the proposal. They may
well require more detail (as in fact they have and rightfully so), but the
summary IS there.
Real customers have stated interest in doing IPv6 PD but not using DHCPv6. As
you may know, the next version of our draft will include elaboration on these
real (not theoretical) customer requirements.
>
>We do engineering here, presumably solving real problems, where the
>existing solutions are inadquate or non-existent.
I believe we seek to find solutions that are either better than existing ones,
or that meet a heretofore unmet requirement. If something is inadquate, by
definition it is not a solution.
>
>> There's no doubt that DHCPv6 PD works, was carefully considered, and
>> does have an install base. We affirm that fully.
>
>In which case, there would appear to be no need to talk about a new
>protocol, since you appear to admit that an existing standard does
>solve the problem.
I'm afraid you misunderstand. That statement was made to further our point that
our goal is NOT to replace DHCPv6 PD. Also, if you read our draft you'll see
the point made that the ICMPv6 based PD mechanism we propose is mean to be an
alternative.
>
>If you want this group to consider a new protocol, start by convincing
>us that:
>
>1) there is a real (not theoretical) problem that needs solving, and
It is a real problem to be solved that customers need to do IPv6 PD and DHCPv6
is not employed. We believe our mechanism does solve this problem.
>
>2) the existing mechanisms do not address it properly, and
By definition, where DHCPv6 is expressly not employed it cannot address the
IPv6 PD requirement at all.
>
>3) the best way to address the problem is with a new mechanism (and
> it's better than other proposed ways of fixing the problem).
Are you aware of other IPv6 PD proposals out there Thomas? Not knowing, I'd
have to allow that there could be.
My reading of RFC 3769 is that it says how any IPv6 PD mechanism must behave,
NOT that said mechanism MUST be the already existing DHCPv6 PD standard. BTW,
to cite RFC 3769 is in no way to say or imply that we're developing this new
solution because we CAN.
Development of both the technical cases and customer requirements for the
alternative IPv6 PD mechanism we propose will primarily be developed in future
revisions of our draft.
It seems many excellent questions and issues have been raised in these many
e-mail exchanges.
These include concerns about the need for elaboration on reasons for customer
requirements, as well as how we see ICMPv6 PD either:
1) solving problems that DHCPv6 PD does not solve, or 2) solving problems
better than DHCPv6 PD does
These group concerns WILL inform how the future draft revisions are written.
Please also provide us with a technical critique of the proposal itself. If we
are to provide the best possible technical solution, we need the best technical
feedback the group has to offer.
>
>At this point, AFAIAC, you have not gotten past either points 1) or 2).
>
>Thomas
Tim
Rom 8:28
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
