Subject: Re: [bess] Introducing a one-implementation requirement before WG last calls

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 24 Nov 2015 16:07:26 -0000

Hi Thomas,

It's really hard to enter this discussion with any context.

Could you post the minutes from the meeting and maybe summarise the points in
favour of this approach?
(Of course, I can listen to the audio when I have some spare time.)

Thanks,
Adrian

---

From: Benson Schliesser <[email-masked]>
Date: Tue, 24 Nov 2015 12:45:51 -0500

Building on Adrian's question, I'd be interested to learn more about why
the WG considers 1 implementation as a reasonable threshold. I.e. as
opposed to something like 2 or more, demonstrated interop/compliance, or
something along those lines.

Personally, I think the implementation requirement is a good idea in
principle. But the threshold doesn't seem to be adequate if the goal is an
interoperable specification. A document with only 1 implementation is more
akin to technical documentation rather than an interoperable specification.
But maybe there is a rationale that I'm failing to consider..?

Thanks,
-Benson

On Tue, Nov 24, 2015 at 11:07 AM, Adrian Farrel <[email-masked]> wrote:

> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 25 Nov 2015 00:16:59 +0100

Hi Adrian,

indeed, minutes should have been available sooner. situation has been 
corrected.

The basic motivation for this is simply to avoid (over)loading the iesg 
with documents that have no (and could possibly never have an) 
implementation. Or, at least, if every spec gets implemented, it is to 
prioritize them.

The discussion happened at the beginning of the meeting. It was on one 
of the slides I have presented as part of the WG status.

-m

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 24 Nov 2015 19:11:14 -0500

Without wanting to be pedantic, I would have expected to see discusison 
of this on the list, and determination that the list agreed with it. 
Discussion at the meeting is informative, but is not the basis for a WG 
decision.

I am also slightly concerned that the working group is creating a 
procedural bar (one that does seem reasonable to me) without buyin from 
the larger community.

Yours,
Joel

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 25 Nov 2015 00:13:54 -0000

Yeah, thanks Martin.

The slide has...

==Raising the bar?==
• Some documents are being pushed to IESG but
without any implementation (plan) to support
them
• We are thinking of “requiring” that at least one
implementation exists before handing the
document to IESG
• Thoughts?

The first bullet allows for a plan to implement, the second requires
implementation. The use of quotes in the second bullet suggests that you may be
considering that the requirement may be flexible. Obviously we have an opening
for discussion, but I wonder how you would decide when to be flexible.

The minutes are a good indication of the level of support you received in the
room, but not a deep discussion :-) There seems to be some confusion in the
discussion between expediting (or unblocking) I-Ds that have an implementation,
and delaying (or blocking) I-Ds that don't have implementations. While, in a
world of limited resources, the two things are related, ideally we are not
significantly gating the progress of one I-D because we are busy processing
another.

Now, I really, really support your motivation, viz. to reduce the pointless,
unreviewed, unnecessary, or substandard drafts being sent for publication. The
question is how to achieve that.

Adrian (still thinking about this)

> -----Original Message-----
> From: BESS [mailto:[email-masked]] On Behalf Of Martin Vigoureux
> Sent: 24 November 2015 23:17
> To: [email-masked]
> Subject: Re: [bess] Introducing a one-implementation requirement before WG
> last calls
> 
> Hi Adrian,
>

---

From: Benson Schliesser <[email-masked]>
Date: Tue, 24 Nov 2015 19:19:47 -0500

I think this may be a useful "procedural bar" and if so then I'd like to
see it implemented in other WGs, too... And, to some extent, it may be
within the prerogative of the WG chairs. But I am also surprised by the
lack of discussion. And I don't see any substantial conversation documented
in the proceedings of the last meeting. I'd like to understand why this
threshold makes sense to the WG, assuming it does...
-Benson

On Tue, Nov 24, 2015 at 7:11 PM, Joel M. Halpern <[email-masked]>
wrote:

> Without wanting to be pedantic, I would have expected to see discusison of
> this on the list, and determination that the list agreed with it.
> procedural bar (one that does seem reasonable to me) without buyin from the
> larger community.
>
> Yours,
> Joel
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 25 Nov 2015 00:20:32 -0000

Joel,

> procedural bar (one that does seem reasonable to me) without buyin from

To be clear, the WG is allowed to make a decision to do this.
http://datatracker.ietf.org/doc/rfc4794/

Adrian

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 25 Nov 2015 14:15:51 +0100

Joel, Benson,

hello.

I agree that there has not been a lengthy discussion during the session 
but some people reacted to the proposal and expressed their support.

Joel, on the specific point that a discussion in a meeting is 
informative, I fully agree, and the point of our e-mail is to continue 
the discussion on the list. We explicitly say that this is a proposal 
and that we are open to comments.

Thanks
-m

Le 25/11/2015 01:19, Benson Schliesser a écrit :
> lack of discussion. And I don't see any substantial conversation
> documented in the proceedings of the last meeting. I'd like to
> understand why this threshold makes sense to the WG, assuming it does...
> -Benson
>
>
> On Tue, Nov 24, 2015 at 7:11 PM, Joel M. Halpern <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Without wanting to be pedantic, I would have expected to see
>     discusison of this on the list, and determination that the list
>     agreed with it. Discussion at the meeting is informative, but is not
>     the basis for a WG decision.
>
>     procedural bar (one that does seem reasonable to me) without buyin
>     from the larger community.
>
>     Yours,
>     Joel
>
>             Could you post the minutes from the meeting and maybe
>             summarise the
>             points in
>             favour of this approach?
>             [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 25 Nov 2015 23:19:24 +0100

Adrian,

Thanks.
Please see my reactions in-line.

-m

Le 25/11/2015 01:13, Adrian Farrel a écrit :
> Yeah, thanks Martin.
>
> The slide has...
>
> ==Raising the bar?==
> . Some documents are being pushed to IESG but
> . We are thinking of "requiring" that at least one
> . Thoughts?

Good question :-) Indeed, the intent is to not be blindly strict. But 
defining the margins of flexibility is the tricky part then.
I am pretty sure that this will be on a case by case with the default 
being the 1 implem requirement.
I'll take an example: draft-ietf-bess-pta-flags
It defines 2 registries as well as a new BGP Extended Community together 
with the associated processing procedures. The latter is definitely 
subject to being implemented and as such subject to the requirement we 
are discussing.
However, what this document really does is to define a mechanism in 
support of specific needs.
So I think that this could be a case where we could skip the 1 implem 
requirement (but apply it to the specs that use pta-flags).

> significantly gating the progress of one I-D because we are busy processing
I'd say there are different points of view rather than confusion. In a 
situation where implementations are not considered mandatory, having one 
might indeed be a criteria for moving faster through the process but I 
think this is one amongst several possible other criterion.

> question is how to achieve that.
The primary intent here is to send to IESG only documents that have an 
implementation. It makes their case stronger, is a contribution to 
reducing the load on IESG's shoulders, and also it anyway makes little 
sense to push through the standardization process an implementable 
specification but for which no implementation exists.
The moment to submit to iesg is definitely a good time (and the last 
possible from a chair's perspective) to think about that.

Now, your two sentences above open the door to a broader set of 
potential actions that could be taken to reach the objective, actions 
which are relevant during the I-D life cycle within the WG. But I guess 
this is a broader discussion.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 25 Nov 2015 17:57:25 -0500

Based on my experience on both the vendor and operator side, I see some
practical problems with this approach:

- There are some (many?) operators that won’t put drafts into an RFP, only
RFCs.

- There are some (many?) vendors that won’t implement a draft or RFC, no
matter how good the quality, unless they have a customer that wants the
feature. That could be an existing customer that needs the feature
operationally (which could lead to early implementation), or it could be a
prospective customer with an RFP.

- Vendors, of course, prioritize their implementation plans, and they
usually put RFCs ahead of drafts, since drafts could change before
publication, requiring a change in the implementation.

For all these reasons, unless there’s an existing customer that needs a
draft’s features to fix an operational problem, it’s less common for
vendors to implement drafts than RFCs.

A better approach might be to do an implementation poll just prior to WG LC
(including implementation plans). The WG can then take the results of the
poll into consideration during WG LC to see if there’s a consensus to send
it to the IESG. There could be a draft that everyone agrees is really
important to get published, but for whatever reason hasn’t yet been
implemented.

Cheers,
Andy

On Wed, Nov 25, 2015 at 5:19 PM, Martin Vigoureux <
[email-masked]> wrote:

> with the associated processing procedures. The latter is definitely subject
> to being implemented and as such subject to the requirement we are
> discussing.
> implementation. It makes their case stronger, is a contribution to reducing
> the load on IESG's shoulders, and also it anyway makes little sense to push
> through the standardization process an implementable specification but for
> which no implementation exists.
> Now, your two sentences above open the door to a broader set of potential
> actions that could be taken to reach the objective, actions which are
> relevant during the I-D life cycle within the WG. But I guess this is a
> broader discussion.
>
>
>
>>>> Could you post the minutes from the meeting and maybe summarise the
>>>> points
>>>>
>>> in
>>>
>>>> favour of this approach?

---

From: Loa Andersson <[email-masked]>
Date: Thu, 26 Nov 2015 13:35:59 +0800

Folks,

I'm very much om the same page as Andy, having knowledge of
implementations is a good thing. A "requirement" that we have an
implementation before requesting that the document is published as
an RFC is in most cases also good.

The tricky part is when to be flexible. I've asked for implementations
for every intended PS we requested publication for. I have more than
once been in a situation there operators tell me that the have the
draft deployed, but where the vendor does not respond to questions
about implementations.

I've also seen where two vendors asked for early allocation because
they are implementing and doing interop tests. Again one or both
vendors does not respond to the implementation poll.

One can speculate about the reasons for this, but it seems that often
the decision whether or not to disclose an implementation is outside
the mandate for people participating in immediate IETF process.

In short, with a sufficient level of flexibility I support this. It
would be good if we can have some type of report when some experience
of the required implementation is at hand.

/Loa

On 2015-11-26 06:57, Andrew G. Malis wrote:
> - There are some (many?) operators that won’t put drafts into an RFP,
> only RFCs.
>
> operationally (which could lead to early implementation), or it could be
> a prospective customer with an RFP.
>
> A better approach might be to do an implementation poll just prior to WG
> LC (including implementation plans). The WG can then take the results of
> the poll into consideration during WG LC to see if there’s a consensus
> to send it to the IESG. There could be a draft that everyone agrees is
> really important to get published, but for whatever reason hasn’t yet
> been implemented.
>
> Cheers,
> Andy
>
>
> On Wed, Nov 25, 2015 at 5:19 PM, Martin Vigoureux
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Adrian,
>
>     Thanks.
>     Good question :-) Indeed, the intent is to not be blindly strict.
>     But defining the margins of flexibility is the tricky part then.
>     I am pretty sure that this will be on a case by case with the
>     default being the 1 implem requirement.
>     It defines 2 registries as well as a new BGP Extended Community
>     together with the associated processing procedures. The latter is
>     definitely subject to being implemented and as such subject to the
>     requirement we are discussing.
>     So I think that this could be a case where we could skip the 1
>     implem requirement (but apply it to the specs that use pta-flags).
>
>     I'd say there are different points of view rather than confusion. In
>     a situation where implementations are not considered mandatory,
>     having one might indeed be a criteria for moving faster through the
>     process but I think this is one amongst several possible other
>     criterion.
>
>     The primary intent here is to send to IESG only documents that have
>     an implementation. It makes their case stronger, is a contribution
>     to reducing the load on IESG's shoulders, and also it anyway makes
>     little sense to push through the standardization process an
>     implementable specification but for which no implementation exists.
>     potential actions that could be taken to reach the objective,
>     actions which are relevant during the I-D life cycle within the WG.
>     But I guess this is a broader discussion.
>
>
>
>             From: BESS [mailto:[email-masked]
>             <mailto:[email-masked]>] On Behalf Of Martin Vigoureux
>             To: [email-masked] <mailto:[email-masked]>
>                 summarise the points

---

From: Martin Vigoureux <[email-masked]>
Date: Thu, 26 Nov 2015 10:22:51 +0100

Andy, Loa,

thanks for sharing your views.
If there are valid reasons for pushing to iesg a non-implemented 
specification, we'd be ready to consider them.
It would simply not be the default way of doing, nor the norm. If it 
was, if every draft was "really important", then none would really be, 
in fact.

Also, Loa, I believe that the situations you describe would be
solved thanks to the introduction of this requirement.

-m

---

From: <[email-masked]>
Date: Thu, 26 Nov 2015 14:34:48 +0100

Hi Andrew,

> - There are some (many?) operators that won’t put drafts into an RFP, 

My take on that is that if a known-stable specs is considered as 
something important to have, operators will put it in their RFPs (maybe 
not as a strict compliance requirement, but certainly as something 
having significant visibility). If they don't, it means that they simply 
aren't looking at new work and noy unlikely to ask anything that vendor 
arent' already implementing or seriously planning to implement.

> - There are some (many?) vendors that won’t implement a draft or RFC, 
> no matter how good the quality, unless they have a customer that wants 
> the feature. That could be an existing customer that needs the feature 
> operationally (which could lead to early implementation), or it could 
> be a prospective customer with an RFP.

This can surely happen on a case by case basis, but in my experience I 
have seen a large number of mature and stable draft having multiple 
implementations before, sometimes long before, having the final 'RFC' 
stamp.   People have learned to get the benefits of, and live with the 
drawbacks of,  early implementations.

Remember we are not talking about gating the progress of specs not 
implemented yet by everyone, but of stable specs that noone has 
implemented yet.

> For all these reasons, unless there’s an existing customer that needs 
> a draft’s features to fix an operational problem, it’s less common for 

With reference to these RFP/RFC considerations, I think we need to focus 
on developing the right tools to:
- keep this idea of 'raising the bar'
- find a way to advertise that a draft is stable enough to be 
implemented and referred to by operators

> A better approach might be to do an implementation poll just prior to 
> WG LC (including implementation plans). The WG can then take the 
> results of the poll into consideration during WG LC to see if there’s 
> a consensus to send it to the IESG. There could be a draft that 
> everyone agrees is really important to get published, but for whatever 
> reason hasn’t yet been implemented.

Not delaying the WG LC  for lack-of-implementation reasons would 
certainly have the merit of allowing the WG to reach consensus on the 
stability of the specs and advertise this fact by other means that "this 
doc goes to IESG now".  The "Waiting for implementation" state 
introduced by IDR (mentioned by John Scudder during BESS meeting) seems 
to be the right tool for the job.

And I agree we should allow chairs to propose skipping the "Waiting for 
implementation" step of a draft not having convincing implementation 
plans, if there is consensus in the WG to do so.

-Thomas

>     However, what this document really does is to define a mechanism
>     in support of specific needs.
>     I'd say there are different points of view rather than confusion.
>     In a situation where implementations are not considered mandatory,
>     having one might indeed be a criteria for moving faster through
>     the process but I think this is one amongst several possible other
>     criterion.
>
>     The primary intent here is to send to IESG only documents that
>     have an implementation. It makes their case stronger, is a
>     contribution to reducing the load on IESG's shoulders, and also it
>     anyway makes little sense to push through the standardization
>     process an implementable specification but for which no
>     implementation exists.
>     The moment to submit to iesg is definitely a good time (and the
>     last possible from a chair's perspective) to think about that.
>
>     actions which are relevant during the I-D life cycle within the
>     WG. But I guess this is a broader discussion.
>
>
>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Thu, 26 Nov 2015 15:01:51 +0100

Hi Loa,

> the mandate for people participating in immediate IETF process.

I would find it quite unlikely to be in a situation where none of the 
vendors implementing a stable spec would have the ability  of disclosing 
it.  I would expect the people who are close to the IETF, if they have 
an interest in seeing the spec progress, to be able to spend the time so 
that someone else sends an appropriate email to [email-masked].

-Thomas

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Patrice Brissette (pbrisset)" <[email-masked]>
Date: Thu, 26 Nov 2015 14:13:34 +0000

Folks,

Have we look at our ³forum² such as OpenStack?
Do they have something in place there?

Regards,

Patrice

   Patrice Brissette
TECHNICAL LEADER.ENGINEERING

[email-masked]
Phone: +1 613 254 3336

Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE
Canada
Cisco.com <http://www.cisco.com/global/CA/>

 Think before you print.This
 email may contain confidential and privileged material for the sole use
 of the intended recipient. Any review, use, distribution or disclosure
by others is strictly prohibited. If you are not the intended recipient
(or authorized to receive for the recipient), please contact the sender
by reply email and delete all copies of this message.
Please click here 
<http://www.cisco.com/web/about/doing_business/legal/cri/index.html> for
Company Registration Information.

On 2015-11-26, 9:01 AM, "BESS on behalf of [email-masked]"
<[email-masked] on behalf of [email-masked]> wrote:

>>> - There are some (many?) operators that won¹t put drafts into an RFP,
>>> only RFCs.
>>>
>>> - There are some (many?) vendors that won¹t implement a draft or RFC,
>>>no
>>> For all these reasons, unless there¹s an existing customer that needs a
>>> draft¹s features to fix an operational problem, it¹s less common for
>>>WG
>>> the poll into consideration during WG LC to see if there¹s a consensus
>>> really important to get published, but for whatever reason hasn¹t yet
>>> been implemented.
>>>
>>> Cheers,
>>> Andy
>>>
>>>
>>>         and delaying (or blocking) I-Ds that don't have
>>>implementations.
>>>         While, in a
>>>         significantly gating the progress of one I-D because we are
>>>busy
>>>         processing
>>>         another.
>>>
>>>In
>>>last
>>>             indeed, minutes should have been available sooner.
>>>situation
>>>             has been
>>>             corrected.
>>>
>__________________________________________________________________________
>Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc
>pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>recu ce message par erreur, veuillez le signaler
>a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>electroniques etant susceptibles d'alteration,
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;

---

From: <[email-masked]>
Date: Thu, 26 Nov 2015 15:45:09 +0100

Hi Patrice,

> Do they have something in place there?

Producing standards and producing implementations are different things.

Openstack produces implementations, which may then may (or may not) 
become a de-facto standard. In that sense Openstack has a built-in 
mandatory implementation step before anything can have a chance of 
becoming a de-facto standard later.

The Openstack community also write specifications before implementing 
things, but these have zero value as standard, and haven't much value 
before they are actually implementing.

Then there is the case of Openstack components having plugin 
architectures. Neutron comes to mind, obviously. The Openstack has a 
pretty strong culture of not giving an community-supported kind of 
official value to an extension of the API that would not be supported by 
one of the reference opensource drivers.

The idea of mandating such a thing as "at least one opensource 
implementation" for IETF would be interesting to toy with. That would be 
quite refreshing. :)

-Thomas

---

From: Loa Andersson <[email-masked]>
Date: Fri, 27 Nov 2015 10:15:27 +0800

Thomas,

> that someone else sends an appropriate email to [email-masked].

Well - I'm not questioning the ability. What I've said that there might
be situations where a vendor are unwilling to disclose. And that as far
as I understand it this most often has nothing to do with the IETF
process.

To quote Adrian:
"...implementations that we know are out there have sullenly refused to 
present details for inclusion in I-Ds".

I've been watching demos (e.g. at MPLS conferences, where it is obvious
that drafts that we are about to ask for publication for (or just have)
must be part of the demo. Asking the "people who are close to the IETF"
just result in "not my decision"!

Having said that I still support what you are doing, only that we should
be careful not to get our expectations up to high based on this action.

/Loa

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 30 Nov 2015 10:32:39 -0500

I am very strongly opposed to this "proposal".

It takes the WG in the wrong direction, and attempts explicitly to undo
the work that led to RFC4794, which eliminated some of the time-wasting
requirements that served only to further extend the already slow IETF
process.

The right time to preserve a specification in an archived form (such as
an RFC) is when the specification has stabilized. Implementation and
deployment sometimes do not occur for years afterward, at which time the
the original authors and/or editors of the specification might have
moved on to other pursuits. In WGs that do have implementation
requirements, specification that were implemented years ago often sit
around as internet-drafts for extended periods of time, just because no
one is available to restart the standardization process. Often the
drafts expire, and sometimes remain expired for years after they've been
deployed. This creates considerable confusion about whether the drafts
have been abandoned.

There is also the point that Andy has raised, that delaying publication
may also delay deployment.

I believe it is improper for the IETF to be demanding details about
implementations, release cycles, and release dates.  It should be noted 
that it becomes quite difficult to gather this sort of information about 
a draft that has been sitting around for years, especially if that draft 
has has been implemented and deployed piecemeal.

There are also some process issues to discuss.

> [Martin] the point of our e-mail is to continue the discussion on the
> list. We explicitly say that this is a proposal and that we are open
> to comments.

The email in question certainly suggests that the WG chairs have already
made a decision to impose a new requirement, but are allowing two weeks
(during what is a holiday season for many) for "discussion" before they 
announce that there is a consensus in favor of their proposal.  This 
does not seem like an appropriate approach, and imho would be worthy of 
appeal.

The routing area used to have more implementation requirements, but
after extensive discussion in 2006 (discussion lasting more than two
weeks), these requirements were eliminated by RFC4794.  The reason is
clear enough.  Quoting RFC4794:

    "Today, one of the big problems the IETF faces is timeliness.
    Applying additional rules to a certain class of protocols hurts the
    IETF's ability to publish specifications in a timely manner."

I don't think anything has changed since the topic was discussed in
2006.  We should be looking for ways to speed up the process, not
looking for even more ways to slow it down.

> [Adrian] To be clear, the WG is allowed to make a decision to do
> this. http://datatracker.ietf.org/doc/rfc4794/

Are you referring to the following paragraph:

    Some working groups within the Routing Area have developed
    procedures, based on RFC 1264, to require implementations before
    forwarding a document to the IESG.  This action does not prevent
    those working groups from continuing with these procedures if the
    working group prefers to work this way.  We encourage working groups
    to put measures in place to improve the quality of their output.

I don't see that this gives individual WGs (not to mention WG chairs)
any right to impose arbitrary new rules.  It only allows them to keep
existing rules.  The most it says about allowing the creation of new
rules is:

    that does not prohibit the Routing Area Directors from requiring
    implementation and/or operational experience

though this presumably would also be subject to appeal if it were
applied arbitrarily.

> [Martin] The basic motivation for this is simply to avoid
> (over)loading the iesg with documents that have no (and could
> possibly never have an) implementation.

I don't think the problem of AD workload can be addressed by having a 
single WG add more delay to its process.  Certainly I don't agree that 
the IESG workload problem should be addressed by having the IETF do less 
work.

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 1 Dec 2015 01:35:07 +0000

I fully agree with Eric's points. In addition to the side-effects Eric had raised, I think it may intensify the monopolization in specification due to the implementation requirement before WG LC. For example, some giants could afford the implementation of whatever specifications they had proposed. However, for SMEs, they tend to start the implementation only when the specification has been standardized (e.g., RFC publishment).

Best regards,
Xiaohu

> From: BESS [mailto:[email-masked]] On Behalf Of Eric C Rosen
> Sent: Monday, November 30, 2015 11:33 PM
> To: Martin Vigoureux; [email-masked]
> Cc: Benson Schliesser; Joel M. Halpern
> It takes the WG in the wrong direction, and attempts explicitly to undo the work
> that led to RFC4794, which eliminated some of the time-wasting requirements
> that served only to further extend the already slow IETF process.
> 
> The right time to preserve a specification in an archived form (such as an RFC) is
> when the specification has stabilized. Implementation and deployment
> sometimes do not occur for years afterward, at which time the the original
> authors and/or editors of the specification might have moved on to other
> pursuits. In WGs that do have implementation requirements, specification that
> were implemented years ago often sit around as internet-drafts for extended
> periods of time, just because no one is available to restart the standardization
> process. Often the drafts expire, and sometimes remain expired for years after
> they've been deployed. This creates considerable confusion about whether the
> drafts have been abandoned.
> 
> There is also the point that Andy has raised, that delaying publication may also
> delay deployment.
> 
> implementations, release cycles, and release dates.  It should be noted that it
> becomes quite difficult to gather this sort of information about a draft that has
> been sitting around for years, especially if that draft has has been implemented
> and deployed piecemeal.
> 
> The email in question certainly suggests that the WG chairs have already made a
> decision to impose a new requirement, but are allowing two weeks (during what
> is a holiday season for many) for "discussion" before they announce that there is
> a consensus in favor of their proposal.  This does not seem like an appropriate
> approach, and imho would be worthy of appeal.
> 
> The routing area used to have more implementation requirements, but after
> extensive discussion in 2006 (discussion lasting more than two weeks), these
> requirements were eliminated by RFC4794.  The reason is clear enough.
> Quoting RFC4794:
> 
> I don't think anything has changed since the topic was discussed in 2006.  We
> should be looking for ways to speed up the process, not looking for even more
> ways to slow it down.
> 
> > [Adrian] To be clear, the WG is allowed to make a decision to do this.
> I don't see that this gives individual WGs (not to mention WG chairs) any right to
> impose arbitrary new rules.  It only allows them to keep existing rules.  The
> most it says about allowing the creation of new rules is:
> 
> though this presumably would also be subject to appeal if it were applied
> arbitrarily.
> 
> > (over)loading the iesg with documents that have no (and could possibly
> > never have an) implementation.
> 
> I don't think the problem of AD workload can be addressed by having a single
> WG add more delay to its process.  Certainly I don't agree that the IESG
> workload problem should be addressed by having the IETF do less work.
> 
> 
> 
> 
>