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)

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 7 Oct 2014 11:38:38 +0200

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.
>
>

---

From: Loa Andersson <[email-masked]>
Date: Tue, 07 Oct 2014 11:48:58 +0200

Folks,

I think we need to be careful about fact, RFC 7190 the status page says:

IETF State:	Submitted to IESG for Publication
Consensus:	Yes
Document shepherd:	Loa Andersson
Shepherd Write-Up:	Last changed 2013-11-16

/Loa

On 2014-10-07 11:38, Abdussalam Baryun wrote:
> 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.
>
> 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.
>
> 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.
>
> 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
>

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 7 Oct 2014 11:06:02 +0100

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:[email-masked]] On Behalf Of Abdussalam Baryun
Sent: 07 October 2014 10:39
To: [email-masked]
Cc: [email-masked]; 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. 

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

Technical Summary

Review and Consensus

Personnel

---

From: Randy Bush <[email-masked]>
Date: Tue, 07 Oct 2014 06:11:05 -0400

> 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.

as a sometimes author, i will take any competent review i can get

our goal should be the best specs we can produce for needed technology,
not creating unnedessary restrictive process and politics.

randy

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 7 Oct 2014 12:36:04 +0200

I understand how things should state while I done some comparison with
other RFCs. However, thanks for your information because it may help the
page designer to make it more helpful for new participants and how the view
IETF pages.

AB

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."
>
>
>
> 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...
>
>
>
> 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:[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>] *On Behalf Of *Abdussalam
> Baryun
> *Sent:* 07 October 2014 10:39
> *To:* [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> *Cc:* [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>; 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)
>
>
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 7 Oct 2014 09:27:55 -0700

> careful when we input but  I will give some examples;

It's not true that no consensus is needed for a document just because it's
not a WG product.  Anything that comes through the IETF stream (including
AD-sponsored documents) need to reflect consensus.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 7 Oct 2014 09:29:35 -0700

(reducing Ccs)

On Tue, Oct 7, 2014 at 2:38 AM, Abdussalam Baryun <
[email-masked]> wrote:

> draft should not be reviewed.
>

Huh?  Why would you put a document in the datatracker in the first place if
it shouldn't be reviewed?

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Tue, 7 Oct 2014 12:43:14 -0400

> needed,

Quite wrong; it needs and has community consensus.

> however, in the document Page in data tracker it should IETF-state
> stop.

What error is that?  First, I can't parse "it should IETF-state as
None", so I'm sure I don't know what you mean.  Second, IETF-state is
"None" because it didn't come from a working group.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Tue, 7 Oct 2014 12:47:18 -0400

> AD-sponsored documents) need to reflect consensus.

That's generally true the vast majority of the time, though there are
exceptions for some Experimental or Informational documents, which is
why the flag is there in the first place.

We do occasionally produce documents that describe proprietary
protocols or that republish outside documents in the IETF stream.  We
try to do those in the Independent stream instead, but it's not always
the best or right thing.  When they're published in the IETF stream,
the point is that we have consensus to publish them, but we might not
have consensus on the protocol that's described.  In those cases,
we'll use "No" for the "Consensus" flag.

Barry

---

From: "GTW" <[email-masked]>
Date: Tue, 7 Oct 2014 13:09:21 -0400

I wonder if "procedures" sort of documents require/deserve the same sort of 
consensus as "technical specification" sort of documents.  This is 
interesting to me as there is a global standards policy debate whether 
"governance" sort of documents should/need the same sort of consensus as 
"technical specification" standards.  There is a contention that 
"governance" sort of documents need not be consensus sort of documents.

there is no doubt a factual answer to this matter in IETF procedures we will 
hear ... yet there are very many varieties of standards development 
organizations around the world with different models

George T. Willingmyre
President GTW Associates

-----Original Message----- 
From: Barry Leiba
Sent: Tuesday, October 07, 2014 12:47 PM
To: Murray S. Kucherawy
Cc: [email-masked] ; RFC Editor ; [email-masked]
Subject: Re: Facts and draft-state information (was Re: Protocol Action: 

Barry

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 7 Oct 2014 13:08:22 -0500

Just piling in after Barry here ... and speaking as the AD who had the most
recent ¨draft on a telechat agenda with consensus = unknown¨, but I'm
hardly the only one.

The field in the tracker is labeled ¨consensus¨, which is ambiguous but
actually means ¨IETF consensus¨. So, it should be set after IETF Last Call.

A fair number of the documents I've processed already had it set to ¨yes¨
when they were publication-requested, so that means the shepherd/working
group chairs thought it meant ¨working group consensus¨.

I believe - but Barry would know - that we've requested that the field
label be changed to ¨IETF Consensus¨ in the datatracker.

(I know we talked about that, but I don't know whether we've made the
request yet)

Spencer

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 7 Oct 2014 11:10:46 -0700

On Tue, Oct 7, 2014 at 11:08 AM, Spencer Dawkins at IETF <
[email-masked]> wrote:

> Just piling in after Barry here ... and speaking as the AD who had the
> most recent ¨draft on a telechat agenda with consensus = unknown¨, but I'm
> hardly the only one.
>
I've set that field as a WG chair to indicate the document came from a
consensus process, which I guess is the same thing, and would always be
"Yes" for the product of a working group anyway.  I've noticed though that
I don't always have control over that field's contents anymore.

-MSK

---

From: Melinda Shore <[email-masked]>
Date: Tue, 07 Oct 2014 10:19:29 -0800

On 10/7/14 10:08 AM, Spencer Dawkins at IETF wrote:
> most recent ¨draft on a telechat agenda with consensus = unknown¨, but
> I'm hardly the only one.
> 
> A fair number of the documents I've processed already had it set to
> ¨yes¨ when they were publication-requested, so that means the
> shepherd/working group chairs thought it meant ¨working group consensus¨.
> 

I think that would be helpful.

In this particular case there appear to be two primary sources of
confusion: 1) on what the word "consensus" means in terms of
process in the datatracker, and 2) that the datatracker is being
taken to be normative rather than informative.  The first appears
to be confusing to a few people and it's great that it's being
addressed; I've never seen anybody be confused about the latter
before.  Doesn't mean that it hasn't happened, but I suspect
that it's not a general problem and the lack of a giant red
"FOR INFORMATIONAL PURPOSES ONLY" label on the datatracker and
tools pages does not appear to be an impediment to getting anything
done.  If this is a more general problem let's do something about
it, and if it's not let's drop it and move on.

Melinda

---

From: t.p. <[email-masked]>
Date: Wed, 8 Oct 2014 10:08:32 +0100

----- Original Message -----
From: "Spencer Dawkins at IETF" <[email-masked]>
To: "Barry Leiba" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "RFC Editor"
<[email-masked]>
Sent: Tuesday, October 07, 2014 7:08 PM

most

The field in the tracker is labeled ¨consensus¨, which is ambiguous but
actually means ¨IETF consensus¨. So, it should be set after IETF Last
Call.

¨yes¨

<tp>

What would be even more helpful would be, as in other systems I use, the
ability to click on a field name and be taken to a help facility for the
various values that can appear in a field.

BUT ... it would only be worth doing if we have the resources to
maintain such a system.  I say that because the second biggest problem I
have with the IETF website (after the denial of service caused by
https:// :-(  is incorrect links, that have not been updated as and when
the website has been reorganised.  I do not have the experience of
website maintenance to know why this is a problem (just observe that it
is, with both the IETF and other websites).

Tom Petch
</tp>

Spencer

On Tue, Oct 7, 2014 at 11:47 AM, Barry Leiba <[email-masked]>
wrote:

> > It's not true that no consensus is needed for a document just
because
> it's

---

From: Loa Andersson <[email-masked]>
Date: Wed, 08 Oct 2014 12:07:10 +0200

Folks,

>> we'll use "No" for the "Consensus" flag.

In the wg part of the data-tracker there is a state "WG Consensus - 
Wating for Writeup". The nit here is that the WG consensus info
disappear (or maybe better "made implicit") when the publication
is requested.

It might be a bit of overkill (and not very high priority) to have
two fields - one "WG Consensus" and "IETF Consensus"?

/Loa

--

---

From: Barry Leiba <[email-masked]>
Date: Wed, 8 Oct 2014 12:00:59 -0400

> two fields - one "WG Consensus" and "IETF Consensus"?

I understand where that comes from, but I think it's an artifact of
the poorly names "Consensus" field.  No document should come out of a
working group with publication requested unless is has working group
consensus, so I don't see the value to such a field.

The problem here is that the "Consensus" field is purely something to
tell the RFC Editor what boilerplate to put on the document, and the
field should be renamed to make that clear and to remove the
confusion.

I believe the IESG does have a ticket open with the tools team to
address this, and it'll eventually pop out and get changed.

Barry

---

From: Loa Andersson <[email-masked]>
Date: Thu, 09 Oct 2014 09:26:31 +0200

Barry,

> address this, and it'll eventually pop out and get changed.

Fair enough - I guess that we have enough knobs to turn to handle this.
The back ground is that there is something in the Shepherds Writeup that
confused me:

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

It seems that we can "forward" documents to the IESG that is not ready
(I don't claim to understand why this should be done) such a document
could have the wg consensus field set to "no".

But I will not push this, I think I pretty much have what I need in the
tracker, with the exception the the initial loop should be removed.

/Loa

--

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 9 Oct 2014 08:57:39 +0100

Yeah, I've often wondered about that text...

> for publication, please explain why the document is being forwarded to

I've always assumed it means "If you are forwarding this to the IESG without it
being ready for publication, you have a lot of explaining to do."

Adrian

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 9 Oct 2014 09:12:48 -0500

> being ready for publication, you have a lot of explaining to do."
I'll confess to being equally mystified.

It made sense to me to request publication for a working group document
that is being - maybe not ¨abandoned¨, but we've recently seen publication
requested for a discussion draft that made people think, is no longer being
maintained, and the working group wants to preserve it in its current state
- like that.

And if it was a working group document that doesn't match what the working
group now thinks, it would make sense to publish it in the Independent
stream, but I guess it could make sense to publish some of these as an
¨IETF consensus = no¨ RFC.

But I'm still not getting ¨please publish this, but it's not ready for
publication¨!

Spencer

---

From: Ralph Droms <[email-masked]>
Date: Thu, 9 Oct 2014 10:17:19 -0400

> being ready for publication, you have a lot of explaining to do."

Perhaps it means "The WG thinks the doc is ready for publication, but I (as doc shpeherd) have the following reservations."  ???

...which, of course, begs the question of why that doc shepherd was selected.

- Ralph

> It made sense to me to request publication for a working group document that is being - maybe not ¨abandoned¨, but we've recently seen publication requested for a discussion draft that made people think, is no longer being maintained, and the working group wants to preserve it in its current state - like that. 
> 
> And if it was a working group document that doesn't match what the working group now thinks, it would make sense to publish it in the Independent stream, but I guess it could make sense to publish some of these as an ¨IETF consensus = no¨ RFC.
> 
> But I'm still not getting ¨please publish this, but it's not ready for publication¨!
> 
> Spencer

---

From: S Moonesamy <[email-masked]>
Date: Thu, 09 Oct 2014 08:31:33 -0700

Hi George,

[Cc trimmed]

At 10:09 07-10-2014, GTW wrote:
>I wonder if "procedures" sort of documents require/deserve the same 
>sort of consensus as "technical specification" sort of 
>documents.  This is interesting to me as there is a global standards 
>policy debate whether "governance" sort of documents should/need the 
>same sort of consensus as "technical specification" 
>standards.  There is a contention that "governance" sort of 
>documents need not be consensus sort of documents.

Process documents are usually published as BCPs.  They gets the same 
consensus treatment as other Standards Track documents.  It would be 
a bit daring of the IESG to argue that these sorts of documents do 
not need consensus.

I came across the following ( http://www.ietf.org/iesg/ ):

   "It administers the process according to the rules and procedures that
     have been ratified by the ISOC trustees"

In my opinion the above is incorrect.  The reference to RFC 2727 in 
the second paragraph (see web page) is also incorrect.

Regards,
S. Moonesamy

---

From: <[email-masked]>
Date: Thu, 9 Oct 2014 16:44:22 +0000

RFC7258 was published as BCP, and manifestly dudn't get the same standards track procrss -fast tracked.
Not even from a wg...

I'm not sure it got consensus, either.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf <[email-masked]> on behalf of S Moonesamy <[email-masked]>
Sent: Friday, 10 October 2014 2:31:33 AM
To: GTW
Cc: [email-masked]
Subject: Re: 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)

Hi George,

[Cc trimmed]

Regards,
S. Moonesamy

---

From: joel jaeggli <[email-masked]>
Date: Mon, 13 Oct 2014 23:15:30 -0700

> ...which, of course, begs the question of why that doc shepherd was selected.

their candor?