Historic: ProjectStatus_2011_09_02

TOC(ProjectList,ProjectStatus*,titleindex)

#!rst
--------------------------------------------------------------------------------
Status for the Alternate Streams Project: 26 Aug 2011 - 02 Sep 2011
--------------------------------------------------------------------------------


Summary
=======

In acceptance phase.

What's done
===========

Mailing list was notified to start acceptance using the beta server.

What's next
===========

Wait for feedback.

Time plan
=========

Probably acceptance will not take longer than a pair of weeks.

Problems and Possibilities
==========================

Nothing remarkable.

--------------------------------------------------------------------------------
Status for the ID Tracking Project: 26 Aug 2011 - 02 Sep 2011
--------------------------------------------------------------------------------


Summary
=======

Working on the customization of ID list and RSS publication.


What's done
===========

Notifications system finished

What's next
===========

Last phase of development. Finish tasks and start acceptance. During 
next week we'll update the beta server with the last changes.

Time plan
=========

Probably next week the development will not get far. So in September 
16 will end the development tasks.

Problems and Possibilities
==========================

Nothing remarkable.

--------------------------------------------------------------------------------
Status for the DB Conversion Project: 26 Aug 2011 - 02 Sep 2011
--------------------------------------------------------------------------------


Summary
=======

Ported delegate and shepherd management in wgchairs, now need to port
the state modeling.

What's done
===========

Ported delegate management, adding tests, ported shepherd management,
also with tests, fixed importers to correctly import data for this.
Found some minor bugs in the original code which I fixed.

Then spent some time digging into how the workflow thing and finding
out where it's hooked in (these have to be ported too as they were
merged unaltered when I did the merge with trunk). Finally worked on
state modeling, contemplating and writing some code to see what's
feasible.

What's next
===========

Get a decision on state modeling, then carry it out, possibly only on
the wgchairs states to begin with to avoid getting sidetracked too
much, import the existing stream states, wrap/port the stream-using
things (e.g. on the /doc/draft-xxx-yy/ page). After that porting the
remaining management code in wgchairs.


Time plan
=========

Looking fine. I'm hoping to get wgchairs done next week.


Problems and Possibilities
==========================

Can't think of anything.


Ole

--------------------------------------------------------------------------------
Status for the Rfc-ed/IANA Sync Project: 26 Aug 2011 - 02 Sep 2011
--------------------------------------------------------------------------------


Summary
=======

Implemented some of the changes to the Datatracker, and planning of the 
IANA communication


What's done
===========

* Recording (in the History) of RFC-editor state updates
* Made ExternalReviewDocEvent for handling expert reviews (only IANA for now)
* Show IANA status in agenda

Regarding IANA communication I had thought about using JSON with 
something like the following::

     {
     "doc": "draft-arkko-dual-stack-extra-lite",
     "type": "iana_review",
     "state": "IANA Not OK",
     "comment": "IANA has issues with the following: ...",
     "changed": "2011-01-13 15:30:59"
     }

The comment is optional (i.e. can be ""), and the changed field ensures 
we don't make duplicate events on the Datatracker side. For the state 
changes (when the document enter IANA responsibility)::

     {
     "doc": "draft-arkko-dual-stack-extra-lite",
     "type": "iana_state_changed",
     "state": "In Progress",
     "changed": "2011-01-13 15:30:52"
     }

The state would just be recorded as text in the Datatracker, ensuring
there that any new states can also  be  handled,  and  it  would be
automatically  handled  in  the Datatracker (there  might be changes if
some  functions make decisions based on  particular IANA states,  but
showing the IANA  states should not require changes). Additionally, the 
RFC asks for updates on when IANA has performed some actions related to 
the document. This could be exported as::

     {
     "doc": "draft-arkko-dual-stack-extra-lite",
     "type": "iana_action",
     "comment": "IANA performed the following actions: ...",
     "changed": "2011-01-13 15:30:52"
     }

As far as I can see, this would cover the data needed in the Datatracker 
from IANA's side, and it would allow future extensions by just making a 
new event type. What do you think?

IANA would notify the datatracker on::

   http://datatracker.ietf.org/iana/update/

(manual "point and click" or post  with no key values). Should probably
be run every hour by cron job like RFC-editor).

Similarly the RFC-editor could update on::

   http://datatracker.ietf.org/rfc-editor/update/

The Datatracker to IANA and RFC-editor could be (in JSON)::

     {
     "doc": "draft-arkko-dual-stack-extra-lite",
     "title": "Scalable Operation of Address Translators with Per-Interface Bindings",
     "authors": [{
         "name": "Jari Arkko",
         "email": "[email protected],
         "organization": ""
         }],
     "expedited_goal_date": "2011-09-17",
     "publication_status": "",
     "consensus": "yes",
     "source": "individual",
     "iesg_contact": "Ralph Droms",
     "document_shepherd": "[email protected]",
     "iana_actions_required": "IANA needs to perform the following..."
     }

These would be shown at::

   http://datatracker.ietf.org/exports/

Comments are welcome.

What's next
===========

Implementing more of the state-specific behaviour (notices, auto-setting 
state, etc.)

Time plan
=========

The plan has been pushed a few days, but overall still on schedule for 
the 14th.

Problems and Possibilities
==========================

The IANA review comments (part 2.1 under IETF Last Call Comments, IANA 
OK, IANA Not OK, etc.) are described as substates. However, since these 
are to be recorded in the history log, they seem to fit better as a 
DocEvent. I thought about making them a tag, but in light of possible 
future expert reviewers this would clutter the possible document tags 
with tags for each expert reviewer (a few for security experts, a few 
from IANA, etc.). Instead I made an ExternalReviewDocEvent. Getting the 
state of an external reviewer would be something like 
doc.latest_event(ExternalReviewDocEvent, type="iana_review"), and this 
could easily be expanded for other external reviewers. What do you think?

Best,
Martin


--------------------------------------------------------------------------------
Status for the WG Charter Tool Project: 26 Aug 2011 - 02 Sep 2011
--------------------------------------------------------------------------------


Summary
=======
Feedback from user tests and discussion


What's done
===========

I only fixed the bug that Robert Sparks pointed out. I wanted to wait 
until everyone agreed on what needs to be changed (and to what).


What's next
===========

Planned changes:

* State description update
* Edit charter text without uploading a txt-file
* Reduced create WG form

Additionally, we discussed splitting charter into multiple Document 
objects. Should I proceed with this, or should we leave it as is?

Time plan
=========


Changes shouldn't take too long, and I'm aiming for a new demo sometime 
this week.

Best,
Martin


--------------------------------------------------------------------------------
Status for the Xml2rfc V2 Project: 26 Aug 2011 - 02 Sep 2011
--------------------------------------------------------------------------------


Summary
=======

Not much more feedback coming in about the GUI or command line tool. We'll wait to hear more. Mostly we are wrapping up the command line application and finishing the GUI application.



What's done
===========

Josh sent you an email with more details on the cache and the DTD validation and what he's worked on this week.



What's next
===========

We'll wait for your response in terms of the XML library and next steps -- and any other feedback you or the team has. We continue to work on the installers for the GUI application.



Time plan
=========

We hope to be finished completely in the next month with the GUI tool.


Problems and Possibilities
==========================

Only open questions from Josh's separate email.