e the status and edit the report, if necessary.
> >
> > --
> > RFC5343 (draft-ietf-opsawg-snmp-engineid-discovery-03)
> > ------
> > Title : Simple Network Management Protocol (SNMP) Context
>
: Simple Network Management Protocol (SNMP) Context
> EngineID Discovery
> Publication Date: September 2008
> Author(s) : J. Schoenwaelder
> Category: PROPOSED STANDARD
> Source : Operations and Management Area Working Group
> Area: Ope
Comments" Markdown format][ICMF], You can use the
> [`ietf-comments` tool][ICT] to automatically convert this review into
> individual GitHub issues.
>
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]: https://github.com/mnot/ietf-comments
>
>
> >
> > > Corrected Text
> > > --
> > > Enclosure
> > >
> > > Notes
> > > -
> > > It's not the right document
> > >
> > > Instructions:
> > > -
> > > This
want it to be automatic, then perhaps we need to reach consensus
> on how new entries will be added.
>
> Regards,
> Ken Vaughn
>
> Trevilon LLC
> 6606 FM 1488 RD #148-503
> Magnolia, TX 77354
> +1-936-647-1910
> +1-571-331-5670 cell
> kvau...@trevilon.com
> www.
gt; > https://www.ietf.org/archive/id/draft-ietf-opsawg-tlstm-update-03.html
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tlstm-update-03
> >
> >
> > Internet-Drafts are also available by rsync at
> > rsync.ietf.org::internet-dr
n 2022-02-28 10:45 AM, Jürgen Schönwälder wrote:
> > Randy,
> >
> > I assume it is fear of all of that, whether this is justified or not
> > can be debated. Frankly, we used a protocol registry because it was
> > handy and we likely did not like a proliferation of regi
ed obsolete"?
>
>- that the possibility of adding these algorithms might somehow
> prolong the lifetime of existing TLS 1.2 deployments or even
> lead to new ones, despite it having been "designated obsolete"?
>
>- something else?
>
&g
ption 1 would require a complete replacement MIB with corresponding impacts
> to existing code to support the new TLS version, so I believe Option 2 would
> be preferred, if allowed.
>
> Regards,
> Ken Vaughn
>
> Trevilon LLC
> 6606 FM 1488 RD #148-503
> Magnolia, TX 773
t feels very wrong if a
secure transport specification provides recommendations about the
usage of something entirely unrelated to the secure transport
specification. If people want to deprecate or retire USM, then this
requires a separate document that changes STD 62.
/js
--
Jürgen Schönwäld
n.com
>
> >
>
>
> _______
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
--
Jürgen Schönwälder Jacobs University Brem
On Thu, Dec 09, 2021 at 10:17:20AM -0600, Kenneth Vaughn wrote:
> > "all these references"
> RFC 7407
> draft-ietf-netconf-https-notif-09.txt
> any other imports of this YANG definition
>
> > the values in the TLS HashAlgorithm
> > registry are only applicable to version of (D)TLS protocol
7354
> +1-936-647-1910
> +1-571-331-5670 cell
> kvau...@trevilon.com
> www.trevilon.com
>
> > On Nov 19, 2021, at 1:40 PM, Jürgen Schönwälder
> > wrote:
> >
> > Let me add one additional observation: RFC 6353 has been a blueprint
> > for the YANG da
SNMP's TC, we should also look at the YANG
equivalent. I also spotted that the YANG definition is imported by
draft-ietf-netconf-https-notif-09.txt, I am not sure whether there are
any other imports of this YANG definition (or the SNMP TC).
/js
On Fri, Nov 19, 2021 at 07:57:32PM +0100, Jürgen
Hi,
any clarifications that are necessary to run SNMP over (D)TLS 1.3 are
worth to work on. Looking at the document, it leaves me a bit puzzled
of what is actually changed. I think all text that is in RFC 6353 and
not modified should be removed from the update (for example, I think
there is no
+1
/js
On Wed, Oct 20, 2021 at 10:44:37PM +0200, Carsten Bormann wrote:
> On 2021-10-20, at 22:22, Henk Birkholz
> wrote:
> >
> > this email *extends* the ongoing call for Working Group Adoption on
> > https://datatracker.ietf.org/doc/html/draft-gharris-opsawg-pcap-02 until
> > *Sunday,
Reviewer: Jürgen Schönwälder
Review result: Not Ready
Summary
>From a YANG modeling point of view, the module is rather straight
forward and I did not discover anything that seems fundamentally
problematic. That said, there are a number of details where I doubt
the model is correct and thi
17 matches
Mail list logo
