On Tue, 15 Sep 2020 at 18:39, Eliot Lear wrote:
>
>
> My concern is not with "new extensions" per se. The hidden assumption
> here is that "extensions" are the only way TLS can evolve. In fact, future
> TLS versions are not constrained to evolve in any particular way. For
> example, future ver
On Tue, Sep 15, 2020, 9:10 AM Eliot Lear
wrote:
>
>
>
> My concern is not with "new extensions" per se. The hidden assumption here
> is that "extensions" are the only way TLS can evolve. In fact, future TLS
> versions are not constrained to evolve in any particular way. For example,
> future
a bit more rationale
arin and lacnic have different attribute names
mention whois and rdap transports
mention rfc7909
have proper oid
advise throttling, and specify fetches no more frequently than weekly
---
A new version of I-D, draft-ymbk-opsawg-finding-geofeeds-03.txt
has been successfully sub
Hi,
I have read this document and its support adoption here.
There’s one comment, maybe the authors can clarify this in the draft.
I believe though not widely used, was recently involved in a talk about
usefulness of TLS session resumption in IoT implementations to improve
session establishm
> My concern is not with "new extensions" per se. The hidden assumption here
> is that "extensions" are the only way TLS can evolve. In fact, future TLS
> versions are not constrained to evolve in any particular way. For example,
> future versions can introduce entirely new messages in the
Hi Bo,
Thanks for addressing my previous comments.
Please see inline ...
> -Original Message-
> From: Wubo (lana)
> Sent: 29 August 2020 09:40
> To: Rob Wilton (rwilton) ; opsawg ;
> draft-ietf-opsawg-tacacs-yang@ietf.org
> Subject: Re: AD review of draft-ietf-opsawg-tacacs-yang-07
Thanks Ben and Eliot for the feedback. Please see inline
On Tue, 15 Sep 2020 at 14:51, Eliot Lear wrote:
> Hi Ben
>
> Thanks for the response. Please see below.
>
> >
> > Agreed ... but this proposal appears to be predicated on a contrary
> assumption. It assumes that it is difficult for malwa
Hi Ben
Thanks for the response. Please see below.
>
> Agreed ... but this proposal appears to be predicated on a contrary
> assumption. It assumes that it is difficult for malware to learn the TLS
> profile of the device, and then proceeds to place this profile information in
> the (public)
Dear Opsawg,
Now the T+ draft is released from the editor stage I have asked for Alan’s
comment to be incorporated, and submitted one other addenda for clarification
on command accounting, into the accounting attributes section:
“Where the TACACS+ deployment is used to support the Device Admini
