I can hold off on rejecting the erratum if you can come up with a better text that everyone agrees with. As is, it is a clever play on words, but I do not see anything terribly wrong with it. I also wonder if the errata is Technical or Editorial, which I will defer to the RFC Editor to evaluate.
Cheers. > On Feb 27, 2025, at 11:16 AM, Donald Eastlake <d3e...@gmail.com> wrote: > > OK, I can believe that. But the wording is terrible and, as a save for next > version, need to be completely clarified. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e...@gmail.com <mailto:d3e...@gmail.com> > > On Thu, Feb 27, 2025 at 11:31 AM Joe Clarke (jclarke) <jcla...@cisco.com > <mailto:jcla...@cisco.com>> wrote: > I think the text is correct as written. There is a nuance in here between > managed protocol (i.e., aspects of the protocol itself) and management > protocol (something like SNMP that performs management of monitoring of the > protocol). > > > > My take is that while the current text might initially confuse the eyes, this > erratum should be rejected. > > > > Joe > > > > From: RFC Errata System <rfc-edi...@rfc-editor.org > <mailto:rfc-edi...@rfc-editor.org>> > Date: Wednesday, February 26, 2025 at 18:17 > To: ietf...@comcast.net <mailto:ietf...@comcast.net> <ietf...@comcast.net > <mailto:ietf...@comcast.net>>, war...@kumari.net <mailto:war...@kumari.net> > <war...@kumari.net <mailto:war...@kumari.net>>, mjethanand...@gmail.com > <mailto:mjethanand...@gmail.com> <mjethanand...@gmail.com > <mailto:mjethanand...@gmail.com>>, henk.birkholz@ietf.contact > <henk.birkholz@ietf.contact>, Joe Clarke (jclarke) <jcla...@cisco.com > <mailto:jcla...@cisco.com>> > Cc: d3e...@gmail.com <mailto:d3e...@gmail.com> <d3e...@gmail.com > <mailto:d3e...@gmail.com>>, opsawg@ietf.org <mailto:opsawg@ietf.org> > <opsawg@ietf.org <mailto:opsawg@ietf.org>>, rfc-edi...@rfc-editor.org > <mailto:rfc-edi...@rfc-editor.org> <rfc-edi...@rfc-editor.org > <mailto:rfc-edi...@rfc-editor.org>> > Subject: [Technical Errata Reported] RFC5706 (8315) > > The following errata report has been submitted for RFC5706, > "Guidelines for Considering Operations and Management of New Protocols and > Protocol Extensions". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid8315 > <https://www.rfc-editor.org/errata/eid8315> > > -------------------------------------- > Type: Technical > Reported by: Donald Eastlake <d3e...@gmail.com <mailto:d3e...@gmail.com>> > > Section: 3.6.1 > > Original Text > ------------- > The protocol document should make clear the limitations implicit > within the protocol and the behavior when limits are exceeded. This > should be considered in a data-modeling-independent manner -- what > makes managed-protocol sense, not what makes management-protocol- > sense. > > Corrected Text > -------------- > The protocol document should make clear the limitations implicit > within the protocol and the behavior when limits are exceeded. This > should be considered in a data-modeling-independent manner -- what > makes managed-protocol sense, not what makes data model > sense. > > Notes > ----- > I am not sure what correct wording would be. The existing wording is self > contradictory. The above "corrected" text is just a guess. > > Instructions: > ------------- > This erratum is currently posted as "Reported". (If it is spam, it > will be removed shortly by the RFC Production Center.) Please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > will log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5706 (draft-ietf-opsawg-operations-and-management-09) > -------------------------------------- > Title : Guidelines for Considering Operations and Management of > New Protocols and Protocol Extensions > Publication Date : November 2009 > Author(s) : D. Harrington > Category : INFORMATIONAL > Source : Operations and Management Area Working Group > Stream : IETF > Verifying Party : IESG > Mahesh Jethanandani mjethanand...@gmail.com
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
