Liaison Statement Manager Extensions

					Liaison Statement Management Tool Enhancements
Development Proposal

1. Introduction

The initial version of the IETF Liaison Statement Management Tool (LSMT) was
deployed to the IETF Liaison Managers on July 21, 2005. This version of the
tool was designed to satisfy the *basic* requirements of RFC 4053 (BCP 103),
“Procedures for Handling Liaison Statements to and from the IETF,” with the
exception of one feature: automatic copying of the appropriate parties. The
intent was to implement that feature in future versions of the tool.

This document presents NeuStar Secretariat Services’ (NSS’) proposal for
enhancing the LSMT to (a) address the requirement that was omitted from the
original version, (b) broaden the use of the tool within the IETF community,
and (c) reduce the need for Secretariat intervention in the submission and
posting of liaison statements to and from the IETF. It consists of a
description of the enhancements to the tool that NSS will implement and
related tasks, a development plan, a staffing plan, the estimated cost (in
both level-of-effort and dollar amount), and a schedule of milestones and
deliverables. It also includes an Appendix which summarizes the procedures
for handling liaison statements that form the basis for the proposed
enhancements.

2. Enhancements to be Implemented and Related Work

2.1 Creating accounts on the LSMT for authorized IETF participants

NSS will create accounts on the tool for all IETF participants who are
authorized to submit liaison statements on behalf of the various IETF
entities as follows:

      For the IETF/IESG Chair, the IAB Chair, and the IETF Area Directors:
       when seated
      For an IETF Liaison Manager: when named
      For an IETF WG Chair and an IETF WG Secretary: upon request

The accounts will be customized and will include *only* the entities that an
individual represents in the “drop-down” list in the “From:” field. For
example, if an individual is the chair of multiple working groups, then his
or her drop-down list will include each of those working groups. If the
individual is an Area Director, then his or her drop-down list will include
*only* the Area (unless that Area Director also happens to be the chair of
one or more working groups). If an individual is an IETF Liaison Manager,
then his or her drop-down list will include *all* IETF entities plus the
relevant Standards Development Organization(s) (SDO(s)).

As part of this effort, NSS will ensure that all accounts are up-to-date as
of the date that the enhanced version of the LSMT is deployed.

2.2 Obtaining approval to send a liaison statement on behalf of the various
IETF entities

2.2.1 On behalf of an IETF WG.
NSS will create a check box where the WG Chair, WG Secretary, or Liaison
Manager can indicate that he or she has obtained prior approval from the
appropriate AD(s) to send the liaison statement. NSS will ensure that the
appropriate ADs are copied on the liaison statement when it is sent.

2.2.2 On behalf of an IETF Area, the IETF as a whole, the IESG, or the IAB.

NSS will create a check box where a Liaison Manager can indicate that he or
she has obtained prior approval from the AD(s), from the IETF/IESG Chair, or
from the IAB Chair, as appropriate, to send the liaison statement. NSS will
ensure that the appropriate party(ies) are copied on the liaison statement
when it is sent.

2.3 Obtaining a list of SDO representatives who are authorized to send
liaison statements on behalf of their respective SDOs.

NSS will request the Liaison Manager for each SDO to provide the Secretariat
with a list of individuals who are authorized to send liaison statements on
behalf of that SDO. These individuals will receive accounts on the tool.
The initial request will be sent at the time that the enhanced version of the
LSMT is deployed. Automated reminders to update the list (i.e., to add and
delete individuals, as appropriate) will be sent quarterly thereafter.

2.4 Implementing a “Post Only” option

Currently, the LSMT sends and posts liaison statements simultaneously. NSS
will implement a “Post Only” option, which will allow a user to post a
liaison statement that was originally sent via e-mail to the “Liaison
Statements” Web page via the tool. When using the “Post Only” option, the
user will be instructed to cut and paste the entire e-mail submission,
including all headers, into the “Body:” field of the Web form.

The “Post Only” option will be available to all individuals with accounts on
the tool. That is, the user will have two options: “Send and Post” or “Post
Only.” The one exception is for an IETF Liaison Manager who wishes to post a
liaison statement to the “Liaison Statements” Web page that was originally
submitted via e-mail by a representative of the Liaison Manager’s SDO.
Although the SDO will be listed on the Liaison Manager’s “drop down” list in
the “From:” field of the Web form, if the Liaison Manager selects the SDO,
then he or she will have only one option: “Post Only.”

2.5 Implementing a Universal “From” address

NSS will implement a universal “From” address, e.g., “lsmt@ietf.org,” and all
outgoing and incoming liaison statements that are sent by the tool will be
sent from this address. The Secretariat will suggest that the list
administrators for all WG discussion lists accept messages from this address
without moderation. The universal “From” address will not be visible to the
public as it should not receive messages.

2.6 Additional features

NSS will implement some additional features to assist the submitters of
outgoing and incoming liaison statements in completing the “From:,” “To:,”
and “Cc:” fields of the template. The features described in the following
subsections will be implemented in the enhanced LSMT.
2.6.1 For outgoing liaison statements:

      The “From:” field: The leadership of all recognized IETF entities will
       have accounts on the tool. (Please see Section A.1 in the Appendix.)
       When the submitter logs on to the tool, if the submitter represents a
       single IETF entity (e.g., a WG), then the “From:” field will include
       the name of the entity that the submitter represents, followed by the
       submitter’s name in parenthesis, e.g.,

       IETF CCAMP WG (Adrian Farrel)

       If the submitter represents multiple entities (e.g., is a chair of two
       or more WGs), then the “From:” field will provide a drop-down list of
       these entities, and the submitter can select the appropriate one for
       the current liaison statement.

       The submitter’s name will be a link to a “mail-to” form that will be
       pre-populated with whatever address is inserted into the “Reply-To:”
       field of the form. Initially, the “Reply-To:” field will be pre-
       populated with the submitter’s e-mail address. However, the field will
       be editable, so that he or she can replace that address with another
       address in cases where it is appropriate for responses to go to another
       individual.

      The “To” field: The “Organization:” sub-field of the “To:” field will
       consist of a drop-down list of all SDOs with which the IETF has a
       formal liaison relationship, and the category “Other.” The submitter
       can select an organization or select “Other.” If the submitter selects
       “Other,” then he or she will manually insert the name of the
       organization in the field. (The “Other” category would be used to send
       or respond to liaison statements to or from SDOs with which the IETF
       does *not* have a formal liaison relationship.)   In either case, the
       submitter will be required to complete the “POC:” sub-field of the
       “To:” field manually. (Note: At some point, it might be useful to
       create an address book for POCs for the various SDOs.)

      The “Cc:” field: If the submitter selects one of the organizations on
       the drop-down list of the “Organization:” sub-field of the “To:” field,
       then the “Cc:” field will be pre-populated with the e-mail address of
       the associated Liaison Manager. For example, if the submitter is
       sending a liaison statement to an ITU-T entity, then the “Cc:” field
       will be pre-populated with Scott Bradner's e-mail address or an
       appropriate alias, e.g., itu-t-liaison-manager@ietf.org (TBD).
       Additional recipients will be automatically added to the “Cc:” list
       depending on the submitting entity, as specified in Section A.5.1 in
       the Appendix.

       Finally, any addresses included in the “Response Contact:” and
       “Technical Contact:” fields of the liaison statement will also receive
       copies of the liaison statement. (Note: a blind copy will be sent to
       “statements@ietf.org” to generate a ticket in the Secretariat's RT
       ticket system.)

2.6.2 For incoming liaison statements:
      The “From:” field: The authorized representatives of the SDOs with
       which the IETF has a formal liaison relationship will have accounts on
       the tool. (Please see Section A.3 in the Appendix.) When an
       authorized representative logs on to the tool, the “From:” field will
       include the name of the SDO followed by the submitter’s name in
       parenthesis, e.g.,

       ITU-T SG 15 (Greg Jones)

       The submitter’s name will be a link to a “mail-to” form that will be
       pre-populated with whatever address is inserted into the “Reply-To:”
       field of the form. Initially, the “Reply-To:” field will be pre-
       populated with the submitter’s e-mail address. However, the field will
       be editable, so that he or she can replace that address with another
       address in cases where it is appropriate for responses to go to another
       individual.

      The “To:” field: The “Organization:” sub-field of the “To:” field will
       consist of a drop-down list of all recognized IETF entities: IETF, IAB,
       IESG, all IETF Areas, and all IETF Working Groups. The list will be
       organized so as to facilitate locating the desired entity (TBD). When
       the submitter selects an entity, the “POC:” sub-field will be filled in
       automatically based on the guidelines contained in Section A.4 in the
       Appendix.

      The “Cc:” field: The “Cc:” field will be pre-populated with the e-mail
       address of the IETF Liaison Manager for the SDO whose authorized
       representative is sending the liaison statement. For example, if the
       submitter represents an ITU-T entity, then the “Cc:” field will be pre-
       populated with Scott Bradner's e-mail address or an appropriate alias,
       e.g., itu-t-liaison-manager@ietf.org (TBD). Additional recipients will
       be automatically added to the “Cc:” list depending on the entity
       selected in the “Organization:” sub-field of the “To:” field as
       specified in Section A.5.2 in the Appendix.

       Finally, any addresses included in the “Response Contact” and
       “Technical Contact” fields of the liaison statement will also receive
       copies of the liaison statement. (Note: a blind copy will be sent to
       “statements@ietf.org” to generate a ticket in the Secretariat's RT
       ticket system.)

3. Development Plan

This section briefly describes the development environment that will be used
to build the LSMT enhancements, and the steps to accomplish the project.

3.1 Development Environment

The LSMT enhancements will be written and maintained in PERL, version 5.8 or
higher, and the source code for the entire tool will be publicly available.

Apache Web server will run the scripts with SSL encryption to enable an https
connection. For authentication, Apache Web server's HTTP Authentication will
be used. MySQL 4.1.12 or higher will be used as the database engine, and PERL
mysql-dbd will be installed along with PERL DBI to create the interface
between the engine and the scripts.
3.2 Steps

This section lists the steps in the development process. The steps will be
performed in the order presented below.

3.2.1 Software Design Document (SDD)

An informal software design document that consists primarily of diagrams and
bullets will be prepared. The document will be submitted to the IETF Tools
Management Committee (TMC) for review, and TMC comments will be addressed.
Please note that the SDD will cover only those features that are described in
Section 2 above. If the IETF believes that it would be desirable to have an
SDD that covers the entire LSMT, then NSS will be pleased to submit an
updated estimate of the LOE, cost, and completion date for the document.

3.2.2 Database Design and Documentation (DBDD)

The database schema for the LSMT enhancements will be designed and
implemented on the existing IETF database. Documentation of the database
schema for the LSMT will be provided.

3.2.3 Coding and Unit Testing

The features described in Section 2 above will be implemented. Unit testing
of each feature in Section 2 will be performed by the developer immediately
after implementation. A well-defined testing plan for each feature will be
prepared, and an automated regression test will be performed after each
individual feature is implemented.

3.2.4 Application Testing

3.2.4.1 Internal Testing

The LSMT enhancements will be tested internally by one or more members of the
NSS staff. Application testing will confirm that the new software fulfills
the features specified in Section 2 of this document, and adjustments will be
made as necessary.

3.2.4.2 External Testing

The LSMT enhancements will be tested by one or more individuals outside of
NSS, e.g., members of the IETF Tools Team. The functionality of the software
will be adjusted, as necessary, based on tester feedback.

3.2.5 Demonstration to the Tools Management Committee

After application testing is complete, NSS will demonstrate the LSMT
enhancements to the TMC members, and make any minor adjustments and
refinements required as a result of their input.

3.2.6 Deploying and Announcement

When the LSMT enhancements have been approved by the TMC, the updated tool
will be deployed on an IETF Web server and announced to the IETF community.

3.3 Version Control
NSS will use a Concurrent Version System (CVS) to maintain versions of the
software.

3.4 Open Sourcing

NSS will install a Web-based application on the IETF server that will allow
the community to access the source code of the LSMT in “read-only” mode.
However, providing Common Development Distribution Licenses (CDDLs) for the
source code remains an open issue, since NSS has some questions concerning
licensing and will need to consult the NeuStar attorneys for more
information.

4. Staffing

This quote reflects a Black Box Model. As such, NeuStar will bring in
multiple developers, with varying degrees of expertise, from its 350 person
development staff to assist with various elements of this project.

In addition, NeuStar will continue to allocate a Senior Software Architect to
provide overall development guidance as well as introduce additional software
development talent as needed throughout the project.

NeuStar requests, and the IETF agrees to provide, an experienced software
lead who can guide and direct the work, and who is empowered to make
decisions on the finer details that inevitably will arise.

5. Cost

NSS will perform the work for a fixed price of $14,792. No penalty will be
incurred should NSS miss the deadline for delivery, acceptance and deployment
of the tool, which is TBD, 2007. However, an additional $1,500 bonus will be
offered if the tool is successfully delivered by the agreed upon Deployment
and Announcement date. Please see “Schedule (Period of Performance)” of this
proposal. The software developed by NSS will be the property of the IETF
Trust.

6. Schedule (Period of Performance)

Below is a list of the major milestones with dates that will be assigned
based on the date of the contract. NSS is prepared to begin work
immediately; however the milestones assume a two week ramp up to contract.

Milestone                                        Completion Date

* Software Design Document                       Contract +24

* Database Design Document                       Contract +24

* Coding, Unit Testing, and Regression Testing   Contract +40

* Internal Testing                               Contract +49

* External Testing                               Contract +54

* Demonstration to the TMC                       Contract +58
* Deployment and Announcement   Contract +59
Appendix: IETF Procedures for Handling Liaison Statements

This Appendix addresses the procedural issues that affect the enhancements
that will be made to the tool.

A.1 Who has the authority to send liaison statements on behalf of the various
IETF entities (i.e., who are the IETF participants who will receive accounts
on the tool)?

NSS understands that the ability to transmit and post liaison statements will
be limited to the following individuals:

      IETF Liaison Managers: on behalf of any IETF entity
      WG Chairs and WG Secretaries: on behalf their working groups
      Area Directors: on behalf of their Areas
      The IESG Chair: on behalf of the IESG
      The IETF Chair: on behalf of the IETF as a whole
      The IAB Chair: on behalf of the IAB

A.2 Who must approve the transmission of a liaison statement sent on behalf
of the various IETF entities?

A.2.1 A liaison statement sent on behalf of an IETF WG

NSS understands that a WG chair, WG secretary, or Liaison Manager should
obtain approval from the appropriate AD prior to sending a liaison statement,
and Cc the AD on the message.

A.2.2 A liaison statement sent on behalf of an IETF Area, the IETF as a
whole, the IESG, or the IAB

NSS understands that if a liaison statement is sent by an IETF Area Director,
the IETF/IESG Chair, or the IAB Chair on behalf of his or her respective
entity, then no additional approval or notification is required. However, if
the liaison statement is sent by an IETF Liaison Manager, then the Liaison
Manager must obtain prior approval from the appropriate party and Cc the
appropriate party(ies) on the message.

A.3 Who has the authority to transmit liaison statements on behalf of the
Standards Development Organizations (SDOs) with which the IETF has formal
liaison relationships (i.e., who are the SDO representatives who will receive
accounts on the tool)?

The IETF Liaison Manager for each SDO will provide the Secretariat with a
list of individuals who are authorized to send liaison statements on behalf
of that SDO. The Liaison Manager will update the list on a quarterly basis.

A.4 Who is the appropriate point-of-contact (POC) for an incoming liaison
statement? (i.e., who is the recipient of a liaison statement sent to one of
the various IETF entities)?

NSS understands that the recipients of incoming liaison statements are as
follows:

                    IETF Entity                    POC
               The IETF or the IESG         The IESG/IETF Chair
                The IAB                              The IAB Chair
                An IETF Area                         The Area Directors
                An IETF WG                           The WG Chairs

A.5 Who must be copied on liaison statements?

NSS understands that the following individuals/entities must be copied on
*all* outgoing and incoming liaison statements:

      The IETF Liaison Manager for the SDO (where applicable)
      The IETF Secretariat (statements@ietf.org)
      Any addresses included in the “Response Contact:” and “Technical
       Contact:” fields of the liaison statement form.

Additional individuals, entities, and mailing lists must be copied on
“outgoing” and “incoming” liaison statements depending on the submitting
entity or the receiving POC, respectively.

A.5.1 Outgoing liaison statements

NSS understands that the following individuals, entities, and mailing lists
must be copied on outgoing liaison statements:


  Submitting Entity                               Cc: Field
The IETF or the IESG            The IETF Chair (if not the submitter)
                                 chair@ietf.org
                                The IESG iesg@ietf.org
The IAB                         The IAB Chair (if not the submitter) iab-
                                 chair@iab.org
                                The IAB iab@iab.org
An IETF Area                    The IETF Area Directors (or one, if the other is
                                 the submitter)
                                The IETF Chair chair@ietf.org
                                The IETF Area Directorate mailing list (where
                                 applicable)
An IETF WG                      The IETF WG Chairs (or one, if the other is the
                                 submitter)
                                The IETF Area Directors
                                The IETF WG Discussion List


A.5.2 Incoming liaison statements

NSS understands that the following individuals, entities, and mailing lists
must be copied on incoming liaison statements:


             Receiving Entity                            Cc: Field
          The IETF or the IESG           The       IESG iesg@ietf.org
          The IAB                        The       IAB iab@iab.org
          An IETF Area                   The       IETF Chair chair@ietf.org
                                         The       other IETF Area Director
           Receiving Entity                    Cc: Field
                                      (where applicable)
                                     The IETF Area Directorate
                                      mailing list (where applicable)
        An IETF WG                   The IETF Area Directors
                                     The other IETF WG Chair (where
                                      applicable)
                                     The IETF WG Discussion List


A.6 Can a liaison statement be sent via e-mail and posted via the LSMT?

With one exception, all individuals with accounts on the tool should be able
to simultaneously send and post liaison statements, or send them by e-mail
and post them via the tool. The one exception is a Liaison Manager. NSS
understands that IETF liaison managers are not permitted to send liaison
statements on behalf of their respective SDOs. However, they should be able
to post a liaison statement, which was originally sent by a representative of
an SDO via e-mail, to the IETF Liaison Statements Web page via the tool.

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:3
posted:3/18/2010
language:English
pages:10