owner:olau@iola.dk resolution_fixed type_defect | by avezza@amsl.com
Since we spoke in August,
Cindy and I have been using the new tracker to send Last Calls, since it seems to be more reliable than the original tracker.
However, we've noticed that there is an unexpected behavior where
the new datatracker is not reliable in ending Last Calls when they
expire.
For example, there are three documents that went into Last Call,
and their Last Calls expired on August 31, 2010. They were still
in Last Call today, when the system should have put them into
either "Waiting for Writeup" (if no writeup had been added) or
"Waiting for AD Go Ahead" (if the writeup was in place). These
documents are dt:draft-ietf-manet-nhdp, dt:draft-ietf-nsis-nslp-auth,
and dt:draft-ietf-ippm-spatial-composition.
I changed their states manually today, but there are a couple of
documents whose Last Call finished today, and if the system hasn't
moved them forward by tomorrow, we'll have to do it manually. The
documents affected in this category are
dt:draft-ietf-ccamp-gmpls-ethernet-pbb-te and dt:draft-ietf-roll-rpl.
But this bug is not universal, as there have been a couple of
documents in the last couple of weeks that worked perfectly. For
an example of the way the system worked correctly please see
dt:draft-ietf-dna-simple and dt:draft-ietf-mipshop-transient-bce-pmipv6
(scroll down in the "History" tab to where the (System) changed the
state at the end of the Last Call).
Issue migrated from trac:378 at 2022-03-04 01:02:20 +0000
owner:olau@iola.dkresolution_fixedtype_defect| by avezza@amsl.comSince we spoke in August,
Cindy and I have been using the new tracker to send Last Calls, since it seems to be more reliable than the original tracker.
However, we've noticed that there is an unexpected behavior where
the new datatracker is not reliable in ending Last Calls when they
expire.
For example, there are three documents that went into Last Call,
and their Last Calls expired on August 31, 2010. They were still
in Last Call today, when the system should have put them into
either "Waiting for Writeup" (if no writeup had been added) or
"Waiting for AD Go Ahead" (if the writeup was in place). These
documents are dt:draft-ietf-manet-nhdp, dt:draft-ietf-nsis-nslp-auth,
and dt:draft-ietf-ippm-spatial-composition.
I changed their states manually today, but there are a couple of
documents whose Last Call finished today, and if the system hasn't
moved them forward by tomorrow, we'll have to do it manually. The
documents affected in this category are
dt:draft-ietf-ccamp-gmpls-ethernet-pbb-te and dt:draft-ietf-roll-rpl.
But this bug is not universal, as there have been a couple of
documents in the last couple of weeks that worked perfectly. For
an example of the way the system worked correctly please see
dt:draft-ietf-dna-simple and dt:draft-ietf-mipshop-transient-bce-pmipv6
(scroll down in the "History" tab to where the (System) changed the
state at the end of the Last Call).
Issue migrated from trac:378 at 2022-03-04 01:02:20 +0000