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] On Behalf Of Martin Vigoureux
Sent: 24 November 2015 23:17
To: 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
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
