Subject: Re: [karp] Responses to Comments for draft-ietf-karp-threats-reqs-01

From: "Michael Barnes" <[email-masked]>
Date: Mon, 10 Jan 2011 14:54:49 -0800

Hi San & Russ,

From: Sam Hartman <[email-masked]>
To: Russ White <[email-masked]>Cc: [email-masked]

> >>>>> "Russ" == Russ White <[email-masked]> writes:
> 
> 
>     Russ> So my sense is that dividing the reachability control plane
>     Russ> from the encryption control plane is a "good thing," likely to
>     Russ> result in fewer poorly understood feedback loops, and fewer
>     Russ> unintended consequences. I'm pretty strongly in favor of
>     Russ> splitting these where possible, and making the API between as
>     Russ> transparent as possible.
> 
>     Russ> But I'm willing to hear arguments to the contrary.  ==
> 
> Russ, I think there is consensus on the requirement currently in the
> document.  I don't think the compelling arguments are about what the
> right thing to do is:m y personal opinion is that the requirement is not
> the best technical approach, but that this split is not nearly as bad of
> a thing as I at first thought it was when I started thinking about KARP.
> 
> However people have made claims that those doing the implementation work
> in this space strongly prefer the split and that adopting a requirement
> for this split will make it more likely to succeed.  I don't think that
> such a split is bad enough on a technical front that we should rule it
> out. So, if the split gets us implementations and the lack of a split
> gets us irrelevance, let's go with the requirement.
> 
> So, my question to the WG as a whole is do we actually want to have
> another round of discussion on whether Russ's technical argument above
> is correct? Or are we willing to accept this requirement as a practical
> necessity? My personal opinion is that this requirement is not a
> technical issue and so having this as a technical discussion is not an
> effective strategy. I feel strongly that we should make forward progress
> and do not feel that strongly about whether this requirement should be
> present.
> 
> That said, if people want to have the technical discussion I'm happy to
> join it on the list or in private.

I thought there had already been a good discussion of this point and thought
it had been closed. I'm happy with the requirement as it is written.

-Michael

---

From: Glen Kent <[email-masked]>
Date: Wed, 12 Jan 2011 06:26:15 +0530

I agree and i would like it to remain the way it is in the
threats-reqs document. We can come back to it later if we find that
this decoupling is not possible or is highly unoptimal.

Glen

On Tue, Jan 11, 2011 at 4:24 AM, Michael Barnes <[email-masked]> wrote:
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>

---

From: [email-masked]
Date: Wed, 19 Jan 2011 15:31:35 +0800

Hi Russ, Sam, Michael and Glen,

I agree to the current threats-reqs document, too. If any new situation 
happen, or there is point that cannot be achieved consensus by all at the 
time being, the document can be updated anyway ^_^ 

Cheers,
Ellen (Xiaoping Liang)

Glen Kent <[email-masked]> 
发件人:  [email-masked]
2011-01-12 08:56

收件人
Michael Barnes <[email-masked]>
抄送
[email-masked], Sam Hartman <[email-masked]>
主题
Re: [karp] Responses to Comments for draft-ietf-karp-threats-reqs-01

Glen

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.