Subject: [OPSAWG] agenta topics for opsawg in Anaheim

From: [email-masked] (Scott O. Bradner)
Date: Sat, 6 Feb 2010 16:13:38 -0500 (EST)

does anyone have agenda items for a opsawg session in Anaheim?

Scott

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 7 Feb 2010 15:48:37 +0100

(speaking as a contributor) - I think that the I-D  proposal for a MIB
module for power state and energy consumption monitoring
http://www.ietf.org/id/draft-quittek-power-mib-00.txt should be on the
agenda. 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Scott O. Bradner
> Sent: Saturday, February 06, 2010 11:14 PM
> To: [email-masked]
> Subject: [OPSAWG] agenta topics for opsawg in Anaheim
> 
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: Benoit Claise <[email-masked]>
Date: Mon, 08 Feb 2010 10:55:57 +0100

Scott,

On the same topic, I would like to have the opportunity to present
http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-01

Regards, Benoit.

---

From: "Juergen Quittek" <[email-masked]>
Date: Mon, 8 Feb 2010 21:13:39 +0100

Yes, I would like to get a slot for presenting it.

Thanks,

    Juergen

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 20 Feb 2010 21:57:54 -0800

Hi -

> From: "Scott O. Bradner" <[email-masked]>
> To: <[email-masked]>
> Sent: Saturday, February 06, 2010 1:13 PM

Some discussion of whether to do an update of RFC 4181 would be nice.
Based on non-response so far, I'm assuming there's no interest,
but it would be nice to have a positive statement of non-interest
so I can drop it from my project list.

Randy

---

From: "David Harrington" <[email-masked]>
Date: Sun, 21 Feb 2010 01:16:32 -0500

At one point, I considered to doing the update.
Mike Heard sent m,e points he had gathered that required updating.
I'd have to look through my emails to find them.
That might take a few days to search through my various files of
emails.

I do think the document that might be better addressed is MIB design
issues, such as flatening tables, o rfavtoring tables, and table
fate-sharing, and possibly relational-database normalization
considerations, such as deletion anomalies, and addition anomlaies
(which fall under the scope of fate-sharing).

dbh 

> [mailto:[email-masked]] On Behalf Of Randy Presuhn
> Sent: Sunday, February 21, 2010 12:58 AM
> To: [email-masked]
> Subject: Re: [OPSAWG] agenta topics for opsawg in Anaheim
> 
> Hi -
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 20 Feb 2010 22:33:38 -0800

Hi -

I submitted an internet draft based on Mike's files in September.
There was some discussion in September, but after the current
version, draft-presuhn-opsawg-rfc4181bis-03.txt, was posted on
September 29, I've heard nothing.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 21 Feb 2010 08:02:05 +0100

> so I can drop it from my project list.

Most of the changes so far seem to be editorial or the incorporation
of errata. I am wondering whether there are more substantial changes
needed and there are people to produce text people can agree on. Is
there something coming up regularly in MIB reviews we can address by
documentation?

/js

-- 
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: Sun, 21 Feb 2010 11:37:00 +0100

Speaking as a contributor, I believe that a revision of 4181 is
necessary. I suggest to add this item to the agenda of the meeting in
Anaheim and discuss whether 

1. there is consensus from the WG to continue this work and baseline
draft-presuhn-opsawg-rfc4181bis as WG I-D
2. if the answer at #1 is 'yes' what are the extent of changes or
additions we want to include  in rfc418bis

I will try to scan the MIB reviews in the last couple of years to look
for misses or unclarities as asked by Juergen. Other are welcome to
share their experience. I am copying the MIB Doctors list in case there
are MIB Doctors who are not on OPSAWG - all are welcome to contribute to
this discussion. 

Regards,

Dan

> [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
> Sent: Sunday, February 21, 2010 9:02 AM
> To: Randy Presuhn
> Cc: [email-masked]
> > Based on non-response so far, I'm assuming there's no 
> interest, but it 
> > would be nice to have a positive statement of non-interest so I can 
> > drop it from my project list.
> 
> Most of the changes so far seem to be editorial or the 
> incorporation of errata. I am wondering whether there are 
> more substantial changes needed and there are people to 
> produce text people can agree on. Is there something coming 
> up regularly in MIB reviews we can address by documentation?
> 
> /js
> 
> --

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 21 Feb 2010 17:17:28 -0800 (PST)

On Sun, 21 Feb 2010, Juergen Schoenwaelder wrote:
> needed and there are people to produce text people can agree on.

If I understand correctly what I read, Juergen is correct: Randy's 
draft incorporates the known errata, the 4841 updates, and some 
editorial changes.  If nothing else was needed, then it would not be 
worth the pain of an update.

However, the copyright notice instructions in 4181 + 4841 (and 
therefore 4181bis) are now seriously obsolete; see, e.g., RFC 5676 
for a recent example.  Indeed, my suggestion to update the document 
(made last September on the MIB-Doctors list) was in direct response 
to an IESG statement that made that copyright stuff obsolete; see 
http://www.ietf.org/mail-archive/web/mib-doctors/current/msg00985.html 
and other messages in that thread.  4181bis does not (yet) have the 
substantive updates needed to align the document with actual 
practice.  My suggestion would be to replace all the text spelling 
out copyright notices and the like with pointers to where current 
information can be found -- assuming that there is consensus that 
this work is necessary.

> additions we want to include  in rfc418bis

I'll chime in with a "yes" to #1.

As for #2, I would certainly recommend replacing the parts of 4181 
that say what copyright and IPR text to put in MIB documents with 
pointers to the authoritative sources on the IETF web site.  Apart 
from that I am neutral.

> are MIB Doctors who are not on OPSAWG - all are welcome to contribute to

Sounds good ... I will lurk and maybe comment from time to time.

Mike Heard

P.S. One nit in draft-presuhn-opsawg-rfc4181bis-03.txt ... one of 
the changes was this:

o  Changed keyword boilerplate to match what is required by idnits.
   (The phrase "NOT RECOMMENDED" is not included in the boilerplate, 
   even though used in the text.)

Rather than do this, please fix idnits, ignore the warning, or 
eliminate the use of NOT RECOMMENDED in 4181bis.  Please note that 
this term is sanctioned by RFC 2119:

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

It's true that RFC 2119 does not include this term in its standard 
boilerplate, but that's obviously a bug in 2119 that has been 
carried forward into idnits.  We should not be slaves to bugs in 
the robot tools!

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 21 Feb 2010 19:45:02 -0800

Hi -

> From: "C. M. Heard" <[email-masked]>
> To: "OPSAWG" <[email-masked]>
> Sent: Sunday, February 21, 2010 5:17 PM
...
> information can be found -- assuming that there is consensus that 
...

Agreed.  But...  I haven't been able to find any one place that actually
spells out exactly what is needed and where it should go.  The current
TLP document seems confusing, since it doesn't seem to match up
with current practice.  Last time I read it (it keeps changing, so I don't
bother trying to keep up with the changes) a MIB module should only
need words to the effect of "see the RFC for full legalese", but that
appears to not be current practice.

<half-facetiously>
Perhaps we should ask the xml2rfc folks to add yet another option
that will cause the tool to insert legalese-du-jour into the MIB module
as well as the other places in the document, and the guidelines could
jsut RECOMMEND using xml2rfc to generate the proper incantations.
</half-facetiously>

That said, if someone has suggested text, I'll happily incorporate it
in the i-d.

Randy

---

From: "tom.petch" <[email-masked]>
Date: Mon, 22 Feb 2010 17:23:06 +0100

----- Original Message -----
From: "Randy Presuhn" <[email-masked]>
To: "OPSAWG" <[email-masked]>
Sent: Monday, February 22, 2010 4:45 AM

Randy

Not so facetiously, I think that the rage - whoops, rate - of change of the
TLP has exceeded the rate of change that those who have updated xml2rfc in the
past are willing to countenance.  I saw a plea for people to take over (on the
ietf list) and subsequent posts suggested that xml2rfc was no longer up to date
with
the TLP.

So, I believe that whatever the current TLP says is right, and xml2rfc is
wrong and that means that what we now see is often wrong.

Looking ahead, I think that this may well be not uncommon, so I think it wrong
for rfc4181bis to include boilerplate, but should rather find a url or some such
by which to reference the current TLP, whatever that might be.

Tom Petch

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 22 Feb 2010 13:53:41 -0800

Hi -

> From: "tom.petch" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; "OPSAWG" <[email-masked]>
> Sent: Monday, February 22, 2010 8:23 AM
> Subject: RFC4181bis was Re: [OPSAWG] agenta topics for opsawg in Anaheim
...
...

If the TLP document were clear about what the incantations needed to be,
I'd agree.  But what http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf
section 6 seems to say is different from my understanding of the advice being
given to editors of internet drafts containing MIB modules.  Or should we simply
assume that http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf will
someday become correct (whether through changes to it or to current practice
or both) and be done with it?

Randy

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 22 Feb 2010 18:54:52 -0800 (PST)

On Mon, 22 Feb 2010, Randy Presuhn wrote:
> [Tom Petch wrote:]

I think I hear an echo of the frustration that I felt as the editor of 4181 when
publication of the document was held up for about 1.5 years waiting for the IPR
documents to get straightened out.  I had hoped that the problem would have been
fixed this time, but it seems not.

Maybe it's time to light a fire under the IESG to make practice match what the
Trust documents say it should be, or to pressure the Trust document current pratice.

Or maybe 4181bis should simply not say anything at all about such matters and
just concentrate on technical issues with MIB modules.

It is really annoying that this problem still isn't satisfactorily solved.

Mike

---

From: "tom.petch" <[email-masked]>
Date: Tue, 23 Feb 2010 14:10:58 +0100

----- Original Message -----
From: "Randy Presuhn" <[email-masked]>
To: "OPSAWG" <[email-masked]>
Sent: Monday, February 22, 2010 10:53 PM
> I'd agree.  But what
http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf
> or both) and be done with it?

I think that the TLP is clear:-)  Section 6 tells you what to put in an IETF
document, ie RFC or I-D; it does not tell you what goes where, it delegates that
to the RFC Editor or IESG.

There is no equivalent of RFC3978 s5.6a; nowhere does it say what must appear
in the Code Component in the I-D or RFC.  Instead, section 4d tells you that
users of Code Components should include an Attribution without specifying the
precise form of words so I think that something like.
         "Copyright (C) The IETF Trust <year>.  This version of
         this MIB module is part of RFC XXXX; see the RFC itself for
         full legal notices."

would encourage such users to get it right, and so could be included.

Section 6 is entitled 'Text To Be Included in IETF Documents" but 6d tells me
not what must appear in the IETF Document, but rather, what the extractor of the
Code Component may put in the extracted Code Component instead of the full BSD
licence from Section 4c.  Note that neither of these include the Attribution so
I think that the Attribution is the one thing that should appear in the Code
Component in the I-D or RFC.  But that is a personal opinion.

You could of course raise this on the IETF list, or the TLP list, which should
be good for another six months of churn; but really, I think we should stay out
of it and not put any detailed advice into RFC4181bis; raise the issues and then
point them at TLP (and, perhaps,  I-D Guidelines, and the RFC Editor's
equivalent thereof).

I think that the TLP is under the guidance of RFC5377 and that it is
authoritative unless and until it contradicts that RFC.

Tom Petch

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 23 Feb 2010 11:52:41 -0800

Hi -

> Sent: Tuesday, February 23, 2010 5:10 AM
> Subject: Re: [OPSAWG] RFC4181bis was Re: agenta topics for opsawg in Anaheim
...
> would encourage such users to get it right, and so could be included.

That was my reading as well, but as the editor of a MIB document, I was
told more was needed.  I don't want to dive into this particular snakepit,
so I just do what I'm told.  Perhaps we should advise MIB authors to omit
the notice from the MIB module, and make the IESG deal with figuring out
what should be there based on the policy du jour - they (or a MIB doctor)
will need to check whatever is there anyway.

...
> point them at TLP (and, perhaps,  I-D Guidelines, and the RFC Editor's

I'm inclined to agree.  All evidence from the last year or so indicates that
the TLP is a moving target, and I have no reason to believe that all the
bugs (e.g. the pre-5378 mess) have been eliminated.

But it's a very unfortunate state of affairs.  Writing a MIB document is
intimidating enough, without forcing someone potentially new to the
IETF (especially someone who does not have English as his/her first
language, and to whom the jargon of American legalese may be
particularly alien) to dig through the TLP to come up with the correct
incantation.  I know the lawyers care a great deal about this stuff,
but for the typical person working on a MIB module, it's just a time
and energy sink, another hoop to jump through.  Anything we can
do to make it less onerous should be considered, even though it
might mean a little extra work for this group.

Randy

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 23 Feb 2010 21:46:17 -0800 (PST)

On Tue, 23 Feb 2010, Randy Presuhn wrote:
> Perhaps we should advise MIB authors to omit the notice from the 
> MIB module, and make the IESG deal with figuring out what should 
> be there based on the policy du jour - they (or a MIB doctor) will 
> need to check whatever is there anyway.

The problem with that is that 4181 (and presumably 4181bis as well) 
is supposed to be a guide for the reviewers (i.e., MIB Doctors) as 
well as for the authors.

> [Tom Petch said:]
> But it's a very unfortunate state of affairs.

You can say that again.  It's a really dreadful state of affairs.

> Writing a MIB document is intimidating enough, without forcing 
> someone potentially new to the IETF (especially someone who does 
> not have English as his/her first language, and to whom the jargon 
> of American legalese may be particularly alien) to dig through the 
> TLP to come up with the correct incantation.  I know the lawyers 
> care a great deal about this stuff, but for the typical person 
> working on a MIB module, it's just a time and energy sink, another 
> hoop to jump through.  Anything we can do to make it less onerous 
> should be considered, even though it might mean a little extra 
> work for this group.

+1

What's needed, of course, is a stable URL that points to the 
requirements du jour.  If I'm not mistaken, we are covered already 
on general boilerplate -- copyright notices, IPR, and the like.  
The part that's missing is a nice little recipe that says "put this 
notice into the MODULE-IDENTITY clause of your MIB module" (which 
3978 had and which 4181 copied).  I see two things that "this group" 
needs to do to make this happen: (1) get the IESG to agree that said 
stable URL and recipe are needed; and (2) be prepared to help write 
the initial version of the recipe.  (I put "this group" in quotes 
because I am not volunteering to help do this.  My bad, sorry.)

Mike Heard

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 24 Feb 2010 15:08:46 +0100

> [mailto:[email-masked]] On Behalf Of C. M. Heard
> Sent: Wednesday, February 24, 2010 7:46 AM
> To: OPSAWG
> > Perhaps we should advise MIB authors to omit the notice 
> from the MIB 
> > module, and make the IESG deal with figuring out what 
> should be there 
> > based on the policy du jour - they (or a MIB doctor) will need to 
> > check whatever is there anyway.
> 
> The problem with that is that 4181 (and presumably 4181bis as 
> well) is supposed to be a guide for the reviewers (i.e., MIB 
> Doctors) as well as for the authors.
> 
> > [Tom Petch said:]
> > > You could of course raise this on the IETF list, or the TLP list, 
> > > which should be good for another six months of churn; but 
> really, I 
> > > think we should stay out of it and not put any detailed 
> advice into 
> > > RFC4181bis; raise the issues and then point them at TLP (and, 
> > > perhaps,  I-D Guidelines, and the RFC Editor's equivalent 
> thereof).
> > 
> > I'm inclined to agree.  All evidence from the last year or so 
> > indicates that the TLP is a moving target, and I have no reason to 
> > believe that all the bugs (e.g. the pre-5378 mess) have 
> been eliminated.
> > 
> > Writing a MIB document is intimidating enough, without 
> forcing someone 
> > potentially new to the IETF (especially someone who does not have 
> > English as his/her first language, and to whom the jargon 
> of American 
> > legalese may be particularly alien) to dig through the TLP 
> to come up 
> > with the correct incantation.  I know the lawyers care a great deal 
> > about this stuff, but for the typical person working on a 
> MIB module, 
> > it's just a time and energy sink, another hoop to jump through.  
> > Anything we can do to make it less onerous should be 
> considered, even 
> > though it might mean a little extra work for this group.
> 
> +1
> 

The IESG provided that URL. See
http://www.ietf.org/iesg/statement/copyright.html 

Today from there one gets to section 4.e of the TLP which then points to
section 4.c (full text of simplified BSD license) or 6.d (BSD License
Notification). 

I think that

>         This version of this MIB module is part of RFC XXXX;
>          see the RFC itself for full legal notices.

still needs to be added, the reason is that there may be other legal
notices beyond the license that the people using the extracted MIB
module may want to see.

Dan

---

From: "David Harrington" <[email-masked]>
Date: Wed, 24 Feb 2010 12:32:21 -0500

Hi,

To help authors (and reviewers), I developed templates to meet the
consensus of the MIB Doctors. Those templates contain copyright
boilerplate.

RFC4181bis could point to the stable URL at tools.ietf.org which is
linked with a stable URL controlled by the rfc-editor, containing
templates for MIB modules and xml2rfc documents, etc. I think we could
easily point to either stable URL.

The problem with this approach is that the TLP keeps changing which
boilerplate is correct, and the tools (xml2rfc and the templates) are
not kept up-to-date (and are hard to keep up-to-date because of the
rate of churn).

An RFC is a bad place to put things that suffer churn. I recommend
having the RFC point to the stable URL(s) for tools, and then keeping
the tools up to date.

A template containing the appropriate templates was probably a good
approach when boilerplates were stable. 

Since boilerplates are not stable, and/or require choices to determine
which boilerplate parts should be included, such as the IANA section
or the MIB security boilerplate, it might be much better to develop an
interactive tool (or series of tools) for authors to answer a series
of questions so the tools (e.g. xml2rfc) could generate the
appropriate template with up-to-date copyright, up-to-date iana
considerations, up-to-date MIB security boilerplate, etc. A
corresponding tool for reviewers, similar to idnits, could be used to
check the boilerplates and confirm the choices that were made. And the
tools might be able to be configured using config files that point to
the latest options and corresponding URLs for boilerplate revisions.

Then RFC4181bis could point to the stable URLs to the tools.

And i think such an approach coudl also be exopanded to provide
support for things like YANG files as well as MIBs. The "guidelines"
documents for MIBs and YANG modules might be different RFCs, but might
be able to point to a common set of URLs for tools to help automate
the process of data model document prep.

dbh

> [mailto:[email-masked]] On Behalf Of tom.petch
> Sent: Tuesday, February 23, 2010 8:11 AM
> To: Randy Presuhn; OPSAWG
> > > Looking ahead, I think that this may well be not 
> uncommon, so I think it
> wrong
> > > for rfc4181bis to include boilerplate, but should rather 
> find a url or some
> such
> > given to editors of internet drafts containing MIB modules. 
>  Or should we
> simply
> > assume that 
> http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf will

---

From: "David Harrington" <[email-masked]>
Date: Wed, 24 Feb 2010 12:53:19 -0500

Just a few more comments:

if a web service was maintained at tools.ietf.org that could record
the choices relevant to boilerplate selectiona, and then generate a
template, the "config file" could actually be a series of xml2rfc
processing instructions at the head of the generated xml2rfc template.
A corresponding tool might also handle updating the choices and the
template's processing instructions.

If we are fairly clear about what needs to be included for boilerplate
sections for IANA and MIB security portions, these might be handled as
xml2rfc processing instructions such as

<boilerplate="MIBsecurity"> 
  <type=rw>
	<list>
		foobarEnable
		foobarDisable
	</list>
   </type>
   <type=ro>
	<list>
		foobarCounter
	</list>
   <type=readcreate>
	<list>
		foobarEntry
	</list>
   </type>
</boileplate>

<boilerplate="MIB-iana"> 
  <type=exists>
	<list>
		entity-mib (52)
	</list>
   </type>
   <type=new suggestedXXX=179>
	<list>
		powermib={ mib-2 XXX }
	</list>
</boileplate>

and so on.

dbh

> [mailto:[email-masked]] On Behalf Of David Harrington
> Sent: Wednesday, February 24, 2010 12:32 PM
> To: 'tom.petch'; 'Randy Presuhn'; 'OPSAWG'

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 24 Feb 2010 11:00:27 -0800

Hi -

> From: "Romascanu, Dan (Dan)" <[email-masked]>
> To: "C. M. Heard" <[email-masked]>; "OPSAWG" <[email-masked]>
> Sent: Wednesday, February 24, 2010 6:08 AM
...
> http://www.ietf.org/iesg/statement/copyright.html 

Would it be preferable to include a normative reference to the IESG statement?
Instead of or in addition to the one to the TLP?

> notices beyond the license that the people using the extracted MIB

This very short notice would certainly make for concise boilerplate.
Current practice in other WGs notwithstanding, can we say that this
is all that is required in the MIB module itself?  Being able to do so
(and include that text in 4181bis) would make it much easier for
MIB authors trying to do the right thing.

Randy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 24 Feb 2010 20:00:59 +0100

> Current practice in other WGs notwithstanding, can we say 
> that this is all that is required in the MIB module itself?  
> Being able to do so (and include that text in 4181bis) would 
> make it much easier for MIB authors trying to do the right thing.
> 
> Randy
> 

No, unfortunately not. This was my initial strong preference as well,
and this is how I first drafted the IESG statement, but when it reached
the IETF Legal Council he pointed out that MIB and PIB modules are
considered code, so according to RFC 5377, RFC 5378, and the resulting
IETF Trust Legal Provisions (TLP) either the full text of a reference to
the BSD license needs to be included. Many edits and discussions later
the IESG issued the current statement. 

Dan

---

From: "tom.petch" <[email-masked]>
Date: Wed, 24 Feb 2010 20:17:19 +0100

----- Original Message -----
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Randy Presuhn" <[email-masked]>; "OPSAWG" <[email-masked]>
Sent: Wednesday, February 24, 2010 8:00 PM
> the IESG issued the current statement.

I do not think that this is quite right.  RFC5378 and RFC5377 delegate to the
IETF Trust the task of determining what text goes into IETF Documents, laying
down the principles on which that text should be based..  The TLP is the outcome
of that, and it delegates to the IESG the task of determining where things go in
I-Ds, not what goes in (nor anything to do with RFC).

I see nowhere in the TLP a requirement for the full BSD licence to appear
anywhere, except in the TLP itself, or even an abbreviated licence.  Rather, the
requirement is for one or the other to appear in Code Component material
extracted from the I-D or RFC.

In this regard, I think that the IESG statement you provided a link to earlier
is well, misleading, perhaps wrong.
"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. "
No they mustn't, 6.d is about the program or other file that includes the Code
Component, not about the IETF Document.

"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."
No, either the licence from 4.c or the abbreviated licence from 6.e, either will
do.  Common sense would say use the shorter 6.e.

And what about 4.d, the most important part?  The IESG statement completely
ignores it and that is what we are currently talking about, what should replace
the legend in RFC3978 5.6a? True, 4.d, like 6.e,, does not require that to
appear in the IETF Document, only in Code Components extracted therefrom, but I
think that that is what we should include in every MIB.

Tom Petch

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 25 Feb 2010 10:22:56 +0100

Hi Tom,

See in-line. 

Thanks and Regards,

Dan

> From: tom.petch [mailto:[email-masked]] 
> Sent: Wednesday, February 24, 2010 9:17 PM
> To: Romascanu, Dan (Dan); Randy Presuhn; OPSAWG
> Subject: Re: [OPSAWG] RFC4181bis
> 
> that this 
> > > is all that is required in the MIB module itself?
> > > Being able to do so (and include that text in 4181bis) 
> would make it 
> > > much easier for MIB authors trying to do the right thing.
> > >
> > > Randy
> >
> > and this is how I first drafted the IESG statement, but when it 
> > reached the IETF Legal Council he pointed out that MIB and 
> PIB modules 
> > are considered code, so according to RFC 5377, RFC 5378, and the 
> > resulting IETF Trust Legal Provisions (TLP) either the full 
> text of a 
> > reference to the BSD license needs to be included. Many edits and 
> > discussions later the IESG issued the current statement.
> 
> I do not think that this is quite right.  RFC5378 and RFC5377 
> delegate to the IETF Trust the task of determining what text 
> goes into IETF Documents, laying down the principles on which 
> that text should be based..  The TLP is the outcome of that, 
> and it delegates to the IESG the task of determining where 
> things go in I-Ds, not what goes in (nor anything to do with RFC).
> 
> I see nowhere in the TLP a requirement for the full BSD 
> licence to appear anywhere, except in the TLP itself, or even 
> an abbreviated licence.  Rather, the requirement is for one 
> or the other to appear in Code Component material extracted 
> from the I-D or RFC.

This is the case when a MIB module is extracted from an RFC - isn't it
so? 

> 
> In this regard, I think that the IESG statement you provided 
> a link to earlier is well, misleading, perhaps wrong.
> "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. "
> No they mustn't, 6.d is about the program or other file that 
> includes the Code Component, not about the IETF Document.
> 

The advice from the legal council was to include the license (full or
short notice) into all code components, which includes MIB and PIB
modules (and YANG modules in the future). The reason is that we cannot
know and rely on what programs that extract and include code components
will do. 

> "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."
> No, either the licence from 4.c or the abbreviated licence 
> from 6.e, either will do.  Common sense would say use the shorter 6.e.

I believe that most people will follow common sense. 

> 
> And what about 4.d, the most important part?  The IESG 
> statement completely ignores it and that is what we are 
> currently talking about, what should replace the legend in 
> RFC3978 5.6a? True, 4.d, like 6.e,, does not require that to 
> appear in the IETF Document, only in Code Components 
> extracted therefrom, but I think that that is what we should 
> include in every MIB.

There is no 6.e in the TLP, so I am not sure what you refer to - is it
6.d? 

I tend to agree that 4.d should be included. The observation is that
inclusion in code (MIB module) is a 'may' in 4.d.  It would be OK to
recommend it in 4181bis. 

Concerning the IESG statements, like any IETF document they are subject
to discussion and improvement. If you feel that the IESG statement
should make the same recommendation please raise the issue with the
IESG. Personally I would wait for 4181bis to advance and collect more
opinions and maybe other issues.