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 protected]
<mailto:[email protected]>> wrote:
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
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.
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).
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.
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.
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.
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.
Adrian (still thinking about this)
-----Original Message-----
From: BESS [mailto:[email protected]
<mailto:[email protected]>] On Behalf Of Martin Vigoureux
Sent: 24 November 2015 23:17
To: [email protected] <mailto:[email protected]>
Subject: Re: [bess] Introducing a one-implementation
requirement before WG
last calls
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
Le 24/11/2015 17:07, Adrian Farrel a écrit :
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
_______________________________________________
BESS mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/bess
_______________________________________________
BESS mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/bess
_______________________________________________
BESS mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/bess
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
