Hi Andrew,
Andrew G. Malis :
- There are some (many?) operators that won’t put drafts into an RFP,
only RFCs.
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.
- 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.
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
On Wed, Nov 25, 2015 at 5:19 PM, Martin Vigoureux
<martin.vigour...@alcatel-lucent.com
<mailto:martin.vigour...@alcatel-lucent.com>> 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:bess-boun...@ietf.org
<mailto:bess-boun...@ietf.org>] On Behalf Of Martin Vigoureux
Sent: 24 November 2015 23:17
To: bess@ietf.org <mailto:bess@ietf.org>
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
_________________________________________________________________________________________________________________________
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.
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
