Subject: [newtrk] Re: BCP 61, advancing to draft

From: [email-masked] (Peter Gutmann)
Date: Mon, 13 Feb 2006 22:48:35 +1300

Simon Josefsson <[email-masked]> writes:
>[email-masked] (Peter Gutmann) writes:
>>>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.
>
>I don't see how that is related to having TLS depend normatively or
>informatively on PKIX.  The TLS protocol can be decoupled from the
>certificate types used.

How?  TLS, at least as used with HTTP (which is probably about 99% of it use)
is synonymous with X.509 PKI.  By "decouple" do you mean replace the current
explicit use of X.509 certs with generic language describing an abstract
certificate type, and then assume that everyone knows that the abstract
certificate type is actually meant to be X.509 even though it's not made
explicit?

(Incidentally, you run into additional problems with TLS extensions, which
reference a pile of X.509 cert mechanisms).

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

---

From: "Robert Snively" <[email-masked]>
Date: Fri, 17 Feb 2006 11:47:36 -0800

The basic problem is that these problems are not going to go away.

There is either a procedure that works and is followed, or there
is a set of customs that are ignored as desired.  What we have
documented is the former, and what we do is the latter.

Why not simply document the customs as the new procedures.

That would be basically a one step standards process with the
possibility
of converting some documents to a "maintenance" or a "super-approved"
state.  This one step standards process is to some extent a consequence
of the
concept of short-term focused working groups.  Without a longer term
group, there is little capability to carry on subsequent standardization
steps.

So whether we close newtrk or not, the problems will remain until
some action fixes them.

Bob

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Eric Rosen
Sent: Friday, February 17, 2006 7:47 AM
To: Brian E Carpenter
Cc: NEWTRK Mailing List
Subject: Re: [newtrk] Re: BCP 61, advancing to draft

> 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: "C. M. Heard" <[email-masked]>
Date: Sun, 19 Feb 2006 21:47:05 -0800 (PST)

On Sun, 19 Feb 2006, Brian E Carpenter wrote:
> Well, I politely disagree, because there is also the twostep proposal
> around, which I am hoping will shortly reappear with a new editor.
> 
> My belief is that twostep is closer to the consensus that prevailed
> at the newtrk BOF, i.e. it keeps the "running code" notion alive
> but without creating unrealistic expectations.
> 
> However, I'd certainly like to see a real debate between these
> two approaches, which we've never had.

Two points:

1.) What we do today, most of the time, to put stuff to PS and leave
it there.  Ergo, one-size-fits-all is closer to prevailing practice
that twostep.

2.) We still have the ludicrous situation of stuff like IANA procedures
sometimes being put up for PS, when it should be BCP, since it cannot
in principle enjoy multiple implementations.  I pointed out an example
recently on this list.  one-size-fits-all cures this problem neatly.

3.) I recently pointed out some examples in the MIB area where the
multistep process resulted in fractured specs or needed work not
getting done.  one-size-fits-all cures this problem, too.

The "running code" notion sounds good, but we don't really practice
it most of the time, have a hard time figuring out how in certain
cases, and in other cases shoot ourselves (or the community) in the
foot when we try.  We have a model of what we _can_ do.  That's
one-size-fits-all.  Let's put it down on paper and get back to work.

//cmh

> Spencer Dawkins wrote:
> >[C. M. Heard wrote:]
> >> 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.
> > 
> > 
> > Hi, John,
> > 
> > To be perfectly correct at this time, our draft would be a proposal 
> > UNDER the table, since it expired in January.
> > 
> > Do you still have the XML around for a respin? I'm not finding my own 
> > copy (sorry!).
> > 
> > Spencer
> > 
> 

.