-
Notifications
You must be signed in to change notification settings - Fork 378
Historic: ProjectStatus_2011_09_02
Robert Sparks edited this page May 1, 2023
·
1 revision
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.