Subject: Re: [nmrg] NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt for Informational RFC
From: Frank Strauß <[email-masked]>
To: [email-masked]
Date: Wed, 31 Jan 2007 16:43:11 +0100
List-Id: Network Management Research Group <nmrg.ibr.cs.tu-bs.de>

Wijnen, Bert (Bert) wrote:
> Juergen and NMRG members. 
> 
> Pls review and post your opinion BEFORE Feb 17th, 2007.

I have read the document and came up with the following comments:

- General:

   What about a glossary to introduce a few common terms for the
   entities and processing steps? I would love to see a figure that
   shows these entities and steps with their relationships and the
   levels of concrete/anonymized/meta data. This could especially help
   to make clear in which spheres anonymized and non-anonymized data
   could reside. (I still have my problems with this question.)

- Section 1, 2nd paragraph

   It looks a bit unfair to state that the mentioned performance
   related publications are based on speculations about SNMP
   performance. I propose to rephrase the last sentence to something
   like: "In fact, there are many speculations how SNMP is being used
   in real world production networks and performance comparisons are
   based on limited test cases, but no systematic wide-range
   measurements have been performed and published so far."

- Section 2.1, 1st paragraph

   You should probably also write a few words about the (unlikely) case
   of fragmented packets.

- Section 2.1, concerning port monitoring

   In practice, such monitoring ports cannot always be configured this
   way. E.g., our (relatively new) Nortel switches allow a monitoring
   port only to monitor no more than two other ports or up to two MAC
   addresses on any port. I have no experience with other vendors, but
   I guess it is a general question of available CPU and bandwidth
   resources on a device's management plane.

- Section 2.1, 3rd paragraph concerning h/w checksum offloading

   Why do you suggest to turn offloading off? In my opinion, wrong
   checksums in traces don't hurt. A short note, so that people don't
   wonder about wrong checksums should be enough.

- Section 2.1, 4th paragraph concerning pcap backups/archives

   Hm. I don't like this paragraph. Software should be "mature enough"
   before you ask people to use it. At least, integrety and correctness
   of data at steps 4+5 should remain the responsibilty of the party
   who would like to collect the measurements.

- Section 2.2, 1st paragraph

   Pcap files *are* machine readable. Porposal: "...that are human
   readable while remaining also machine readable for ..."

- Section 2.2, 2nd paragraph

   s/a [OASISRNG] schema/a RELAX NG schema [OASISRNG]

- Section 2.2, 4th paragraph concerning h/w checksum offloading again

   I suggest to make checksum error ignorance mandatory. See another
   comment above.  Are you sure that pcap files recorded with a tool
   like tcpdump and with the aforementioned filter expression contain
   IP fragments at all? I didn't check it.

- Section 2.2, last paragraph concerning XML and CSV formats

   So snmpdump cannot read CSV and creating CSV is one-way? Maybe, it's
   worth to state this explicitly. Furthermore, I would prefer to
   decide for one format. That would make data handling, script
   authoring, etc. much easier.

- Section 2.3, 1st paragraph concerning Perl

   The Perl community names it "modules" instead of "packages",
   AFAIK. If you decide to change it, also grep for subsequent
   occurances of the word "package".

- Section 2.3, 2nd paragraph concerning anonymization retaining lexi-order

   It would be fine to have this feature mature enough so that this is
   no longer work in progress when the document is ready to become an
   Informational RFC.  Maybe it already is, since HS06 was published in
   April 2006? However, the goal seems to be non-trivial to me,
   especially when you want to be able to merge traces, right?

   I'm generally missing more information about anonymization. Which
   pieces of information can or should be anonymized? Wouldn't it be
   meaningful to add a flag to the schema to signal which pieces have
   actually been anonymized?  Should a value A that has been anonymized
   to value B be anonymized to B again in subsequent occurances? If
   yes, how could this mapping be maintained for merged traces? I think
   there are quite some interesting questions. :-)

   A central question for this document is, whether these issues should
   be addressed here or whether they should be left to implementors or
   to other documents. In the latter case, it should be made clear that
   the schema specified in this document can be expanded somehow.

- Section 2.4, 1st paragraph concerning storage of pcap and processed data

   Why should they be stored together? My understanding is that the
   person that records the trace may be interested in anonymization of
   the data. So pcap data MIGHT be archived by the user that applies
   steps 1-3 (see also above), and the XML or CSV data is stored in the
   repository.

- Section 2.4, last paragraph concerning storage of original pcap data

   Due to the obvious conflict in the interests of the data supplier
   (anonymized data) and the repository operator (availabilty also of
   source data), I suggest to drop the strict need to keep the original
   data.

- Section 3.6, 2nd paragraph

   s/identity/identify/

- Section 3.9

   a/Assumption/Assumptions/

- Section 3.12

   Please give a reference to RFC 2579.

- Section 4.1, the RNG Schema

   I did not read the schema carefully, primarily because I'm not very
   familiar with Relax NG. Maybe some of the comments in Section 4.2
   also apply to this schema.

   I tried to convert the schema to XSD using trang, but only got a
   trang segfault on Debian/sarge, so I'm not sure whether I did
   something wrong, whether there is an error in the schema, or whether
   just my trang is broken.

   Are elements by default optional? I suggest to make almost all
   pieces of information optional, so that data suppliers can remove
   those pieces of information that they have to hide for any reason.

- Section 4.2, CSV value #8 (SNMP protocol operation)

   Maybe, it would be better to delay decoding of the SNMP operation
   (and probably other types of decoding) to the analysis step, so that
   (obscure and very unlikely) cases of non-standard operations could
   also be handled? If you want to have such values in a human readable
   form, maybe a mixture of text (if well-known an decodeable) and
   numeric (if unknown) values would be doable.

- Section 4.2, CSV value #10 (SNMP error-status)

   Why do you decode protocol operations to keywords, and keep
   error-status as a numeric value?

- Section 4.2, CSV value #13/3 (object values)

   Does this mean, that exception names appear twice? Wouldn't it be
   better to keep the third value empty in case of exceptions?

- Section 5, 1st paragraph on sensitive data

   It is a subjective matter what pieces of information are
   "unneeded". I propose something like s/unneeded/unwanted/.

- Section 5, 2nd paragraph

   s/suppress/suppress or anonymize/ ?

(I did not review Sections 7+ (References and below).)

Date: Wed, 31 Jan 2007 09:38:57 +0100
From: Aiko Pras <[email-masked]>
To: [email-masked]
Subject: Re: [nmrg] NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt for Informational RFC
Cc: [email-masked], "Wijnen, Bert \(Bert\)" <[email-masked]>

Wijnen, Bert (Bert) wrote:
> NMRG members:
> 
> In order to consider this as an NMRG document, it is not sufficient 
> to "not object". We need at least a set of NMRG members/participants
> to review the document and to comment. If you are happy with the
> document and support its publication as an NMRG supported
> Informational RFC, then I would like to hear that, prefereably
> by posting such a statement to the NMRG list. Something aka
> 
>   I have read the document, it is in good shape and I support
>   its publication as Informational RFC.

Hi all

I've read the document and I'm very happy with it. I support very much 
publication as Informational RFC. :-)

Aiko

Content-class: urn:content-classes:message
Date: Tue, 30 Jan 2007 14:58:54 +0100
From: "Wijnen, Bert \(Bert\)" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: [nmrg] NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt for Informational RFC

Juergen and NMRG members. 

Pls review and post your opinion BEFORE Feb 17th, 2007.

Juergen wrote:
> > [...] Since I am personally involved
> > as the author/editor, the first thing we need is a shepherd who is 
> > willing to run the process, which starts with soliciting RG 
> reviews by 
> > doing a RG last call. Any volunteers?
> 
> Our shepherd for <draft-irtf-nmrg-snmp-measure-01.txt> is 
> Bert Wijnen and he will now take over the procedure. Thanks 
> to Bert for helping us with this and also many thanks to the 
> others who volunteered to help move this document along.
> 
> /js
I am starting my work as shepherd of this document, using
the irtf-rfcs-01a draft (as Juergen had included in his
posting last Friday) as the process to follow. This is
based on:

Juergen, 
According to the irtf-rfcs-01a draft, we need to make sure 
we have consensus that this is an RG supported document.

from my quick checking of the nmrg mlist archives, it seems that
you proposed to make this an NMRG document in march 2006, when you
psted the abstract of your individual doument, and asked:

   I believe that this work is highly relevant for the NMRG
   and I hereby propose to turn this Internet-Draft which 
   is still an individual submission into an NMRG sponsored
   Internet-Draft. Please let me know what you think about
   this and especially if you have concerns about doing so.

For all I can tell, I am the only one who responded positive 
to this. I see no negative answers, but a lot of silence w.r.t.
this question. So it seems you have assumed that silence means 
consent (and give the formulation of your question, we can
indeed interpret silence as consent, or at least as no objection.

NMRG members:

In order to consider this as an NMRG document, it is not sufficient 
to "not object". We need at least a set of NMRG members/participants
to review the document and to comment. If you are happy with the
document and support its publication as an NMRG supported
Informational RFC, then I would like to hear that, prefereably
by posting such a statement to the NMRG list. Something aka

  I have read the document, it is in good shape and I support
  its publication as Informational RFC.

If you have comments/sugegstions/concerns, pls let us know and
post them to this NMRG mailing list.

Pls send your review comments/results BEFORE 17 Feb 2007.
Sooner is of course better. This allows for the authors to do
a new revision (if needed) before the ID cutoff.

I propose that we consider my own review comments (posted yesterday,
http://mail.ibr.cs.tu-bs.de/pipermail/nmrg/2007-January/001187.html)
as initial RG LC comments.

Bert

content-class: urn:content-classes:message
Date: Mon, 29 Jan 2007 19:25:47 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: <[email-masked]>
Subject: [nmrg] IETF OPS Area Meetings and mini-BOFs: Preliminary Agenda for the Prague IETF meeting - March 2007

I believe that the following announcement may be of interest to the
participants in NMRG. Note that the agenda is at this point preliminary
and subject to change and that the exact day and time of the OPS Area
meetings during the IETF meeting week may also change.

Dan

 
     Operations and Management (OPS) Area AGENDA

     Meeting : IETF68, Monday March 19, 2007 and Thursday March 22, 2007
     Location: Prague, Congress II, Monday March 19, 2007 15:20 to 17:20
and Grand Ballroom Thursday March 22, 2007 9:00 to 11:30
     Chairs  : David Kessens ([email-masked]) and Dan Romascanu
([email-masked]) 
     Jabber  : [email-masked]
     URL     : http://www.ops.ietf.org/
     Agenda  : version 0.1 (draft)
     ==============================================================

Meeting 1 - Monday March 19, 2007 15:20 to 17:20

1. Meeting Administrivia                 ADs        (total: 5 min)
        - Mailing list and URL
        - Minutes Scribe
        - Jabber Scribe
        - Blue Sheets

2. Mini-BOF A: COPS push mode policy configuration - Tom Taylor and Tina
Tsou (total: 30 min)

This mini-BOF is requested to gain comments on a technical proposal to
reduce the number of messages required when COPS is used to support push
mode policy configuration, where each request-state corresponds to an
user session. The essence of this proposal is to allow the PDP to
request the opening of a new request-state in the same message that
sends down policy to be stored against this request-state. At the other
end of the session life cycle, allow the PDP to delete a request-state. 
The proposed extensions to COPS could save two to three messages per
session, depending on the details that are finally agreed.

I-D:  to be submitted 

3. Mini-BOF B: - Manageability and Operational Guidelines - David
Harrington (total: 30 min)

We need to develop multi-protocol manageability and operational
guidelines for developers of protocols in the IETF. An internet-draft
has been published that summarizes previous work on this goal as a
starting point. This work would lead to either a WG, if enough people
want to be involved, or a design team to get the document finished. If
we can get enough feedback from operators and from protocol designers,
this could lead to a BCP; with limited input it would lead to an
Informational RFC instead. 

I-D: to be submitted

4. Mini-BOF C: Best Current Practices in Operations and Management -
David Harrington (total: 20 min)

This would be an effort to get operators together in a WG to develop a
set of best current practices, and a description of supporting
technologies, for manageability and operations, similar to the work done
in the OpSec WG. There will not be an internet-draft published prior to
ietf68. A WG should be created for operators to do this work.

5. Improved Efficiency of the OPS Area - proposal for the formation of a
OPS Area WG - ADs (total: 20 min)

6. Open Microphone - 15 min

Meeting 2 - Thursday March 22, 2007 - 9:00 to 11:30AM

1. Meeting Administrivia                 ADs        (total: 5 min)
        - Mailing list and URL
        - Minutes Scribe
        - Jabber Scribe
        - Blue Sheets

2. Mini-BOF D: NE/facilities/lines/protocols/services data modeling -
Michael Alexander (total: 40 min)

Network Management (NM) standards have traditionally been focused on
protocols, such as pertaining to configuration management and discovery.
Yet, all areas of Network Management, ranging from Element Management
(EM) to Network Management Systems (NMS) and Service Management Systems
have in common that they critically rely on underlying data structures
describing devices and services being managed. Network elements (NE)
frequently spawn ten thousands of managed objects, such as for a
multiservice switch...Traditionally, standardization of access-methods
(protocols), discovery, etc. have received most attention, while the
more heterogeneous data models and data modeling per saw comparatively
less. As there are real possibilities to standardize underlying and
universal commonalities in EMS/NMS/Service Management Systems on the one
side and managed attributes of NEs, protocols, transmission facilities,
lines and services on the other, the two distributions should be closer
aligned. Despite the complexity, it is possible to identify and define
frameworks and meta models of each constituent and their relation to
each other, that would substantially ease the management of present and
future devices, networks and services.

I-D: 

3. Mini-BOF E: MIB module editing in XML : Emile Stephan (total: 20 min)

Present the state of the art of editing MIB module in XML; Introduce a
basic template to edit SMI items in pure XML instead of in raw text;
Propose a simple XML template for SMI items; discuss the connections
with XML schema and network management protocols.

I-D: draft-stephan-ops-xml-mib-module-template-00 (under edition to be
submitted before mid February)

4. Mini-BOF F: Japanese Data Model Standards: Tomoyuki Iijima (total: 20
min)

 I'd like to show the data model examples we developed and was adopted
in the Japanese Standard body.

We developed data models of VLAN, Filter (Access Control List), and so
on and those data models were adopted by Japanese standardization body
called INTAP/OSMIC as standard data models. I'd like to make our data
model examples be adopted as an Informational RFC.

I-D: to be submitted

5. Mini-BOF G: OWL techniques for MIB to XML documents and schema
translation - Bob Natale (total: 40 min)

Specification of a standard methodology for translating SNMP MIBs into
outputs more directly usable by emerging SOA/web services management
tools, and specification of a standard methodology for validating those
translations.  Appropriate translation outputs are TBD by the WG, but
can be expected to include one or more of the following: XML, RDF, WSDL,
WS-Policy, WS-Event/Notification, Ontology.  The translation output(s)
should allow for extension of the respective managed element data model
in the native SOA/web services environment.  Because of the
extensibility objective, reverse translation back into SNMP MIB format
is a non-goal of the WG, but the possibility should be considered when
weighing alternatives.

I-D: to be submitted

6. Open microphone (total: 25 min)

 

_______________________________________________
AAA-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/aaa-doctors

Date: Mon, 29 Jan 2007 18:12:45 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [nmrg] Re: future of the snmp measurement document - shepherding volunteer needed
Reply-To: [email-masked]

On Fri, Jan 26, 2007 at 11:16:09PM +0100, Juergen Schoenwaelder wrote:

> [...] Since I am personally involved
> as the author/editor, the first thing we need is a shepherd who is
> willing to run the process, which starts with soliciting RG reviews by
> doing a RG last call. Any volunteers?

Our shepherd for <draft-irtf-nmrg-snmp-measure-01.txt> is Bert Wijnen
and he will now take over the procedure. Thanks to Bert for helping us
with this and also many thanks to the others who volunteered to help
move this document along.

/js

-- 
Juergen Schoenwaelder		 {International|Jacobs} University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

content-class: urn:content-classes:message
Date: Mon, 29 Jan 2007 16:07:06 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "OPS Area" <[email-masked]>, <[email-masked]>, <[email-masked]>,  <[email-masked]>, "MIB Doctors \(E-mail\)" <[email-masked]>, <[email-masked]>
Subject: [nmrg] OPS Area Meetings and mini-BOFs: Preliminary Agenda for Prague (corrected date) 

Please find below the preliminary agenda of the meetings in Prague, as
well as the list of mini-BOFs that David and myself have approved for
Prague. We were not able to grant to everybody the time that you
requested - please be prepared to adjust and manage your time
accordingly. Also note that there still may be changes in the dates and
time of the meting slots as result of IESG-Secretary changes. 

Please comment on the agenda items and mini-BOF proposals. 

We are looking forward to see you all in Prague. 

Dan

 
     Operations and Management (OPS) Area AGENDA

     Meeting : IETF68, Monday March 19, 2007 and Thursday March 22, 2007
     Location: Prague, Congress II, Monday March 19, 2007 15:20 to 17:20
and Grand Ballroom Thursday March 22, 2007 9:00 to 11:30
     Chairs  : David Kessens ([email-masked]) and Dan Romascanu
([email-masked]) 
     Jabber  : [email-masked]
     URL     : http://www.ops.ietf.org/
     Agenda  : version 0.1 (draft)
     ==============================================================

Meeting 1 - Monday March 19, 2007 15:20 to 17:20

1. Meeting Administrivia                 ADs        (total: 5 min)
        - Mailing list and URL
        - Minutes Scribe
        - Jabber Scribe
        - Blue Sheets

2. Mini-BOF A: COPS push mode policy configuration - Tom Taylor and Tina
Tsou (total: 30 min)

This mini-BOF is requested to gain comments on a technical proposal to
reduce the number of messages required when COPS is used to support push
mode policy configuration, where each request-state corresponds to an
user session. The essence of this proposal is to allow the PDP to
request the opening of a new request-state in the same message that
sends down policy to be stored against this request-state. At the other
end of the session life cycle, allow the PDP to delete a request-state. 
The proposed extensions to COPS could save two to three messages per
session, depending on the details that are finally agreed.

I-D:  to be submitted 

3. Mini-BOF B: - Manageability and Operational Guidelines - David
Harrington (total: 30 min)

We need to develop multi-protocol manageability and operational
guidelines for developers of protocols in the IETF. An internet-draft
has been published that summarizes previous work on this goal as a
starting point. This work would lead to either a WG, if enough people
want to be involved, or a design team to get the document finished. If
we can get enough feedback from operators and from protocol designers,
this could lead to a BCP; with limited input it would lead to an
Informational RFC instead. 

I-D: to be submitted

4. Mini-BOF C: Best Current Practices in Operations and Management -
David Harrington (total: 20 min)

This would be an effort to get operators together in a WG to develop a
set of best current practices, and a description of supporting
technologies, for manageability and operations, similar to the work done
in the OpSec WG. There will not be an internet-draft published prior to
ietf68. A WG should be created for operators to do this work.

5. Improved Efficiency of the OPS Area - proposal for the formation of a
OPS Area WG - ADs (total: 20 min)

6. Open Microphone - 15 min

Meeting 2 - Thursday March 22, 2007 - 9:00 to 11:30AM

1. Meeting Administrivia                 ADs        (total: 5 min)
        - Mailing list and URL
        - Minutes Scribe
        - Jabber Scribe
        - Blue Sheets

2. Mini-BOF D: NE/facilities/lines/protocols/services data modeling -
Michael Alexander (total: 40 min)

Network Management (NM) standards have traditionally been focused on
protocols, such as pertaining to configuration management and discovery.
Yet, all areas of Network Management, ranging from Element Management
(EM) to Network Management Systems (NMS) and Service Management Systems
have in common that they critically rely on underlying data structures
describing devices and services being managed. Network elements (NE)
frequently spawn ten thousands of managed objects, such as for a
multiservice switch...Traditionally, standardization of access-methods
(protocols), discovery, etc. have received most attention, while the
more heterogeneous data models and data modeling per saw comparatively
less. As there are real possibilities to standardize underlying and
universal commonalities in EMS/NMS/Service Management Systems on the one
side and managed attributes of NEs, protocols, transmission facilities,
lines and services on the other, the two distributions should be closer
aligned. Despite the complexity, it is possible to identify and define
frameworks and meta models of each constituent and their relation to
each other, that would substantially ease the management of present and
future devices, networks and services.

I-D: 

3. Mini-BOF E: MIB module editing in XML : Emile Stephan (total: 20 min)

Present the state of the art of editing MIB module in XML; Introduce a
basic template to edit SMI items in pure XML instead of in raw text;
Propose a simple XML template for SMI items; discuss the connections
with XML schema and network management protocols.

I-D: draft-stephan-ops-xml-mib-module-template-00 (under edition to be
submitted before mid February)

4. Mini-BOF F: Japanese Data Model Standards: Tomoyuki Iijima (total: 20
min)

 I'd like to show the data model examples we developed and was adopted
in the Japanese Standard body.

We developed data models of VLAN, Filter (Access Control List), and so
on and those data models were adopted by Japanese standardization body
called INTAP/OSMIC as standard data models. I'd like to make our data
model examples be adopted as an Informational RFC.

I-D: to be submitted

5. Mini-BOF G: OWL techniques for MIB to XML documents and schema
translation - Bob Natale (total: 40 min)

Specification of a standard methodology for translating SNMP MIBs into
outputs more directly usable by emerging SOA/web services management
tools, and specification of a standard methodology for validating those
translations.  Appropriate translation outputs are TBD by the WG, but
can be expected to include one or more of the following: XML, RDF, WSDL,
WS-Policy, WS-Event/Notification, Ontology.  The translation output(s)
should allow for extension of the respective managed element data model
in the native SOA/web services environment.  Because of the
extensibility objective, reverse translation back into SNMP MIB format
is a non-goal of the WG, but the possibility should be considered when
weighing alternatives.

I-D: to be submitted

6. Open microphone (total: 25 min)

 

content-class: urn:content-classes:message
Date: Mon, 29 Jan 2007 16:06:00 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "OPS Area" <[email-masked]>, <[email-masked]>, <[email-masked]>,  <[email-masked]>, "MIB Doctors \(E-mail\)" <[email-masked]>, <[email-masked]>
Subject: [nmrg] OPS Area Meetings and mini-BOFs: Preliminary Agenda for Prague

Please find below the preliminary agenda of the meetings in Prague, as
well as the list of mini-BOFs that David and myself have approved for
Prague. We were not able to grant to everybody the time that you
requested - please be prepared to adjust and manage your time
accordingly. Also note that there still may be changes in the dates and
time of the meting slots as result of IESG-Secretary changes. 

Please comment on the agenda items and mini-BOF proposals. 

We are looking forward to see you all in Prague. 

Dan

 
     Operations and Management (OPS) Area AGENDA

     Meeting : IETF68, Monday March 19, 2007 and Thursday March 22, 2007
     Location: Prague, Congress II, Monday March 19, 2007 15:20 to 17:20
and Grand Ballroom Thursday March 22, 2007 9:00 to 11:30
     Chairs  : David Kessens ([email-masked]) and Dan Romascanu
([email-masked]) 
     Jabber  : [email-masked]
     URL     : http://www.ops.ietf.org/
     Agenda  : version 0.1 (draft)
     ==============================================================

Meeting 1 - Monday March 19, 2007 15:20 to 17:20

1. Meeting Administrivia                 ADs        (total: 5 min)
        - Mailing list and URL
        - Minutes Scribe
        - Jabber Scribe
        - Blue Sheets

2. Mini-BOF A: COPS push mode policy configuration - Tom Taylor and Tina
Tsou (total: 30 min)

This mini-BOF is requested to gain comments on a technical proposal to
reduce the number of messages required when COPS is used to support push
mode policy configuration, where each request-state corresponds to an
user session. The essence of this proposal is to allow the PDP to
request the opening of a new request-state in the same message that
sends down policy to be stored against this request-state. At the other
end of the session life cycle, allow the PDP to delete a request-state. 
The proposed extensions to COPS could save two to three messages per
session, depending on the details that are finally agreed.

I-D:  to be submitted 

3. Mini-BOF B: - Manageability and Operational Guidelines - David
Harrington (total: 30 min)

We need to develop multi-protocol manageability and operational
guidelines for developers of protocols in the IETF. An internet-draft
has been published that summarizes previous work on this goal as a
starting point. This work would lead to either a WG, if enough people
want to be involved, or a design team to get the document finished. If
we can get enough feedback from operators and from protocol designers,
this could lead to a BCP; with limited input it would lead to an
Informational RFC instead. 

I-D: to be submitted

4. Mini-BOF C: Best Current Practices in Operations and Management -
David Harrington (total: 20 min)

This would be an effort to get operators together in a WG to develop a
set of best current practices, and a description of supporting
technologies, for manageability and operations, similar to the work done
in the OpSec WG. There will not be an internet-draft published prior to
ietf68. A WG should be created for operators to do this work.

5. Improved Efficiency of the OPS Area - proposal for the formation of a
OPS Area WG - ADs (total: 20 min)

6. Open Microphone - 15 min

Meeting 2 - Monday March 19, 2007 - 9:00 to 11:30AM

1. Meeting Administrivia                 ADs        (total: 5 min)
        - Mailing list and URL
        - Minutes Scribe
        - Jabber Scribe
        - Blue Sheets

2. Mini-BOF D: NE/facilities/lines/protocols/services data modeling -
Michael Alexander (total: 40 min)

Network Management (NM) standards have traditionally been focused on
protocols, such as pertaining to configuration management and discovery.
Yet, all areas of Network Management, ranging from Element Management
(EM) to Network Management Systems (NMS) and Service Management Systems
have in common that they critically rely on underlying data structures
describing devices and services being managed. Network elements (NE)
frequently spawn ten thousands of managed objects, such as for a
multiservice switch...Traditionally, standardization of access-methods
(protocols), discovery, etc. have received most attention, while the
more heterogeneous data models and data modeling per saw comparatively
less. As there are real possibilities to standardize underlying and
universal commonalities in EMS/NMS/Service Management Systems on the one
side and managed attributes of NEs, protocols, transmission facilities,
lines and services on the other, the two distributions should be closer
aligned. Despite the complexity, it is possible to identify and define
frameworks and meta models of each constituent and their relation to
each other, that would substantially ease the management of present and
future devices, networks and services.

I-D: 

3. Mini-BOF E: MIB module editing in XML : Emile Stephan (total: 20 min)

Present the state of the art of editing MIB module in XML; Introduce a
basic template to edit SMI items in pure XML instead of in raw text;
Propose a simple XML template for SMI items; discuss the connections
with XML schema and network management protocols.

I-D: draft-stephan-ops-xml-mib-module-template-00 (under edition to be
submitted before mid February)

4. Mini-BOF F: Japanese Data Model Standards: Tomoyuki Iijima (total: 20
min)

 I'd like to show the data model examples we developed and was adopted
in the Japanese Standard body.

We developed data models of VLAN, Filter (Access Control List), and so
on and those data models were adopted by Japanese standardization body
called INTAP/OSMIC as standard data models. I'd like to make our data
model examples be adopted as an Informational RFC.

I-D: to be submitted

5. Mini-BOF G: OWL techniques for MIB to XML documents and schema
translation - Bob Natale (total: 40 min)

Specification of a standard methodology for translating SNMP MIBs into
outputs more directly usable by emerging SOA/web services management
tools, and specification of a standard methodology for validating those
translations.  Appropriate translation outputs are TBD by the WG, but
can be expected to include one or more of the following: XML, RDF, WSDL,
WS-Policy, WS-Event/Notification, Ontology.  The translation output(s)
should allow for extension of the respective managed element data model
in the native SOA/web services environment.  Because of the
extensibility objective, reverse translation back into SNMP MIB format
is a non-goal of the WG, but the possibility should be considered when
weighing alternatives.

I-D: to be submitted

6. Open microphone (total: 25 min)

 

Content-class: urn:content-classes:message
Subject: RE: [nmrg] future of the snmp measurement document - shepherdingvolunteer needed
Date: Mon, 29 Jan 2007 11:04:45 +0100
From: "Wijnen, Bert \(Bert\)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

I reviewed the document and have the following comments,
just NITS and TYPOs

- abstract
  In order to prevent discussion/questioning about it, you might want
  to de-emphasize the "configuration" usage of SNMP. How about changing

   The Simple Network Management Protocol (SNMP) is widely deployed to
   monitor, control and configure network elements.  Even though the

  wo something aka

   The Simple Network Management Protocol (SNMP) is widely deployed to
   monitor, control and (sometimes also) configure network elements.  
   Even though the

- page 6
   It is recommended to capture at least a full week of data.  Operators
   are encouraged to capture traces over even longer periods of time.
   Tools such as tcpslice [1] or pcapmerge [3] can be used to merge or
   split pcap trace files as needed.

  I would change "to merge or split" into "to split or merge" so that
  you have the same sequence as the "tcpslice pr pcapmerge".

- page 6
   For each captured trace, some meta data should be recorded and made
   available.  The meta data should include information such as where
   the traces was collected, when it was collected, contact information,

  s/the traces/the trace/  ??

   the size of the trace, any known special events during the data
   collection period and so on.  It is also extremely useful to provide
   a unique identification.  There are special online services such as
   DatCat [4] where meta data can be store and which provide unique
   identifiers.

  s/can be store/can be stored/

- section 4.2
   The comma separated values (CSV) format has been design to capture

  s/has been design/has been designed/ 

  2.   Source IP address in dotted quad notation (IPv4), for example
       "127.0.0.1", or compact hexadecimal notation (IPv6), for example
       "::1".

  Would it not be better to use the reserved addresses for example as
  per RFC3330 and RFC3849!!??

   8.   SNMP protocol operation indicated by one of the keywords get-
        request, get-next-request, get-bulk-request, set-request, trap,
        trap2, inform, response, report.

  I onder why sme operations are represented by the full name, while
other
  are represented by a name that is not complete.
  Why not use the pdu-names as per RFC3416L
   PDUs ::= CHOICE {
        get-request      GetRequest-PDU,
        get-next-request GetNextRequest-PDU,
        get-bulk-request GetBulkRequest-PDU,
        response         Response-PDU,
        set-request      SetRequest-PDU,
        inform-request   InformRequest-PDU,
        snmpV2-trap      SNMPv2-Trap-PDU,
        report           Report-PDU }

  So change inform to inform-request and trap2 to snmpV2-trap 

   13.  For each varbind in the varbind list, three output elements are
        generated

        1.  Object names given as object identifiers in dotted decimal

  s/Object names given as object identifiers/Object name goven as object
identifier/
  That is make it singular instead of plural?  After all you speak "for
each object",
  and it seems to me that for one object you have only one name/oid.
  Same for sub-points 2 and 3.

        2.  Object base type name or exception names, that is one of the
            following: null, integer32, unsigned32, unsigned64,
            ipaddress, octet-string, object-identifier, no-such-object,
            no-such-instance, and end-of-mib-view.

  Is the 'unsigned64' meant to be used for Counter64? 

- security considerations section:
    Anonymization techniques can be applied to keep more information in
    traces which could reveal sensitive information.  When using 

  s/could reveal/could otherwise reveal/ ??

- general
  You use "bytes" instead of "octets". 
  I know some IETF people prefer "octets". 

- references.
  not sure I understand why RFC3418 is normative while 2863 is
informative.
  same for some other RFCs. But I can live with it.

Bert

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen 
> Schoenwaelder
> Sent: vrijdag 26 januari 2007 23:16
> To: [email-masked]
> Subject: [nmrg] future of the snmp measurement document - 
> shepherdingvolunteer needed
> 
> Hi,
> 
> a few days ago, I visited Aiko Pras and this led (among other 
> things) to the updated version of <of 
> <draft-irtf-nmrg-snmp-measure>. We moved the format 
> specifications into the body of the document and revised the 
> XML format to match existing implementations, to deal with 
> Opaque varbind values, and to have a proper namespace. We 
> also dropped the appendix about meta-data and instead provide 
> a reference to the www.datcat.org CAIDA project. Aiko and I 
> believe that the document is essentially done and useful 
> since it documents the trace exchange formats that are being 
> using for some time now successfully.
> 
> So we would like to move this document forward. To do this, 
> it is important to know that the IRTF has raised the bar 
> significantly to publish RFCs. There is a working document 
> (currently expired) which defines a procedure which 
> essentially consists of the following steps:
> 
> a) There needs to be some RG last call and the level of support and
>    number of reviewers should be documented.
> 
> b) A document shepherd must be selected to run the process. This
>    should be a person not involved as an author or main technical
>    contributor.
> 
> c) Once RG support has been established, the sponsoring RG chair
>    brings the document to the IRSG for publication.
> 
> d) A (firm) eight-week IRSG review period follows after which 
> a poll is
>    taken.  Reviews should be similar to that for a conference paper.
> 
> e) Reviews should be written to be public.  In particular, they should
>    be sent to the submitted RG mailing list.
> 
> f) Once the IRSG supports the document, the document goes to the RFC
>    editor who sends it to the IESG for review.
> 
> g) Once the IESG review is complete, the document goes into the
>    publication queue.
> 
> As you can see, the process is non-trivial. Note that I do 
> not want to stimulate a discussion of the value of all this 
> here - I am just interested to move a document forward. Since 
> I am personally involved as the author/editor, the first 
> thing we need is a shepherd who is willing to run the 
> process, which starts with soliciting RG reviews by doing a 
> RG last call. Any volunteers?
> 
> /js
> 
> [I am attaching the latest IRTF RFC publication process draft 
> I have seen as some of your might be interested what the 
> details of this procedure are.]
> 
> -- 
> Juergen Schoenwaelder		 {International|Jacobs} 
> University Bremen
> <http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 
> 28725 Bremen, Germany
> 

Date: Fri, 26 Jan 2007 23:16:09 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [nmrg] future of the snmp measurement document - shepherding volunteer needed
Reply-To: [email-masked]

--tKW2IUtsqtDRztdT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,

a few days ago, I visited Aiko Pras and this led (among other things)
to the updated version of <of <draft-irtf-nmrg-snmp-measure>. We moved
the format specifications into the body of the document and revised
the XML format to match existing implementations, to deal with Opaque
varbind values, and to have a proper namespace. We also dropped the
appendix about meta-data and instead provide a reference to the
www.datcat.org CAIDA project. Aiko and I believe that the document is
essentially done and useful since it documents the trace exchange
formats that are being using for some time now successfully.

So we would like to move this document forward. To do this, it is
important to know that the IRTF has raised the bar significantly to
publish RFCs. There is a working document (currently expired) which
defines a procedure which essentially consists of the following steps:

a) There needs to be some RG last call and the level of support and
   number of reviewers should be documented.

b) A document shepherd must be selected to run the process. This
   should be a person not involved as an author or main technical
   contributor.

c) Once RG support has been established, the sponsoring RG chair
   brings the document to the IRSG for publication.

d) A (firm) eight-week IRSG review period follows after which a poll is
   taken.  Reviews should be similar to that for a conference paper.

e) Reviews should be written to be public.  In particular, they should
   be sent to the submitted RG mailing list.

f) Once the IRSG supports the document, the document goes to the RFC
   editor who sends it to the IESG for review.

g) Once the IESG review is complete, the document goes into the
   publication queue.

As you can see, the process is non-trivial. Note that I do not want to
stimulate a discussion of the value of all this here - I am just
interested to move a document forward. Since I am personally involved
as the author/editor, the first thing we need is a shepherd who is
willing to run the process, which starts with soliciting RG reviews by
doing a RG last call. Any volunteers?

/js

[I am attaching the latest IRTF RFC publication process draft I have
seen as some of your might be interested what the details of this
procedure are.]

-- 
Juergen Schoenwaelder		 {International|Jacobs} University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

--tKW2IUtsqtDRztdT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="draft-irtf-rfcs-01a.txt"

Network Working Group                                            A. Falk
Internet-Draft                                                IRTF Chair
Intended status: Informational                          January 10, 2007
Expires: July 14, 2007

                        IRTF Research Group RFCs
                        draft-irtf-rfcs-01a.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 14, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2007).

Falk                      Expires July 14, 2007                 [Page 1]

Internet-Draft                  IRTF RFCs                   January 2007

Abstract

   This document describes a process for research groups in the Internet
   Research Task Force to publish RFCs.

Table of Contents

   1.  Changes from Last Version  . . . . . . . . . . . . . . . . . .  3

   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

   3.  Document Shepherds . . . . . . . . . . . . . . . . . . . . . .  5

   4.  Document Tracker . . . . . . . . . . . . . . . . . . . . . . .  6

   5.  Process Description  . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  Research Group Preparation . . . . . . . . . . . . . . . .  7
     5.2.  IRSG Review  . . . . . . . . . . . . . . . . . . . . . . .  7
       5.2.1.  Initial steps  . . . . . . . . . . . . . . . . . . . .  8
       5.2.2.  Reviews  . . . . . . . . . . . . . . . . . . . . . . .  8
       5.2.3.  Poll . . . . . . . . . . . . . . . . . . . . . . . . .  8
       5.2.4.  Followup . . . . . . . . . . . . . . . . . . . . . . .  9
     5.3.  IESG Review  . . . . . . . . . . . . . . . . . . . . . . .  9
     5.4.  RFC Editor Handling  . . . . . . . . . . . . . . . . . . . 10

   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11

   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12

   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13

   9.  Informative References . . . . . . . . . . . . . . . . . . . . 14

   Appendix A.  IESG Notes  . . . . . . . . . . . . . . . . . . . . . 15

   Appendix B.  State Diagram . . . . . . . . . . . . . . . . . . . . 16

   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18

Falk                      Expires July 14, 2007                 [Page 2]

Internet-Draft                  IRTF RFCs                   January 2007

1.  Changes from Last Version

   Updates from draft-irtf-rfcs-00.txt:

   o  Moved IESG review to occur before RFC Editor submission

   o  Expansion of shepherd duties

   o  Added section on tracker

   o  Text on thorough reviews

   o  Removed a decreasingly-relevant section on A-D sponsored documents
      as a model for the IRTF docs

   o  Linkage added to draft-iab-rfc-editor

   o  Added state diagram

   o  Reformatting

Falk                      Expires July 14, 2007                 [Page 3]

Internet-Draft                  IRTF RFCs                   January 2007

2.  Introduction

   This document specifies a review and publication process for the
   Internet Research Task Force (IRTF) [RFC2014].  Most documents
   undergoing this process will come from IRTF Research Groups and the
   objective is that they are published as Informational or Experimental
   RFCs by the RFC Editor.

   Currently, the IRTF Research Group drafts are treated like
   independent submissions by the RFC Editor.  Roughly, the process
   consists of the following steps:

   o  The document author submits an Internet Draft to the RFC Editor as
      an independent submission.

   o  The RFC Editor performs independent submission review (ISR) for
      editorial acceptability and may request the authors revise the
      document before publishing.

   o  The IESG performs a review (to avoid standards process end-
      arounds) and inserts a disclaimer (see RFC3932[RFC3932]).

   o  Independent submissions are delayed by lower priority treatment as
      they move through the RFC Editor's queue.

   This document defines the review and publication process for an IRTF
   Document Stream.  (Document streams are described in Section 5 of
   [I-D.iab-rfc-editor].)  The process may be summarized as:

   o  The Research Group reviews the document and agrees it should be
      published (but may not agree on the technical content).

   o  The Internet Research Steering Group (IRSG) conducts a thorough
      technical and editorial review

   o  The Internet Engineering Steering Group (IESG) reviews the
      document to assure there are no conflicts the standardization
      activities

   o  The document is submitted to the RFC Editor for publication

   This draft has been updated based on about nine months of experience
   and processing of four documents.  The IRTF plans to continue the
   trial of this process for several more documents and may again revise
   this process.

Falk                      Expires July 14, 2007                 [Page 4]

Internet-Draft                  IRTF RFCs                   January 2007

3.  Document Shepherds

   Documents should have a shepherd.  This is a relatively new concept
   initially developed in the IETF to ensure that issues raised in the
   review and publication process are responded to in a timely manner.
   The IETF shepherding process is described in
   [I-D.ietf-proto-wgchair-doc-shepherding] and has been adapted to the
   IRTF publication process.

   Shepherd responsibilities are noted for each phase of the publication
   process in subsequent sections.  Some general things to note:

   o  Shepherds should normally be an RG chair since they know the IRSG
      members, are familiar with the technical content, and know the
      document history.  However, the RG chair should not be a shepherd
      if they are an author of the document.

   o  Shepherds are responsible to track and facilitate document
      progression through RFC publication.  This includes finding IRSG
      reviewers, facilitating resolution of review comments, entering
      information into the tracker(s), keeping track of review
      schedules, and prodding token holders to act expeditiously.

   o  Shepherds should summarize substantive review comments and their
      resolution.

   o  Shepherds should be copied on all correspondence regarding a
      document.  For example, if the IESG has questions during their
      review, the shepherd should be included in the exchange.  This can
      be helpful should the RG take a position different than the author
      on suggested changes.

Falk                      Expires July 14, 2007                 [Page 5]

Internet-Draft                  IRTF RFCs                   January 2007

4.  Document Tracker

   As of this writing the IRSG is using its own public document tracker
   [TRAC].  This tracker is intended to collect the shepherd and
   reviewer identities, reviewer comments, and state transitions as the
   document progresses.  It is the responsibility of the shepherd to
   maintain the tracker.

   It is expected that, in the future, the IRTF will use the IETF's I-D
   Tracker [IDTRAC] to collect and manage this information.
   Modifications are planned for the I-D Tracker to accommodate the IRTF
   publication process.  When the I-D Tracker can support the process
   described below, the IRSG tracker will no longer be used.

   Information to be captured in the tracker:

   o  URL to the draft (updated if the draft is revised)

   o  Document shepherd

   o  Type of RFC: Informational or Experimental

   o  Desired IESG Note text

   o  Reviewers (volunteers for the thorough review)

   o  Scheduled date for IRSG poll

   o  IRSG poll results

   o  Pointers to RG reviews

   o  IRSG Review text (or pointers)

   o  IRSG review resolutions (or pointers)

Falk                      Expires July 14, 2007                 [Page 6]

Internet-Draft                  IRTF RFCs                   January 2007

5.  Process Description

   The following sections describe the steps for IRTF-track document
   review and publication process.  There are fundamentally two steps:
   IRSG review and IESG review.  The document shepherd is responsible
   for making sure reviews are responded to and documented and that the
   process moves along.

   The RFC Editor and the IAB have reviewed the procedure below and
   fully support it. [[anchor4: Need to confirm that all the parties --
   IRSG, IAB, IESG, and RFC Editor -- still support the modifications.
   This text remains as a placeholder for a statement of support by the
   relevant bodies.]]

5.1.  Research Group Preparation

   An RG may choose to publish RFCs as independent submissions directly
   to the RFC Editor or may decide to publish a document using the IRTF
   publication track.  If the latter is chosen, the RG must review the
   document for editorial and technical quality.

   The document should contain a statement in the abstract identifying
   it as the product of the RG and a paragraph in the first section
   describing the level of support for publication (e.g., "this document
   represents the consensus of the FOOBAR RG", "the views in this
   document were considered controversial by the FOOBAR RG but the RG
   reached a consensus that the document should still be published") and
   the breadth of review for the document.  For example, was this
   document read by all the active contributors, only three people, or
   folks who are not "in" the RG but are expert in the area?  It should
   also be very clear throughout the document that it is not an IETF
   product and is not a standard.  If an experimental protocol is
   described appropriate usage caveats need to be present.  If the
   protocol has been considered in an IETF working group in the past,
   this should be noted in the introduction as well.

   The shepherd should be selected at this time as discussed in
   Section 3.  Now the document may be submitted to the IRSG for review.

5.2.  IRSG Review

   IRSG review includes at least two thorough technical reviews
   concluding with a poll of the IRSG on whether the document should be
   published.  It is the IRSG's responsibility to ensure high technical
   and editorial quality.

Falk                      Expires July 14, 2007                 [Page 7]

Internet-Draft                  IRTF RFCs                   January 2007

5.2.1.  Initial steps

   The RG chair brings the document to the IRSG for publication by
   sending an email message to the IRSG requesting review and including
   a pointer to the draft.  The expectation is that the RG chair has
   already reviewed the draft thoroughly and considers it of publishable
   quality editorially and technically.  The RG should be copied on the
   mail message requesting IRSG review.  The RG chair should identify
   the document shepherd at that time (if it isn't them).

   The shepherd should do several things at this time:

   1.  Create an entry in the tracker for the document, entering all of
       the items listed in Section 4 that are available and setting the
       document state to "IRSG Review".

   2.  Send an email to the IRSG mailing list with pointers to the new
       tracker entries (this may be automated)

   3.  Find two members of the IRSG to perform a thorough review of the
       document.  (This is to ensure at least two thorough reviews are
       performed.)

   4.  Schedule the poll eight weeks later.

5.2.2.  Reviews

   The purpose of the IRSG review is to ensure consistent editorial and
   technical quality for IRTF publications.  Reviews should be similar
   to that for a conference paper.  Reviews should be written to be
   public.  Review comments should be sent to the IRSG and RG mailing
   lists and entered into the tracker.

   All IRSG review comments must be addressed.  However, the RG need not
   accept every comment.  It is the responsibility of the shepherd to
   understand the comments and ensure that the RG considers them
   including adequate dialog between the reviewer and the author and/or
   RG.

   Reviews and their resolution should be entered into the tracker by
   the document shepherd.

5.2.3.  Poll

   A (firm) eight-week IRSG review period follows after which a poll is
   taken.  Votes can be:

Falk                      Expires July 14, 2007                 [Page 8]

Internet-Draft                  IRTF RFCs                   January 2007

   o  'ready to publish' -- requires a thorough read and reasonably
      detailed review

   o  'not ready to publish' -- requires a thorough read, reasonably
      detailed review, and actionable comments.

   o  'no objection' -- I don't object if this document goes forward;
      I've read the document (perhaps quickly); I have some small
      comments which are not show stoppers; I don't have great expertise
      in the area.

   o  'request more time to review' -- a commitment to provide a
      thorough review in a specified period of time.

   At least two other IRSG members (besides the one sponsoring the
   document) need to vote 'ready to publish' for the document to move
   forward.  Any vote of 'not ready to publish' will hold a document's
   progress until the comments are addressed.  The IRTF chair may choose
   to override 'not ready to publish' holds that, in the opinion of the
   chair, have received an adequate response.  The IRTF chair will
   record the poll results in the tracker.

5.2.4.  Followup

   When an ID has been published reflecting the resolution of all
   comments, the RG chair or the shepherd sends an email to the IRTF
   Chair (cc'ing the IRSG and the RG) summarizing the IRSG review
   comments and their resolution and including pointers to the tracker
   entries, detailed reviews, and discussion.

   IRSG Review is concluded at this time.  The tracker should be updated
   to reflect moving to new state, IESG Review.

5.3.  IESG Review

   The IRTF Chair will forward the summary email to the IESG [[anchor12:
   sent to the secretariat?]]requesting the document be reviewed using
   the criteria from RFC3932.  RFC3932 describes a review process to
   ensure non-IETF documents do not conflict with active or immanent
   IETF work.  The request email to the IESG should identify the
   document authors and shepherd.  The document shepherd should provide
   the IESG reviewer with the desired IESG note (and rationale) from the
   list in Appendix A.

   The IESG member leading the review should make it clear to the rest
   of the IESG that IRTF documents on the agenda are to be reviewed
   according to RFC 3932 procedures.  At the time of this writing, a
   recommended procedure is to include text in the Note field of the

Falk                      Expires July 14, 2007                 [Page 9]

Internet-Draft                  IRTF RFCs                   January 2007

   Tracker to this effect.  In the future, other methods of identifying
   these documents may arise, such as IRTF documents being grouped
   separately on the agenda or being marked as such explicitly in the
   tracker. [[anchor13: Mark Townsley requested this text.  Seems a
   little too mechanical for me but it can be removed later.]]

   The document shepherd is responsible for collecting IESG comments and
   responding to questions.  This may include checking the IETF I-D
   tracker for IESG comments and forward them to the research group.  A
   revised draft may be required to respond to IESG comments.

   There are several reasons why the IESG may question or object to a
   document being published which are described in RFC3932 section 4.
   However, the decision to publish a document ultimately rests with the
   RFC Editor, under the direction of the IAB (as described in
   [I-D.iab-rfc-editor].

   The shepherd now sends a request for publication including pointers
   to the reviews in the tracker to the IRTF Chair, cc'ing the RG and
   IRSG.  The tracker should be updated at this time to reflect the new
   state, "Doc approved, awaiting submission to RFC Editor."

5.4.  RFC Editor Handling

   The IRTF Chair will forward the request for publication email to the
   RFC Editor, placing the document in the RFC Editor's publication
   queue.  The tracker should be updated to reflect the state of "RFC
   Editor publication queue."

   The document enters the RFC Editor queue at the same priority as
   IETF- and IAB-track (non-standards) documents.  The document shepherd
   is responsible for ensuring that the document authors are responsive
   to the RFC Editor and that the RFC editing process goes smoothly.
   The AUTH48 review stage of RFC publication is an area where the
   shepherd's may be of particular assistance, ensuring a) authors
   respond promptly in reviewing about-to-be-published documents and b)
   authors don't inject changes into the document at the last minute
   which would not be supported by the research group.

Falk                      Expires July 14, 2007                [Page 10]

Internet-Draft                  IRTF RFCs                   January 2007

6.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

Falk                      Expires July 14, 2007                [Page 11]

Internet-Draft                  IRTF RFCs                   January 2007

7.  Security Considerations

   There are no security considerations in this document.

Falk                      Expires July 14, 2007                [Page 12]

Internet-Draft                  IRTF RFCs                   January 2007

8.  Acknowledgements

   Many thanks for Mark Allman, Bob Braden, Brian Carpenter, Leslie
   Daigle, Stephen Farrell, Tom Henderson, Rajeev Koodli, Allison
   Mankin, Karen Sollins, and Mark Townsley who contributed to
   preparation of this process.

Falk                      Expires July 14, 2007                [Page 13]

Internet-Draft                  IRTF RFCs                   January 2007

9.  Informative References

   [I-D.iab-rfc-editor]
              Daigle, L., "The RFC Editor", draft-iab-rfc-editor-00
              (work in progress), May 2006.

   [I-D.ietf-proto-wgchair-doc-shepherding]
              Levkowetz, H. and D. Meyer, "Protocol Pilot: Workgroup
              Chair Followup of AD Evaluation Comments",
              draft-ietf-proto-wgchair-doc-shepherding-00 (work in
              progress), July 2004.

   [IDTRAC]   "IETF I-D Tracker", 2006,
              <https://datatracker.ietf.org/public/pidtracker.cgi>.

   [RFC2014]  Weinrib, A. and J. Postel, "IRTF Research Group Guidelines
              and Procedures", BCP 8, RFC 2014, October 1996.

   [RFC3932]  Alvestrand, H., "The IESG and RFC Editor Documents:
              Procedures", BCP 92, RFC 3932, October 2004.

   [TRAC]     "IRTF Document Tracker", 2006,
              <http://www1.tools.ietf.org/group/irtf/trac/report/1>.

Falk                      Expires July 14, 2007                [Page 14]

Internet-Draft                  IRTF RFCs                   January 2007

Appendix A.  IESG Notes

   After the review an IESG note is typically added.  Rather than the
   disclaimers found in RFC3932, the IESG will instruct the authors to
   add the following disclaimer:
        "This RFC is a product of the Internet Research Task Force and
         is not a candidate for any level of Internet Standard.  The
         IRTF publishes the results of Internet-related research and
         development activities.  These results might not be suitable
         for deployment."

   For documents that specify a protocol or other technology and that
   have been considered in the IETF at one time:

         "This RFC is a product of the Internet Research Task Force.
         The content of this RFC was at one time considered by the
         IETF, and therefore it may resemble a current IETF work in
         progress or a published IETF work.  However, this is not an
         IETF document is not a candidate for any level of Internet
         Standard.  The IRTF publishes the results of Internet-related
         research and development activities.  These results might not
         be suitable for deployment."

Falk                      Expires July 14, 2007                [Page 15]

Internet-Draft                  IRTF RFCs                   January 2007

Appendix B.  State Diagram

   The diagram below shows the states and transition events for IRTF RFC
   processing.

  +---------------+     +------------+ review cmnts  +---------------+
  | request to    |     |            |-------------->| IRSG Review:  |
  | publish from  |---->|IRSG Review |               | revised ID    |
  | RG chair      |     |            |<--------------| needed        |
  +---------------+     +------------+               +---------------+
                              |
                              |IRSG
                              |Approval
                              |
                              V
                      +--------------+ review cmnts  +---------------+
                      | IESG         |-------------->|IESG review:   |
                      | 'end-around' |               |revised ID     |
                      | review       |<--------------|needed         |
                      +-------+------+               +---------------+
                              |
                              |shepherd sends
                              |summary email
                              |
                              V
                     +---------------+
                     | Doc approved, |
                     | awaiting      |
                     | submission to |
                     | RFC Editor    |
                     |               |
                     +---------------+
                              |
                              |IRTF chair
                              |sends msg
                              |to RFC Ed
                              |
                              V
                     +---------------+               +-----------------+
                     | RFC Editor    |               |                 |
                     | publication   |-------------->|  RFC published  |
                     | queue         |               |                 |
                     +---------------+               +-----------------+

Falk                      Expires July 14, 2007                [Page 16]

Internet-Draft                  IRTF RFCs                   January 2007

Author's Address

   Aaron Falk
   USC Information Sciences Institute
   4676 Admiralty Way, Suite 1001
   Marina Del Rey, California  90292
   USA

   Phone: +1-310-448-9327
   Email: [email-masked]

Falk                      Expires July 14, 2007                [Page 17]

Internet-Draft                  IRTF RFCs                   January 2007

Full Copyright Statement

   Copyright (C) The Internet Society (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Falk                      Expires July 14, 2007                [Page 18]


--tKW2IUtsqtDRztdT--

Date: Fri, 26 Jan 2007 22:57:00 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [nmrg] [[email-masked]: I-D ACTION:draft-irtf-nmrg-snmp-measure-01.txt]
Reply-To: [email-masked]

Hi,

the updated version of the SNMP measurement document has been posted
by the IETF secretariat (see below). I will say more about the
potential future of this document in a subsequent message.

/js

----- Forwarded message from [email-masked] -----

To: [email-masked]
Cc: 
From: [email-masked]
Date: Fri, 26 Jan 2007 15:50:02 -0500
Subject: I-D ACTION:draft-irtf-nmrg-snmp-measure-01.txt 
Precedence: list
Reply-To: [email-masked]
Errors-To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: SNMP Traffic Measurements and Trace Exchange Formats
	Author(s)	: J. Schoenwaelder
	Filename	: draft-irtf-nmrg-snmp-measure-01.txt
	Pages		: 23
	Date		: 2007-1-26
	
The Simple Network Management Protocol (SNMP) is widely deployed to
   monitor, control and configure network elements.  Even though the
   SNMP technology is well documented, it remains relatively unclear how
   SNMP is used in practice and what typical SNMP usage patterns are.
   This document proposes to carry out large scale SNMP traffic
   measurements in order to develop a better understanding how SNMP is
   used in real world production networks.  It describes the motivation,
   the measurement approach, and the tools and data formats needed to
   carry out such a study.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-irtf-nmrg-snmp-measure-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-irtf-nmrg-snmp-measure-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

----- End forwarded message -----

Date: Thu, 25 Jan 2007 10:36:20 +0100
From: "J.P. Martin-Flatin" <[email-masked]>
To: IRTF Network Management Research Group <[email-masked]>
Subject: [nmrg] ITU-T recommendations available for free
Reply-To: "J.P. Martin-Flatin" <[email-masked]>

-------- Original Message --------
Date: Thu, 18 Jan 2007 17:36:54 +0000
From: David Chadwick <[email-masked]>
Organization: University of Kent

Dear All

ITU just announced

      From the beginning of 2007, ITU-T Recommendations will be available
      without charge for a trial period.

      With only a small number of exceptions all in-force Recommendations
      will be available in PDF form via a simple mouse click.

      There is a general belief that the strategic importance of making
      on-line access to ITU-T Recommendations free outweighs the costs (in
      terms of lost revenue) to ITU. This is seen as a way to increase the
      transparency of ITU-T work and encourage wider participation in
      ITU-T activities. It is also believed that this policy will help
      increase developing countries' awareness of pertinent issues and
      help to promote the participation of academia in ITU-T work.

Links to all the recommendations start here

     http://www.itu.int/ITU-T/publications/recs.html

Links to the X Recommendations start here

     http://www.itu.int/rec/T-REC-X/e

Enjoy

David
--
   ogsa-wg mailing list
   [email-masked]
   http://www.ogf.org/mailman/listinfo/ogsa-wg

Date: Thu, 25 Jan 2007 08:36:52 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [nmrg] [[email-masked]: [IRSG] call for a plenary research talk at the Prague IETF]
Reply-To: [email-masked]

Hi,

below about an opportunity to give a really good talk in front of
a large technical audience. Like Steve Jobs... ;-)

/js

----- Forwarded message from Aaron Falk <[email-masked]> -----

To: Internet Steering Group <[email-masked]>
From: Aaron Falk <[email-masked]>
Date: Wed, 24 Jan 2007 16:27:48 -0800
Subject: [IRSG] call for a plenary research talk at the Prague IETF
Precedence: list
Errors-To: [email-masked]

As I mentioned in my last message, we are trying something new for  
the IAB plenary at the Prague IETF.  Rather than a long talk by an  
RG, we are going with a short talk about the highlights of a group  
and a second research talk which may or may not be related to the  
IRTF.  So, this is a call for ideas on a research talk at the IETF.   
I'm attaching a message below from an IAB member outlining some of  
the, er, quality control requirements for such a talk.  Ideally, we  
want an engaging speaker with interesting stuff that's relevant to  
the IETF.  If you have suggestions (and have reason to believe they  
would be available to give a talk in Prague in March) please send  
suggestions.  The IAB (with our input) will make the decision to  
extend the invitation.

--aaron

Begin forwarded message:

> From: Eric Rescorla <[email-masked]>
> Date: January 11, 2007 2:43:31 PM PST
> To: [email-masked]
> Subject: Criteria for plenary talks
>
> On yesterday's call I volunteered to write up what I thought
> was a reasonable barrier for a plenary talk. My overriding
> principle is that we don't *need* to have any given talk.
> If people are just sitting through it wishing they were in
> the bar, then we should have them in the bar. So, with that
> in mind, a talk should be:
>
> - On a topic of general interest to a reasonably large fraction
>   of the IETF population.
> - Deliver new information at a level they can process. E.g.,
>   security is a topic of general interest but it doesn't make
>   sense to have Dan Boneh talk about Bilinear Maps.
> - Be reasonably well delivered and hopefully entertaining.
>
> The first point we can evaluate from the talk proposal. The
> second two points require us to either have a lot of trust
> in the person speaking (e.g., I would let Steve Jobs speak
> because I know he's entertaining...) or that we see the
> slides in advance. Optimally, we'd see the slides and have
> someone report that this person was a good speaker.
>
> Note that I'm not suggesting we hack the slides into being good.
> Rather, we solicit proposals for plenary talks and if people's
> slides look bad we don't let them talk (again, with the exception
> of the people we really know will be good...)
>
> -Ekr
>
_______________________________________________
IRSG mailing list
[email-masked]
http://mailman.isi.edu/mailman/listinfo/irsg

----- End forwarded message -----

-- 
Juergen Schoenwaelder		 {International|Jacobs} University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

content-class: urn:content-classes:message
Date: Wed, 24 Jan 2007 02:05:33 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "OPS Area" <[email-masked]>, <[email-masked]>, <[email-masked]>,  "MIB Doctors \(E-mail\)" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: [nmrg] LAST REMINDER: OPS Area mini-BOFs in Prague

To all contributors who intend to present in Prague - If you did not do
it yet, please confirm the submissions for a mini-BOF slot at the OPS
Area meetings in Prague and send us the following information: . 

- short technical scope description (not much more than one paragraph)
- goals of the proposal, where this can lead: e.g. new protocol or
extension of an existing protocol, standard, BCP or Informational RFC,
formation of a WG or individual submission, other
- estimation of time you will need in Prague including Q&A
- whether there is an Internet-Draft or you intent to submit one before
the Prague IETF

Please send us this information until 1/25 the latest. David and me will
meet on 1/26 and will communicate the finalized agenda shortly after. 

Thanks and Regards,

Dan

 

Date: Wed, 17 Jan 2007 15:37:22 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [nmrg] Re: 22nd NMRG meeting in Prague in March 2007
Reply-To: [email-masked]

On Tue, Jan 09, 2007 at 10:42:24AM +0100, Juergen Schoenwaelder wrote:

> [...] To complement Dan's efforts, I propose to hold an NMRG meeting
> on Friday March 23, either just during the afternoon or the full day.

[...]

I have asked for an IETF Friday meeting slot with the option to extend
into the afternoon to have more time for discussion. We will have to
wait what comes out of the scheduling algorithm executed by the IETF
secretariat.

I working on collecting contributions to the meeting in cooperation
with Dan Romascanu and Dave Kessens who are organizing some IETF
mini-bof session at the Prague IETF. We are open for proposals; if you
have done research that you want to discuss with an IETF community,
going to Prague is a perfect chance of doing this.

/js

-- 
Juergen Schoenwaelder		 {International|Jacobs} University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

Date: Wed, 17 Jan 2007 15:21:49 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [nmrg] snmp trace analysis status update
Reply-To: [email-masked]

Hi,

at the IETF in Montreal, I reported about the activity to collect SNMP
traces and to analyze what is going on in production networks. We have
done some additional work in this space and we are doing the final
edits on a paper which will be presented at IM 2007.

Since there are lots of SNMP experts on this list and since we still
have a window to make some updates, I have put a draft copy on the
web.

    http://www.faculty.iu-bremen.de/jschoenwae/papers/im-2007.pdf

We appreciate feedback.

/js

PS: We are still looking for more traces. If you believe our data
    source is biased, please help us to unbias it. ;-)

-- 
Juergen Schoenwaelder		 {International|Jacobs} University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

Content-class: urn:content-classes:message
Subject: RE: [nmrg] 22nd NMRG meeting in Prague in March 2007
Date: Tue, 16 Jan 2007 10:57:19 +0100
From: "Giorgio Nunzi" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi Juergen,

Here is my contribution:

> a) Do you support an NMRG meeting in Prague?

Yes

> b) Do you plan to attend an NMRG in Prague?

Yes

> c) Do you have any research results you like to present during an NMRG
>    meeting in Prague?

Not sure at the moment. We can provide more input later on.

Giorgio

From: "David B Harrington" <[email-masked]>
To: <[email-masked]>
Subject: RE: [nmrg] 22nd NMRG meeting in Prague in March 2007
Date: Mon, 15 Jan 2007 12:32:15 -0500

Has anything been decided about whether such a meeting will precede or
follow the IETF meeting? I would like to start the lengthy corporate
process to book my airline, so I need to know when the NMRG meeting
will be.

dbh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Aiko Pras
> Sent: Monday, January 15, 2007 10:54 AM
> To: [email-masked]
> Cc: Aiko Pras
> Subject: Re: [nmrg] 22nd NMRG meeting in Prague in March 2007
> 
> Juergen Schoenwaelder wrote:
> > a) Do you support an NMRG meeting in Prague?
> Yes
> > 
> > b) Do you plan to attend an NMRG in Prague?
> My plan is to attend the NMRG meeting on friday, and IETF meetings 
> provided they are at the end of the week (I will not be able 
> to attend 
> the entire week).
> 
> > c) Do you have any research results you like to present 
> during an NMRG
> >    meeting in Prague?
> I think some results of our SNMP trace analysis can be presented.
> 
> Bye
> 
> Aiko
> -- 
> !! This message is brought to you via the `nmrg' mailing list.
> !! Please do not reply to this message to unsubscribe. To 
> unsubscribe or adjust
> !! your settings, send a mail message to 
> <[email-masked]>
> !! or look at https://mail.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.
> 

Date: Mon, 15 Jan 2007 16:54:23 +0100
From: Aiko Pras <[email-masked]>
To: [email-masked]
Subject: Re: [nmrg] 22nd NMRG meeting in Prague in March 2007
Cc: Aiko Pras <[email-masked]>

Juergen Schoenwaelder wrote:
> a) Do you support an NMRG meeting in Prague?
Yes
> 
> b) Do you plan to attend an NMRG in Prague?
My plan is to attend the NMRG meeting on friday, and IETF meetings 
provided they are at the end of the week (I will not be able to attend 
the entire week).

> c) Do you have any research results you like to present during an NMRG
>    meeting in Prague?
I think some results of our SNMP trace analysis can be presented.

Bye

Aiko

Content-class: urn:content-classes:message
Subject: RE: [nmrg] 22nd NMRG meeting in Prague in March 2007
Date: Tue, 9 Jan 2007 15:37:18 +0100
From: "Wijnen, Bert \(Bert\)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

> a) Do you support an NMRG meeting in Prague?
> 
yes

> b) Do you plan to attend an NMRG in Prague?
> 
not 100% sure. In principle yes... but
It will be the 3rd weekend that I am not home if
I cannot catch a plane on Friday eve 23rd.

> c) Do you have any research results you like to present during an NMRG
>    meeting in Prague?
> 
no

Bert

Date: Tue, 9 Jan 2007 10:42:24 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [nmrg] 22nd NMRG meeting in Prague in March 2007
Reply-To: [email-masked]

Hi,

I hope you all had a good transition into 2007. As most of us are
getting back into "office mode", I like to foster some discussion
on the next NMRG meeting.

Dan Romascanu (IETF OPS area director) is organizing two sessions
during the 68. IETF meeting, which will take place in Prague March
18-23, in order to solicit ideas and proposals for work the IETF
should consider in the network management space. The NMRG should of
course provide input to these sessions. To complement Dan's efforts, I
propose to hold an NMRG meeting on Friday March 23, either just during
the afternoon or the full day.

Note that the Prague meeting may be an excellent place to present
research ideas that you believe should lead not just to some nice
papers but impact the world.

Since people start to make travel plans for Prague, I like to solicit
your feedback on the following three questions:

a) Do you support an NMRG meeting in Prague?

b) Do you plan to attend an NMRG in Prague?

c) Do you have any research results you like to present during an NMRG
   meeting in Prague?

It would be nice to receive your feedback by the end of this week.

/js

-- 
Juergen Schoenwaelder		 {International|Jacobs} University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

content-class: urn:content-classes:message
Date: Wed, 3 Jan 2007 10:42:43 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "MIB Doctors" <[email-masked]>, <[email-masked]>, "DNS Directorate" <[email-masked]>
Cc: [email-masked]
Subject: [nmrg] OPS Area BOFs in Prague

Happy New Year!

This is a final reminder that we shall schedule for the Prague IETF a
number of BOFs or mini-BOFs in the OPS area meeting slots with the
intention to bring to attention new ideas in the operations and
management area and discuss which of those are worth becoming subject
for future standardization, research or prototyping work. We (David and
Dan) will be meeting by the end of the month to discuss the proposed BOF
subjects, please send your proposals as soon as you can, but not later
than January 24. Any of the lists in the area would do, but
[email-masked] would probably be the best. 

Note that if you intent to ask for a separate and dedicated BOF session
rather than for a mini-BOF in the OPS area meeting slots the deadline
for submitting a BOF request is January 15. 

David and Dan