Subject: Re: Last Call: <draft-housley-two-maturity-levels-06.txt> (Reducing the Standards Track to Two Maturity Levels) to BCP

From: Alessandro Vesely <[email-masked]>
Date: Wed, 01 Jun 2011 12:10:40 +0200

For an outsider's feedback about John's comments (1), (4), and (5):

On 31/May/11 18:23, John C Klensin wrote:
> This proposal is problematic in several ways.  The first is
> obviously the most important, but the others suggest changes
> that might be useful whether or not that main provision is
> adopted.
> 
> (1) Excessively-high requirements for Proposed Standard and
> dropping the three-level model.
> 
> 	The document asserts, I believe correctly, that one of the
> 	problems with the IETF Standards Process is that the
> 	relatively low bar established for Proposed Standards in
> 	RFC 2026 has evolved into a very high bar and that we
> 	should return to that lower requirement level.  Yet it
> 	effectively proposed to solve that problem by reducing the
> 	number of steps in the standards process to two.  No
> 	evidence has been offered that whether or not the standards
> 	process is two levels or three has anything to do with
> 	difficulties completing Proposed Standards or getting them
> 	to a satisfactory level of completeness and correctness.
> 	The logic on that subject in the document appears to me to
> 	quite similar to a physician saying "We agree there is a
> 	problem with your hand.  We don't know how to treat it
> 	either surgically or medically, but we should do something,
> 	so let's amputate your foot".  That really makes no sense
> 	and is probably bad for the patient (only probably... one
> 	really never knows).
> 
> 	In addition, draft-housley-two-maturity-levels-06 does not
> 	discuss any mechanism for getting from the current
> 	as-practiced requirements for Proposed Standard back to the
> 	requirements of RFC 2026, a schedule for doing so, nor
> 	whether it is necessary to warn readers about the level of
> 	scrutiny applied (it may not be, but there has been little
> 	or no discussion of that subject in the IETF and there is
> 	no such discussion in the document).  If this were a
> 	technical specification, unless there were an expectation
> 	that a transition will occur immediately and by magic, that
> 	omission would be a "known defect".
> 
> 	Suggestion: The level of completeness and quality required
> 	for a Proposed Standard, at least insofar as those
> 	requirements exceed the requirements in RFC 2026, are
> 	entirely in the hands of the IESG, relevant WGs, and the
> 	Last Call process.  Whether those requirements can be
> 	reduced to the level required by 2026 has nothing to do
> 	with this document because there is no change to the 2026
> 	requirements.

While those considerations are entirely self-evident, I omit John's
suggestions (i), (ii), and (iv) as they address an apparently
different problem.  In facts, on the requirements for Proposed
Standard, the I-D says that "they remain exactly as specified in RFC
2026", which seems to mean that the I-D is not attempting to alter
their formal status in any way.

I agree that the transition described in Section 5 is somewhat abrupt.
 It seems to me it would be smoother and more flexible to allow the
new two-step ladder to coexist with the current three-step one, at
least temporarily.  That is to say, use "add to" rather than "replace"
or "change" in the RFC Editor notes, and alter the last sentence in
section 2 to read

   Minor revisions and the removal of unused features are expected,
   but a significant revision may require that the specification
   accumulate more experience at either Proposed Standard or Draft
   Standard before progressing.

In John's word:

>         (iii) The above implies that different areas, and
> 			perhaps even different WGs within an area, will end
> 			up with different practical requirements based, at
> 			least in part, on their perception of the risks
> 			implied by a less comprehensive document.  I see
> 			that as an advantage and recognition of reality,
> 			not a problem. 

> (4) Discussion of the STD document series in Section 6.
> 
> 	It has been pointed out several times, in recent months to
> 	suppress discussion of proposals that might be alternates
> 	to some or all of this one, that there are many issues with
> 	how the IETF develops, approves, documents, and manages
> 	standards that are not addressed in this specification and
> 	that the community cannot reasonable expect to address all
> 	at the same time.  The question of what should be done
> 	about the STD numbers is just one entry on this very long
> 	list.  Examination of other IETF procedural RFCs indicates
> 	that we rarely, if ever, include a discussion of a single
> 	option that we have decided to _not_ pursue (even if only
> 	in the near term).  The only apparent justification for
> 	including Section 6 in this draft is that there was a
> 	specific proposal in an earlier version, a proposal that,
> 	as the draft indicates, did not get community consensus.
> 	The section should be dropped from this document before
> 	publication.  If the community wants to have a series
> 	discussion of STD numbers, I suggest that
> 	draft-klensin-std-numbers might be one contribution to that
> 	discussion.

+1, different documents for different problems.

> (5) Patents
> 
>     The specification says (last bullet in Section 2): 
> 
>     > * If patented or otherwise controlled technology is
> 	>   required for implementation, the separate
> 	>   implementations must also have resulted from separate
> 	>   exercise of the licensing process.  
> 
> 	While this text is copied from 2026, things have changed
> 	and the requirement has been interpreted very loosely,
> 	particularly to leave interpretation of "required" in the
> 	hands of the implementers.
> 
> 	If it is repeated in a spec that is approved now and that
> 	claims to reset and clarify Draft Standard requirements, it
> 	can easily be read as a requirement that the community has
> 	to somehow evaluate whether claimed controlled technology
> 	is actually "required for implementation".  That may be
> 	obvious in some cases; it may be highly controversial and
> 	dependent of validity of patent claims (something that can
> 	normally be resolved only by the courts) in others.  The
> 	IETF has been repeatedly advised, both by legal counsel and
> 	by various incarnations of IPR WGs, to avoid straying into
> 	the territory in which it takes a position on whether an
> 	IPR claim is valid.  Consider a scenario in which some
> 	company, say ChuckCo, decides that an IETF Internet
> 	Standard for Alice's proposal would put them at a
> 	competitive disadvantage.  It is merely necessary for
> 	ChuckCo to file an IPR claim against the technology in
> 	Alice's spec, even a obviously spurious one, assert a
> 	completely irrational and punitive licensing model that
> 	cannot be exercised in a reasonable way, and then sit back
> 	and watch the IETF paralyze itself over this provision as
> 	written.
> 
> 	Suggestion: I believe that advice of Counsel should be
> 	sought about this language and, if feasible, alternate
> 	language produced that either turns the requirement into an
> 	"if feasible" request or that places the responsibility for
> 	evaluating whether the claims are applicable on the
> 	implementers and not on the IETF or IESG.

I suggest that any IPR notices be referenced from RFCs, somewhere
among other boilerplate in the front matter.  If at all possible,
purely defensive patents, for which clearly worded statements grant
unencumbered use of the relevant technology, should enjoy a
distinguished wording that quickly conveys such condition.  No
separate exercise of the licensing process seems to be necessary for
such cases.  On the opposite, I see no reasons for standardizing
technologies that are known to require payed licenses, unless (part
of) that money goes to the IETF.

jm2c

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 05 Jun 2011 18:51:20 +0100

Pete Resnick wrote:
 [...]

> Section 2.2
> (a) Specifically, merge Draft Standard into Internet Standard
> (b) Combine criteria from Draft Standard and Standard
>     (i) Significant number of implementations with successful 
> operational experience
>     (ii) No unresolved errata causing interoperational problems
>     (iii) No unused features, except allow unused features that do not 
> greatly increase implementation complexity
>     (iv) Independent patent/licensing for implementations
> (c) Remove overt requirement for documentation of interoperability 
> testing

 [...]

> 2.2(b)(i) - This is the current requirement for Internet Standard. I'm 
> fine with that remaining, but object to the removal of any notion of 
> interoperability. If this were changed to "A significant number of 
> interoperable implementations...", I would have no objection.

+1.

> 2.2(b)(iii) - I would prefer that this be amended to "All unused 
> 'MUST' requirements will be changed to 'SHOULD' requirements." If 
> deployment is interoperable and a feature is unused, it means that the 
> feature was not actually REQUIRED for interoperability. I object to 
> this as it stands.

-1.
If for a protocol X nobody implemented MUST implement security 
mechanism, I don't think I would like it to be downgraded to a SHOULD. 
At least not without a good explanation.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 07 Jun 2011 22:00:35 -0600

Pete, thanks for your helpful summary. Comments inline, now that I've
had a chance to review all of the Last Call feedback.

On 5/30/11 5:20 PM, Pete Resnick wrote:
> On 5/5/11 11:13 AM, The IESG wrote:
>> The IESG has received a request from an individual submitter to consider
>> the following document:
>> - 'Reducing the Standards Track to Two Maturity Levels'
>>    <draft-housley-two-maturity-levels-06.txt>  as a BCP
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> [email-masked] mailing lists by 2011-06-02. Exceptionally, comments may be
>> sent to [email-masked] instead. In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>>    
> 
> Man without hat: Speaking as an individual contributor, not an AD.

Ditto.

> Summary: I am in favor of most of the changes in this document. The
> primary change I am opposed to is the one identified in the title and
> therefore object the adoption of this document as a BCP. However, I
> believe there is a single (though significant) change that would make
> the document acceptable to me.

My summary: I am in favor of many of the changes in this document,
although what you and I like and dislike does not overlap much. :|

> Details:
> 
> The document says in section 1 that the motivation for the changes is:
> 
>    In the current environment, many documents are published as Proposed
>    Standard and never advance to a higher maturity level. 

I think that's fine and usually appropriate.

>    In addition,
>    IETF working groups and IESG members provide much more scrutiny than
>    is called for by RFC 2026 [1] prior to publication as Proposed
>    Standard.

Although this is adduced as a motivation, by my reading it doesn't
actually motivate the proposals in this document.

> I certainly agree with addressing the above concerns. 

I'm not yet convinced that these are real problems.

> Section 2 lists
> one additional motivation for the changes:
> 
>    The benefit associated with a third maturity level has proven
>    insufficient to justify the effort associated with document
>    progression.
> 
> I'll address this below.

I think the third maturity level is unnecessary, but I'm not yet
convinced that we understand what results we're trying to achieve and
what behaviors we're trying to encourage by modifying the standards track.

> Here is a summary of the process changes that occur in the document, by
> section:
> 
> Section 2
> (a) Generally, go to two maturity levels, Proposed Standard and Internet
> Standard
> (b) Only review the changes, not the entire document, when recycled at
> Proposed
> 
> Section 2.1
> (a) Go back to 2026 level of (i.e., less) scrutiny for Proposed Standard
> 
> Section 2.2
> (c) Remove overt requirement for documentation of interoperability testing
> 
> Section 3
> (a) No more annual review of Proposed Standards for movement to Historic
> 
> Section 4
> (a) Allow normative references from Internet Standards to Proposed
> Standards
> 
> (Editorial note: Please move 2(b) into 2.1. That change is a change to
> the handling of Proposed Standards and therefore belongs in 2.1. That
> makes the rest of Section 2 just introductory text and not making a
> specific procedural change.)
> 
> My analysis by section:
> 
> 2(a) - I am opposed to this change and will discuss it below in section
> 2.2(a).

I am in favor of this change.

> 2(b) - I like this change and support it.

I'm mostly agnostic about this, although I note that sometimes things
change (e.g., new security threats) and it makes sense to revisit parts
of a document even if they haven't been changed (or, in some instances,
especially if they haven't been changed).

> 2.1(a) - I wholeheartedly agree with this change (or, more to the point,
> reversion to the documented way of doing things). 

I disagree with this change. It sounds attractive ("let's return to the
golden age") but I agree with those who posted during the Last Call that
it is a significant change from current practice. You could argue that
current practice is not the best practice, but I don't see how a
reversion to RFC 2026 principles here is truly best current practice. In
addition, IMHO we have not thought enough about the consequences of a
lower bar for Proposed Standard (e.g., our "customers" think that an RFC
is an RFC, and if we suddenly start publishing PS specs of lesser
quality then we might be diluting our brand).

> However:
> - This document gives no mechanism to facilitate this change. I would
> like to hear how this will be accomplished.

I have my doubts that this is even achievable now, at least absent
serious changes to IETF culture and individual expectations among spec
authors, WG chairs, Area Directors, review teams, and everyone else.

> - This change, along with 2(b) has the potential to greatly increase the
> number of RFCs published. The document does not discuss the impact of that.

And, more to the point I think, to greatly decrease the quality of RFCs
published. Perhaps that's OK, but we need pretty strong consensus that
it's the right thing to do, and I haven't seen that consensus in the
Last Call discussion.

> 2.2(a) - I see no motivation for this change other than the one sentence
> in section 2. This change does not address the difficulty of going from
> Proposed to Draft, and it doesn't address the heightened scrutiny for
> going to Proposed. Therefore, if the only reason for changing from three
> levels to two is that getting through the three levels is too hard, and
> most of the procedural changes in this document are to make it easier to
> get through the first two levels, I see no justification for removing
> the third (and in 2026, easiest to get through) level. It does not solve
> any identified problem.

I'm in favor of this change. I don't think the document describes the
motivation very well, but this one makes sense to me. As Thoreau said,
"simplify, simplify, simplify" (although why did he need to say it three
times?).

> 2.2(b)(ii) - I have no objection to this new requirement, but have no
> strong feeling about it.
> 
> 2.2(b)(iii) - I would prefer that this be amended to "All unused 'MUST'
> requirements will be changed to 'SHOULD' requirements." If deployment is
> interoperable and a feature is unused, it means that the feature was not
> actually REQUIRED for interoperability. I object to this as it stands.
> 
> 2.2(b)(iv) - This is the current requirement for Draft Standard. I'm
> fine with that remaining.
> 
> 2.2(c) - If this is actually "subsumed" by 2.2(b)(i) (see my change
> above), then I am fine with this change.

Agreed.

> 3(a) - I have no objection to this change, but hope that the review can
> be reinstated once the rest of the process settles down.

IMHO this makes a lot of work for various folks with no clear benefit.
Strike it.

> 4(a) - I have no objection to this change as it applies to Draft Standards.

Right. Although I think various Last Call commenters are right that this
needs to be handled on a case-by-case basis (especially if we start
publishing lower-quality or less-mature PS documents).

> So, to summarize, here is how I break down the changes this document
> proposes and my position on them:
> 
> A. For Proposed Standard:
> - Go back to 2026 review levels for approval
> - Only review changes, not the entire document, for recycling at Proposed.
> 
> I am in favor of these changes.

I am not in favor of these changes.

> B. For Draft Standard:
> - Remove requirement for formal documentation of interoperability tests.
> - Require only a significant number of [interoperable] implementations
> with successful operational experience.
> - Allow no unresolved interoperability errata.
> - Allow for unused [SHOULD level] requirements if they don't increase
> implementation complexity.
> - Allow for downrefs to Proposed Standard documents.
> 
> I am in favor of these changes with the square bracketed insertions I
> have made, except for the last one which I can live with.

I am in favor of these changes.

> C. Eliminate annual review of Proposed Standards.
> 
> I would prefer not to make this change, but since it does not reflect
> reality, I am OK with it.

I would prefer to make this change.

> D. For Internet Standards:
> - Combine Draft Standards into this category.
> 
> This is the only change that I strongly object to since I don't see any
> problem that is solved by doing this and therefore oppose adoption of
> the present document as BCP.

The is the only change I'm strongly in favor of.

> So, here is my a proposed alternative:
> 
> 1. Make the changes in (A). We still need to say how to make that
> happen, and how to deal with the increased number of RFCs.

I say: don't make these changes.

> 2. Make the changes in (B).

Agreed.

> 3. Make the changes in (C).

Agreed.

> With regard to the STD numbers, I think that it would be reasonable to:
> 
> 4. Assign STD numbers to everything at Draft Standard.

I agree with John Klensin and others that this text can be safely
removed. It's off-topic at this point in the conversation anyway.

> And if people really think that the current *titles* of the levels are a
> problem:
> 
> 5. Change the name of "Internet Standard" to "Mature Standard" (or
> "Deployed Standard" or whatever label we like).
> 
> 6. Change the name of "Draft Standard" to "Internet Standard".

I disagree -- there's no reason to change the branding.

> I am happy to write an I-D if there is support for this.

And I'm happy to write an I-D that makes a stronger case for two-track.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Pete Resnick <[email-masked]>
Date: Tue, 7 Jun 2011 23:57:15 -0500

> had a chance to review all of the Last Call feedback.

A conversation I'm happy to have. Comments inline. We are still men 
without hats.

> I think that's fine and usually appropriate.

So you think that this is *not* a motivation for the changes and is 
*not* something we need to change? Interesting.

> actually motivate the proposals in this document.

We agree on that point.

> I'm not yet convinced that these are real problems.

This we're likely to agree to disagree on.

> what behaviors we're trying to encourage by modifying the standards track.

Strongly agreed on the latter point: I'm not at all convinced that we 
understand what results we're trying to achieve and
what behaviors we're trying to encourage by modifying the standards 
track. And given that, whatever change we end up making, I have to say 
that this document can't be it, because it does not explain what we're 
trying to achieve.

> it's the right thing to do, and I haven't seen that consensus in the

All of the above may be true. I personally think that the best thing 
that could happen in some sense is to "decrease the quality" of Proposed 
Standard RFCs, but that's certainly a controversial view. And I think 
it's worthy of an independent discussion. So, at the very least, we 
either need to agree on this as a topic for this document or remove it.

> "simplify, simplify, simplify" (although why did he need to say it three

"Simplify" (even three times) is not a good motivation for this change. 
If "simplify, simplify, simplify" means "cut off your right arm, cut off 
your left arm, and cut off your left leg", I will certainly be a simpler 
being for the act, but none the better; I would argue a bit worse for my 
purposes. "Simplify" is not, in and of itself, a good justification. So 
I want to hear more. Certainly more than is in the current document.

Agreed.

> I am not in favor of these changes.

I'll try to argue separately later for why this is good. But I suspect 
that we're going to be deadlocked at least with regard to this document.

> I am in favor of these changes.

Excellent. This we probably can get agreement on for this document.

> I would prefer to make this change.

I don't mind, but I might want to wordsmith to still allow the IESG the 
possibility to classify something as Historic with simply a Last Call.

> The is the only change I'm strongly in favor of.

Again, I'll wait to hear the justification. But to say I am very 
skeptical would be to understate.

> And I'm happy to write an I-D that makes a stronger case for two-track.

So, I think I hear us agreeing that it would be fine to make the changes 
to requirements for Draft Standard, but not agreeing to much of anything 
else. You're willing to write an I-D explaining why it's a good idea to 
go to two-tracks and I'm willing to write an I-D explaining why it's a 
good idea to go back to 2026 requirements for Proposed Standard, and we 
both seem to agree that the present I-D does neither of these things. 
Given that, I think it makes sense to remove the two-track business and 
the Prosposed Standard business from this document and simply make it 
about simplifying the requirements for Draft Standard.

I think we will wait for the shepherding AD to give us direction. :-)

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Jun 2011 01:28:47 -0400

> *not* something we need to change? Interesting.

For what it's worth, quite apart from thinking that the draft in
question will do nothing to change the state of affairs with respect
to advancement, I also wonder why anyone cares whether documents
advance.

If someone cares enough, documents will advance.  Someone will do the
work.  For instance, apparently Scott Hollenbeck cared about the
advancement of EPP.  The Extensible Provisioning Protocol is a full
Standard.  Meanwhile, the protocol some EPP-using registries employ to
update the contents of their DNS zone files (DNS Update, RFC 2136) is
a Proposed Standard and has been since 1997.  I assert that someone
fooling with DNS dynamic update such that the protocol changed
incompatably would have far more wide-ranging and deleterious
consequences for the Internet than someone altering EPP in a
backward-incompatible way.  We have a hope of contacting all the EPP
users on Earth, to begin with.  (None of this is to denigrate EPP or
the work that those who moved it along the standards track undertook.
I think it is an excellent example of what to do and how to do it.
It's just also a handy example of a well-defined protocol with a
reasonably tightly packed user community, compared to some other
protocols.)

If the people who use and rely on a protocol don't care about this
maturity-level advancement to do something about it, why should the
rest of us care?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Cridland <[email-masked]>
Date: Wed, 08 Jun 2011 08:58:29 +0100

On Wed Jun  8 05:57:15 2011, Pete Resnick wrote:
> All of the above may be true. I personally think that the best  
> thing that could happen in some sense is to "decrease the quality"  
> of Proposed Standard RFCs, but that's certainly a controversial  
> view. And I think it's worthy of an independent discussion. So, at  
> the very least, we either need to agree on this as a topic for this  
> document or remove it.

Just to throw in my tuppence, once more:

I'm entirely in favour of there being a cheaper, rougher,  
lower-quality grade of specification; I think this should be what  
Proposed Standard was originally intended to be; I think there is a  
pressing need for a specification grade to fill this niche within the  
IETF. In this, I think I'm in agreement with Pete.

I am very much against trying to redefine - and at this stage it is a  
de jure redefinition, as it were - Proposed Standard *or any other  
RFC grade* to fill this gap. I think customer expectation of the RFC  
series is now for a much higher quality than RFC 2026 envisaged, and  
the net result of regrading PS would be that of lowering the quality  
of the specifications used in the field. In this, I think I'm in  
agreement with Peter.

The best proposal I've seen - and I'd note that I can't recall now if  
this is Keith Moore's or Scott Bradner's, to my shame - is that of  
marking up specific I-D documents as being a "Stable Snapshot". This  
proposal seems to have the following benefits:

a) It satisfies the two paragraphs above in a non-conflicting manner.  
That is, it provides everything that RFC 2026's PS was intended to  
without being an RFC, with all that that moniker currently implies.

b) It's fairly obvious, in my view, how to start to use the new  
grade, and how we might adapt to it in a smooth manner. Working  
Groups, authors, etc would be able to start to use it in a fairly  
ad-hoc manner, without the kinds of flag day changes to process that  
two-maturity-levels seems to imply.

So if anyone has the patience for another I-D thrown into the soup,  
I'm willing to [re]write this one up, assuming the original  
instigator[s] of the proposal don't wish to.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 11 Jun 2011 07:36:46 +0300

08.06.2011 10:58, Dave Cridland wrote:
>> that could happen in some sense is to "decrease the quality" of 
>> Proposed Standard RFCs, but that's certainly a controversial view. 
>> And I think it's worthy of an independent discussion. So, at the very 
>> least, we either need to agree on this as a topic for this document 
>> or remove it.
>
> [ . . . ]
>
> marking up specific I-D documents as being a "Stable Snapshot". 
To my mind, this will override the basic rule of RFC 2026:

>        ********************************************************
>        *                                                      *
>        *   Under no circumstances should an Internet-Draft    *
>        *   be referenced by any paper, report, or Request-    *
>        *   for-Proposal, nor should a vendor claim compliance *
>        *   with an Internet-Draft.                            *
>        *                                                      *
>        ********************************************************
whereas you propose making I-Ds almost Standards Track.  As it was 
discussed before, there is an evidence of leaving PSs without any 
action/progress; introducing "Stable Snapshots" there might occur 
"Stable Snapshots" left without any action, like PSs.  But PSs are RFCs 
at least and I-Ds are "nothing-as-per-2026".  Adopting this proposal 
might result in implementators claiming "we implement "Stable Snapshot" 
of the Internet-Draft", which is unacceptable, IMO.

Mykyta Yevstifeyev
> This proposal seems to have the following benefits:
>
> b) It's fairly obvious, in my view, how to start to use the new grade, 
> and how we might adapt to it in a smooth manner. Working Groups, 
> authors, etc would be able to start to use it in a fairly ad-hoc 
> manner, without the kinds of flag day changes to process that

---

From: Julian Reschke <[email-masked]>
Date: Sat, 11 Jun 2011 09:59:29 +0200

On 2011-06-11 06:36, Mykyta Yevstifeyev wrote:
> ...
> ...

Out of curiosity: why do you find that "unacceptable"?

It's *good* when the stuff in IDs gets implemented, and it's also good 
if there's clear information *which* draft is implemented.

What can be problematic is when products are *released* with this kind 
of implementation.

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 11 Jun 2011 16:47:38 +0300

> What can be problematic is when products are *released* with this kind 
Under-development implementation is doubtlessly useful.  Above under 
"implementing" I meant final implementation, incorporating some 
technology in the final product.  Introducing "Stable Snaps" is very 
likely to make such cases more frequent, as they will be made almost 
equal to RFCs.

Mykyta Yevstifeyev