On Tuesday, October 7, 2014, Adrian Farrel wrote:
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@xxxxxxxx] On Behalf Of Abdussalam Baryun
Sent: 07 October 2014 10:39
To: ietf@xxxxxxxx
Cc: iesg@xxxxxxxx; 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.