Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

> On Feb 8, 2018, at 5:17 AM, Randy Bush wrote: > >>> Unfortunately, the fundamental concern that motivated my DISCUSS >>> remains: I do not believe that this document matches the consensus >>> of the IETF community. >> That's an interesting claim. >> If the process has not been

Re: [OPSAWG] Adding Joe Clarke as a chair.

Congratulations Joe, this is excellent news for OPsAWG! On May 24, 2017, at 7:45 AM, Warren Kumari > wrote: Hi all, Benoit and I have been discussing this for a while, and we'd like to announce that we are adding Joe Clarke as an OpsAWG chair. Joe

Re: [OPSAWG] WG adoption poll for In-Situ OAM drafts

Hi, Linda, Moving the discussion to i...@ietf.org, other aliases to Bcc. Please see inline. — Carlos Pignataro, car...@cisco.com “Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis." On Jan 30,

Re: [OPSAWG] WG adoption poll for In-Situ OAM drafts

Thanks again, Tianran and Adrian. Please find a couple additional comments inline. — Carlos Pignataro, car...@cisco.com “Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis." On Dec 16, 2016, at 1:28 AM, Zhoutianran

Re: [OPSAWG] WG adoption poll for In-Situ OAM drafts

Hi Adrian, Interesting thoughts, please see inline. — Carlos Pignataro, car...@cisco.com “Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis." On Dec 15, 2016, at 5:09 PM, Adrian Farrel

Re: [OPSAWG] WG adoption poll for In-Situ OAM drafts

Hi, Bert, Please find a couple of follow-ups inline. — Carlos Pignataro, car...@cisco.com “Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis." On Dec 14, 2016, at 9:48 AM, Bert Wijnen (IETF)

Re: [OPSAWG] WG adoption poll for In-Situ OAM drafts

Hi, Tianran & Warren, Yes, the WG should adopt these documents, and yes I have read them (and wrote some of them) [NB: I am a co-author] These documents provide a well organized description of an operator-acknowledged problem space / opportunity space, and then follows to defining both data

Re: [OPSAWG] MD Type attack (Was: Question regarding Proof of Transit draft)

nt, indeed. The MIIM is one we should expand upon. Thanks! — Carlos. > Thanks, > Tal. > > >> -Original Message- >> From: Carlos Pignataro (cpignata) [mailto:cpign...@cisco.com] >> Sent: Wednesday, July 20, 2016 11:51 AM >> To: Tal Mizrahi >>

Re: [OPSAWG] MD Type attack (Was: Question regarding Proof of Transit draft)

— Carlos. > I hope you will elaborate more on the threat model in the next version of the > draft. > > Cheers, > Tal. > > >> -Original Message- >> From: Carlos Pignataro (cpignata) [mailto:cpign...@cisco.com] >> Sent: Wednesday, July 20, 2016 11

[OPSAWG] MD Type attack (Was: Question regarding Proof of Transit draft)

Tal, > On Jul 20, 2016, at 6:30 AM, Tal Mizrahi wrote: > > Hi Sashank, > >> [SD] The attack is valid only if the attacker can get away bypassing a >> service function/node. >> For example, if the attacker bypasses a node and if POT determines it did >> not bypass is a

Re: [OPSAWG] Conflict review on draft-pfaff-ovsdb-proto-02

I agree -- I see no conflict with l2tpext work. -- Carlos. On Aug 19, 2013, at 12:54 PM, Ignacio Goyret i.goy...@alcatel-lucent.com wrote: I don't see any conflict with l2tpext wg work. -Ignacio At 07:43 8/19/2013, Ted Lemon wrote: I've taken on the conflict review for

Re: [OPSAWG] Fwd: New Version Notification for draft-fan-opsawg-packet-loss-01.txt

Hello, Fan, Ramki, Just because there is a hammer, it does not mean that every problem is a nail. Someone mentioned this on the presentation at Berlin. Fan, It really is all about scope and goals. You mention that ICMP is not appropriate, and then that it is appropriate. I suspect the real

Re: [OPSAWG] Fwd: New Version Notification for draft-fan-opsawg-packet-loss-01.txt

There are two other considerations: 1. ICMP packets might follow a different path than the application in the presence of ECMP 2. The ICMP responder might rate limit and drop if it's a router regardless of the drop characteristics of the path -- RFC 6192. Thanks, Thumb typed by Carlos