Thomas,
On 2015-11-26 22:01, thomas.mo...@orange.com wrote:
Hi Loa,
Loa Andersson :
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.
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 bess@ietf.org.
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
-Thomas
On 2015-11-26 06:57, Andrew G. Malis wrote:
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
<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,
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.
_______________________________________________
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
