Subject: [Detnet] Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT)

From: Alissa Cooper <[email-masked]>
Date: Thu, 25 Oct 2018 02:36:09 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-detnet-use-cases-19: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-detnet-use-cases/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This document has useful content but I'm not convinced of its archival value.
Consistent with the IESG statement on supporting documents
<https://www.ietf.org/blog/support-documents-ietf-working-groups/?primary_topic=7&>,
I am abstaining. Notably, the detnet charter states:

"WG sustaining/informational documents may include:

These documents may not necessarily be published, but may be
maintained in a draft form or on a collaborative Working Group wiki
to support the efforts of the Working Group and help new comers:

Problem statement and (constrained) deployment environments
User-driven use cases"

So I would not have expected this document to be published as an RFC. I also
could not find any other WG documents referencing this normatively.

There are a few places in the document that are particularly problematic for an
archival document:

4.2.1

"There are many field protocols used today; some are standards-based
   and others are proprietary (see standards [lontalk], [modbus],
   [profibus] and [flnet])."

I would suggest s/today/at the time of this writing/

5.1.2

"Note: Current WG discussion indicates that some peer-to-peer
   communication must be assumed, i.e. the PCE may communicate only
   indirectly with any given device, enabling hierarchical configuration
   of the system."

This seems like it could be rendered out of date. I would suggest deleting
"Current WG discussion indicates that."

12.4

"Current WG consensus is that this item won't be
   directly supported by the DetNet architecture, for example because it
   implies guarantee of in-order delivery of packets which conflicts
   with the core goal of achieving the lowest possible latency."

Same comment as above. I would suggest deleting "Current WG consensus is that."

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 25 Oct 2018 16:06:38 +0000

Hi Alissa,

Much thanks for your careful review. I wanted to address one item, I'll let the authors respond on the others.

While I understand your comment is non-blocking on the document, I wanted to understand your comment that you are abstaining to be "consistent" with the IESG statement on support documents. The IESG statement (to me) was not blocking the publication of support documents. To me, it was addressing the concern on support documents holding up the commencement of solution work.

Here's why I supported this document for publication:

- Based on the working group and Chairs agreement to publish. The charter does not prevent publication. This charter text was carefully considered when the group was chartered as it was felt by the IESG at that time that it was not for the IESG to prevent publication of a support document.
- The document shepherd writeup says "This document provides context for the DetNet WG and has guided the development of other WG documents." Not sure on your comment justifying not-to-publish as the document is not normatively referenced, the document is informatively referenced (typical as it is an informational document) by other documents.
-  Per the IESG statement, this document has not prevented the commencement of solution work. Conversely, it has greatly helped to scope the solution work.
- Most important for this document are the non-procedural aspects supporting publication. As this work is closely aligned with IEEE's TSN work, having an RFC shows the consensus of the working group. For other SDOs, a wiki does not have "consensus". As the author list indicates, the document had input from a diverse set of the community. As Spencer says, it provides context for operators and vendors not participating in IETF. And as the Genart reviewer says "really cool document to read". For many operators/users, informational documents are a means to participate without showing preference for one solution or another.

Perhaps, I or the document shepherd should have included this justification in our writeups so as to have gained your support for publishing the document. We can talk more among the IESG on this so as not to confuse the community on what the IESG statement says when considering future requests for publishing informational documents.

Thanks again everyone for your careful reviews!
Deborah

-----Original Message-----
From: iesg <[email-masked]> On Behalf Of Alissa Cooper
Sent: Thursday, October 25, 2018 5:36 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Please refer to https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwICaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=-ufLqOntt6LejLMTbN3QpjYHxsObxmPKRhiF3FnmoI0&m=Kk4Tim7T1xoM_57ir44IuIiwjdLJfYagnDbl49ar0Uk&s=aGn8gh-OaaaNpVH4q-AwBc69kz1YuKm6pkljH-KsoO8&e=
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Ddetnet-2Duse-2Dcases_&d=DwICaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=-ufLqOntt6LejLMTbN3QpjYHxsObxmPKRhiF3FnmoI0&m=Kk4Tim7T1xoM_57ir44IuIiwjdLJfYagnDbl49ar0Uk&s=XB07PuCt9z-okatqF0o7VTGRXtTaIcbj6NTiPhfaarw&e=

This document has useful content but I'm not convinced of its archival value.
Consistent with the IESG statement on supporting documents <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_blog_support-2Ddocuments-2Dietf-2Dworking-2Dgroups_-3Fprimary-5Ftopic-3D7-26&d=DwICaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=-ufLqOntt6LejLMTbN3QpjYHxsObxmPKRhiF3FnmoI0&m=Kk4Tim7T1xoM_57ir44IuIiwjdLJfYagnDbl49ar0Uk&s=ChURBbS2T-QEMj2Es8v2Ky1c2niPWTxfDgA4yMO8Uug&e=>,
I am abstaining. Notably, the detnet charter states:

These documents may not necessarily be published, but may be maintained in a draft form or on a collaborative Working Group wiki to support the efforts of the Working Group and help new comers:

Problem statement and (constrained) deployment environments User-driven use cases"

So I would not have expected this document to be published as an RFC. I also could not find any other WG documents referencing this normatively.

There are a few places in the document that are particularly problematic for an archival document:

4.2.1

5.1.2

This seems like it could be rendered out of date. I would suggest deleting "Current WG discussion indicates that."

12.4

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Thu, 25 Oct 2018 18:12:46 +0000

Hi Alissa,
Regarding the wording that you point out is "problematic for an archival document" I completely agree, I just missed those, and they should certainly be changed as you suggest. 
Thanks,
Ethan (as Editor of DetNet Use Cases draft)

-----Original Message-----
From: BRUNGARD, DEBORAH A <[email-masked]> 
Sent: Thursday, October 25, 2018 9:07 AM
To: Alissa Cooper <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT)

Hi Alissa,

-----Original Message-----
From: iesg <[email-masked]> On Behalf Of Alissa Cooper
Sent: Thursday, October 25, 2018 5:36 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT)

4.2.1

5.1.2

12.4

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Fri, 26 Oct 2018 16:59:57 +0000

Hi Alissa,
One reason we planned to publish the Use Cases draft is that the WG decided early on not to have a "Requirements" draft, because we weren't sure what kind of solution would be reasonable to provide, and we didn't want to have to eliminate an otherwise good solution because it missed one or more "requirements". So the Use Cases draft has been used for that purpose, and is referenced informationally in other WG drafts wherever "requirements" would otherwise be referenced. The point is that the Use Cases draft started out with some things that our best proposed solution could not address, so we removed them from the "requirements" (i.e. the expectations of the use cases) rather than scrap the solution. 
Ethan (as Use Cases draft editor).

-----Original Message-----
From: Alissa Cooper <[email-masked]> 
Sent: Thursday, October 25, 2018 2:36 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; Lou Berger <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT)

This document has useful content but I'm not convinced of its archival value.
Consistent with the IESG statement on supporting documents <https://www.ietf.org/blog/support-documents-ietf-working-groups/?primary_topic=7&>,
I am abstaining. Notably, the detnet charter states:

4.2.1

5.1.2

12.4

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 26 Oct 2018 18:38:47 +0100

> I am abstaining. Notably, the detnet charter states:

I wonder how aligned with the rest of the IETF this policy is when 
applied to use cases documents?

Pulling together use case information is often a method of focussing the 
design requirements by casing them into something solid that those 
working on the problem can use to build a mental model of how the design 
maps to reality. Some people need these models to visualise what they 
are attempting to design. Some reader need them to solidity an abstract 
protocol into reality to better understand the invariants, the 
constraints and boundaries and how the components of the solution fit 
together. I for one find these sorts of text helpful in better 
understanding the problem.

The "reward" to the authors for the non-trivial work for pulling this 
together is a published RFC. Maybe some may consider that to be vanity, 
but the fact is that people are more inclined to so work if they 
perceive a tangible reward for their work, and an RFC is one of the few 
"rewards" the IETF has to offer.

Publication of such text as an RFC thus serves two purposes: a starting 
point for someone to understand the problem that the designers were 
trying to solve as seen at the time that they worked on it, and as an 
acknowledgement by the IETF that the work of defining the scenarios of 
use was done by the authors.

I therefore think that dismissing such work in this way is 
counterproductive and demotivating, quite the opposite of what the IESG 
should be striving to achieve.

Best regards

Stewart

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Fri, 26 Oct 2018 17:46:57 +0000

Hi Stewart,

I agree – I sent an earlier reply (on the list) to Alissa explaining why we went for publication. As this is a document which will be looked at by IEEE and others, it is of value to have it published vs. a wiki. And publication indicates consensus of the group.

I will be following up with the IESG on both the interpretation of the IESG statement for publishing informationals and use of Abstains so we can be consistent for the community.

Thanks,
Deborah

From: detnet <[email-masked]> On Behalf Of Stewart Bryant
Sent: Friday, October 26, 2018 1:39 PM
To: Alissa Cooper <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Detnet] Alissa Cooper's Abstain on draft-ietf-detnet-use-cases-19: (with COMMENT)

<https://www.ietf.org/blog/support-documents-ietf-working-groups/?primary_topic=7&><https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_blog_support-2Ddocuments-2Dietf-2Dworking-2Dgroups_-3Fprimary-5Ftopic-3D7-26&d=DwMCaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=lchXVchqutYIXZlb8_XEWZ7USiRrQ2VJVrh0WmBqWP4&s=aXPoSaTDFB9Gn1bZTQF-0XPrx5bjeML4lxq8PNz5aqo&e=>,

I wonder how aligned with the rest of the IETF this policy is when applied to use cases documents?

Pulling together use case information is often a method of focussing the design requirements by casing them into something solid that those working on the problem can use to build a mental model of how the design maps to reality. Some people need these models to visualise what they are attempting to design. Some reader need them to solidity an abstract protocol into reality to better understand the invariants, the constraints and boundaries and how the components of the solution fit together. I for one find these sorts of text helpful in better understanding the problem.

The "reward" to the authors for the non-trivial work for pulling this together is a published RFC. Maybe some may consider that to be vanity, but the fact is that people are more inclined to so work if they perceive a tangible reward for their work, and an RFC is one of the few "rewards" the IETF has to offer.

Publication of such text as an RFC thus serves two purposes: a starting point for someone to understand the problem that the designers were trying to solve as seen at the time that they worked on it, and as an acknowledgement by the IETF that the work of defining the scenarios of use was done by the authors.

I therefore think that dismissing such work in this way is counterproductive and demotivating, quite the opposite of what the IESG should be striving to achieve.

Best regards

Stewart

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 26 Oct 2018 11:12:56 -0700

On Fri, Oct 26, 2018 at 10:38 AM Stewart Bryant <[email-masked]>
wrote:

> Consistent with the IESG statement on supporting documents<https://www.ietf.org/blog/support-documents-ietf-working-groups/?primary_topic=7&> <https://www.ietf.org/blog/support-documents-ietf-working-groups/?primary_topic=7&>,

I didn't abstain because I don't care that much, but I am aligned with that
policy (though it predates me, so I wasn't part of crafting it).

> design requirements by casing them into something solid that those working
> on the problem can use to build a mental model of how the design maps to
> reality. Some people need these models to visualise what they are
> attempting to design. Some reader need them to solidity an abstract
> protocol into reality to better understand the invariants, the constraints
> and boundaries and how the components of the solution fit together. I for
> one find these sorts of text helpful in better understanding the problem.
>
> together is a published RFC. Maybe some may consider that to be vanity, but
> the fact is that people are more inclined to so work if they perceive a
> tangible reward for their work, and an RFC is one of the few "rewards" the
> IETF has to offer.
>
> point for someone to understand the problem that the designers were trying
> to solve as seen at the time that they worked on it, and as an
> acknowledgement by the IETF that the work of defining the scenarios of use
> was done by the authors.
>

> should be striving to achieve.

I'm perhaps less sanguine than you about the value of use case documents,
but the IESG statement doesn't say that they aren't valuable, what it says
is that they don't always have high *archival* value (and I note that the
second value proposition you mention isn't about the value of the document
being published at all, but rather about rewarding the authors).

That's speaking in general, of course. I *did* review this specific
document and in my opinion the level of detail and domain specificity in it
does not have very high archival value. So, while I did not abstain, were I
making the choice, i would not publish this as an RFC.

-Ekr

Best regards

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 26 Oct 2018 19:27:33 +0100

On 26/10/2018 19:12, Eric Rescorla wrote:
>
>
> On Fri, Oct 26, 2018 at 10:38 AM Stewart Bryant 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>>     <https://www.ietf.org/blog/support-documents-ietf-working-groups/?primary_topic=7&>
> I didn't abstain because I don't care that much, but I am aligned with 
> that policy (though it predates me, so I wasn't part of crafting it).

Note that I was wondering about the IETF as a whole rather than their 
current leadership or the leadership that took the decision to publish 
that IESG statement.

>
>
>     Pulling together use case information is often a method of
>     focussing the design requirements by casing them into something
>     solid that those working on the problem can use to build a mental
>     model of how the design maps to reality. Some people need these
>     models to visualise what they are attempting to design. Some
>     reader need them to solidity an abstract protocol into reality to
>     better understand the invariants, the constraints and boundaries
>     and how the components of the solution fit together. I for one
>     find these sorts of text helpful in better understanding the problem.
>
>     The "reward" to the authors for the non-trivial work for pulling
>     this together is a published RFC. Maybe some may consider that to
>     be vanity, but the fact is that people are more inclined to so
>     work if they perceive a tangible reward for their work, and an RFC
>     is one of the few "rewards" the IETF has to offer.
>
>     Publication of such text as an RFC thus serves two purposes: a
>     starting point for someone to understand the problem that the
>     designers were trying to solve as seen at the time that they
>     worked on it, and as an acknowledgement by the IETF that the work
>     of defining the scenarios of use was done by the authors.
>
>
>     counterproductive and demotivating, quite the opposite of what the
>     IESG should be striving to achieve.
>
>
> I'm perhaps less sanguine than you about the value of use case 
> documents, but the IESG statement doesn't say that they aren't 
> valuable, what it says is that they don't always have high *archival* 
> value (and I note that the second value proposition you mention isn't 
> about the value of the document being published at all, but rather 
> about rewarding the authors).

Quite, but rewarding authors and contributors for their work is 
fundamental to motivating them. The IETF I see these days seems less 
motivated that it was in previous days, and motivation is a key part of 
the IESG role.

- Stewart

> document and in my opinion the level of detail and domain specificity 
> in it does not have very high archival value. So, while I did not 
> abstain, were I making the choice, i would not publish this as an RFC.
>
> -Ekr
>
>     Best regards
>
>     Stewart
>
>

---

From: Alissa Cooper <[email-masked]>
Date: Sat, 27 Oct 2018 10:30:06 +0200

Hi Deborah,

> On Oct 25, 2018, at 6:06 PM, BRUNGARD, DEBORAH A <[email-masked]> wrote:
> 
> Hi Alissa,
> 
> While I understand your comment is non-blocking on the document, I wanted to understand your comment that you are abstaining to be "consistent" with the IESG statement on support documents. The IESG statement (to me) was not blocking the publication of support documents.

Perhaps this was not clear from the ballot, but I didn’t abstain because I thought it was what the IESG statement requires. What I said was that my ballot position is consistent with the statement. Specifically, it is consistent with this text:

"While writing down such things as requirements and use cases help to get a common understanding (and often common language) between participants in the working group, support documentation doesn’t always have a high archival value. Under most circumstances, the IESG encourages the community to consider alternate mechanisms for publishing this content, such as on a working group wiki, in an informational appendix of a solution document, or simply as an expired draft.”

From what I could gather this document was very valuable to the WG, but the incremental value of getting IETF consensus, running it through the publication process, and archiving it as an RFC wasn’t obvious. An internet draft seemed just as good, especially given those couple of references to “current WG discussion” and “current WG consensus."

> To me, it was addressing the concern on support documents holding up the commencement of solution work.
> 
> - Based on the working group and Chairs agreement to publish. The charter does not prevent publication.

Yep, the point of the abstain ballot is explicitly not to prevent publication.

> This charter text was carefully considered when the group was chartered as it was felt by the IESG at that time that it was not for the IESG to prevent publication of a support document.

An internet-draft can be referenced this way.

> - Most important for this document are the non-procedural aspects supporting publication. As this work is closely aligned with IEEE's TSN work, having an RFC shows the consensus of the working group.

Having an RFC shows the consensus of the IETF, not the WG.

> For other SDOs, a wiki does not have "consensus". As the author list indicates, the document had input from a diverse set of the community. As Spencer says, it provides context for operators and vendors not participating in IETF. And as the Genart reviewer says "really cool document to read". For many operators/users, informational documents are a means to participate without showing preference for one solution or another.
> 

I don’t think the statement is confusing, but I suspect the IESG would be happy to entertain clarifications to it if you have suggestions.

Thanks,
Alissa

---

From: Stewart Bryant <[email-masked]>
Date: Sat, 27 Oct 2018 09:34:55 +0100

> An internet-draft can be referenced this way.

Not is some SDOs.

As I recall the ITU, for example,  will reference RFCs but not IDs.

- Stewart

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sat, 27 Oct 2018 03:52:39 -0500

Hi, Deborah,

On Fri, Oct 26, 2018, 12:47 BRUNGARD, DEBORAH A <[email-masked]> wrote:

> Hi Stewart,
>
>
>
> I agree – I sent an earlier reply (on the list) to Alissa explaining why
> we went for publication. As this is a document which will be looked at by
> IEEE and others, it is of value to have it published vs. a wiki. And
> publication indicates consensus of the group.
>
>
>
> I will be following up with the IESG on both the interpretation of the
> IESG statement for publishing informationals and use of Abstains so we can
> be consistent for the community.
>
Are you thinking following up in Bangkok?

My understanding matches yours - the problem we were solving was when we
chartered a theoretically 18-24 month working group to specify something
developers could implement, and the working group spent 17-23 months on use
cases, problem statements, requirements docs, and architectures, and
developers had nothing.

We also had publication requests for these drafts that had been useful at
the beginning of solutions work, but hadn't been maintained since that
started, so weren't consistent with the standards-track documents they had
supported, being published at the same time.

That was why I thought the IESG came up with the statement on working group
support documents - not to ban classes of (informational) documents, but to
get to standards-track documents faster.

We can talk about what the right thing to do is, but I don't think the IESG
has a common understanding about that today.

Each IESG is special, and this IESG can certainly change the way the
current IESG works (within our BCP framework), but it's likely that this is
a change we should confirm with the community, after we ourselves figure
out this IESG thinks.

Spencer

---

From: Alissa Cooper <[email-masked]>
Date: Sat, 27 Oct 2018 19:53:49 +0200

Hi Stewart,

> On Oct 26, 2018, at 7:38 PM, Stewart Bryant <[email-masked]> wrote:
> 
> 
> 
>> <https://www.ietf.org/blog/support-documents-ietf-working-groups/?primary_topic=7&> <https://www.ietf.org/blog/support-documents-ietf-working-groups/?primary_topic=7&>,

I suppose we would have heard more concerns when we published the statement if people thought it was not aligned.

> The "reward" to the authors for the non-trivial work for pulling this together is a published RFC. Maybe some may consider that to be vanity, but the fact is that people are more inclined to so wor…

I think considering RFCs as rewards to individuals for their work would create some fairly perverse incentives that would not align well with the IETF’s goals of producing output of sound engineering quality. (Not a comment on the quality of this document in particular, but about the general effect.)

> I therefore think that dismissing such work in this way is counterproductive and demotivating, quite the opposite of what the IESG should be striving to achieve.

I could see how this conclusion could follow from your other premises if I were to hold a DISCUSS indefinitely, but I balloted ABSTAIN purposefully because it doesn’t block publication.

Thanks,
Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Sat, 27 Oct 2018 19:56:11 +0200

Hi Spencer,

> On Oct 27, 2018, at 10:52 AM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Deborah,
> 
> On Fri, Oct 26, 2018, 12:47 BRUNGARD, DEBORAH A <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Stewart,
> 
>  
> 
> My understanding matches yours - the problem we were solving was when we chartered a theoretically 18-24 month working group to specify something developers could implement, and the working group spent 17-23 months on use cases, problem statements, requirements docs, and architectures, and developers had nothing. 
> 
> We also had publication requests for these drafts that had been useful at the beginning of solutions work, but hadn't been maintained since that started, so weren't consistent with the standards-track documents they had supported, being published at the same time.
> 
> That was why I thought the IESG came up with the statement on working group support documents - not to ban classes of (informational) documents, but to get to standards-track documents faster.

An ABSTAIN ballot does not ban a document or a class of documents. It is explicitly defined to allow for the publication of the document.

Alissa

> 
> We can talk about what the right thing to do is, but I don't think the IESG has a common understanding about that today.
> 
> Each IESG is special, and this IESG can certainly change the way the current IESG works (within our BCP framework), but it's likely that this is a change we should confirm with the community, after we ourselves figure out this IESG thinks.
> 
> Spencer
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 28 Oct 2018 20:50:49 -0500

Hi, Alissa,

On Sat, Oct 27, 2018, 12:56 Alissa Cooper <[email-masked]> wrote:

> That was why I thought the IESG came up with the statement on working
> group support documents - not to ban classes of (informational) documents,
> but to get to standards-track documents faster.
>
>
> An ABSTAIN ballot does not ban a document or a class of documents. It is
> explicitly defined to allow for the publication of the document.
>

Understood.

I've also gotten mail this past summer from one of our most experienced TSV
chairs, who did not understand the meaning of an avalanche of ABSTAINs in
the way that you and I understand it.

He may not be the only person in the IETF to have missed that subtle
distinction.

Without going back for a quote, he was basically saying he thought more
tgan one ABSTAIN was a pretty strong signal from the IESG that a document
should not be published.

Travel safely.

Spencer

Alissa
>
>
> We can talk about what the right thing to do is, but I don't think the
> IESG has a common understanding about that today.
>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 29 Oct 2018 17:41:58 +0000

On 29/10/2018 01:50, Spencer Dawkins at IETF wrote:
> Without going back for a quote, he was basically saying he thought 
> more tgan one ABSTAIN was a pretty strong signal from the IESG that a 
> document should not be published.

That was always my understanding when I was on the IESG.

- Stewart

---

From: Adam Roach <[email-masked]>
Date: Mon, 29 Oct 2018 14:02:08 -0500

> That was always my understanding when I was on the IESG. 

It is mine as well, but it only serves as advice. For informational 
documents, it has no process significance, since it does not preclude 
publication. Basically, if there are a large number of ABSTAINs, it 
means that the working group is publishing the document over the 
objections of the IESG (unless it uses this advice as an opportunity to 
reconsider the request for publication). It is my understanding that the 
process is set up exactly to allow this kind of thing to happen.

It's certainly fair game to discuss whether the system *should* be set 
up this way, but I can't imagine any realistic changes other than ones 
that would actually block publication under such circumstances -- and I 
doubt that's where the community wants to take things.

In this particular case, it appears as if you're trying to get an IESG 
member to say that she supports publication of a document when that is 
not actually true. Given that there is no practical difference in 
getting the document published, this pressure seems kind of problematic.

/a

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 29 Oct 2018 16:35:43 -0500

Hi, Adam,

> getting the document published, this pressure seems kind of problematic.

Pronouns are confusing, but since Stewart was replying to me, I'm not sure
who "you" is.

But just in case it's me, we're still talking about an Informational
document that requires one Yes and no Discusses to publish, no? And our BCP
says that Informational documents do not reflect IETF consensus or
recommendation, in https://tools.ietf.org/html/rfc2026#section-4.2.2.

So, I know why an AD would ballot DIscuss on an Informational document, but
I'm less clear about why ADs ballot Abstains.

Of course, we've had conversations about this at least since Stewart was on
the IESG. So I'll stop typing, and go back to packing.

Travel safely, all, of course.

Spencer

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 29 Oct 2018 22:23:05 -0400

Hi Spencer,

> On Oct 29, 2018, at 5:35 PM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Adam, 
> 
> On Mon, Oct 29, 2018 at 2:02 PM Adam Roach <[email-masked] <mailto:[email-masked]>> wrote:
> Pronouns are confusing, but since Stewart was replying to me, I'm not sure who "you" is. 
> 
> But just in case it's me, we're still talking about an Informational document that requires one Yes and no Discusses to publish, no? And our BCP says that Informational documents do not reflect IETF consensus or recommendation, in https://tools.ietf.org/html/rfc2026#section-4.2.2 <https://tools.ietf.org/html/rfc2026#section-4.2.2>.  
> 
> So, I know why an AD would ballot DIscuss on an Informational document, but I'm less clear about why ADs ballot Abstains. 

I usually ballot Abstain on an Informational document if I personally do not believe that the document has any archival value. I feel that balloting an Abstain lets me stay true to my conscience, while respecting the consensus of the working group that sent the document over. 

Stewart,
  Are you objecting to anything specific in the text of the IESG statement itself? If so, I would greatly appreciate it if you can explain your objection(s). 

Thanks
Suresh

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 31 Oct 2018 09:14:51 -0400

> On Oct 29, 2018, at 1:41 PM, Stewart Bryant <[email-masked]> wrote:
> 
> 
> 
>> Without going back for a quote, he was basically saying he thought more tgan one ABSTAIN was a pretty strong signal from the IESG that a document should not be published.
> 

This does not match what is described at <https://www.ietf.org/standards/process/iesg-ballots/>, which is the guideline I follow. Informational documents require one Yes ballot with no Discuss ballots. If we wanted to block publication, someone would need to ballot Discuss, or we would all need to ballot something besides Yes, including the sponsoring AD.

When I filed my ballot, this document already had one Yes and five No Objection ballot positions, so the implication that my Abstain was meant to trigger some set of ballots that would block this document seems misplaced.

Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 31 Oct 2018 09:17:27 -0400

> So, I know why an AD would ballot DIscuss on an Informational document, but I'm less clear about why ADs ballot Abstains. 

I ballot Abstain when my position on the document is consistent with what is described at <https://www.ietf.org/standards/process/iesg-ballots/ <https://www.ietf.org/standards/process/iesg-ballots/>>, namely "I oppose this document but understand that others differ and am not going to stand in the way of the others.”

Alissa

> 
> Of course, we've had conversations about this at least since Stewart was on the IESG. So I'll stop typing, and go back to packing.
>