Re: Liaison Statement Improvements SOW for Community Input

Ray Pelletier <> Thu, 03 April 2014 14:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 05F151A0211; Thu, 3 Apr 2014 07:32:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.892
X-Spam-Status: No, score=-101.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eQiS5n6TNRoe; Thu, 3 Apr 2014 07:31:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 533061A020E; Thu, 3 Apr 2014 07:31:57 -0700 (PDT)
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 15.0.913.9; Thu, 3 Apr 2014 14:31:52 +0000
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
Subject: Re: Liaison Statement Improvements SOW for Community Input
From: Ray Pelletier <>
In-Reply-To: <>
Date: Thu, 03 Apr 2014 10:31:41 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <>
References: <>
To: IETF Discussion <>
X-Mailer: Apple Mail (2.1874)
X-Originating-IP: []
X-ClientProxiedBy: ( To (
X-Forefront-PRVS: 0170DAF08C
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019001)(6009001)(6049001)(428001)(243025003)(377454003)(51704005)(199002)(189002)(24454002)(51856001)(76796001)(54316002)(81816001)(80976001)(83072002)(76482001)(15202345003)(85852003)(77096001)(74366001)(46102001)(95666003)(4396001)(50226001)(98676001)(99396002)(56776001)(50986001)(97186001)(76786001)(59766001)(49866001)(47736001)(81686001)(47976001)(77982001)(97336001)(15975445006)(81342001)(92566001)(53806001)(82746002)(77156001)(79102001)(74502001)(50466002)(88136002)(19580405001)(92726001)(83322001)(19580395003)(69226001)(62966002)(85306002)(95416001)(93136001)(63696002)(47776003)(36756003)(87266001)(81542001)(94316002)(87286001)(93516002)(83716003)(66066001)(80022001)(42186004)(23746002)(33656001)(47446002)(74706001)(89996001)(86362001)(56816005)(31966008)(90146001)(74662001)(65816001)(74876001)(87976001)(93916002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR06MB234; H:[]; FPR:FCF8F21C.AC3A9719.70E39EAB.8AA6DA4D.203E1; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Received-SPF: None (: does not designate permitted sender hosts)
Cc:, " IAB" <>, The IESG <>, IETF Announcement list <>, Working Group Chairs <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IETF announcement list. No discussions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Apr 2014 14:32:02 -0000


A reminder that Community input is being sought for this Liaison Statement Improvements SOW


On Mar 24, 2014, at 2:34 PM, IETF Administrative Director <> wrote:

> The IAOC desires improvements to the liaison statement tracking capabilities in the datatracker to 
> address community requests and to simplify ongoing maintenance of the related code.
> The community comment period ends 7 April 2014.  The IAOC will consider all comments received 
> during this prior.
> Liaison relationships with other standards setting bodies are managed by the IAB. The processes for 
> managing the relationships are detailed in RFC4052, and the procedures for handling liaison statements 
> are detailed in RFC4053. The current liaison statement management tool (LSMT) began from the 
> definitions in that RFC and the LMST has been improved through previous contracted development. 
> Individuals using the tool must follow the guidelines in RFC4691.  Developers working on the liaison 
> statement management section of the datatracker must be familiar with all three RFCs. 
> SOW Deliverables / Tasks
> a.  Migrate the codebase and data to new models, refining the models as necessary. 
> b.  Add history to liaison statements, capturing when they were received, posted, resent, approved, marked 
> dead or modified.
> c.  Add Point of Contact email addresses for each body to be used as the default Response Contact.
> d.  Capture other SDOs identifiers for liaison statements.
> e.  Add “Action Holder” email addresses to incoming liaison statements.
> f.  Add the ability for a liaison statement to reference multiple other liaison statements as related.
> g.  Allow a liaison statement to be sent from multiple bodies and sent to multiple bodies.
> h.  Add the concept of a “dead” liaison statement, allowing an approver or the secretariat to remove a 
> statement from the pending queue without posting it. Add a view to manage the set of dead liaison statements.
> i.  Add the ability to resend a liaison statement.
> j.  Improve search over posted liaison statements, searching all fields and allowing the results to be 
> limited to a particular source and/or destination body and/or a particular time range. Facilitate browsing a 
> series of related liaison statements as a “thread”.
> k.  Address known issues with the liaison statement entry form when used as the secretariat and when used 
> as a liaison manager.
> l.  Make it easier to see which liaison statements still need action.
> m.  Ensure liaison statement approvers are notified when there is something to approve.
> n.  Remove the restriction against duplicate liaison statement titles.
> o.  Allow the set of attachments to a liaison statement to be edited. In particular allow an attachment to be 
> deleted. Leave a record in the history for each editing event.
> p.  Improve test coverage, and ensure tests exercise the use cases detailed in this document.
> All information submitted in response to this announcement is voluntary and may be used in the 
> development of the SOW.
> Thanks for your continuing advice and support.
> Ray Pelletier 
> IETF Administrative Director