Re: [OPSAWG] [EXT] Re: [Technical Errata Reported] RFC3413 (7694)

Hi - (Odd that I didn't see the original report) The report is correct that RFC 3415 defines a possible errorIndication of notInView, and that RFC 3413 doesn't explicitly say what to do about it. But that's about it. The cases enumerated in 3.2 (5) are errors that effectively short-circuit

Re: [OPSAWG] [Technical Errata Reported] RFC5343 (7645)

Hi - On 2023-09-18 12:42 AM, Jürgen Schönwälder wrote: This erratum should be rejected since the text does not appear in RFC 5343. It seems the text is found in 5340, 'OSPF for IPv6', and this is a typo when the erratum was entered. I concur. There may be a problem, but it's not in RFC 5343.

Re: [OPSAWG] I-D Action: draft-ietf-opsawg-tlstm-update-13.txt

Hi - On 2023-03-02 7:08 AM, Joe Clarke (jclarke) wrote: - Sect 4: Added the snmpTlstmHashAlgorithms node to represent the new registry --- This is related to the issue that is still under review On this point, I would like some guidance from other MIB experts.  You have created a “dummy”

Re: [OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-tlstm-update-12: (with COMMENT)

Hi - On 2023-02-28 6:39 AM, Joe Clarke (jclarke) wrote: Thanks for the review, Eric (and Lars). There was no formal MIB Doctor review, but we did receive comments from Jürgen and Randy, who are members of MIB Doctors (I believe), during the progress of this draft.  Those comments were

Re: [OPSAWG] [Editorial Errata Reported] RFC7666 (7258)

Hi - There *is* an issue - the first two possible values spelled out in the DESCRIPTION clause do not match the enumerated SYNTAX values' labels. Randy On 2022-12-01 1:46 PM, Chris Smiley wrote: Greetings, FYI - this report has been deleted as junk. Thank you. RFC Editor/cs On Nov 30,

Re: [OPSAWG] WG LC: draft-ietf-opsawg-tlstm-update

Hi - On 2022-08-29 3:09 PM, Kenneth Vaughn wrote: I still assert that the way I read the SnmpTLSAddress paragraph, “may not” makes more sense. I think we agree on the intent at this point, we just need to agree on the wording that conveys the correct intent. I talked to my technical editor

Re: [OPSAWG] RFC 6353 Update to support TLS 1.3

3 (as well as TLS 1.2) maintenance engineers from adding inappropriate algorithms? Randy Joe On 3/1/22 00:40, Randy Presuhn wrote: Hi - Wait... are there or are there not any plans for additions to the registry? If there are no plans for additions, the argument about confused TLS implemen

Re: [OPSAWG] RFC 6353 Update to support TLS 1.3

2 at 10:24:53AM -0800, Randy Presuhn wrote: Hi - On 2022-02-28 6:28 AM, Kenneth Vaughn wrote: To OPSAWG, especially MIB doctors and SNMP-experts: We have contacted the TLS community about potentially allowing for the continued use and maintenance of the IANA TLS HashAlgorithm Registry

Re: [OPSAWG] RFC 6353 Update to support TLS 1.3

as I can see, what implementations do internally. My questions were based in my skepticism with regard to to the stance that *any* MIB module changes would really be technically (rather than politically) necessary. Randy /js On Mon, Feb 28, 2022 at 10:24:53AM -0800, Randy Presuhn wrote: Hi

Re: [OPSAWG] RFC 6353 Update to support TLS 1.3

Hi - On 2022-02-28 6:28 AM, Kenneth Vaughn wrote: To OPSAWG, especially MIB doctors and SNMP-experts: We have contacted the TLS community about potentially allowing for the continued use and maintenance of the IANA TLS HashAlgorithm Registry (RFC 5246) in the update to RFC 6353 so that we do

Re: [OPSAWG] CALL FOR ADOPTION: Transport Layer Security Verion 1.3 (TLS 1.3) Transport Model for the Simple Network Management Protocol Version 3 (SNMPv3)

Hi - On 2022-01-05 7:04 AM, Jürgen Schönwälder wrote: USM is a part of STD62 and I do not think it is the job of an update of RFC 6353 to make any changes concerning STD62 and the status of USM. SNMP RFCs usually talk about what is mandatory to implement (to guarantee some level of

Re: [OPSAWG] draft-vaughn-tlstm-update-01 (TLSTM Update to support TLS 1.3)

Hi - On 2021-10-21 1:28 PM, Kenneth Vaughn wrote: ... If I properly understand your suggestion, you are requesting that we make the new document a stand-alone document and the group could separately consider the retirement of RFC 6353 - perhaps on a separate timeline. ... That seems

Re: [OPSAWG] draft-vaughn-tlstm-update-01 (TLSTM Update to support TLS 1.3)

Hi - On 2021-10-20 8:38 PM, Kenneth Vaughn wrote: I would like to present https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update-01/ . This document is a proposal to update to RFC 6353 (TLS Transport Model for SNMP) to 

Re: [OPSAWG] Question regarding RFC 7860: Password mechanism

Hi - On 11/18/2019 7:07 PM, Greg MacLellan wrote: I just came across RFC 7860 while looking for updates to the SNMPv3 authentication models. It's good to see updated hash algorithms, however, I'm confused by several aspects of section 9.3, Derivation of Keys from Passwords: 1. Why is the word

Re: [OPSAWG] Thoughts on draft-song-opsawg-ntf

Hi - On 10/18/2018 12:58 AM, Tianran Zhou wrote: Well, the first paragraph in section 1.4 is neither clear nor necessary. I would suggest to remove this paragraph. Is that OK for you? The paragraph does seem clear, but is (in my opinion) incorrect. However, it appears to be an integral part

Re: [OPSAWG] Thoughts on draft-song-opsawg-ntf

Hi - On 10/17/2018 6:37 PM, Tianran Zhou wrote: I do not mean to say the SNMP design is problematic. But I think it's not designed for periodically getting operational data, which is one important case for streaming telemetry. That's one of the possible use cases for RFC 2981 or RFC 3877, and

Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 Contributions, Status and Plans

Hi - Uri is said to have said: ... My concern (and displeasure) is that in the past few days > we’ve seen plenty of emails on this subject, but nothing > along the lines of the above – which IMHO is the only thing > that would actually matter (everything else is just waste > of bandwidth).

Re: [OPSAWG] [Errata Verified] RFC7666 (4710)

Hi - >From: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> >Sent: Jun 18, 2016 12:05 AM >To: Randy Presuhn <randy_pres...@mindspring.com> >Cc: tina.tsou.zout...@huawei.com, i...@ietf.org, jm+i...@kubek.fr, >keii...@iijlab.net, opsawg@ietf.org, RFC Erra

Re: [OPSAWG] [Errata Verified] RFC7666 (4710)

Hi - I am puzzled that this change was permitted. It seems to be in clear violation of the constraints imposed by RFC 2579 section 5. Once the textual convention has been published, such a change, even if it is a "fix", is not allowed by the interoperability rules. Randy -Original

Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT)

Hi - From: Kathleen Moriarty kathleen.moriarty.i...@gmail.com Sent: Jun 22, 2015 4:57 AM To: The IESG i...@ietf.org Cc: draft-ietf-opsawg-vmm-mib.sheph...@ietf.org, draft-ietf-opsawg-vmm-...@ietf.org, opsawg-cha...@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-vmm-mib...@ietf.org Subject:

Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT)

Hi - ARRGH! I apologize for sending a blast of HTML gobbledygook. Here's what I intended to say: Sorry, I don't mean to be dense, but I can't provide text to explain this because this rationale doesn't make any sense to me at all. I still don't see how monitoring a not-necessarily- trusted VM

Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT)

Hi - From: Black, David david.bl...@emc.com Sent: Jun 22, 2015 5:06 PM To: Randy Presuhn randy_pres...@mindspring.com, Kathleen Moriarty kathleen.moriarty.i...@gmail.com Cc: draft-ietf-opsawg-vmm-mib...@ietf.org draft-ietf-opsawg-vmm-mib...@ietf.org, draft-ietf-opsawg-vmm-...@ietf.org draft

Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT)

text/html; charset=UTF-8: Unrecognized ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-vmm-mib-03: (with COMMENT)

Hi - From: Kathleen Moriarty kathleen.moriarty.i...@gmail.com Sent: Jun 22, 2015 12:45 PM To: Michael MacFaden m...@vmware.com Cc: draft-ietf-opsawg-vmm-mib.sheph...@ietf.org draft-ietf-opsawg-vmm-mib.sheph...@ietf.org, Randy Presuhn randy_pres...@mindspring.com, draft-ietf-opsawg-vmm

Re: [OPSAWG] Review and contribution requested: draft-boesch-idxp-idpef-01 (Bjoern-C. Boesch)

Hi - Has there been some discussion of the reasons why this work doesn't emply one of the established management information data modeling languages, such as Yang or SNMP SMI? Randy -Original Message- From: B.-C. Boesch bjoernboe...@gmx.net Sent: Apr 29, 2015 7:41 AM To: s...@ietf.org,

Re: [OPSAWG] [BEHAVE] NATV2-MIB: Proposed additional read-write control on per-subscriber statistics

Hi - From: ietfdbh ietf...@comcast.net Sent: Feb 7, 2015 6:24 AM To: 'Tom Taylor' tom.taylor.s...@gmail.com, beh...@ietf.org, opsawg@ietf.org Subject: Re: [OPSAWG] [BEHAVE] NATV2-MIB: Proposed additional read-write control on per-subscriber statistics ... What impact would this on-off

Re: [OPSAWG] Major NAT MIB Issue: Notifications and processor requirements at the agent

Hi - From: Simon Perreault sperrea...@jive.com Sent: Oct 27, 2014 6:35 AM To: Tom Taylor tom.taylor.s...@gmail.com Cc: opsawg@ietf.org opsawg@ietf.org, beh...@ietf.org beh...@ietf.org Subject: Re: [OPSAWG] Major NAT MIB Issue: Notifications and processor requirements at the agent ...

Re: [OPSAWG] Read-write access in VMM-MIB

Hi - From: t.petch ie...@btconnect.com Sent: May 28, 2014 2:30 AM To: Hirochika Asai pa...@hongo.wide.ad.jp, joel jaeggli joe...@bogus.com Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Read-write access in VMM-MIB ... SNMP has never said much about persistence (table row status being the exception).

Re: [OPSAWG] Read-write access in VMM-MIB

Hi - From: Hirochika Asai pa...@hongo.wide.ad.jp Sent: May 26, 2014 10:48 AM To: joel jaeggli joe...@bogus.com Cc: opsawg@ietf.org opsawg@ietf.org Subject: Re: [OPSAWG] Read-write access in VMM-MIB ... I think it would be better to move this issue to the IESG, but I don't keep up the procedure.

Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04)

Hi - From: Joe Marcus Clarke jcla...@cisco.com To: Randy Presuhn randy_pres...@mindspring.com Cc: opsawg@ietf.org Sent: Thursday, August 29, 2013 4:11 PM Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) ... I would be happy with read-only objects

Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04)

Hi - From: Joe Marcus Clarke jcla...@cisco.com Sent: Aug 23, 2013 11:56 AM To: Michael MacFaden m...@vmware.com, opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) ... My other comment (not quoted here) is that I was asking if some more