[OPSAWG] Alexey Melnikov's No Record on draft-ietf-opsawg-mud-20: (with COMMENT)

Alexey Melnikov has entered the following ballot position for draft-ietf-opsawg-mud-20: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

Re: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)

I haven't balloted yet, and this is EKR's ballot thread, but one point is worth bringing up here ... On Mon, Apr 16, 2018 at 7:25 AM, Eric Rescorla wrote: > Hi Eliot, > > Thanks for continuing the conversation. My question is how this fits into > the system as a whole. > > ISTM

Re: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)

Hi Eric, On 16.04.18 14:25, Eric Rescorla wrote: > Hi Eliot, > > Thanks for continuing the conversation. My question is how this fits > into the system as a whole. > > ISTM that there are two ways in which a MUD policy can affect the > network's behavior: > > - Additive -- it lets the device do

Re: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)

Hi Eliot, Thanks for continuing the conversation. My question is how this fits into the system as a whole. ISTM that there are two ways in which a MUD policy can affect the network's behavior: - Additive -- it lets the device do things it otherwise might not be permitted to do (e.g., accept

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-10.txt

I have some concerns with the document, and with the process by which we've gotten here. Let me recap some history. There's a lot to take in, so I'll present concerns in point form. First, the document. * my "Security Considerations" text was first plagarised in draft-06, * when I

[OPSAWG] Spencer Dawkins' Yes on draft-ietf-opsawg-mud-20: (with COMMENT)

Spencer Dawkins has entered the following ballot position for draft-ietf-opsawg-mud-20: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

Re: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)

Hi Eric, Trimming. On 15.04.18 21:22, Eric Rescorla wrote: > > > > >> IMPORTANT >>> The certificate extension is described below. >>> >>> The information returned by the MUD file server (a web server) is >>> valid for the duration of the Thing's connection, or as

Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

> iff i can select which community's or communities' values form the sampling > bucket(s), this seems reasonable. if i am community transparent, i probably > don't want a bucket for each community on my inbound set. Yes, this sounds better. It can be achieved by configuring the intermediate

Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

Sun, Apr 15, 2018 at 12:32:49PM -0400, Joel M. Halpern: > (the authors would not have written it if no one wanted it.) eh, that might not be a valid argument :) > Also, one of the arguments for doing this in the router is that you can > get more timely and precise correlation. Except that for

Re: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)

On Mon, Apr 16, 2018 at 6:55 AM, Eliot Lear wrote: > Hi Eric, > On 16.04.18 14:25, Eric Rescorla wrote: > > Hi Eliot, > > Thanks for continuing the conversation. My question is how this fits into > the system as a whole. > > ISTM that there are two ways in which a MUD policy can