Re: [dhcwg] I-D Action: draft-templin-duid-ipv6-01.txt

[Simon Hobson <[e-mail]>]

Templin (US), Fred L <[e-mail]> wrote:

> Bob, see below for a replay of what I have answered and will continue to answer:
> 
>> Again, why do you need to use an IPv6 address for this?    Why can’t one of the current DUID approaches be used?
> 
> [RFC7401] and [draft-ietf-drip-rid] are examples of IPv6 address generation
> methods that generate an address intended to be used as an *identity* but
> possible not as a *locator*. In other words, the address could appear in control
> message ID fields but may or may not be "ping'able" in the data plane. And,
> even if it were "ping'able", pervasive use of the address for data communications
> could present an unacceptable privacy exposure.

Please don't take this as a personal attack, it's intended to (try to) be helpful.

There is a disconnect between the question you were asked, and the question you have answered. It's sounding very much like the interviews where the interviewer is asking a question, but the politician has decided one the different question they want to answer - and no matter how many times the interviewer tries to get the question answered, the politician persists in answering their different choice of question.
I sense a frustration on both sides : you perceive that you keep being asked a question you've already answered; other perceive that you are refusing to answer it; while the reality is that there's been a misunderstanding that leads to the perceptions remaining.

The question was : "why can't one of the existing methods be used ?"
The question you have answered is : "what allows other types to be created ?"

As others have been trying to say, just because you **can** doesn't mean that you **should**. So far you've been saying "we can do this", but you've given no indication of "why" anyone should do that. You need to document specific use cases where your ID works, but an existing ID type cannot be used - until you do that, the question will remain as to "why not use something that's already defined ?"

And both Bernie and Bob have given considerable detail as to why your suggestion might not be (note, "might not be", not "is not") a suitable identifier - i.e. points that do need addressing if the idea is to be taken seriously.

So, as I see it :
You need to say **why** existing types are unsuitable for the use cases you have in mind.
Clearly articulate what those use cases are.
Address the technical issues (mostly around lifetime and guarantee of uniqueness) that have been raised.

Simon