Instead of saying "You are doing something wrong" you might get more help and
clarity by saying "I do not understand how this works."
There are three fields you are talking about.
IETF State shows the state of the document before publication is requested.
Maybe individuals and WG chairs could be more rigorous about updating this
field, however, once publication is requested the field becomes obsolete and we
move to...
IESG State shows the state of the document as it is evaluated by the IESG prior
to publication as an RFC.
Consensus only appears as a field once a document is being processed by the
IESG. It is used to communicate with the RFC Editor to help them understand
which of the IAB's approved boilerplate paragraphs to include in the final RFC.
In addition, you appear to believe that an individual I-D advanced by AD
sponsorship cannot be last called. You are wrong.
As a bottom line, you need to understand that the datatracker is a tool to aid
the processing of documents not a tool to record history. There are often
historic facts that can be gleaned from the datatracker, but that is just a
lucky happenstance.
Adrian
From: iesg [mailto:iesg-bounces(_at_)ietf(_dot_)org] On Behalf Of Abdussalam
Baryun
Sent: 07 October 2014 10:39
To: ietf(_at_)ietf(_dot_)org
Cc: iesg(_at_)ietf(_dot_)org; RFC Editor
Subject: Facts and draft-state information (was Re: Protocol Action:
'Case-Sensitive String Support in ABNF' to Proposed Standard
(draft-kyzivat-case-sensitive-abnf-02.txt)
Is the IESG system reviewing drafts without checking the IETF state per draft?
If the IETF state of the draft is not submitted to IESG then the draft should
not be reviewed. I thought IETF system is interconnected and if I get a message
from IESG saying that a documented is submitted then the IETF state of the
draft is submitted.
The draft in subject is not product of IETF WG so it has no consensus needed,
however, in the document Page in data tracker it should IETF-state as None and
that there were consensus as Yes. We need to make this error stop. There are
other state/info issues with other RFCs that we need to be careful when we
input but I will give some examples;
7181 is WG RFC but has the IETF-state still been in last call and was not
assigned with shephered.
7190 is WG RFC but says unknown for consensus. It should change to Yes.
7193 is WG RFC but has IETF-state as None, it should be changed to submitted to
IESG or to any body it was submitted through.
7195, 7198 are WG RFCs but have consensus as unknown. It should change to Yes.
7199 is WG RFC but IETF-state still WG document, consensus still unknown,
shepherd is not assigned. Please change.
7200 is WG RFC but IETF-state is still write up, consensus unknown. Please
change.
I just done quick and random check and many are with mistakes that don't
reflect reality. Consensus is very critical and there is no doubt that it
should have been gained, but our pages make doubts. I suggest all WGs
management SHOULD review their draft-states/RFCs in data tracker to give them
real process-states with facts and correct information.
Best Regards,
AB
On Monday, October 6, 2014, The IESG wrote:
The IESG has approved the following document:
- 'Case-Sensitive String Support in ABNF'
(draft-kyzivat-case-sensitive-abnf-02.txt) as Proposed Standard
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is Barry Leiba.
A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-kyzivat-case-sensitive-abnf/
Technical Summary
This document extends the base definition of ABNF (Augmented Mackus-
Naur Form) to include a way to specify ASCII string literals that are
matched in a case-sensitive manner. It is being proposed as an
individual submission on the Standards Track, to update RFC 5234.
Review and Consensus
The document was briefly discussed on the abnf-discuss list. It
got good feedback and no objections, and is considered to be a good
proposal. The document is ready for last call.
Personnel
Barry Leiba is the document shepherd and the sponsoring AD.