Subject: [newtrk] BCP 61, advancing to draft

From: Sam Hartman <[email-masked]>
Date: Thu, 09 Feb 2006 20:00:01 -0500

Hi.  I'd like to remind everyone of BCP 61.  It says roughly that
protocols we approve need a mandatory to implement security mechanism.
We here in the security area think that's a great idea.  O, by the
way, we're here to help you.

As part of our plan for world domination^h^h^hhelping you, we've
created a number of security solutions including things like SASL,
TLS, IPsec, Kerberos, GSS-API, and CMS.  We really like it when you
use these security services instead of inventing your own.  First, it
makes it hugely easier for us to review your documents.  Second, it
makes it easier when we need to do algorithm upgrades to things like
hash functions or replace DES with AES.  Finally it probably makes
your security easier to deploy.

There's this littple problem though.  All of the above are at proposed
standard.

For a number of reasons they are not moving to draft as soon as anyone
would like.

So, I see two options that I don't like.  First, we can avoid security
in anything going to draft.  Draft becomes a dumping ground for all
the older protocols (plus a few things like SNMP that invent their own
security) without updates that add security.  Secondly, we can block
everything from going to draft.

Does anyone want to work on a better answer to this?

--Sam

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 10 Feb 2006 10:02:54 +0100

> For a number of reasons they are not moving to draft as soon as anyone

Care to elaborate?

> Does anyone want to work on a better answer to this?

Seems that there are two possible answers:

- Move the security stuff to Draft (knocking down the reasons for that not 
happening one at a time, possibly changing the criteria for Draft on the 
way)
- Abolish Draft

I consider the third option - having Draft with downreference to Proposed - 
to be a Bad Idea. If we have to do that, I'd rather abandon Draft.

              Harald

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Feb 2006 10:41:04 +0100

(cc's stripped, AD hat off).

 > Does anyone want to work on a better answer to this?

Yes. draft-carpenter-newtrk-twostep or draft-loughney-newtrk-one-size-fits-all

     Brian

.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 10 Feb 2006 07:34:33 -0500

>>>>> "Harald" == Harald Tveit Alvestrand <[email-masked]> writes:

    >> 
    >> For a number of reasons they are not moving to draft as soon as
    >> anyone would like.

    Harald> Care to elaborate?

Sure, but this is very much with my AD hat off and with the warning
that I'm probably wrong on some of these.

SASL: internationalization issues; low number of volunteers dedicating
time.  Not clear which mechanism to move to draft to validate the framework.

IPsec: just moved to proposed again; not many implementations; already
needs for clarifications drafts.

TLS: Moving to proposed again because of hash mess.

Kerberos: Doable, but we're all fairly busy working on meeting new
customer needs.  We did recently hold a meeting and develop feature
matrix and roughly what we'd need to remove from the spec.  We were
really hoping that RFC 4120 would not need things removed; I think a
lot of us lost interest in moving Kerberos to draft any time soon when
we found out that was not the case.

GSS-API: Needs a mechanism to move to drfat.  Kerberos mechanism
depends on Kerberos.  Everything else needs some significant work on
the documentation front that no one is really chartered to do.  An
individual wanted to do the work and was encouraged to contact an AD
when they had a draft; haven't heard from them in months.

PKIX: I think has some internationalization issues; possibly some hash
fun.  Not really sure.

CMS: Unsure.  Wouldn't surprise me if besides PKIX dependencies this
was in the best shape.

--Sam
.

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 10 Feb 2006 08:06:27 -0500

On  10 Feb 2006, at 04:02, Harald Tveit Alvestrand wrote:
% Seems that there are two possible answers:
%
% - Move the security stuff to Draft (knocking down the reasons for that
% not happening one at a time, possibly changing the criteria for Draft
% on the way)
% - Abolish Draft
%
% I consider the third option - having Draft with downreference to
Proposed -
% to be a Bad Idea. If we have to do that, I'd rather abandon Draft.

I would suggest that in parallel both (1) "move the security stuff to
Draft"
and (2) "abolish Draft Standard" of Harald's suggestions be undertaken.

My guess is that Sam's note was a polite way of trying to "encourage"
the security community to undertake (1), but I could be wrong.

Security is not the only thing that impedes going to Draft Standard
or Full Standard.  There is a longish list of things that can impede
progression away from Proposed Standard.  We have an impressive number
of IETF standards-track protocols that have been at Proposed Standard
for many many years.  Some are widely used, while others are widely
ignored.

My proposal for a new standards track looks roughly like this:

1) Proposed Standard
 	- Rules exactly as they are to progress to Proposed Standard
 	- No Changes
2) Delete the "Draft Standard" state, but keep the "multiple
interoperable
 	implementations" rule and apply that rule to "Full Standard".
3) Require that most Proposed Standards (i.e. those that are not blocked
 	by the failure of some other standard to advance) move to Full
 	Standard within 2 years (edit time to your taste) of publication
 	as a Proposed Standard or 2 years of all normative references
 	moving to Full Standard, whichever comes later.  Anything that
 	does not meet that requirement automatically gets reclassified
 	as HISTORIC status unless the IESG grants an exception at the
 	2 year timeout.  IESG exceptions are themselves limited to 2 years.
 	Any IESG exception requires the IESG to publicly say why the
 	exception was granted in the particular case.
4) 3 months after the above changes are approved, any documents
already at
 	Draft Standard progress automatically to Full Standard, unless the
 	IESG takes some other action (e.g. move to Historic) on the
 	Draft Standard(s) during the 3 month window just after the process
 	changes are approved.

This achieves the following goals:
 	(1) simplifies the standards track greatly,
 	    which by itself increases the incentive to advance a document,
 	    and (in theory) reduces the workload for the IESG.
 	(2) retains the requirement for demonstrated interoperability
 	    before becoming a Full Standard.  We all understand why this
 	    is important.
 	(3) creates a "timeout" that incents WGs and individuals to
 	    progress their documents all the way along to Full Standard,
 	    lest the document(s) automatically move to HISTORIC.
 	    This timeout period does not start until the document
 	    is unblocked by normative references.
 	(4) gives the IESG the power to grant exceptions to the "timeout"
 	    for any exceptional cases.

Yours,

Ran
[email-masked]
.

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 11 Feb 2006 02:33:24 +1300

RJ Atkinson <[email-masked]> writes:
>These also don't look like low-hanging fruit.
>
>I think TLS is probably the lowest hanging fruit here.  IPsec, Kerberos, and
>SASL come next in a clump.  GSS-API, PKIX, and CMS seem pretty high up the
>tree just now.

And that's the problem - CMS and TLS are both blocked waiting on PKIX (this is
what held up TLS at the RFC 2246 stage for what, three years?).  Presumably
IPsec will also block on PKIX.  This is why I proposed the relative- rather
than absolute-value reference approach in my previous message.  Without this,
you get the priority-inversion situation of the lowest-hanging fruit stalled
behind the highest-hanging fruit (not to mention appallingly mangled
metaphors).

Peter.
.

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 11 Feb 2006 02:13:15 +1300

Sam Hartman <[email-masked]> writes:
>Sure, but this is very much with my AD hat off and with the warning that I'm
>probably wrong on some of these.
>
>[List snipped]

Just looking at this list, is the document-status thing just a case of
changing some policy, or is there more to it than that?  For example from that
list TLS, Kerberos, and CMS have all been around for 10-15 years so it's
unlikely that there are going to be major changes in the spec, and in
particular that there will be non-backwards-compatible changes.  So all you'd
need to do is instead of pointing to [RFCxxxx], point to [TLS], where [TLS] is
"'The TLS Protocol', version 1.1 or any later version".  This is already done
by documents like the GPL, which specify use of "version X or any later
version" rather than hardcoding in a particular document.  Since these
protocols stick around for years, even decades (I mean we've only just got
around to deprecating the broken SSLv2 protocol after 12 years of use), I
can't see any major interop problems turning up.  Without this, you end up
with horrible priority inversions where some far-distant unfinished spec ends
up blocking a major standards effort that needs to refer to it.

Peter.
.

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 10 Feb 2006 08:21:16 -0500

> time.  Not clear which mechanism to move to draft to validate the

So the issue here is multiple-dependency:
 	- SASL can't advance because of the I18N rules
 	- lots of other stuff can't advance because of SASL

I'd say that the thing to do is to waive the I18N rule to
let SASL go to Draft (with a requirement that I18N issues
get addressed before further forward motion) -- then push
on the I18N portion of the IETF to pitch in on this.

I'm familiar with several languages and from time to time (e.g. MIME)
have been involved in I18N discussions in the IETF.  However, a big
percentage of the IETF are only familiar with one or two languages
(polyglots are actually rare in our circles).  Those familiar with
only one language are not likely to be able to help very much.

> needs for clarifications drafts.

One only needs 2 interoperable implementations to move to Draft
Standard.
If the new spec(s) don't have that, push the implementers to sort out
interoperability, find 2 that work, declare victory, and move to Draft.

If our current process had been around when TCP was first being
specified,
implemented, and tested, TCP would have become totally wedged also,
IMHO.

> TLS: Moving to proposed again because of hash mess.

I'd suggest pushing on this one first in a focused way.  The hash
situation should be very straight-forward to sort out, if the ADs
apply time pressure to the group.  Adding new hash functions is
not technically difficult, though IETF processes can be very difficult
these days.

> we found out that was not the case.

If the issue is that not all features of 4120 are in at least 2
implementations, there are a couple of approaches.  One is to go
find a sponsor to fund someone to add the missing feature(s) to
either MIT Kerberos or Heimdal.  The other is to do what OSPF did
with M-OSPF, move the not yet widely implemented (but perceived
useful) items into a separate document so the main spec can advance
more quickly.

(Aside: I still miss having M-OSPF.  It worked very well and was very
easy to configure and operate.  PIM has never come close to being as
useful as M-OSPF.  Sigh)

> when they had a draft; haven't heard from them in months.

Given that analysis, this is probably not low hanging fruit.

I think TLS is probably the lowest hanging fruit here.  IPsec, Kerberos,
and SASL come next in a clump.  GSS-API, PKIX, and CMS seem pretty high
up the tree just now.

Just as I believe the security-interested people in the IETF need to
pitch
in to help other areas advance their specs, I also believe the I18N-
interested
people in the IETF need to help the security specs so the security
area can
advance its specs.  We are all in this together.

Yours,

Ran
[email-masked]
.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 10 Feb 2006 08:29:40 -0500

In message <[email-masked]>, RJ Atkin
>not technically difficult, though IETF processes can be very difficult

The issue is not adding the hash functions, it's adding the negotiation
to permit their use.

 		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 10 Feb 2006 07:20:37 -0800

I note that just because some dependencies are not yet
ready to be progressed to Draft Standard doesn't preclude
us from revising protocols as needed to address other
issues holding them at Proposed.  For instance, with
LDAP, we've resolved a host of issues requiring publication
of revised LDAP specifications.  These will get published
at Proposed in conjunction with revised TLS and SASL specs,
then pending implementation reports and other requirements,
we should get to Draft.

I also note that the formal Draft Standard declaration
is not nearly as important as resolution of the technical
issues that kept us at Proposed.  As these issues have been
adequately addressed, I'm quite happy.  The formalities
will catch up in due course.

That is, I really don't see a problem here. 

Kurt

At 05:00 PM 2/9/2006, Sam Hartman wrote:

>_______________________________________________
>saag mailing list
>[email-masked]
>http://jis.mit.edu/mailman/listinfo/saag

.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 10 Feb 2006 15:56:01 +0100

> behind the highest-hanging fruit (not to mention appallingly mangled

I don't think PKIX should be critical for TLS.  Look at TLS-PSK,
TLS-SRP and TLS-OpenPGP.  Decoupling TLS from PKIX fully would be a
good idea.  It would also help non-PKIX TLS mechanisms, which is also
good.

OTOH, to abolish draft seem like a better approach to me.  The market
doesn't seem to care if a document is at proposed or draft.  The
technical quality isn't better at higher standards level either.  Just
look at DNS.

The only people who seem to care about this separation is long time
IETF attendees, but they seem to have few instruments available to
apply pressure on others to write standards.  To make somebody write a
standard, there should be some incentive or at least some good reason
for doing the work.  It is not a compelling reason to ask "Well, don't
you want this document as Draft?".  I'm not sure I see any real reason
for spending the time on moving, say, IPSEC from proposed to draft.
For most organizations, it seems the time is better spent on improving
implementations (which will result in improvements to the standard
too, eventually).

Thanks,
Simon
.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 10 Feb 2006 10:37:18 -0600

Trimming down to Newtrk plus Ran (I don't know if Ran is on Newtrk, but all 
of the other process-ish discussants are - and Ran, please take this as a 
compliment, because it means you may have been doing real work :-)...

>  implementations" rule and apply that rule to "Full Standard".

There have been several two-stage suggestions previously, and I liked most 
of them, so I like Ran's particular variant, certainly as a starting point.

>  exception was granted in the particular case.

I have two comments here. One is that any time we have made noises like 
"gee, how 'bout we actually do what RFC 2026, and RFC 1620 before that, and 
RFC 1310 before that, say we're going to do, and bail all the old Proposed 
Standards to Historic if there's no energy to advance them", total panic has 
broken out.

Let me be very clear. We have never had time to do what our standards 
process says we do, except in exceptional cases. Extrapolating from roughly 
March 1992, I'm guessing that we never will. Proposals that assume a 
90-degree turn need to explain the physics that result in that turn.

I happen to like where Ran is headed, because I think (sighting along the 
top of his head forward), we would be headed to a place were we don't have 
as many active standards-track documents - but the ones we have, are the 
ones that we care about. For me personally, the DeCruft work was depressing 
because the criteria seemed to be, "well, if this RFC was FTPed over a 
satellite link, we have to make sure that 'no one on another planet might 
have been eavesdropping and might now be thinking about planning to use it' 
before we can move it to Historic". "No energy" means "no standard", given a 
certain amount of time. Doesn't make the documents vaportize, just tells the 
rest of the world that this once-Proposed Standard is getting no attention 
from anyone, so should realistically be "use at own risk".

Just FWIW, I'm not sure that the reclassification needs to be an IESG 
responsibility - we've had 13(ish) ADs put these protocols on the standards 
track, knowing full well that many of these protocols will be implemented 
and widely deployed; does it take 13 ADs to say, "well, maybe this document 
should advance"? Since the alternative seems to be encouraging people to pay 
no attention at all to standards maturity levels, perhaps "seems mostly 
harmless" would be an acceptable reason for an exception. But that's a side 
issue.

Second - and this is a way-detailed comment on Ran's proposal - I happened 
to notice http://standards.ieee.org/guides/bylaws/sect5.html#5.3, from 
another standards organization; their algorithm is "gotta look at every 
standard every five years and pick of (1) reaffirm, (2) revise, or (3) 
withdraw". We've sorta/kinda done the pass looking at the Proposed Standards 
that we wanted to withdraw. If we made another pass saying, "these are the 
ones we want to reaffirm; we think they are OK for advancement", we might be 
pretty close to what (I understood) Ran was proposing. And if the first-pass 
number was three years, and the extension was two years, that would give us 
the same horizon IEEE 802 uses (which doesn't make it right, but doesn't 
make it wrong, either).

Thanks,

Spencer 

.

---

From: John C Klensin <[email-masked]>
Date: Fri, 10 Feb 2006 11:38:01 -0500

> draft-loughney-newtrk-one-size-fits-all

Or 
   draft-ietf-newtrk-repurposing-isd

With explicit qualifying language about these cases (not just a
downref, about which I agree with Harald).  I don't see
"twostep" as being helpful to this problem, since there would
still be a downref problem.

or, if we can't solve this problem (for some plausible value of
"solve" without abandoning a multi-stage process, the
hypothetical

   draft-(hypothetical)-merger-ISO/IEC-JTC1/SCnn

More seriously, I continue to favor a rule that says that, if
someone has achieved wide deployment and interoperability
demonstrated in production implementations, we should write up
any concerns we have about the thing and then move the whole
business, list of concerns and all, directly to full standard.
It seems to me that we need to remember that, whether we have
one standards maturity level, or two or three or four, those
levels are tied to maturity of definition and interoperable
implementations, not to whether we recommend the thing.  We
still have "required/ recommended/ not recommended" in our
traditions somewhere, in spite of never assigning them any more.
One inference to be drawn from Sam's note is that we are
beginning to resemble a slapstick act: first we find a large
block and call it a "rule", then we put it in front of
ourselves, and then we trip over it and fall down.

Let's take TLS as an example.  No one serious can make a case
that it is not widely deployed, or that there are not multiple
implementations, or that those implementations are not
interoperable.  So it depends on some externalities that are not
resolved in a way that we'd consider optimal (such as a good PKI
structure) and we don't have completely satisfactory ways of
dealing with some issues.   So... document those observations as
risks, warn people that they should be aware of problems that
might occur in the future and that they should watch for an
improved "version N+1".  Then get it out there and put this to
rest.

The reality is that, if anyone really waited for things to meet
the IETF's current rules for full standards, we'd be running
telnet, FTP, email, and little else on the network -- at least
until someone deprecated them for not meeting those standards.

       john

p.s. FWIW, part of the original motivation for ISDs was to
provide a framework for developing and implementing this sort of
"document it and move on" approach.  That, and other things, got
lost in arguments about how much text belonged where, how much
work the IESG wanted to do, etc.   I lay good odds that if the
security area wants to block anything from moving to Draft
unless all of the relevant security protocols ducks have been
lined up and marched to Draft under the current rules, the
discussion of that will waste significantly more time.

.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 10 Feb 2006 06:52:33 -0800

One big issue we have with security protocols moving to draft is that
there is very little volunteer interest in testing SHOULD/MUST
interop beyond the basics (if even that). Our protocols have a lot of
SHOULDs that have nothing to do with interop and are very difficult
to test. But, even without those, the security area has been much
less active at voluntary interop testing than other areas, which
makes "going to Draft" not appealing. We are generally happy to cycle
at Proposed. Sam's message points out a significant ramification of
that attitude, although I don't have a proposed solution to the
problem.

--Paul Hoffman, Director
--VPN Consortium
.

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 10 Feb 2006 09:08:26 -0500

On  10 Feb 2006, at 08:33, Peter Gutmann wrote:
> what held up TLS at the RFC 2246 stage for what, three years?).

> Presumably IPsec will also block on PKIX.

ESP/AH do not depend on PKIX, and they ought not normatively depend
on IKE (or any other automatic key management method), so ESP/AH
should be able to move forward without PKIX.  Similarly, applications
that use ESP/AH, should be able to move forward when ESP/AH move
forward,
regardless of IKE (or PKIX).

The modular design of ESP/AH/ISAKMP/IKE was very deliberate -- because
the original designer of ESP/AH fully expected that the key management
schemes would need to change (given the past history of Diffie-Hellman
and Needham-Schroder in the published history up through 1995).

Cheers,

Ran
.

---

From: "Lucy E. Lynch" <[email-masked]>
Date: Fri, 10 Feb 2006 08:52:33 -0800 (PST)

> compliment, because it means you may have been doing real work :-)...

list admin note -  the following names were added to secondary posting 
this am to save wear and tear on your truely:

[email-masked]
[email-masked]
[email-masked]
[email-masked]

This means they can post, but won't see list traffic (at those 
addresses).

.

---

From: John C Klensin <[email-masked]>
Date: Fri, 10 Feb 2006 11:58:58 -0500

--On Friday, 10 February, 2006 10:37 -0600 Spencer Dawkins
<[email-masked]> wrote:

>...
> Second - and this is a way-detailed comment on Ran's proposal
> - I happened to notice
> http://standards.ieee.org/guides/bylaws/sect5.html#5.3, from
> another standards organization; their algorithm is "gotta look
> at every standard every five years and pick of (1) reaffirm,
> (2) revise, or (3) withdraw". We've sorta/kinda done the pass
> looking at the Proposed Standards that we wanted to withdraw.
> If we made another pass saying, "these are the ones we want to
> reaffirm; we think they are OK for advancement", we might be
> pretty close to what (I understood) Ran was proposing. And if
> the first-pass number was three years, and the extension was
> two years, that would give us the same horizon IEEE 802 uses
> (which doesn't make it right, but doesn't make it wrong,
> either).

The "five year rule" is one that ANSI imposes on all of its
accredited SDOs.  While it has some advantages, it has
observably had a few side effects.   First, in encourages
keeping what we call WGs around forever to maintain (and develop
new versions of) documents.   Second, those semi-permanent WGs
tend to develop feature-creep, and bad second- and third- and
fourth-system effects to justify their continued existence (and
perhaps fine lunches and dinners)... any standard can be made
"better" by adding a few additional features, right?  Sometimes
that process produces strict forward compatibility, sometimes it
doesn't, but it often does not yield the kind of extreme
protocol compatibility over time on which the Internet depends.
To use a favorite example that Ned Freed and I often cite, the
relationship between X.400(84) and X.400(88) --in which
communication between the two versions could occur only via
gateways and often with some information loss-- would be
difficult or impossible to develop in the IETF.  In ISO (and
ANSI SDOs and the ITU-T) it is, demonstrably, fairly easy.

So be a bit careful what you wish for here.

    john

.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 10 Feb 2006 17:03:16 -0500

>>>>> "RJ" == RJ Atkinson <[email-masked]> writes:

    >> Kerberos: Doable, but we're all fairly busy working on meeting
    >> new customer needs.  We did recently hold a meeting and develop
    >> feature matrix and roughly what we'd need to remove from the
    >> spec.  We were really hoping that RFC 4120 would not need
    >> things removed; I think a lot of us lost interest in moving
    >> Kerberos to draft any time soon when we found out that was not
    >> the case.

    RJ> If the issue is that not all features of 4120 are in at least
    RJ> 2 implementations, there are a couple of approaches.  One is
    RJ> to go find a sponsor to fund someone to add the missing
    RJ> feature(s) to either MIT Kerberos or Heimdal.  The other is to
    RJ> do what OSPF did with M-OSPF, move the not yet widely
    RJ> implemented (but perceived useful) items into a separate
    RJ> document so the main spec can advance more quickly.

I think there are one or two things we found that we need a second
implementation for.  That is relatively easy.  We found several items
that we'd left in from 1510 because they were harmless.  However they
are things like X.500 realm names that no one plans to implement and
that we don't have interop tests for.  They're not actually useful to
anyone so removing them is far better than implementing.

The challenge is to produce a spec revision that is sufficiently
focused.  I have lowe confidence that would happen.  Remember we're
talking about the same people (and I'm as guilty as anyone else in the
Kerberos group) who took 11 years to bring pk-init to the IESG.

--Sam

.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 10 Feb 2006 16:57:43 -0500

>>>>> "RJ" == RJ Atkinson <[email-masked]> writes:

    RJ> ESP/AH do not depend on PKIX, and they ought not normatively
    RJ> depend on IKE (or any other automatic key management method),
    RJ> so ESP/AH should be able to move forward without PKIX.
    RJ> Similarly, applications that use ESP/AH, should be able to
    RJ> move forward when ESP/AH move forward, regardless of IKE (or
    RJ> PKIX).

However BCP 107 argues that there should be few applications for which
ESP/AH is appropriate without automated key management.

I also suspect that ESP/AH depend on the architecture document.

.

---

From: Russ Housley <[email-masked]>
Date: Fri, 10 Feb 2006 17:28:12 -0500

CMS depends on PKIX, so it cannot advance until PKIX does.

Russ

.

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 10 Feb 2006 18:37:18 -0500

> I also suspect that ESP/AH depend on the architecture document.

I am sympathetic to the notion that no cryptographic system
is easy to use without automatic key management.  That said,
insisting that a mechanism can only progress jointly with its
(deliberately architecturally decoupled) key management method
mostly seems to increase our process gridlock in a way that
seems needless.

Given the note at the start of today which started this thread,
it seems wisest to keep ESP/AH (and the applications that depend
on them -- and probably the IPsec Arch document) de-coupled
from ISAKMP/IKE for advancement purposes.

There is a clear trade-off between being practical about solving
current issues versus being dogmatic about the ideal policy one
might prefer in an ideal world.  That trade-off is something that
the powers that be need to sort out among themselves.  I think the
tools are already in place so that ESP/AH, IPsec Arch, and their
dependent apps could all move rapidly to Draft Standard, without
waiting for IKEv2 to get sorted out -- if the powers that be wanted
to make that choice.  For openers, people continue to use IKEv1
even as IKEv2 is being sorted out.  IKEv1 is very widely deployed
and used these days.  ESP/AH can work with IKEv1 to have automatic
key management -- until IKEv2 gets sorted out or KINK gets sorted
out or some other better solution appears on the scene.

Cheers,

Ran

.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 10 Feb 2006 15:51:09 -0800

On Feb 10, 2006, at 8:38 AM, John C Klensin wrote:
>
> p.s. FWIW, part of the original motivation for ISDs was to provide  
> a framework for developing and implementing this sort of "document  
> it and move on" approach.  That, and other things, got lost in  
> arguments about how much text belonged where, how much work the  
> IESG wanted to do, etc.   I lay good odds that if the security area  
> wants to block anything from moving to Draft unless all of the  
> relevant security protocols ducks have been lined up and marched to  
> Draft under the current rules, the discussion of that will waste  
> significantly more time.

Agreed.

I would not mind creating another version of the SRD overlay  
approach, along with support scripts. If there is a desire to include  
notations and other items, that should not be a problem implement.   
Linking this with some type of database, (perhaps a moderated wiki)  
may provide timely information for the participants tracking issues  
currently in flux, and perhaps offer a repository for warnings and  
cautions.  Any major effort to revamp many documents will make  
referencing documents even more difficult, where these types of tools  
and overlays could provide some needed stability.

-Doug

.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 10 Feb 2006 20:18:04 -0500

Speaking from an IPsec point of view:
 - the majority of IPsec vendors are selling VPN.
 - few of us even have host implementations on which another protocol
   could really use our security service. (This in itself is very sad)
 - so, there is almost no market push for IPsec vendors to take a 
   further interest in the process. None of *our* customers would care.

Now, the vendors who do have host integrated implementations: KAME/BSD,
Solaris, Linux and Microsoft, might be persuaded to care, but in most
cases the upper layer protocols that want IPsec are still not part of
our portfolio. 

Which documents are waiting on IPsec to go to PS?
For which vendors is this a *market* problem for them?

- -- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 10 Feb 2006 21:47:24 -0500

>>>>> "RJ" == RJ Atkinson <[email-masked]> writes:

    RJ> Given the note at the start of today which started this
    RJ> thread, it seems wisest to keep ESP/AH (and the applications
    RJ> that depend on them -- and probably the IPsec Arch document)
    RJ> de-coupled from ISAKMP/IKE for advancement purposes.

    RJ> There is a clear trade-off between being practical about
    RJ> solving current issues versus being dogmatic about the ideal
    RJ> policy one might prefer in an ideal world.  That trade-off is
    RJ> something that the powers that be need to sort out among
    RJ> themselves.  

I think the community (and the leadership) have spoken on this issue.
I think we said that we all believe that automated key management is
really important from a technical standpoint.

I'd much rather have proposed standards that have automated key
management than draft standards that assume people will use manual
keying.

--Sam
.

---

From: Tony Hansen <[email-masked]>
Date: Sat, 11 Feb 2006 01:14:31 -0500

Is it time to move beyond volunteers? Perhaps we need to ask some
organization (ISOC? IGB? ????) if they would be willing to support an
effort to do the interop testing?

	Tony Hansen
	[email-masked]

.

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 11 Feb 2006 09:03:49 -0500

> management than draft standards that assume people will use manual

You can have draft standards with automated key management.
It only requires advancing IKEv1 separately from (in parallel with)
IKEv2.  If you'd like to do that but think the current rules
don't allow, then lets have a discussion about fixing the rules.

IKEv1 isn't going away anytime soon from the deployed world,
simply because it will take a while (probably years, if history
holds true) before there are multiple IKEv2 implementations
that can talk with each other, regardless of what the IETF does.
It took IKEv1 some number of years to reach that state, despite
active interoperability testing throughout that period.
So such a modest step as advancing the 2 versions of IKE
in parallel is not harming deployed security at all.

It is a choice that the IESG gets to make.

The bottom line is in your last paragraph, which basically says
that you are comfortable having a lot of application protocols
stuck at PS for a while, possibly years.

If that is true, why should ordinary IETF participants feel
much incentive to progress anything beyond PS ?

I'm not upset with anyone or any group, but I am greatly confused
by the thread of the past day or so.

Cheers,

Ran

PS:	Not speaking for my employer, but one of the observations
	from when I've occasionally been an end-user (ISP or
	other end user) is that the market need is for a stable
	openly published specification and for interoperability.
	The market does not care a great deal whether something
	is PS, DS, FS, or Informational.

PPS:	What Michael Richardson says, echos my PS just above,
	and sadly enough, has been true of the IPsec WG for
	almost 10 years now.

.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 11 Feb 2006 07:15:21 -0800

At 9:03 AM -0500 2/11/06, RJ Atkinson wrote:
>IKEv2.

That "only" assumes that there is interest in doing the work of 
testing every SHOULD and MUST; so far, there has not been. The "only" 
also assumes that there are multiple interoperable implementations of 
every SHOULD and MUST, which there is not.

>It is a choice that the IESG gets to make.

No, it is a choice that the IPsec community gets to make. In the over 
seven years since IKEv1 has been around, there has not been interest 
in testing for the purpose of advancing the category of the protocol.

>stuck at PS for a while, possibly years.

I read it differently: the IETF is willing to accept that some 
protocols will never advance in status because they rely on other 
protocols which will never advance in status. I don't see a lot of 
"comfort" there.

--Paul Hoffman, Director
--VPN Consortium
.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Feb 2006 09:12:05 +0100

> still be a downref problem.

John, my twostep draft explicitly allows downrefs in all cases.
That can be debated of course, but that was my proposal.
It also is completely compatible with an ISD like approach,
but doesn't require it to solve the downref problem.

    Brian

.

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 11 Feb 2006 09:03:49 -0500

Cheers,

Ran

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Feb 2006 09:22:16 +0100

Comments in line...

Spencer Dawkins wrote:
> Trimming down to Newtrk plus Ran (I don't know if Ran is on Newtrk, but 
> all of the other process-ish discussants are - and Ran, please take this 
> as a compliment, because it means you may have been doing real work :-)...
> 
> 
>> 1) Proposed Standard

This is pretty much draft-carpenter-newtrk-twostep so far
> 
> 
> There have been several two-stage suggestions previously, and I liked 
> most of them, so I like Ran's particular variant, certainly as a 
> starting point.
> 
> "gee, how 'bout we actually do what RFC 2026, and RFC 1620 before that, 
> and RFC 1310 before that, say we're going to do, and bail all the old 
> Proposed Standards to Historic if there's no energy to advance them", 
> total panic has broken out.
> 
> process says we do, except in exceptional cases. Extrapolating from 
> roughly March 1992, I'm guessing that we never will. Proposals that 
> assume a 90-degree turn need to explain the physics that result in that 
> turn.
> 
> I happen to like where Ran is headed, because I think (sighting along 
> the top of his head forward), we would be headed to a place were we 
> don't have as many active standards-track documents - but the ones we 
> have, are the ones that we care about. For me personally, the DeCruft 
> work was depressing because the criteria seemed to be, "well, if this 
> RFC was FTPed over a satellite link, we have to make sure that 'no one 
> on another planet might have been eavesdropping and might now be 
> thinking about planning to use it' before we can move it to Historic". 
> "No energy" means "no standard", given a certain amount of time. Doesn't 
> make the documents vaportize, just tells the rest of the world that this 
> once-Proposed Standard is getting no attention from anyone, so should 
> realistically be "use at own risk".

I disagree. As we saw during the multiple last calls and reviews of
the decruft draft, there are lots of old PS documents that are claimed
to be in active use and I'm willing to bet we missed one or two. Why
cause hassle and annoy people by blindly demoting them?

My twostep draft explicitly removes the notion that staying for ever
in PS is a bug. I still believe that by reducing the number of stages
from 3 to 2 we would make it significantly more attractive to people to
make the effort to produce implementation reports, because by
doing so they would achieve "final status". But I don't think automatic
demotion of standards would cause anything but annoyance.

Incidentally, I wrote the twostep draft before I became the responsible
AD. Is there anybody out there who would like to take over as
author? xml2rfc source is available.

     Brian
> responsibility - we've had 13(ish) ADs put these protocols on the 
> standards track, knowing full well that many of these protocols will be 
> implemented and widely deployed; does it take 13 ADs to say, "well, 
> maybe this document should advance"? Since the alternative seems to be 
> encouraging people to pay no attention at all to standards maturity 
> levels, perhaps "seems mostly harmless" would be an acceptable reason 
> for an exception. But that's a side issue.
> 
> Second - and this is a way-detailed comment on Ran's proposal - I 
> happened to notice 
> http://standards.ieee.org/guides/bylaws/sect5.html#5.3, from another 
> standards organization; their algorithm is "gotta look at every standard 
> every five years and pick of (1) reaffirm, (2) revise, or (3) withdraw". 
> We've sorta/kinda done the pass looking at the Proposed Standards that 
> we wanted to withdraw. If we made another pass saying, "these are the 
> ones we want to reaffirm; we think they are OK for advancement", we 
> might be pretty close to what (I understood) Ran was proposing. And if 
> the first-pass number was three years, and the extension was two years, 
> that would give us the same horizon IEEE 802 uses (which doesn't make it 
> right, but doesn't make it wrong, either).
> 
> Thanks,
> 
> Spencer
> 
> .

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 11 Feb 2006 10:24:54 -0600

I have an inline comment further down, but just as prelude ... am I the only 
person who thinks that we are wedged in the least reasonable standards track 
structure, and that almost any change we make would be more reasonable 
(especially if we actually started to do what the process says we do)?

I happened to like the twostep draft, because I thought it would be an 
improvement. I also liked a lot of other drafts that have been banging 
around in Newtrk, because I thought they would also be improvements.

From: "Brian E Carpenter" <[email-masked]>

>> top of his head forward), we would be headed to a place were we don't 
>> have as many active standards-track documents - but the ones we have, are 
>> the ones that we care about. For me personally, the DeCruft work was 
>> depressing because the criteria seemed to be, "well, if this RFC was 
>> FTPed over a satellite link, we have to make sure that 'no one on another 
>> planet might have been eavesdropping and might now be thinking about 
>> planning to use it' before we can move it to Historic". "No energy" means 
>> "no standard", given a certain amount of time. Doesn't make the documents 
>> vaportize, just tells the rest of the world that this once-Proposed 
>> Standard is getting no attention from anyone, so should realistically be 
>> "use at own risk".
>

I may have misunderstood, but I thought one of the challenges of decruft was 
communities who did their work in the IETF, deployed a protocol, and went 
home victorious - ten or fifteen years ago, leaving a standards-track RFC 
hanging at PS.

To use one example (cited by Pekka), do we think that anyone in the X.25 
community would be hassled or annoyed when RFC 1381 and RFC 1382 move to 
historic? People may be using X.25 MIBs in operational networks every day, 
but is any purpose served when we continue to carry these specifications in 
the same category as RFC 3261 (SIP)?

If the RFC Editor was looking to our standards classifications as a clue 
about removing RFCs from the RFC repository, so Historic specifications 
might actually evaporate, I could better understand our hesitation, but 
since we have almost every RFC ever issued still available online, plus the 
Internet Engineering Note series, I just don't "get it". Sorry.

> demotion of standards would cause anything but annoyance.

I don't think that hanging in PS forever has to be a bad thing, but it's a 
bad thing now, because it's documented as a bad thing in 2026.

But as to whether it's a good thing ... OK, let's hypothetically assume that 
someone becomes interested in working on protocol specifications now. I 
believe that this hypothetical newbie has a pretty steep learning curve 
ahead, and the forest of specifications on the standards track won't help 
with that learning curve.

So I'm wondering why annoying people who no longer participate in IETF 
matters more than annoying people who do?

Thanks,

Spencer 

.

---

From: John C Klensin <[email-masked]>
Date: Sat, 11 Feb 2006 12:29:20 -0500

--On Saturday, 11 February, 2006 09:12 +0100 Brian E Carpenter
<[email-masked]> wrote:

>> With explicit qualifying language about these cases (not just
>> a downref, about which I agree with Harald).  I don't see

Sorry, I obviously wrote too quickly to be clear.  I believe
that "no downrefs with an exception procedure" (i.e., what we
have today plus or minus quibbles) is a necessary element of
preserving a multiple-step standards process.  Without it, I
think things rapidly deteriorate to single-step whether that is
the intention or not.  I think the model of RFC 3967 is one way
out of the trap your draft identifies.  I think that there could
be several other models, including a requirement to explicitly
document what is being done in, e.g., an annotation to the
reference that became part of the Last Call review.  Some would
consider that a streamlining of the 3967 procedure, others as
closer to "just do the downref and don't worry about it".

But, in any event, what I intended by "... still be a downref
problem..."  was "we would still need to sort out what to do
about those cases".  Obviously, if your twostep draft were
adopted without alteration or further discussion, that problem
would be eliminated but I didn't see that happening and, at the
moment, that draft is as dead as the ISD one(s).

best,
     john

.

---

From: Sam Hartman <[email-masked]>
Date: Sat, 11 Feb 2006 13:34:21 -0500

>>>>> "Paul" == Paul Hoffman <[email-masked]> writes:

    Paul> That "only" assumes that there is interest in doing the work
    Paul> of testing every SHOULD and MUST; so far, there has not
    Paul> been. The "only" also assumes that there are multiple
    Paul> interoperable implementations of every SHOULD and MUST,
    Paul> which there is not.

Testing every should and must is not required.  You need to test every
protocol feature.
That is a   simpler  task.
However I suspect there still is not interest in doing that.

--Sam

.

---

From: Sam Hartman <[email-masked]>
Date: Sat, 11 Feb 2006 13:50:46 -0500

John, I will observe that I have found significant value in going back
and making the revisions to specifications to address clarity problems
based on deployment and to remove unused features.  I'we witnessed
this with IPsec and participated in many years of it with Kerberos.
I'm also involved in the current effort of this form with SASL.  I
agree that this process is critical to the IETF's success.

I cannot say however that I have seen significant value in waiting for
references.  If a spec is clear enough that you can get multiple
interoperable implementations and can document that fact, it seems
like you've said something about the normative references.  I'm not
quite sure what that something is, but I think it is sufficient.

In effect, I'm saying that the pragmatic test of "are the downrefs
good enough that we can get multiple interoperable implementations
without cringing," is a good enough test.  For that reason, I believe
that there is little value in requiring people to go out of their way
for down references.  There probably i value in allowing specific
objections of the form "that downref isn't of sufficient quality to
understand this spec."

--Sam If you disagree, I'd ask you to focus in your disagreement on
how the down reference rules improve the quality of our specifications
in practice.

.

---

From: Douglas Otis <[email-masked]>
Date: Sat, 11 Feb 2006 12:16:02 -0800

On Sat, 2006-02-11 at 12:29 -0500, John C Klensin wrote:
>
> Obviously, if your twostep draft were adopted without alteration or
> further discussion, that problem would be eliminated but I didn't see
> that happening and, at the moment, that draft is as dead as the ISD
> one(s).

Reference stability is likely of comparable merit to that of references
to documents at various levels of classification.  The ISD proposal at
least attempted to provide stable user-friendly references, and the SRD
attempted something very similar, but with less effort.  Apparently,
still too much or too messy.

Would the IESG consider a mechanical updating of documents to replace
all RFCXXXX names with a hierarchical 

	{order}.<family>.<genus>.<version>. 

This may require converting existing RFCs into a form that can generate
new outputs as discussed on the IETF mailing list. 

Naming could be compared to an attempt to compose a set of books where
an RFC represent a chapter.  Once a family/genus name is created for
each RFC, a script could provide the substitution, together with the
renamed xml bibliography.  Lookups for RFCXXXX could reference to the
new name.  Depending upon the status of the RFC, it could be organized
into different {orders} such as IS/PS.

-Doug

.

---

From: Joe Touch <[email-masked]>
Date: Sat, 11 Feb 2006 14:01:37 -0800

Sam Hartman wrote:
> Testing every should and must is not required.

That seems odd; what is sufficient protocol testing if not to validate
the MUST and MUST NOTs?

Joe

---

From: John C Klensin <[email-masked]>
Date: Sat, 11 Feb 2006 17:29:39 -0500

--On Saturday, 11 February, 2006 13:50 -0500 Sam Hartman
<[email-masked]> wrote:

> John, I will observe that I have found significant value in
> going back and making the revisions to specifications to
> address clarity problems based on deployment and to remove
> unused features.  I'we witnessed this with IPsec and
> participated in many years of it with Kerberos. I'm also
> involved in the current effort of this form with SASL.  I
> I cannot say however that I have seen significant value in
> waiting for references.  If a spec is clear enough that you
> can get multiple interoperable implementations and can
> document that fact, it seems like you've said something about
> the normative references.  I'm not quite sure what that
> something is, but I think it is sufficient.
> 
> In effect, I'm saying that the pragmatic test of "are the
> downrefs good enough that we can get multiple interoperable
> implementations without cringing," is a good enough test.  For
> that reason, I believe that there is little value in requiring
> people to go out of their way for down references.  There
> probably i value in allowing specific objections of the form
> "that downref isn't of sufficient quality to understand this
> spec."

I think we agree, or at least nearly so.  All I propose is that
we make an effort to distinguish between references that are
presumed to be of the same quality and maturity as the
specification under consideration and those that are not.  For
that latter, I think that, in the interest of stability and
retention of meaning when the referenced documents are updated,
we need to make a reasonable effort to document the level of
stability.  I don't think that documentation process need be
extensive.  Statements such as "the use of this for option N
within this document seems sufficient while that for option M is
less certain" or "this document is under review and may be
updated, but the reference from this specification applies
specifically to the text in section XX; any revisions to that
referenced spec do not apply to this standard" or "the
referenced specification is under revision, but this
specification depends on the interpretation of that reference as
documented in the so-far-unapproved revisions" should be
sufficient.

> --Sam If you disagree, I'd ask you to focus in your
> disagreement on how the down reference rules improve the
> quality of our specifications in practice.

I think the situation is very different from the established and
deployed specification you posit above and a relatively newer
piece of work.   For the former, information about how stable
the technology is on which the specification depends may be
important, but mostly for distinguishing boundaries and the
details of dependencies.  For the latter, that same information
may be critical in making decisions about what to implement and
when. Watch for a draft.

    john

.

---

From: Pekka Savola <[email-masked]>
Date: Sun, 12 Feb 2006 17:45:54 +0200 (EET)

> Testing every should and must is not required.  You need to test every

Depends on what you call a 'feature'.  For example, a protocol might 
have a MUST discard clause for certain malformed, insecure or spoofed 
packets.  If an implementation under testing does not implement that 
MUST, the outcome of the testing might be unspecified and we don't 
really know how compliant implementations would perform.  Testing 
SHOULDs have similar, but slightly different implications: two 
compliant implementations might (but where at least one doesn't 
implement a SHOULD) not be enough to know if all the acceptable 
combinations would work.

I think the main issue here the motivation for pushing specs along on 
the standards track.  If we do it to demonstrate that the spec is 
known to interoperate under rigorous testing and be relevant to be 
implemented in its entirety, detailed reports could be very useful. 
If the motivation is to just obtain a status level and/or allow 
normative referencing by other specs, it is not so useful.

With the current 3-level standards track and downref rules, I'd 
propose that Draft Standards should not require very detailed 
implementation reports, but that getting to Full Standard should. If 
we eliminate one step and/or remove downref rules, I'd vote for 
requiring sufficiently detailed interoperability and implementation 
reports.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 12 Feb 2006 11:26:55 -0500

Pekka, we don't do or require conformance testing.  We do not 
actually ask whether the implementations "conform" to the 
specification.  We ask whether the implementations implement the 
feature, and whether they interoperate.
Features are usually understood to be larger granularity than each 
individual MUST or SHOULD in the document.
(That still produces a lot of features in a protocol like OSPF or BGP.)
Specifically, we do not require testing of every boundary condition 
and error case identified in the RFC for advancement.
The description for the testing is usually "thorough", but not 
"rigorous".  We do generally put together test descriptions to make 
sure we covered all of the options in all of the features.

Full standard does not require more testing than draft.  It requires 
more real world experience.

Yours,
Joel M. Halpern

At 10:45 AM 2/12/2006, Pekka Savola wrote:
>have a MUST discard clause for certain malformed, insecure or 
>spoofed packets.  If an implementation under testing does not 
>implement that MUST, the outcome of the testing might be unspecified 
>and we don't really know how compliant implementations would 
>perform.  Testing SHOULDs have similar, but slightly different 
>implications: two compliant implementations might (but where at 
>least one doesn't implement a SHOULD) not be enough to know if all 
>the acceptable combinations would work.
>
>I think the main issue here the motivation for pushing specs along 
>on the standards track.  If we do it to demonstrate that the spec is 
>requiring sufficiently detailed interoperability and implementation reports.
>
>--

.

---

From: Larry Masinter <[email-masked]>
Date: Sun, 12 Feb 2006 17:57:23 -0800

> implement a SHOULD) not be enough to know if all the acceptable 

http://www.ietf.org/internet-drafts/draft-ietf-newtrk-interop-reports-00.txt

proposes creating a separate Protocol Feature Set which identifies
what constitutes the "features" for a protocol.

It is consistent with one-step or two-step or three-step, and might
even be a way of migrating gradually between those.

Larry

.

---

From: <[email-masked]>
Date: Mon, 13 Feb 2006 05:49:34 +0200

Hi all,

>draft-loughney-newtrk-one-size-fits-all

I've been lurking on this thread, but just had to add 2 cents.  In
various
discussions, I can understand the need for a 3-step process at an
abstract
level, but practically, I don't see the need.  I think that we roughly
need something like "This is what recommend to be deployed" and "we
think
this is right, but there might be a few kinks still left to work out" - 
which I would propose to be a nice split between "Standard" and
"Experimental".
There is nothing preventing us from revising "Standard" documents with
bug
fixes, feature drops, etc.  We do that already.  There are a large
number of
protocols that get revised at proposed and stay that way.

I guess, at the end of the day, what we do is dependent upon what we
want.
Most of the discussion on the ISD (and relatated) proposal is that we
don't
think potential result is worth the effort.

John

.

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 13 Feb 2006 21:08:36 +1300

Simon Josefsson <[email-masked]> writes:
>I don't think PKIX should be critical for TLS.  Look at TLS-PSK, TLS-SRP and
>TLS-OpenPGP.

All of those combined are buried in the noise floor compared to use of
certificates with TLS:

TLS-PSK: Really only accepted as something for low-powered devices (although I
         disagree with this use).

TLS-SRP: Amost never used due to patent concerns.
TLS-PGP: Never used (or at least there's probably some experimental
         implementation somewhere, but I'm not aware of it).

>Decoupling TLS from PKIX fully would be a good idea.  It would also help non-
>PKIX TLS mechanisms, which is also good.

I think it'd be a good idea too, but it'll never happen in practice.  You'd
have to convince several million web sites with several hundred million
dollars tied up in infrastructure to change, which is never going to happen.
Currently every one of them will still do SSLv3 at the drop of a handshake
option, which wasn't even an RFC, let alone a standards-track one.

Peter.
.

---

From: Sam Hartman <[email-masked]>
Date: Sun, 12 Feb 2006 15:20:08 -0500

Remember the goal of the implementation report is to test the
specification and make sure it is clear enough to create two
interoperable implementations.  We are not doing conformance testing;
we are not doing interoperability testing of the implementations.
We're simply trying to determine if the spec is good enough that you
can create interoperable implementations from it.

At least when I've asked other IESG members about this it explicitly
means that you don't check error paths involving data that a
conforming implementation cannot generate.

Conformance testing is very useful and the kind of testing we've done can be a useful in developing conformance tests.

But please let's not make the job harder than it has to be.

.

---

From: Sam Hartman <[email-masked]>
Date: Sun, 12 Feb 2006 21:42:49 -0500

>>>>> "Larry" == Larry Masinter <[email-masked]> writes:

    Larry> http://www.ietf.org/internet-drafts/draft-ietf-newtrk-interop-reports-00.txt

    Larry> proposes creating a separate Protocol Feature Set which
    Larry> identifies what constitutes the "features" for a protocol.

    Larry> It is consistent with one-step or two-step or three-step,
    Larry> and might even be a way of migrating gradually between
    Larry> those.

As a side note, we found this analysis (based on an early draft of
your work) very useful in creating a feature matrix for Kerberos.

.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 14 Feb 2006 11:05:16 -0800

On Feb 12, 2006, at 7:49 PM, <[email-masked]>  
<[email-masked]> wrote:
> various discussions, I can understand the need for a 3-step process  
> at an
> abstract level, but practically, I don't see the need.  I think  
> that we roughly need something like "This is what recommend to be  
> deployed" and "we think this is right, but there might be a few  
> kinks still left to work out" -  which I would propose to be a nice  
> split between "Standard" and "Experimental". There is nothing  
> preventing us from revising "Standard" documents with bug fixes,  
> feature drops, etc.  We do that already.  There are a large number  
> of protocols that get revised at proposed and stay that way.
>
> I guess, at the end of the day, what we do is dependent upon what  
> we want. Most of the discussion on the ISD (and relatated) proposal  
> is that we
> don't think potential result is worth the effort.

As RFC documents increase in number, and become modified again and  
again, the increased entropy makes reviewing or understanding what is  
involved with a particular endeavour increasingly difficult.  Down  
referencing is just one aspect of the problem.  A document naming  
convention or a reference overlay like SRD sits atop the profusion of  
numbered documents and adds clarity and reference stability.  This  
only needs a directory to publish relational documents by those so  
motivated.  In the case of naming or the named linking of related  
documents, the overview needed should be minimal.

Rather than viewing this problem from the perspective of the auto  
mechanic who has memorized relevant part numbers, for the typical  
person looking for a part however, user-friendly listings are  
extremely helpful.  The named organization effort would be done one  
time, but the benefits are accumulative.  Even the mechanic has been  
known to overlook a part number update.

-Doug

.

---

From: <[email-masked]>
Date: Wed, 15 Feb 2006 15:06:57 +0200

Doug

>> want. Most of the discussion on the ISD (and relatated) proposal is 
>> that we don't think potential result is worth the effort.
>
>As RFC documents increase in number, and become modified again 
>and again, the increased entropy makes reviewing or 
>understanding what is involved with a particular endeavour 
>increasingly difficult.  Down referencing is just one aspect 
>of the problem.  A document naming convention or a reference 
>overlay like SRD sits atop the profusion of numbered documents 
>and adds clarity and reference stability.  This only needs a 
>directory to publish relational documents by those so 
>motivated.  In the case of naming or the named linking of 
>related documents, the overview needed should be minimal.
>
>Rather than viewing this problem from the perspective of the 
>auto mechanic who has memorized relevant part numbers, for the 
>typical person looking for a part however, user-friendly 
>listings are extremely helpful.  The named organization effort 
>would be done one time, but the benefits are accumulative.  
>Even the mechanic has been known to overlook a part number update.

I think that's what we have been thinking wrt the ISD/SRD proposals,
but I don't think we've had great buy-in from the larger community.

John

.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 15 Feb 2006 09:35:59 -0800

On Feb 15, 2006, at 5:06 AM, <[email-masked]>  
<[email-masked]> wrote:
>
>
> I think that's what we have been thinking wrt the ISD/SRD  
> proposals, but I don't think we've had great buy-in from the larger  
> community.

At the last newtrk meeting, the majority of those attending did see  
merit in the SRD proposal.  Since then, DTD and XSLT script have been  
published with the draft to auto-generate HTML versions of the SRD  
overlays, utilizing present xml bibliography databases.  This draft  
is at the beginning of its development.  From the first meeting,  
issues remaining were whether there should be an option to add  
notes.   Details related to naming and numbering should receive  
greater review as well.  Once newtrk made these decisions, setting up  
a repository for both working and accepted SRD overlays would allow  
the experiment to begin.  Only then, allowing SRD overlays to provide  
a _real_ service, would buy-in across the larger community be  
discernible, especially when the needed tools and IETF directories  
are made available.

The next IETF meetings dropped newtrk from the schedule.  Why was  
this SRD effort curtailed when the WG seemed in favor of pursing the  
concept?  Surely, IESG overview of simple SRD overlays would not be  
too demanding.  These overlays should even assist with their other  
duties.

-Doug

.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 16 Feb 2006 10:20:09 -0500

>>>>> "Jari" == Jari Arkko <[email-masked]> writes:
    Jari> o Desire to address a number of issues in one go.  For
    Jari> instance, produce a "bis" revision along with adding features
    Jari> 1, 2, and 3. I would suggest a stepwise approach would be
    Jari> better. Take small steps, but take them often. As an example,

  As I've said before --- we made this mistake with IKEv1->IKEv2.

    Jari> o Lack of editor and other participant resources for the
    Jari> work. I suspect timely completion of spec revisions has an
    Jari> impact on the availability of people to do the work. For
  
  There is another factor here -- it's hard to make a small change to an
existing document because the .xml file isn't available. (Or may never
have existed).

  And the nroff source that the rfc-editor used, won't match.

    Jari> o Lack of interoperability testing of all features.  If this
    Jari> situation persists, I don't think its just a question about
    Jari> interop events or even funding.  Its a more fundamental issue
    Jari> about specs matching the needs of the world. Personally, I

  Interop events and funding *ARE* important issues.

  Lots of people want open source reference implementations --- it's
hard to fund this. Even if you assume the people are free (they aren't),
you can't afford to attend meetings, interop events. etc. without funding.
  
    Jari> like small base specs accompanied with a number of optional
    Jari> extensions. They are a bit harder to read, but the tradeoff
    Jari> wrt publication speed is well worth it.

  I agree strongly. Make people plan for new features being added,
rather than adding them.  Mostly, we do a good job here, but not
always. 
  
    Jari> I would also suggest pursuing the IKEv2 clarifications (is the
    Jari> result a "bis"?) work as soon as possible, and not adding new
    Jari> features during that process.

  I agree.

- --

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Feb 2006 15:44:02 +0100

Douglas Otis wrote:

...
> The next IETF meetings dropped newtrk from the schedule.  Why was  this 
> SRD effort curtailed when the WG seemed in favor of pursing the  
> concept?  Surely, IESG overview of simple SRD overlays would not be  too 
> demanding.  These overlays should even assist with their other  duties.

SRDs haven't been discussed in the IESG. Right now we need to figure out
a higher level view of where newtrk should go, and I've asked Scott Bradner
to address that in the General Area open meeting planned for Dallas.

    Brian

.

---

From: Eric Rosen <[email-masked]>
Date: Fri, 17 Feb 2006 10:46:53 -0500

> Right now we need to figure out a higher level view of where newtrk should
> go, 

How about shutting it down due to lack of productivity? 

I guess I'd like to understand why  a new "higher level view of where newtrk
should go" is going to be any more effective than the old view. 

Newtrk has demonstrated all the worst "design by committee" problems.  Every
possible point of view seems to  have a constituency, and since there are no
technical facts in  dispute, there is no way to determine,  with any sort of
objectivity, who  is right.  The initial  goal was to  simplify the official
process and  make it more  like what we  really do.  Naturally, many  of the
proposals  ended up  trying  to make  it  even more  complicated, by  adding
additional layers (workgroup snapshort, srds, etc.).

Of course, there was the very productive effort to go through all the telnet
options and figure out which ones  need to be reclassified as historical ;-)
I'm sure the Internet is working much better as a result of that effort.

This has  really been  a classic case  of a  WG that runs  wild (even  if in
circles)  and cannot  maintain its  focus on  the problem  that needs  to be
solved.  
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 17 Feb 2006 10:23:52 -0600

From: "Eric Rosen" <[email-masked]>

> How about shutting it down due to lack of productivity?

I wish Eric's suggestion was less reasonable than it is, but it's a 
reasonable suggestion.

(rest of justified rant deleted)

So, I guess the metaquestion would be, do we actually need to make any 
changes to the standards process at all, or is simply ignoring the 
inconvenient parts of the current process the best path forward?

And the meta-metaquestion would be, do people look to IETF for standards, or 
simply for specifications?

Thanks,

Spencer 

.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 17 Feb 2006 17:52:10 +0100

> How about shutting it down due to lack of productivity?
Well, it's not been entirely unproductive.  And as you point out, some
of the problem lies with the IESG's inability to take any sort of
responsibility in this space.  They think it ain't broke, by in large. 
I think there are a few obvious breaks.  2026 is in dire need of a
rewrite.  Either there is a distinction between PS and standard or there
is not.  Either the IESG follows  the rules we set out in that document
or we should remove them.  The problems aren't technical.

Eliot
.

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 17 Feb 2006 12:54:35 -0800 (PST)

>>>>> On Fri, 17 Feb 2006, Eric Rosen wrote:
Eric> > Right now we need to figure out a higher level view of where
Eric> > newtrk should go, 
Eric> 
Eric> How about shutting it down due to lack of productivity? 

>>>>> On Fri, 17 Feb 2006, Spencer Dawkins wrote:
Spencer> I wish Eric's suggestion was less reasonable than it is, but
Spencer> it's a reasonable suggestion.

I am afraid that I have to agree.

Eric> [ ... ] The initial goal was to simplify the official process
Eric> and make it more like what we really do.  Naturally, many of the
Eric> proposals ended up trying to make it even more complicated, by
Eric> adding additional layers (workgroup snapshort, srds, etc.).

There is exactly one proposal on the table that would simplify the
process and make it more like what we really do, and that proposal
is draft-loughney-newtrk-one-size-fits-all.  I think the WG should
either adopt that proposal and send it out for IETF last call or
else admit defeat and close up shop.

//cmh

.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 17 Feb 2006 13:43:40 -0800

> Eric> adding additional layers (workgroup snapshort, srds, etc.).

sigh.

> else admit defeat and close up shop.

Tracking document relationships with the SRD overlay conveys the  
endeavour affected by a proposed change.  Clearly, the present  
document classification has not been effective at communicating the  
status for a set of documents as related to a particular endeavour.   
Within a particular endeavour, there might be a stable set of  
documents and a newer set of documents proposing a modification to  
overcome some issue.  With the SRD approach, there is a way to ensure  
these different sets of documents can be discerned.  Rating those  
document sets should be based upon interoperability, which makes the  
two-step approach appear more appropriate.  As any document can  
appear within multiple sets of documents at any point in time, these  
two ratings would be best done at the set level (the SRD level).   
This would then suggest, for RFCs, fewer distinctions are needed.   
Even the SRD overlay provides a category for experimental components  
within the set.

I could agree with both the one-size at the RFC, and the two-step at  
the SRD.  The SRD overlay is not complicated.  Newtrk should ensure  
this scheme is clear and straight forward.  Providing the tools to  
start this transition does not need to wait for documents that define  
one-size or two-step however.

-Doug

.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 17 Feb 2006 15:56:26 -0800

Hello folks,

I've been lurking on the mailing list for all these many months.
It seems there is rough consensus that the standardization
process is broken.  I certainly think so.  If it cannot be fixed,
then I guess there are even more problems than I thought.

Regards,
Charlie P.

.

---

From: John C Klensin <[email-masked]>
Date: Sat, 18 Feb 2006 10:57:12 -0500

--On Friday, 17 February, 2006 10:23 -0600 Spencer Dawkins
<[email-masked]> wrote:

> I wish Eric's suggestion was less reasonable than it is, but
> it's a reasonable suggestion.
>...
> So, I guess the metaquestion would be, do we actually need to
> make any changes to the standards process at all, or is simply
> ignoring the inconvenient parts of the current process the
> best path forward?

I disagree.  I think the critical-path metaquestion is "is it
possible to make significant and substantive changes to the
standards process without first making significant and
substantive changes to the process by which standards process
changes are reviewed and approved"?    If the answer is "yes",
then we need to look elsewhere for the causes of paralysis in
newtrk, perhaps looking at your proposed metaquestion above.
If the answer is "no", then we should either give up or start
looking at some of the more radical reorganizational proposals
that have gone quietly into limbo.

     john

.