Subject: Re: [Tools-discuss] Querying a failure mode in I-D submission

From: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Feb 2013 08:23:35 +0000

Just to complete the story: today the draft submission succeeded,
so whatever state was blocking it yesterday has been deleted overnight.
The existence of the bug is pretty much confirmed.

Any ideas, or shall I just submit this as a ticket?

   Brian

On 31/01/2013 12:47, Brian E Carpenter wrote:
> Hi,
> 
> Is the following a possible bug in the I-D submission system?
> 
> It's only speculation, but I think this has happened to me twice now.
> 
> 1. I verify a new (non-WG, -00) draft via http://www.ietf.org/tools/idnits/
> (with one warning, see below**).
> 
> 2. Then I attempt to submit it via https://datatracker.ietf.org/idst/upload.cgi
> 
> The system comes back with "Your draft has NOT been verified to meet IDNITS requirements. (View IDNITS Results)"
> and the nits results are completely blank (https://datatracker.ietf.org/submit/status/47888/#)
> 
> Last time this happened I submitted a ticket without result, and when I
> tried the submission again a day later, it worked fine. This time, I will
> try again tomorrow...
> 
> Is it possible that the manual idnits run is leaving behind some state that causes
> the idnits run during the upload to fail?
> 
> ** The warning that I get is:
> 
>   == Couldn't figure out when the document was first submitted -- there may
>      comments or warnings related to the use of a disclaimer for pre-RFC5378
>      work that could not be issued because of this.  Please check the Legal
>      Provisions document at http://trustee.ietf.org/license-info to determine
>      if you need the pre-RFC5378 disclaimer.
> 
> 
> Regards
>    Brian Carpenter
> 
> 
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 1 Feb 2013 10:11:53 +0100

Hi Brian,

I did submit a ticket yesterday on the failure of ID submission. Which
they apparently have fixed. I did notice that there was a mismatch of
ID-nits version where the submission process used 2.12.14 and tools site
still uses 2.12.13.

Cheers

Magnus

On 2013-02-01 09:23, Brian E Carpenter wrote:
> _______________________________________________
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss
> 
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Scott O Bradner <[email-masked]>
Date: Thu, 31 Jan 2013 11:22:51 -0500

I'm getting something like this as well but with a updated ID 

it says that the ID has not been verified to pass ID Nits but when I look
at the ID Nits output I just see "idnits 2.12.14"

Scott

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 04 Feb 2013 13:20:01 +0000

> at the ID Nits output I just see "idnits 2.12.14"

Yes, that's the symptom, so my speculation that it's related to
a 00 version was false.

   Brian

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 04 Feb 2013 17:25:07 +0100

Hi,

This phenomenon (bug, issue, annoying behaviour) started some time in
December.  Occasionally, the text returned to the submission tool after
a call-out to idnits only contains the first few lines of text, which
means that the submission tool can't find idnits' "No nits found"
declaration.

Once this starts occurring, it can be fixed by doing a reload or restart
of Apache.  Lacking a reload, it will occur much more often after the
first occurrence.

We haven't managed to figure out what triggers this, and once it occurs,
the desire is to do a reload on Apache to get the service operating
properly again, of course, so debugging is hard...

My current thoughts are that Apache could be timing the shell process out
too early in some load situations, and I'm looking at ways to verify and
possibly mitigate this, but I have neither a definite idea of what the
problem is, or a clear solution, at the moment.  When this occurs, the
secretariat now knows to do a reload on Apache, but this is not a solution,
just a temporary workaround.

Best regards,

	Henrik

-- 

I'm transitioning to a new PGP key at the moment, see details at
http://www.levkowetz.com/gpg-key-transition-2013-01-18.txt.asc

pub   4096R/8FBB171A 2013-01-21 [expires: 2015-01-21]
      Key fingerprint = 89F8 DCE7 EAE7 2F53 0905  C652 4E9B 574B 8FBB 171A

Henrik Levkowetz  <[email-masked]>