Subject: 2026, draft, full, etc.

From: Eliot Lear <[email-masked]>
Date: Tue, 30 Oct 2007 11:18:08 +0100

[I'm changing the subject and cutting off the references list as we seem
to have changed topic.]

Simon,

> DS designates a mature standard.  If you read the requirements in RFC
> 2026 for a mature standard it is clear that few of the modern IETF
> protocols live up to that standard -- you need to demonstrate
> interoperability between two completely independent implementations of
> _all_ features in the protocol standard.

I think we can all agree that the calendaring standard is mature.  We
are in the process of doing what I would consider to be a relatively
minor update to it, and yet it is only PS.  IMAPv4 is only PS and yet
has MASSIVE deployment.  LDAP is only PS and is MASSIVELY deployed.  SIP
is all over the place and it is only PS as well.  And so it's pretty
clear that nobody cares about DS or IS.  What's more, why should they? 
What benefit does it bring to anyone to advance a standard to DS?  AND
it's a whole lot of work.

So why are we even having an argument about what gets stuck into
requirements for DS?  Shouldn't we instead be eliminating it entirely?

Eliot

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Dave Cridland <[email-masked]>
Date: Tue, 30 Oct 2007 11:21:47 +0000

> clear that nobody cares about DS or IS.  What's more, why should  

Well, we don't, but mostly because we tend to know what the actual  
status of a particular protocol is. Usually.

But not always, especially when it falls outside our area of  
expertise, and far more importantly, people not directly involved in  
the IETF at all don't know.

I've suggested before that the advancement of a specification is a  
highly overloaded action - it implies that the IETF thinks it's a  
good idea, it implies that the specification is sound, it implies  
it's well deployed.

> it's a whole lot of work.
But it does do some good to review past specifications and note if  
they're still ok, it does do some good to note that specifications  
are solid, and it does do some good to say they're widely deployed.  
Sadly, this information does not get captured anywhere.

> requirements for DS?  Shouldn't we instead be eliminating it  

And lose even the small amount of information it does give people?

I think we'd do better to decide what information we want to be able  
to provide, and provide it, rather than wondering how many levels of  
overloaded information we should have.

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: <[email-masked]>
Date: Tue, 30 Oct 2007 13:21:18 -0000

> I've suggested before that the advancement of a specification 
> is a highly overloaded action - it implies that the IETF 
> thinks it's a good idea, it implies that the specification is 
> sound, it implies it's well deployed.

Does the IETF have a way to communicate that a specification is 
a good idea with a sound specification and that is well deployed?
For that matter, does the IETF have a way to make that determination?

One way in which the IETF has conveyed additional info in the past
is by designating RFCs as part of a BCP or FYI series. Similar 
mechanisms could be used to convey that a specification is more
than just a plain old humdrum RFC.

The point of all this being, that if the IETF does communicate that
certain RFCs are of a higher class than others, it makes it harder
for others to misunderstand the meaning (or mislead others about the
meaning) of RFC status for some particular protocol.

--Michael Dillon

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 30 Oct 2007 12:14:37 -0600

Dave Cridland wrote:
> they're still ok, it does do some good to note that specifications are
> solid, and it does do some good to say they're widely deployed. Sadly,
> this information does not get captured anywhere.

Not to mention the value of incorporating the results of implementation
and deployment experience (though perhaps that's part of what you call
reviewing past specifications).

I suppose that incorporating experience, reviewing the specification,
and the like can be done by cycling at PS forever, so it's not clear
whether DS and IS really matter. However, it may be that those good
things happen only by advancing a technology to DS. If so, then perhaps
it's OK that doing so is "a whole lot of work" as Eliot says. After all,
advancing an I-D to RFC is a whole lot of work, too, but we generally
consider that process to be beneficial. Maybe we need to more clearly
enunciate the benefits of advancing a technology to DS?

Peter

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

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 30 Oct 2007 14:00:42 -0500

At 05:18 AM 10/30/2007, Eliot Lear wrote:
>has MASSIVE deployment.  LDAP is only PS and is MASSIVELY deployed.

DHCP is the best (worse?) example of this, IMO. It's been DS (meaning 
at least 2 independent implementations) for how many years now (5, 6 
or 8+ years)? It's (as you say) MASSIVELY deployed. Yet it isn't a 
Full STD.  That one had always caused me to pause about how serious 
IETFers are really about 2026 processes...

>SIP
>clear that nobody cares about DS or IS.

Actually some do care *AND* the IETF gets dinged on this one by those 
that aren't IETFers as not mature. These are the same (psst: idoits) 
that confuse Internet "Draft" with "Draft" Standard, somehow thinking 
each status is the same (...somehow).

>What's more, why should they?

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Oct 2007 10:11:04 +1300

> requirements for DS?  Shouldn't we instead be eliminating it entirely?

Well, as you know Eliot, we tested the IETF's enthusiasm for tackling
that discussion a couple of years ago, and found it lacking. I continue
to believe that to keep the "running code" goal alive, we need something
like the PS to DS promotion available, but we need to change things
to make it more attainable in practice. But if you want to see progress,
you're going to have to show a measure of consensus to the General AD.

Comments on draft-carpenter-rfc2026-changes-01.txt are welcome.

    Brian

---

From: Ned Freed <[email-masked]>
Date: Tue, 30 Oct 2007 16:02:44 -0700 (PDT)

> minor update to it, and yet it is only PS.

It is less clear, however, that all of its many features have been implemented
interoperabiy.

> IMAPv4 is only PS and yet has MASSIVE deployment.

The main barrier to IMAP moving to draft is the large number of normative
references that first need to move first. Getting RFC 2822 to draft is a
necessary first step and we're working on that. But what about TLS? The
now-widespread use of TLS+plain has solved a lot of problems for appplications
but has created a serious obstacle to standards track advancement.

Perhaps a downreference exception needs to be made here, but if so that needs
to be approved in advance because nobody is going to bother going through all
the pain of documenting interoperability without first being sure that a
normative reference issue isn't going to render their work meaningless.

> LDAP is only PS and is MASSIVELY deployed.

I suspect the main issue is the same as for IMAP.

> clear that nobody cares about DS or IS.

I really don't think that's true. The problem is rather than people have
(correctly IMO) assessed that while the benefits of DS are real they just
aren't worth the cost. The question, then, is whether or not the cost can be
lowered without compromising the status, and if so, how. My personal opinion is
that major loosening of the downref rules as well as less nit-picking on
feature lists would help a lot without damaging the brand in any significant
way.

> requirements for DS?  Shouldn't we instead be eliminating it entirely?

I agree with Brian that this isn't the answer. But the current situation isn't
right either. We need to focus on what's important, which is real world
interoperability. Things have gotten too complex for a more exhaustive academic
approach to be viable.

				Ned

P.S. I actually started working on a feature checklist for RFC 3501 at one
point but after looking at the issues with normative refrences I simply gave
up.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 30 Oct 2007 17:32:33 -0700

I agree, but only partly.

A second pass on the documents does have a beneficial effect. This is particularly the case for older 'standards' where the documents simply don't match current requirements (no security, iana considerations for a start) and are often missing key folklore essential for interoperability.

Where I think the process goes wrong is that it applies to documents, not protocols. A lot of crud goes through the mill in the name of avoiding recycling at proposed. And when a major revision of an existing protocol is done the revision goes back to proposed before being promited to draft.

> -----Original Message-----
> From: Eliot Lear [mailto:[email-masked]] 
> Sent: Tuesday, October 30, 2007 6:18 AM
> To: Simon Josefsson
> Cc: IETF Discussion
> Subject: 2026, draft, full, etc.
> 
> [I'm changing the subject and cutting off the references list 
> as we seem to have changed topic.]
> 
> Simon,
> 
> I think we can all agree that the calendaring standard is 
> mature.  We are in the process of doing what I would consider 
> to be a relatively minor update to it, and yet it is only PS. 
>  IMAPv4 is only PS and yet has MASSIVE deployment.  LDAP is 
> only PS and is MASSIVELY deployed.  SIP is all over the place 
> and it is only PS as well.  And so it's pretty clear that 
> nobody cares about DS or IS.  What's more, why should they? 
> What benefit does it bring to anyone to advance a standard to 
> DS?  AND it's a whole lot of wo0�5X�0=��+��o��ܢmt۝y����Ô�cD\#t��(�����'r����L��貇�H��IP��~��y�;��C��m4�^��}��M�{^��%j�.�w(�ק��Z�Ǭ��,j� �z�"�}t\Ȧx��>��ǝ#"r�,��D��Z���ڵ��{}rݴӽ{�m�ӽ41�,j�n��=��P���= �}z�^y�N���f��p��foOor��i��w(���z�rN�;۽8N��M��Ȭr�(�s��֜�sL�
��zV�����N�bsm6���~��W�q8ky�H�ױ�߱�+����Eϫ�t�
��B��&�ej`Z��φ)e��[jG����('r���Ib���j�^j�"���d���ɢǟ��'���ۧv�(�s���jP+�+ڕ8�{}Nrݴӽ4�m����Q0� � �<�ͽ�}4�/5�WJ��I�+{M?]'�(���n��k��f�y�8i���u�u�xkP� D�+��"�x������+�+���-DM�ۧki�_�Y^���y�Ӆ�މ�_��_��1�����z�"�}����q�^�ǥ��K��Ht�8�r�,���z��z����'���r��zm����5��_��?�������+-�w��'�~f���"z��z���؞��+�˛��-�{.n�+�����O��fj)m�'�~'�~��.+-�i��������ު笶'�~����y�azZK��R���&ކ�i����
bz���j)fj��b��?��_��������ު笶'�~����y�l���&�
��z{Sʗ��[b����h�y��wZ�-8��v�:�����_n��q�"z��

I agree, but only partly.

A second pass on the documents does have a beneficial effect. This is particularly the case for older 'standards' where the documents simply don't match current requirements (no security, iana considerations for a start) and are often missing key folklore essential for interoperability.

Where I think the process goes wrong is that it applies to documents, not protocols. A lot of crud goes through the mill in the name of avoiding recycling at proposed. And when a major revision of an existing protocol is done the revision goes back to proposed before being promited to draft.

> -----Original Message-----
> From: Eliot Lear [mailto:[email-masked]] 
> Sent: Tuesday, October 30, 2007 6:18 AM
> To: Simon Josefsson
> Cc: IETF Discussion
> Subject: 2026, draft, full, etc.
> 
> [I'm changing the subject and cutting off the references list 
> as we seem to have changed topic.]
> 
> Simon,
> 
> I think we can all agree that the calendaring standard is 
> mature.  We are in the process of doing what I would consider 
> to be a relatively minor update to it, and yet it is only PS. 
>  IMAPv4 is only PS and yet has MASSIVE deployment.  LDAP is 
> only PS and is MASSIVELY deployed.  SIP is all over the place 
> and it is only PS as well.  And so it's pretty clear that 
> nobody cares about DS or IS.  What's more, why should they? 
> What benefit does it bring to anyone to advance a standard to 
> DS?  AND it's a whole lot of work.
> 
> So why are we even having an argument about what gets stuck 
> into requirements for DS?  Shouldn't we instead be 
> eliminating it entirely?
> 
> Eliot
>

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 31 Oct 2007 10:17:01 +0100

> Comments on draft-carpenter-rfc2026-changes-01.txt are welcome.

|  Formally abolishing the now pointless "STD 1" RFCs.

NAK - I hope we get a new STD 1 soon, ideally after 4234bis got its
STD number.

| The IETF will not  normally modify protocols developed elsewhere,

IMO the IETF must be able to adopt specific versions of a standard
developed elsewhere.  E.g. UTF-8 is what STD 63 says, it can't be
modified "elsewhere".

|  It would be much less confusing  if a new or existing acronym was 
| assigned as part of the initial standards action (thus RFC 2821 
| would have been associated with SMTP).

IMO more with ESMTP than with SMTP, I think you need a better
example here.

| Similarly, the STD number should be assigned at PS stage for
|  simpler tracking - thus RFC 2821 would also be known as PS10,
| for example. 

NAK, adding a "PS10" alias to "RFC 2821" doesn't help.  Many
PS don't deserve a separate STD number, unless they actually
make it to this level.  Some PS even don't need a nice acronym.

It might be different when a PS tries to update an existing STD,
as it's the case for RFC 2821.

| Rename PS as Preliminary Standard.

Some PS really are "proposed standards" as defined in 2026,
i.e. "immature specifications".  Or mature protocols where the
specification needs a thorough cleanup, e.g. RFC 2616.

 [2026]
| A standards action is initiated
[...]
| in the case of a specification not  associated with a Working Group, a
| recommendation by an individual to  the IESG.

 [your text]
|   A standards action is initiated
[...]
| in the case of a specification not associated with a Working Group, an
| agreement by an Area Director to recommend a specification to the
| IESG.  The IESG is empowered to define the procedures for this.

| RATIONALE: Aligning with reality.

JFTR, in reality I used the "recommendation by an individual" loophole
in two cases, for 4234bis and Archived-At. 

We had a similar debate about the shepherd-ION some months ago.
I need an appealable offense if the IESG refuses a "standards action" 
for frivolous reasons.  The RFC 2026 text offers this, I'm not sure
about your text.

| Remove the reference to gopher.

Sigh.   I kind of like RFC 4266, is that "PS gopher" in your terminology ?

| Add a note that the RFC Editor maintains errata for published RFCs.

<joke> Also add a note that they maintain a pending errata mailbox
with a submission from February 2005 waiting for publication. </joke>

 Frank