Subject: [OPS-AREA] FW: IESG Statement on Copyright

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 17 Sep 2009 12:38:57 +0200

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
IESG Secretary
Sent: Wednesday, September 09, 2009 10:45 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: IESG Statement on Copyright 

This IESG Statement obsoletes all earlier IESG Statements regarding
Copyright statements in MIB and PIB Modules.

The IESG is providing this guidance to align current practice with RFC
5377, RFC 5378, and the resulting IETF Trust Legal Provisions (TLP)
(http://trustee.ietf.org/license-info).

IETF Contributions and IETF Documents often include code components that
are intended to be directly processed by a computer. Examples of such
code components include ABNF definitions, XML Schemas, XML DTDs, XML
RelaxNG definitions, tables of values, MIBs, PIBs, ASN.1, and classical
programming source code. The IETF Trust maintains a list of code
component types. A link to this list can be found on this web
page: http://trustee.ietf.org/license-info.

In addition to the code component types listed, any text found between
the markers &lt;CODE BEGINS&gt; and &lt;CODE ENDS&gt; shall be
considered a code component. Authors may wish to use these markers as
clear delimiters of code components.

Authors are encouraged to collect code into a separate section or
appendix.

The TLP requires copyright notice in IETF Documents, but not necessarily
in each code component within an IETF Document. Authors may choose to
include a copyright notice as a comment when a significant amount of
code is collected together. For example, authors may include a copyright
notice in a comment as part of an ASN.1 module or a representation of a
classical programming language file. If IETF Document authors choose to
include a code component copyright notice comment, they must follow the
guidance in Section 6.d of the TLP.
Implementors that extract any code component from the IETF Document must
include the BSD license text as described in Section 4.e of the TLP.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 22 Sep 2009 14:48:03 +0200

There are a number of issues that gathered around 4181 that would
deserve attention if a willing editor is found. 

Dan

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of C. M. Heard
> Sent: Tuesday, September 22, 2009 12:48 AM
> To: MIB Doctors (E-mail)
> Cc: OPS Area (E-mail)
> Subject: Re: [MIB-DOCTORS] FW: IESG Statement on Copyright
> 
> Greetings,
> 
> It seems to me that the new IESG statement on MIB and PIB 
> module copyrights obsoletes Section 3.7 of RFC 4181 
> (Guidelines for Authors and Reviewers of MIB Documents) and 
> all of RFC 4841 (RFC 4181 Update to Recognize the IETF 
> Trust).  If the cycles exist to do it, someone should write a 
> short RFC to update RFC 4181 and to obsolete RFC 4841, or 
> even better, issue an upated version of the mib guidelines 
> that obsoletes both 4181 and 4841.
> 
> Just in case anyone should ask, I'm stil retired from MIB 
> work, and I don't have the cycles to do it myself.
> 
> Best regards,
> 
> Mike Heard
> 
> On Thu, 17 Sep 2009, Romascanu, Dan (Dan) wrote:
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of IESG Secretary
> > IETF Contributions and IETF Documents often include code components 
> > that are intended to be directly processed by a computer. 
> Examples of 
> > such code components include ABNF definitions, XML Schemas, 
> XML DTDs, 
> > XML RelaxNG definitions, tables of values, MIBs, PIBs, ASN.1, and 
> > classical programming source code. The IETF Trust maintains 
> a list of 
> > code component types. A link to this list can be found on this web
> > The TLP requires copyright notice in IETF Documents, but not 
> > necessarily in each code component within an IETF Document. Authors 
> > may choose to include a copyright notice as a comment when a 
> > significant amount of code is collected together. For 
> example, authors 
> > may include a copyright notice in a comment as part of an 
> ASN.1 module 
> > or a representation of a classical programming language 
> file. If IETF 
> > Document authors choose to include a code component 
> copyright notice 
> > comment, they must follow the guidance in Section 6.d of the TLP.
> > Implementors that extract any code component from the IETF Document 
> > must include the BSD license text as described in Section 
> 4.e of the TLP.
> > 
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Sep 2009 14:54:50 +0200

> deserve attention if a willing editor is found. 

Do we have a list of those issues somewhere?

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 22 Sep 2009 15:00:27 +0200

Nothing as ordered as we would it to be. I remember discussions having
started a few times but we need to go back into the MIB Doctors
archives. There are also three verified errata (editorial stuff). 

Dan

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Tuesday, September 22, 2009 3:55 PM
> To: Romascanu, Dan (Dan)
> Cc: C. M. Heard; MIB Doctors (E-mail); OPS Area (E-mail)
> Subject: Re: [OPS-AREA] [MIB-DOCTORS] FW: IESG Statement on Copyright
>

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 21 Sep 2009 14:47:54 -0700 (PDT)

Greetings,

It seems to me that the new IESG statement on MIB and PIB module 
copyrights obsoletes Section 3.7 of RFC 4181 (Guidelines for Authors 
and Reviewers of MIB Documents) and all of RFC 4841 (RFC 4181 Update 
to Recognize the IETF Trust).  If the cycles exist to do it, someone 
should write a short RFC to update RFC 4181 and to obsolete RFC 
4841, or even better, issue an upated version of the mib guidelines 
that obsoletes both 4181 and 4841.

Just in case anyone should ask, I'm stil retired from MIB work, and 
I don't have the cycles to do it myself.

Best regards,

Mike Heard

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 22 Sep 2009 14:30:46 -0700 (PDT)

Other than the copyright text that goes in MIB modules, the only 
issues that I know of that we all agreed were actually issues are 
the errata now on the RFC Editor site.  Attached is an e-mail 
message on this subject sent to David Harrington and Bert Wijnen 
earlier this year.

In my archives I found a discussion that tooks place between 16 Oct 
2005 and 4 Jan 2006 as to whether RFC 4181 should be listed as 
updating STD 58 (RFCs 2578, 2579, and 2580), as suggested by Alfred 
Hoenes.  We decided that the answer was NO, but in the process there 
was an inconclusive discussion as to whether the MUSTs in 4181 that 
go beyond the requirements of STD 58 (there are some in sec. 4.6.4) 
ought to be SHOULDs instead.  The subject lines in the relevant 
threads are "RFC 4181 indeed updates RFC 2578..2580" and "Erratum 
for RFC 4181".  If it's too much of a pain to search the mib-doctors 
archive, I can make the 28 messages that I saved from those threads 
available as a Unix mbox file.

Mike Heard

> > Do we have a list of those issues somewhere?

Subject: RE: Does another RFC4181 update need to be done?
From: "C. M. Heard" <[email-masked]>
To: David Harrington <[email-masked]>
Cc: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 3 Mar 2009 12:28:31 -0800 (PST)

Hello David,

I looked in my mail archive and the only RFC 4181 errata that I 
found were in the attached message from 1 Nov 2005.  These, as it 
happens, have been posted by the RFC Editor, contrary to what I said 
below.  After so long away from the subject my memory of it is 
failing :-(

I do have some vague recollections of some other stuff that came up 
when we discussed the RFC 4181 update to recognize the IETF Trust 
(which became RFC 4841), but I can't find anything in my records.  
Bert once volunteered to convert the doucment in to xml2rfc format, 
and I sent him some errata that **may** have contained more than 
those in the attached message -- but I'm not sure.

Bert, if you have anything lying around that might help please 
forward it to David.

Thanks,

Mike

On Tue, 3 Mar 2009, David Harrington wrote:
> OK. If you send me the errata list, I will try to update the document
> (and convert source to xml2rfc format in the process).
> 
> Thanks,
> dbh
> 
> > From: C. M. Heard [mailto:[email-masked]] 
> > Sent: Tuesday, March 03, 2009 10:42 AM
> > To: David Harrington
> > Cc: Bert Wijnen (IETF)
> > Subject: RE: Does another RFC4181 update need to be done?
> > 
> > I have the nroff source for the draft that was approved for 
> > publication.  That source does not include the changes made by the 
> > RFC, nor any subsequently reported errata (and not all of the ones 
> > reported by me and Alfred Hoenes were posted on the RFC Editor 
> > site).  There is no xml2rfc source.
> > 
> > Let me know if you want what I have.  Probably the most accurate way
> 
> > to do the update would be to start from the RFC text and the errata.
> 
> > I kept a list of errata that I could dig out for you.  I did that 
> > once for Bert.
> > 
> > Mike
> > 
> > 
> > On Tue, 3 Mar 2009, David Harrington wrote:
> > > Do you have the sources?
> > > I might find time to do a quick update.
> > > 
> > > dbh 
> > > 
> > > > From: C. M. Heard [mailto:[email-masked]] 
> > > > Sent: Tuesday, March 03, 2009 1:51 AM
> > > > To: David Harrington
> > > > Cc: Dan Romascanu; Ron Bonica; Bert Wijnen (IETF)
> > > > Subject: Re: Does another RFC4181 update need to be done?
> > > > 
> > > > Yes it does -- but I don't have the time to do it.
> > > > 
> > > > It was a mistake (IMHO) to ever put any IPR stuff into 4181.  It
> > > > delayed the document by 1.5 years, waiting for the IPR WG to get
> > > > done with RFCs 3978 and 3979, and those docs have now been updated 
> > > > twice now.  If 4181 is ever rewritten and reissued, it should point 
> > > > to the legend instruction URLs -- which, one hopes, will be more
> > > > stable than the actual copyright text.
> > > > 
> > > > Mike Heard
> > > > 
> > > > On Mon, 2 Mar 2009, David Harrington wrote:
> > > > > Hi,
> > > > > 
> > > > > Does another RFC4181 update need to be done?
> > > > > See attached.
> > > > > 
> > > > > dbh
> > > > > 
> > > > > From: RFC Editor [mailto:[email-masked]] 
> > > > > Sent: Monday, March 02, 2009 8:12 PM
> > > > > To: Glenn M. Keeni; Pasi Eronen; Tim Polk; Russ Housley
> > > > > Cc: Stacy Burns; Chris Lonvick; David Harrington; RFC Editor
> > > > > Subject: [ADs] Re: AUTH48 [SB]: RFC 5427
> > > > > <draft-ietf-syslog-tc-mib-08.txt> NOW AVAILABLE
> > > > > 
> > > > > Glenn, Pasi, and Tim,
> > > > > 
> > > > > Does the copyright in the MIB need to be updated?  The text currently
> > > > > reads:
> > > > > 
> > > > >     DESCRIPTION
> > > > >         "The MIB module containing textual conventions for syslog
> > > > >          messages.
> > > > > 
> > > > >          Copyright (C) The IETF Trust (2009).  This version of
> > > > >          this MIB module is part of RFC 5427; see the RFC itself for
> > > > >          full legal notices.
> > > > >         "
> > > > > 
> > > > > The BSD license in the IETF-Trust-License-Policy document states:
> > > > > 
> > > > >    Copyright (c) <insert year> IETF Trust and the persons identified as
> > > > >    authors of the code.  All rights reserved.   
> > > > > 
> > > > > Thanks!
> > > > > 
> > > > > RFC Editor
> > > > > 
> > > > > 
> > > > > 
> > > > > On Sat, Jan 10, 2009 at 11:17:30AM +0900, Glenn M. Keeni wrote:
> > > > > > 
> > > > > > Hi,
> > > > > >  I, an author of RFC 5427, am aware of the new copyright notice
> > > > > >  and I do approve this document (RFC 5427) for publication under
> > > > > >  the RFC 5378 copyright notice and legends.
> > > > > > 
> > > > > >  Thanks and cheers
> > > > > > 
> > > > > > Glenn
> > > > > > 
> > > > > > Stacy Burns wrote:
> > > > > > > Correction, inline.
> > > > > > > 
> > > > > > > RFC Editor/sb
> > > > > > > 
> > > > > > >> On Jan 9, 2009, at 11:02 AM, Stacy Burns wrote:
> > > > > > >> Glenn,
> > > > > > >>
> > > > > > >> As of 10 November 2008, the RFC Editor has been instructed to publish
> > > > > > >> documents with the copyright notice and legends adopted by the IETF
> > > > > > >> by the publication of BCP 78 / RFC 5378.  Please review the new 
> > > > > > >> copyright notice and legends and the text located at 
> > > > > > >> http://trustee.ietf.org/license-info/.
> > > > > > >>
> > > > > > >> If you, as an author of RFC 5410, agree with the copyright and
> > > > > > > If you, as an author of RFC 5427 ...
> > > > > > >> legends as defined in RFC 5378, please send us an explicit
> > > > > > >> acknowledgment that you are aware of the new copyright notice and
> > > > > > >> legends and that you approve this document for publication under the
> > > > > > >> RFC 5378 copyright notice and legends.  If all of the authors agree, 
> > > > > > >> we will update RFC 5410 to reflect the new copyright notice as it
> > > > > > >> appears in Item 6b of 
> > > > > > >> http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf, and 
> > > > > > >> continue with the publication process.
> > > > > > >>
> > > > > > >> However, if you are unable to agree to publish the document with the
> > > > > > >> new copyright notice and legends, please let us know, and we will
> > > > > > >> delay publication until the issue has been resolved.  The appropriate
> > > > > > >> parties are working to resolve this issue as quickly as possible.  We 
> > > > > > >> plan to update you on the situation and provide an email address
> > > > > > >> (once it is available) where you can send your questions and/or 
> > > > > > >> concerns regarding the new copyright notice and legends.
> > > > > > >>
> > > > > > >> Please note that document currently available at 
> > > > > > >> http://www.rfc-editor.org/authors/rfc5427.txt doesn't reflect the 5378 
> > > > > > >> copyright. You must review it at http://trustee.ietf.org/license-info/.
> > > > > > >>
> > > > > > >> RFC Editor/sb
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > > 
> > > > > 
> > > > > 
> > > > 
> > > 
> > > 
> > 
> 

Subject: Re: Erratum for RFC 4181
From: "C. M. Heard" <[email-masked]>
To: RFC Editor <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, David Kessens <[email-masked]>
Date: Tue, 1 Nov 2005 21:12:49 -0800 (PST)

On Sun, 23 Oct 2005, C. M. Heard wrote:
> On Sun, 16 Oct 2005, Alfred HÎnes wrote:
> > I've [...] observed two minor typos in the text of RFC 4181
> > that migth be worth noting for consideration in the case of
> > any future update to this RFC:
> > 
> > *  The bottom text line of page 29 says:
> > 
> >       " ... .  Two point are worth reiterating:"
> >                        ^^
> >    It should say:
> > 
> >       " ... .  Two points are worth reiterating:"
> > 
> > *  The first line of item 8 in Appendix A, on page 34, says:
> > 
> >       "... -- if the draft does not contains a verbatim copy ..."
> >                                            ^
> >    It should say:
> > 
> >       "... -- if the draft does not contain a verbatim copy ..."
> 
> RFC Editor:
> 
> As document editor, I would like to request than an RFC Erratum be
> created for RFC 4181 listing these errors.  Thanks to Alfred HÎnes
> for pointing them out.

In addition to the above, I have noticed the following formatting
error in the first bullet in Section 4.6.1.1 on p. 14.  The text
in the RFC looks like this:

   - For integer-valued enumerations:

     - INTEGER is REQUIRED; - Integer32, Unsigned32, and Gauge32 MUST
     NOT be used.

and it should look like this:

   - For integer-valued enumerations:

     - INTEGER is REQUIRED;
     - Integer32, Unsigned32, and Gauge32 MUST NOT be used.

I would appreciate it if you would include this item when you create
the erratum for RFC 4181.

Regards,

Mike Heard

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 23 Sep 2009 10:14:46 +0200

I have some good news to share. Randy Presuhn stepped ahead and accepted
to be the editor of 4181bis. Thanks, Randy!

I have two questions: 

1. OPSAWG (which did not exist by the time 4181 was edited and
published) seems to me to be the natural home for 4181bis. Does anybody
see any problem with this? If all agree we shall move discussions to
[email-masked]

2.  What should be the scope of 4181bis? 

Thanks and Regards,

Dan

> Sent: Wednesday, September 23, 2009 12:31 AM
> To: Romascanu, Dan (Dan)
> Cc: Juergen Schoenwaelder; MIB Doctors (E-mail); OPS Area (E-mail)
> Subject: Re: [MIB-DOCTORS] [OPS-AREA] FW: IESG Statement on Copyright
> 
> Other than the copyright text that goes in MIB modules, the 
> only issues that I know of that we all agreed were actually 
> issues are the errata now on the RFC Editor site.  Attached 
> is an e-mail message on this subject sent to David Harrington 
> and Bert Wijnen earlier this year.
> 
> 2005 and 4 Jan 2006 as to whether RFC 4181 should be listed 
> as updating STD 58 (RFCs 2578, 2579, and 2580), as suggested 
> by Alfred Hoenes.  We decided that the answer was NO, but in 
> the process there was an inconclusive discussion as to 
> whether the MUSTs in 4181 that go beyond the requirements of 
> STD 58 (there are some in sec. 4.6.4) ought to be SHOULDs 
> instead.  The subject lines in the relevant threads are "RFC 
> 4181 indeed updates RFC 2578..2580" and "Erratum for RFC 
> 4181".  If it's too much of a pain to search the mib-doctors 
> archive, I can make the 28 messages that I saved from those 
> threads available as a Unix mbox file.
> 
> Mike Heard
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 23 Sep 2009 10:26:02 +0200

> threads available as a Unix mbox file.

This was the conversation that I also had in mind, although for some
reasons I remembered it being more dramatic than it looks to me now. 

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 23 Sep 2009 11:21:47 +0200

> 2.  What should be the scope of 4181bis? 

Bug fixes and alignment to current IETF procedures and rules (although
the last thing might be an endless undertaking ;-). As little rewrite
as possible if you ask me.

/js

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 23 Sep 2009 10:07:16 -0400

+1 
dbh 

> [mailto:[email-masked]] On Behalf Of Juergen 
> Schoenwaelder
> Sent: Wednesday, September 23, 2009 5:22 AM
> To: Romascanu, Dan (Dan)

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 23 Sep 2009 09:27:18 -0700 (PDT)

+1 also (though I really don't have a stake in the outcome).

One of the things that should probably be discussed is whether the 
issues brought up in the attached e-mail (downgrading some of the 
MUSTSs to SHOULDs) should be addressed under the head of bug fixes.

//cmh

> > as possible if you ask me.

Subject: Re: RFC 4181 indeed updates RFC 2578..2580 (fwd)
From: Andy Bierman <[email-masked]>
To: [email-masked]
Cc: "'C. M. Heard'" <[email-masked]>, "'Mreview (E-mail)'" <[email-masked]>,'Alfred HÎnes' <[email-masked]>
Date: Mon, 24 Oct 2005 13:05:09 -0700

David B Harrington wrote:

>Hi,
>
>As I contributed to the development of the mib guidelines, I thought
>we were producing guidelines to help people, not new rules to hit them
>over the head with.
>
>RFCs 2578-2580 were developed by a working group, following
>appropriate IETF procedures for developing new standards-track RFCs,
>notably those procedures documented in RFC2026, section 6.2. 
>
>The mib guidelines were developed by the MIB Doctors, a closed group,
>following a process that was consistent with BCP procedures, but not
>consistent with IETF procedures for developing new standards-track
>RFCs.
>
>Therefore, I object to the mib guidelines, a BCP document, being
>considered an official update to the SMIv2 STD rules, and I object to
>enforcement of the new MUST requirements in the mib guidelines, since
>those requirements can have a serious impact on implementers, who have
>not had the opportunity to debate the proposals in an open working
>group, and test the proposed and draft standards, as afforded by the
>three-phase standards-development process. 
>
>Is that a solid-enough opinion on the topic?
>

I agree with you.  I don't care as much about SNMP as I used to,
but from a process POV, it is better to make these guidelines SHOULD
instead of MUST, especially en masse.  IMO, MUST should be reserved
for when it would cause "obvious harm to interoperability" to do otherwise.
MIB style guidelines have a minimal impact (at best) on interoperability.
(Perhaps SHOULD is even too strong for some guidelines, but MAY is
too weak. Oh well.)

>David Harrington
>[email-masked]

Andy

>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of C. M. Heard
>>Sent: Monday, October 24, 2005 11:04 AM
>>To: Mreview (E-mail)
>>Cc: Alfred HÎnes
>>Subject: RE: RFC 4181 indeed updates RFC 2578..2580 (fwd)
>>
>>On Sat, 22 Oct 2005, Wijnen, Bert (Bert) wrote:
>>> If we want to do anything we should create the exact and complete list
>>> of what we are altering. Note that if something that is OK in STD58
>>> and is still OK/ACCEPTABLE (although maybe not recommended or prefered
>>> by RFC4181), then we (MIB doctors) can strongly advise a WG to follow
>>> the recommendations of 4181, but I doubt we can block a document for
>>> that. So I am somewhat hesitant to tag 4181 with a "Updates STD58"
>>> because it makes the "guidelines" a "hard rules" as opposed to
>>> guidelines. I think we intended the last (namely guidelines). I do
>>> see that at a few places we may be saying that we are in fact 
>>> changing a rule.
>>
>>Obviously, the "General Documentation Guidelines" in Section 3 don't
>>have anything to do with RFCs 2578/2579/2580 so we can focus attention
>>on Section 4, which says:
>>
>>   The guidelines in this section are intended to supplement the SMIv2
>>   documents in the following ways:
>>
>>    o to document the current generally accepted interpretation when
>>      those documents contain ambiguities or contradictions;
>>
>>    o to update recommendations in those documents that have been shown
>>      by practical experience to be out-of-date or otherwise suboptimal;
>>
>>    o to provide guidance in selection of SMIv2 options in cases where
>>      there is a consensus on a preferred approach.
>>
>>The first two bullets are clearly things that could be considered as
>>updating the SMIv2 RFCs, although there is precedent for not
>>considering ambiguity resolution as a specification update (for
>>instance RFC 1122 is not listed as updating RFCs 791 and 792, even
>>though it has text to clear up many ambiguities in those
>>specifications).  The last bullet covers usage guidelines, and I
>>tend to agree with Bert that since those are guidelines and not
>>hard-and-fast requirements they need not be considered updating to
>>the SMIv2 RFCs.
>>
>>Here is a list of things I've found in RFC 4181 that either update a
>>recommendation or document and resolve a contradiction in the SMIv2
>>RFCs.  The list seems pretty short;  it is possible that I've
>>overlooked something.
>>
>>- Section 4.2 abolishes the recommendation in RFCs 2579 and 2579
>>that names be limited to 32 characters.  It does not alter the
>>requirement that names be limited to 64 characters, so the critera
>>for syntactic validity remain unchanged.
>>
>>- Section 4.6.1.2 abolishes the requirement that RFC 2578 imposes on
>>"standard" MIB modules that the Counter64 type may be used only if
>>the information being modelled would wrap in less than one hour if
>>the Counter32 type was used instead.
>>
>>- Section 4.9 resolves contradictions between the general rule that
>>MIB moudule revisions shall not make semantic changes to existing
>>definitions and the specific lists of changes that RFC 2580 allows
>>to be made to compliance statements and capabilities statements.
>>
>>HOWEVER, this is not the whole story.
>>
>>After re-reading the document it becomes clear that RFC 4181 Section
>>4 supplements the SMIv2 documents in at least one other way that
>>those stated:  in some cases content requirements are imposed on
>>IETF MIB modules that go beyond the minimal requirements of correct
>>syntax specified in the STD 58 documents.  One example is Section
>>4.5 on the usage of the MODULE-IDENTITY macro.  It says:
>>
>>   RFC 2578 Section 5 describes how the various clauses are used.  The
>>   following additional guidelines apply to all MIB modules over which
>>   the IETF has change control:
>>
>>Another example is the following from Section 4.6.4:
>>
>>   - If dynamic row creation and/or deletion by management applications
>>     is supported, then:
>>   [ ... ]
>>     - There either MUST be one columnar object with a SYNTAX value of
>>       StorageType [RFC2579] and a MAX-ACCESS value of read-create, or
>>       else the row object (table entry) DESCRIPTION clause MUST specify
>>       what happens to dynamically-created rows after an agent restart.
>>
>>     - If the agent itself may also create and/or delete rows, then the
>>       conditions under which this can occur MUST be clearly documented
>>       in the row object DESCRIPTION clause.
>>
>>Should these things be considered as updating the STD 58 RFCs?  Or is
>>the situation something like the Host Requirements documents (RFCs
>>1122/1123, STD 3), which specify requirements for hosts that are in
>>addition to the basic requirements of the underlying protocols?
>>
>>Mike
>>
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 25 Sep 2009 17:17:49 +0200

I think that we should consider also the following: 

1. Update the tools information. We refer now
http://www.ops.ietf.org/mib-review-tools.html but is the information
there accurate, with smicng support aparently discontinued? 

2. information about templates - refer to RFC 5249 ? 

Also - is it time to move this discussion to OPSAWG? 

Dan
(speaking as contributor)

> Sent: Wednesday, September 23, 2009 7:27 PM
> To: David B Harrington
> Cc: 'MIB Doctors (E-mail)'; 'OPS Area (E-mail)'
> One of the things that should probably be discussed is 
> whether the issues brought up in the attached e-mail 
> (downgrading some of the MUSTSs to SHOULDs) should be 
> addressed under the head of bug fixes.
> 
> //cmh
> 
> > > > I have some good news to share. Randy Presuhn stepped ahead and 
> > > > accepted to be the editor of 4181bis. Thanks, Randy!
> > > > 
> > > > I have two questions: 
> > > > 
> > > > published) seems to me to be the natural home for 
> 4181bis.  Does 
> > > > anybody see any problem with this? If all agree we shall move 
> > > > discussions to [email-masked]
> > > > 
> > > Bug fixes and alignment to current IETF procedures and rules 
> > > (although the last thing might be an endless undertaking ;-). As 
> > > little rewrite as possible if you ask me.
> > > 
> > > /js
> > > 
> > > --

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 25 Sep 2009 12:28:18 -0400

The MIB templates should be updated to match the updated copyright as
well.
I think should also be done in OPSAWG.

dbh 

> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Friday, September 25, 2009 11:18 AM
> To: C. M. Heard; David B Harrington
> Cc: MIB Doctors (E-mail); OPS Area (E-mail)
> Subject: RE: [MIB-DOCTORS] [OPS-AREA] FW: IESG Statement on
Copyright

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 25 Sep 2009 18:36:08 +0200

Good point. 

Dan

> From: David B Harrington [mailto:[email-masked]] 
> Sent: Friday, September 25, 2009 7:28 PM
> To: Romascanu, Dan (Dan); 'C. M. Heard'
> Subject: RE: [MIB-DOCTORS] [OPS-AREA] FW: IESG Statement on Copyright
> 
> The MIB templates should be updated to match the updated 
> copyright as well.
> whether the