Re: Facts, please, not handwaving [Re: Its about mandate RE: Why cant the IETF embrace an open Election Process]

[Dave Crocker]

I would argue that "Proposed Standard" as the end-of-the-line
in our standardization process is just wrong.  I certainly can see
an argument for merging "Proposed" and "Draft" - but there are lots
of indications that even the simplified one-step process of moving 
from Draft to full Standard would not get done much of the time.


The reality of the current IETF is that we view publishing a Proposed 
specification as an indication of success.  That is, we think it is an 
ending, rather than a beginning.


A minor problem with this is that we have no sense of what IETF actually 
gets deployed and used, and what doesn't. This leaves us exposed to 
developing  very unrealistic feeling about our current impact on the 
Internet.


(The status of Historic is not relevant to this question, since it is 
applied only erratically and long after a specification has demonstrated 
that it is not useful...any more.)


What we need is a more immediate basis for assessing current utility of 
recent IETF work.


That's why I keep suggesting that we set a time-limit for deployment and 
use of Proposed specifications.  Those failing to garner the necessary 
community support automatically go to Historic.  Those that succeed go 
to Full.


Of course, such a mechanism would require that the IETF community 
actually step up and take affirmative responsibility for whether our 
output gets used.


d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: security features.... (Re: Facts, please)

[Russ Allbery]

Hallam-Baker, Phillip <[EMAIL PROTECTED]> writes:

> I think the question starts with a false premise, that the security
> layer should be in HTTP. Since HTTP is the new IP this makes no more
> sense than having authentication at the IPSEC layer.

> The place for the authentication layer is actually HTML and that is out
> of scope. Moreover there has to be deep level support in the O/S if the
> authentication layer is going to be robust.

There are reasons to provide security at multiple layers.  Security at the
HTTP layer is better if the purpose is to prevent unauthorized people from
retrieving resources via HTTP.  Security at the HTML layer is better for
some applications where you want to authenticate the server content to the
browser and are trying to prevent phishing.

You may scoff at doing security at the HTTP layer, and yet nearly everyone
who maintains HTTP content that requires authentication does exactly that,
usually by putting more weight on cookies than they were really designed
to bear and sometimes by (ab)using other HTTP headers (cf Negotiate-Auth).
The small handful of exceptions mostly instead do authentication at the
SSL layer (and face significant UI challenges in doing so, unfortunately,
which mostly rule out those solutions except within fairly controlled
communities).

> If we take the traditional IETF view of security perfectionism then the
> only answer on the table is the WS-* based identity metasystem,
> CardSpace, Higgins etc running on top of trustworthy hardware.

I think this is a little silly.  There are much less complex security
solutions that would meet the IETF criteria simply by enabling one to use
SASL or GSS-API for authentication, as can be seen in many other
applications.

HTTP poses special challenges because it's semi-stateless and because it's
in some respects fundamentally split between two symbiotic protocols (HTTP
and TLS) in a more fundamental way that for Internet protocols where TLS
is optional and strong authentication can be achieved without TLS, but
most of the challenges really stem from the fact that it's extremely
widely used, extremely widely deployed, and a very tempting target for
attack.

> From a security point of view it is clear to me that neither approach
> has any bearing on HTTP. Or rather to the extend that it does the
> bearing is minimal. So I don't see any real purpose in delaying the
> advance of HTTP to full standard.

At this point, widespread deployment of HTTP without interoperable
security is water under the bridge, and I agree that it probably doesn't
make a lot of sense to block its advancement towards full standard because
of missed opportunities years ago.  It shares, in other respects, the
features of a full standard, such as extremely high resistance to change.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Facts, please, not handwaving [Re: Its about mandate RE: Why cant the IETF embrace an open Election Process]

[Sam Hartman]

> "Henning" == Henning Schulzrinne <[EMAIL PROTECTED]> writes:

Henning> For this particular case, I don't think there is a
Henning> scientifically provable right answer, so a reasonable
Henning> approach is to pick a number (1 or 2 or 3 steps) that
Henning> most active participants affected can live with, and then
Henning> put processes in place that actually align reality with
Henning> goals. For example, I'd be very interested in the
Henning> aggregate opinions of WG chairs, since they have to do
Henning> much of the grunt work to make Draft and Standard happen.

Henning> In cases of inherent uncertainty, the wisdom of the crowd
Henning> is probably the best one can do. Thus, create a small
Henning> number of self-consistent proposals, and determine a
Henning> reasonable group of affected individuals, and then work
Henning> through a process of elimination in that group, with a
Henning> simple vote. I don't really care whether this group is a
Henning> NONCOM-style selected random group, all NONCOM-eligible
Henning> individuals, all ADs + WG chairs or all recent RFC
Henning> authors. Currently, we're getting the opinion of those
Henning> most inclined to come to a process plenary and to step up
Henning> to the microphone, which is not necessarily
Henning> representative of the affected community.


This is one direction we could take.  Nowe all you need to do is build
a consensus that is the direction we wish to take.  Others may for
example believe that doing anything is more harmful than having a
solution that does not enjoy IETF-wide rough consensus.  That's a
valid opinion to have.

So if you cannot get consensus on the solution, it is reasonable to
get consensus on how to make a decision.

However, you must not presume that you will get consensus on how to
make a decision.

Absent consensus on how to make a decsion, perhaps you could try and
get consensus that a decision must be made.  If you have consensus
that decisions must be made and no consensus on how to do it,then well
it kind of sucks but at least you know you have a problem.

However absent even a consensus that a decision must be made you are
not done discussing.


One drawback of the consensus process is that it is not guaranteed to
terminate.  I considered that a feature when I started working in the
IETF.  I'm willing to bet the organization on the assumption that
there is never a case where a decision must be made and we cannot at
least get consensus that such a decision must be made.

--Sam


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: security features.... (Re: Facts, please)

[Sam Hartman]

> "Hallam-Baker," == Hallam-Baker, Phillip <[EMAIL PROTECTED]> writes:

>> From: Harald Alvestrand [mailto:[EMAIL PROTECTED] > I don't
>> disagree. The IETF might first try to design an authentication
>> > feature worth requiring. None of the current options are at
>> all > satisfactory.
>> 
>> In fact TLS + HTTP Basic Auth is pretty interoperable, secure
>> against quite a few attacks, and widely deployed.
>> 
>> The requirements needed to be "satisfactory" depend very much
>> on your viewpoint; last week I talked to the guy who
>> implemented Freenigma (PGP for web mailers,
>> http://www.freenigma.com), and he commented that "this will
>> never get past the security gurus in the IETF because it's so
>> simple, people might actually use it".
>> 
>> That says something frightening about the kind of impression we
>> give to people who work on making usable security.  "Usable"
>> needs to be an important component of "satisfactory".

Hallam-Baker,> I think the question starts with a false premise,
Hallam-Baker,> that the security layer should be in HTTP. Since
Hallam-Baker,> HTTP is the new IP this makes no more sense than
Hallam-Baker,> having authentication at the IPSEC layer.

For what it's worth, I think there need to be components both at the HTTP and 
HTML layers.

You want the binding to TLS at the HTTP layer for a number of reasons
including support for DAV, ATOM and other situations where there is no
HTML.  It's also easier to bind across one layer than two.  Finally,
HTML limits you to one round trip.  Sometimes that's undesirable.


However, I think you want the UI, and in the HTML case the
specification of what authentication mechanisms to use to be done in
HTML.

--Sam


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: security features.... (Re: Facts, please)

[Dave Cridland]

On Tue Sep 19 18:50:41 2006, Robert Sayre wrote:

Tony Finch wrote:

The implementations fail to use the negotiation features to
work securely when possible, and instead baffle users with 
terrible user

interfaces bristling with options.


Negotiation features don't work very well in practice so client
vendors don't rely on them.


They work just fine in email, which is where Tony is complaining 
about their lack of use.


It's entirely possible to discover TLS support and authentication 
methods, and automatically select the strongest combination, with 
minimal user interaction. I have yet to find any email server (IMAP, 
ESMTP, ACAP, etc) for which the negotiation in-built into the 
protocol fails to the extent that the negotiated features are not in 
fact supported.


Twice, I have seen the negotiated features fail, but only twice, both 
times asa result of bugs in the server, and nothing to do with the 
design of the protocols as such. Both cases are vanishingly rare, and 
one was in unreleased software, so I'm less than convinced that they 
represent an argument that this negotiation does not work very well 
in practise.


Unfortunately, this does not leave many possible explanations for why 
many client implementors make this much more complicated for the user 
than it needs to be.


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

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: security features.... (Re: Facts, please)

[Gray, Eric]

Harald,

The below is an easy mis-construction to make - from discussion
within the IETF, involving security experts. 

What I believe I've actually seen is along the lines of "we don't
want  because it is likely to be
mis-represented as having resolved security issues it has already been
determined it does not resolve."  One case where this has come up, is
in discussions of the use of TCP/MD5 - where the problem is not so much
that anyone "mis-represents" it as almost anybody can use it with little
- or no - work to be done.

There's certainly a degree of legitimacy in the concerns about 
possible misrepresentation.  If it's "for free" - then it is really
tempting to try to represent it as adequate (unless you're selling a
product that does something better).

From that, it is not hard to see how someone might get the idea
that "ease of use" might be a "problem" with a security/authentication
mechanism.  It's certainly easy to see how this would be doubly true in
any "easy to use" solution someone might wish to propose that is already
known to be less than perfect...

--
Eric

--- [SNIP] ---
--> The requirements needed to be "satisfactory" depend very much on your 
--> viewpoint; last week I talked to the guy who implemented Freenigma
--> (PGP for web mailers, http://www.freenigma.com), and he commented that 
--> "this will never get past the security gurus in the IETF because it's 
--> so simple, people might actually use it".
--> 
--> That says something frightening about the kind of impression we give 
--> to people who work on making usable security. "Usable" needs to be an 
--> important component of "satisfactory".
--> 
--> (He's quite aware of the obvious security defects of his scheme, btw. 
--> It's a tradeoff.)
--> 
-->Harald
--- [SNIP] ---

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: security features.... (Re: Facts, please)

[Jeffrey Altman]

Robert Sayre wrote:
> On 9/19/06, Harald Alvestrand <[EMAIL PROTECTED]> wrote:
>> Robert Sayre wrote:
>> >
>> > I don't disagree. The IETF might first try to design an authentication
>> > feature worth requiring. None of the current options are at all
>> > satisfactory.
>>
>> In fact TLS + HTTP Basic Auth is pretty interoperable, secure against
>> quite a few attacks, and widely deployed.
> 
> Ah, this is the "wink, wink" approach to mandatory authentication.
> Specify something no one uses. Here is my bank's web site:
> . It looks like a phishing attack.

If you try https://www.chase.com it redirects you to
http://www.chase.com.  How lame.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: security features.... (Re: Facts, please)

[Harald Alvestrand]

Hallam-Baker, Phillip wrote:

I think the question starts with a false premise, that the security layer 
should be in HTTP. Since HTTP is the new IP this makes no more sense than 
having authentication at the IPSEC layer.
  
I think the concept of  "THE security layer" is a false premise. There's 
no shortage of FPs

The place for the authentication layer is actually HTML and that is out of 
scope.
Actually I think Secure HTML (RFC 2659) died for lack of interest, not 
because it was out of scope

 Moreover there has to be deep level support in the O/S if the authentication 
layer is going to be robust.

If we take the traditional IETF view of security perfectionism then the only 
answer on the table is the WS-* based identity metasystem, CardSpace, Higgins 
etc running on top of trustworthy hardware.

If we take a more pragmatic view (I hope we do) then we accept that we have to have something else on tap that we can use now, OpenID has a lot to offer. 


Regardless of which view we take it is clear that it would be most beneficial 
if the two approaches were to meet in the middle. Starting the tunnel at both 
ends at once only save time if the two tunnels actually meet up.


From a security point of view it is clear to me that neither approach has any 
bearing on HTTP. Or rather to the extend that it does the bearing is minimal. 
So I don't see any real purpose in delaying the advance of HTTP to full 
standard.
  
I think the inevitable dread of the inevitably interminable discussion 
of details of indetectable significance among the people who would have 
to carry it forward has more to do with its non-advancement than the 
missing usable security option




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Facts, please, not handwaving [Re: Its about mandate RE: Why cant the IETF embrace an open Election Process]

[Hallam-Baker, Phillip]

For what it is worth my takehome from the Montreal meeting was that there was 
genuine desire for change but no recognition of consensus on a particular way 
forward.

One of the reasons that there is no recognition of consensus on a way forward 
is that we did not learn the nature of the objections from the IESG or even who 
was making it. In other words precisely the type of opaque decision making 
processes that were being criticized.

It is a FACT that the IETF produces a minute number of actual 100% standards 
each year. You are the one indulging in handwaving here, not me. 

It is a FACT that when I am asked to propose venues for standards activities 
the IETF is currently a much harder sell than it should be. 

Stop trying to shoot the messenger here. I want to be in a position where I can 
suggest bringing work to the IETF in a pre-standards multi-party meeting and 
not having people laugh or groan.

I certainly do not recommend IETF in all circumstances, nor do I recommend 
against IETF in every case. My problem is that I cannot recommend IETF in as 
many situations as I would like.

The two principle issues being the lack of standards recognition (pushback: 
can't we just do an informational RFC) and the large dose of Not Invented Here.

> -Original Message-
> From: Brian E Carpenter [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, September 19, 2006 11:34 AM
> To: Eliot Lear
> Cc: ietf@ietf.org
> Subject: Re: Facts, please, not handwaving [Re: Its about 
> mandate RE: Why cant the IETF embrace an open Election Process]
> 
> Eliot Lear wrote:
> > Brian E Carpenter wrote:
> > 
> >>>We could argue this interminably or you could simply grasp 
> the nettle 
> >>>and align theory with reality.
> >>
> >>It was clear in Montreal that there is no community 
> consensus to spend 
> >>effort on doing this, so we have closed down this avenue for now.
> > 
> > 
> > I'm sorry, Brian, but this answer is truly unacceptable.  
> Reality is 
> > that our 3 step process is not functioning as documented.  
> We thought 
> > we were fixing it in NEWTRK, but you shut down that group.  Please 
> > tell me and the rest of the community what path you expect 
> to correct 
> > the error.  If you don't have a proposal I will have one of my own.
> 
> I'm not sure that I can say it more clearly than I did the first time.
> I do not believe there is enough interest in this problem in 
> the community to invest effort in fixing it. That is quite 
> distinct from whether you, I or a number of other individuals 
> believe it needs fixing.
> 
> I think you weren't in Montreal. You might want to check the 
> plenary minutes at 
> http://www3.ietf.org/proceedings/06jul/plenaryw.html
> or listen to the audio at
> ftp://limestone.uoregon.edu/pub/videolab/media/ietf66/ietf66-c
h5-wed-plenary.mp3
> 
> If you can build a strong constituency for a given proposal, 
> that might change things. But over the last few years, I 
> haven't seen more than a few people supporting any given 
> proposal, including ones that I've made, and that doesn't cut 
> it for something that affects every single WG.
> 
>  Brian
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: security features.... (Re: Facts, please)

[Hallam-Baker, Phillip]

> From: Harald Alvestrand [mailto:[EMAIL PROTECTED] 
> > I don't disagree. The IETF might first try to design an 
> authentication 
> > feature worth requiring. None of the current options are at all 
> > satisfactory.
> 
> In fact TLS + HTTP Basic Auth is pretty interoperable, secure 
> against quite a few attacks, and widely deployed.
> 
> The requirements needed to be "satisfactory" depend very much 
> on your viewpoint; last week I talked to the guy who 
> implemented Freenigma (PGP for web mailers, 
> http://www.freenigma.com), and he commented that "this will 
> never get past the security gurus in the IETF because it's so 
> simple, people might actually use it".
> 
> That says something frightening about the kind of impression 
> we give to people who work on making usable security. 
> "Usable" needs to be an important component of "satisfactory".

I think the question starts with a false premise, that the security layer 
should be in HTTP. Since HTTP is the new IP this makes no more sense than 
having authentication at the IPSEC layer.

The place for the authentication layer is actually HTML and that is out of 
scope. Moreover there has to be deep level support in the O/S if the 
authentication layer is going to be robust.

If we take the traditional IETF view of security perfectionism then the only 
answer on the table is the WS-* based identity metasystem, CardSpace, Higgins 
etc running on top of trustworthy hardware.

If we take a more pragmatic view (I hope we do) then we accept that we have to 
have something else on tap that we can use now, OpenID has a lot to offer. 

Regardless of which view we take it is clear that it would be most beneficial 
if the two approaches were to meet in the middle. Starting the tunnel at both 
ends at once only save time if the two tunnels actually meet up.


>From a security point of view it is clear to me that neither approach has any 
>bearing on HTTP. Or rather to the extend that it does the bearing is minimal. 
>So I don't see any real purpose in delaying the advance of HTTP to full 
>standard.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Facts, please, not handwaving [Re: Its about mandate RE: Why cant the IETF embrace an open Election Process]

[Gray, Eric]

Eliot/Brian,

This, I think, is part of the problem.

To say that "it is well understood that the Internet mainly 
runs on Proposed Standards," is to indulge in over-simplification. 
And to say "we are not actually following our documented process"
- is to focus on the meta-issues when the problem is with what is
documented in the RFCs themselves, in many cases.

One of the useful features of the current "process" is that 
it means the community has one or two opportunities to insist that
what is technically documented is in alignment with reality.  For
many of the most important RFCs, it takes more than competence and
an RFC to implement what's actually going to work in the Internet.
A significant amount of the time it either takes lab testing, some
snooping on what goes on the wire, some reverse engineering and at
least one more iteration of lab testing - or it takes being on the
"inside track" in dominant (or early) implementation.

One of the reasons why it _looks_ like "the Internet mainly 
runs on Proposed Standards," is that the people who know about the
difference between what's technically done, and what's technically
documented, have no real incentives to get involved in efforts to
document what they know - thus letting future competitors have the
information for free.  This is - I believe - a key factor in why
most Proposed Standards do not progress to Draft Standard.

This factor has come up repeatedly in the efforts to advance
Proposed Standards that I've been involved in, and it usually adds
years to the process.

But another factor is that we (as in the IETF) aren't usually
satisfied with just documenting what is really being done.  For one
reason or another, many of us would like to "fix" the Standard to -
for example - make it consistent with protocols and specifications
we've developed since then, even if that means documenting protocol
behaviors that are inconsistent with what is really being done.  

These factors just adds to the burden.  Because it is not easy 
to progress along the standards track, many (if not most) Proposed 
Standards only roughly document what the Internet runs on.

I would argue that "Proposed Standard" as the end-of-the-line
in our standardization process is just wrong.  I certainly can see
an argument for merging "Proposed" and "Draft" - but there are lots
of indications that even the simplified one-step process of moving 
from Draft to full Standard would not get done much of the time.

There are examples of ways to deal with this difficulty from 
other standards groups.  The issue we need to decide as a group is
whether we're happy with our (slightly) imperfect process, or we
would like to adopt (and/or modify) someone else's.

--
Eric

--> -Original Message-
--> From: Eliot Lear [mailto:[EMAIL PROTECTED] 
--> Sent: Monday, September 18, 2006 4:13 AM
--> To: Brian E Carpenter
--> Cc: ietf@ietf.org
--> Subject: Re: Facts, please, not handwaving [Re: Its about 
--> mandate RE: Why cant the IETF embrace an open Election Process]
--> 
--> Brian E Carpenter wrote:
--> > Phill,
--> >
--> >> As a result the IETF is a standards body with 2000 active
--> >> participants that produces on average less than 3 
--> standards a year
--> >> and typically takes ten years to produce even a specification.
--> >
--> > It is well understood that the Internet mainly runs on Proposed
--> > Standards,
--> > so the appropriate metric is how many Proposed Standards the IETF
--> > produces
--> > a year. I think you will find that is more than three.
--> 
--> I have to agree.  Going back to the numbers I posted to 
--> NEWTRK in March:
--> 
--> Status  1999200020012002200320042005
--> -
--> PS  102 119 71  105 103 131 169
--> 
--> 
--> 
--> This represents a tremendous amount of work by many people.  And so
--> while I *do* believe we have process problems, they are 
--> largely of the
--> form that we are not actually following our documented 
--> process.  I also
--> believe that we need to be more nimble when it comes to changing our
--> processes.  I would like to see both of those problems 
--> corrected in due
--> course.
--> 
--> I have not done the work to review velocity from -00 to 
--> RFC, but perhaps
--> Bill Fenner has.
--> 
--> Eliot
--> 
--> ___
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Facts, please, not handwaving [Re: Its about mandate RE: Why cant the IETF embrace an open Election Process]

[Dave Crocker]

Henning Schulzrinne wrote:
I interpreted the microphone and hand-raising in Montreal that people 
were tired of interminable process discussions that consume lots of 
resources and in the end accomplish nothing.



Henning and Brian,

I think you are confusing "accomplish nothing" with "produces a 
consensus result that then gets dismissed by IETF management."


The difference is fundamental.

d/


--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: security features.... (Re: Facts, please)

[Robert Sayre]

On 9/19/06, Harald Alvestrand <[EMAIL PROTECTED]> wrote:

Robert Sayre wrote:
>
> I don't disagree. The IETF might first try to design an authentication
> feature worth requiring. None of the current options are at all
> satisfactory.

In fact TLS + HTTP Basic Auth is pretty interoperable, secure against
quite a few attacks, and widely deployed.


Ah, this is the "wink, wink" approach to mandatory authentication.
Specify something no one uses. Here is my bank's web site:
. It looks like a phishing attack.



That says something frightening about the kind of impression we give to
people who work on making usable security. "Usable" needs to be an
important component of "satisfactory".

(He's quite aware of the obvious security defects of his scheme, btw.
It's a tradeoff.)


Fully agree. Many non-standard schemes are more secure and more usable
than the IETF options, though.

Tony Finch wrote:

The implementations fail to use the negotiation features to
work securely when possible, and instead baffle users with terrible user
interfaces bristling with options.


Negotiation features don't work very well in practice so client
vendors don't rely on them.

--

Robert Sayre

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Facts, please, not handwaving [Re: Its about mandate RE: Why cant the IETF embrace an open Election Process]

[Brian E Carpenter]

Eliot Lear wrote:

Brian E Carpenter wrote:


We could argue this interminably or you could simply grasp the nettle
and align theory with reality.


It was clear in Montreal that there is no community consensus to spend
effort on doing this, so we have closed down this avenue for now.



I'm sorry, Brian, but this answer is truly unacceptable.  Reality is
that our 3 step process is not functioning as documented.  We thought we
were fixing it in NEWTRK, but you shut down that group.  Please tell me
and the rest of the community what path you expect to correct the
error.  If you don't have a proposal I will have one of my own.


I'm not sure that I can say it more clearly than I did the first time.
I do not believe there is enough interest in this problem in the
community to invest effort in fixing it. That is quite distinct from
whether you, I or a number of other individuals believe it needs fixing.

I think you weren't in Montreal. You might want to check
the plenary minutes at http://www3.ietf.org/proceedings/06jul/plenaryw.html
or listen to the audio at
ftp://limestone.uoregon.edu/pub/videolab/media/ietf66/ietf66-ch5-wed-plenary.mp3

If you can build a strong constituency for a given proposal,
that might change things. But over the last few years, I haven't
seen more than a few people supporting any given proposal,
including ones that I've made, and that doesn't cut it for
something that affects every single WG.

Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Facts, please, not handwaving [Re: Its about mandate RE: Why cant the IETF embrace an open Election Process]

[Henning Schulzrinne]

I interpreted the microphone and hand-raising in Montreal that people 
were tired of interminable process discussions that consume lots of 
resources and in the end accomplish nothing.


One way to ensure that there are no such discussions is to make all such 
discussions fruitless and interminable.


Another approach is to try to find ways to make quick and decisive 
progress, so that people aren't exhausted and that participation by 
those whose primary interest is technical can be ensured.


For this particular case, I don't think there is a scientifically 
provable right answer, so a reasonable approach is to pick a number (1 
or 2 or 3 steps) that most active participants affected can live with, 
and then put processes in place that actually align reality with goals. 
For example, I'd be very interested in the aggregate opinions of WG 
chairs, since they have to do much of the grunt work to make Draft and 
Standard happen.


In cases of inherent uncertainty, the wisdom of the crowd is probably 
the best one can do. Thus, create a small number of self-consistent 
proposals, and determine a reasonable group of affected individuals, and 
then work through a process of elimination in that group, with a simple 
vote. I don't really care whether this group is a NONCOM-style selected 
random group, all NONCOM-eligible individuals, all ADs + WG chairs or 
all recent RFC authors. Currently, we're getting the opinion of those 
most inclined to come to a process plenary and to step up to the 
microphone, which is not necessarily representative of the affected 
community.


Henning

Eliot Lear wrote:

Brian E Carpenter wrote:

We could argue this interminably or you could simply grasp the nettle
and align theory with reality.

It was clear in Montreal that there is no community consensus to spend
effort on doing this, so we have closed down this avenue for now.


I'm sorry, Brian, but this answer is truly unacceptable.  Reality is
that our 3 step process is not functioning as documented.  We thought we
were fixing it in NEWTRK, but you shut down that group.  Please tell me
and the rest of the community what path you expect to correct the
error.  If you don't have a proposal I will have one of my own.

Eliot

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Facts, please, not handwaving [Re: Its about mandate RE: Why cant the IETF embrace an open Election Process]

[Eliot Lear]

Brian E Carpenter wrote:
>> We could argue this interminably or you could simply grasp the nettle
>> and align theory with reality.
>
> It was clear in Montreal that there is no community consensus to spend
> effort on doing this, so we have closed down this avenue for now.

I'm sorry, Brian, but this answer is truly unacceptable.  Reality is
that our 3 step process is not functioning as documented.  We thought we
were fixing it in NEWTRK, but you shut down that group.  Please tell me
and the rest of the community what path you expect to correct the
error.  If you don't have a proposal I will have one of my own.

Eliot

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Facts, please, not handwaving

[Jefsey_Morfin]

Dear Frank,
the main problem in a human debate is that the different protagonists 
tend to see the world, the debate, and the vision of others through 
their own vision. If they are reasonably clever what is something I 
take for granted here, and sufficently informed (what RFC 3935 
requires), the whole issue is actually for them to progressively 
understand the others' point of view. When they have understood each 
others, the solution is usually obvious to all, or the differences 
one can manage.

The whole issue is therefore to adopt a system where:
- one can understand the others' point of view (a methodology is 
needed to make sure that no lobby exclude other positions)
- one can check the competence of the proponents. The Internet 
standard process goes into that direction when it calls for some 
network experts to be involved in new areas to network engineering. 
The education process can also help. However, humility is probably 
the best way to learn from others. This can be helped by some 
methodology. A WG should commonly produce a document, not to revise 
someone's proposition.
- one must have the appropriate medium  to express the common 
understanding. The IETF currently proceed like Nature. RFC are 
articles, calling officially for comments. This is research, not 
engineering. Engineering would result in an IETF Good Book. It would 
address reality, not document its own virtuality (cf. below).

At 04:32 19/09/2006, Frank Ellermann wrote:
>Jefsey_Morfin wrote;
>
> > The Internet has dramatically increased this to the point we
> > have accepted it as a virtual and a global world, i.e. a
> > conceptual and geographical equivalent coverage to reality.
> > The IETF is therefore in the core of this
>
>But not alone, googlebot, wikipedia, and some other companies
>are nearer to that core.

?
These are content services not the network architecture. Not the same 
layer as IETF. They are nearer from people's core, not of the network's core.

They build over the IETF vision. Reread RFC 3935. The IETF technology 
is not a technology, but the technology the IETF members want, from 
their core values. This is the problem: the reference is not the 
reality, but the virtuality made of the previous RFCs.

> > the support of what people are to believe to be their
> > _unique_ virtuality.
>
>I don't believe in "unique", and I don't believe in arbitrary
>borders between "real" and "virtual".

This is not a question of faith. In writing this you just prove that 
you are in your own virtuality. Reality is what makes electon exist 
and move. Virtuality is everything human brains can devise to 
document it. Physical laws structure a virtuality which tries to best 
document reality. For centuries we believed in Ptolemy's system, then 
in Copernic's and Newton's law, then in Eistein's law, now we know 
from corrections that most probably all is fractal (and I think there 
is a simple, good, and universal reason for that I call syllodata, 
and I explained to Sam Hartman). Use the excel paradigm. Metadata are 
the column, syllodata are the formulas.

Reality IS. Virtuality is when you start saying you BELIEVE. A 
context is when you say "we believe".

> > The RFC system is not accompanied by a network ontology RFCs
> > would update.
>
>Evolving as needed.  Today you can get human readable meta data
>for RFCs with the rfc-editor.org search engine, use ietf.tools,
>Bill's additional dependency tools, etc.  Some years ago I had
>only a CD ROM and grep.

This is not an ontology. It certainly could help building an IETF 
vision ontology. But this is still to be done. Then, the referent 
being the IETF and not the reality, it would not be an attempt to a 
universal model but to an IETF model.

> > There is therefore no description of the virtuality the IETF
> > develops and the world is to beleive in.
>
>If we're in a sub-sub-sub-thread of "newtrk" (and not "NomCom")
>here, then IIRC one conclusion was that everybody is free to
>write "overview" documents about everything (s)he cares about.
>
>Getting rough consensus for a publication as an IETF RFC is of
>course a separate issue.

The target is not to pile virtualities. It is to document their 
aggregation, as multiple faces of reality. This can only be made in a 
concerted way. Rough consensus is not a concerted system.

> > reality is diverse, so the virtuality must be diverse
>
>Yes, therefore please don't write "unique" outside of contexts
>where it's clear / necessary / desirable / ... (roll your own).

I do not call for uniqueness. I oppose the uniqueness of IETF borned 
from rough consensus. At the end of the day IETF has only one 
standard, one doctrine, one RFC, one single root, one single IP 
addressing plan, one single pivotal language, one single IANA,. 
etc.  This is why I call the result the "mono-Internet".

> > IETF wants to influence THE way people design, use, and
> > manage the Internet.
>
>There's no "THE way" in RFC 3935.

Oh! yes there is. There is 

Re: security features.... (Re: Facts, please)

[Tony Finch]

On Tue, 19 Sep 2006, Harald Alvestrand wrote:
>
> In fact TLS + HTTP Basic Auth is pretty interoperable, secure against quite a
> few attacks, and widely deployed.

But mostly ignored, because the user interface is dreadful. Practically
all websites use one of the ad-hoc mechanisms that Russ referred to.

> The requirements needed to be "satisfactory" depend very much on your
> viewpoint; last week I talked to the guy who implemented Freenigma (PGP for
> web mailers, http://www.freenigma.com), and he commented that "this will never
> get past the security gurus in the IETF because it's so simple, people might
> actually use it".
>
> That says something frightening about the kind of impression we give to people
> who work on making usable security. "Usable" needs to be an important
> component of "satisfactory".
>
> (He's quite aware of the obvious security defects of his scheme, btw. It's a
> tradeoff.)

http://www.links.org/?p=130

Over the last year we've moved all our email users over to secure
authentication (with TLS and SASL, or the old passowrd authentication
alternatives) and the main usability problem is not the protocols as
specified. The implementations fail to use the negotiation features to
work securely when possible, and instead baffle users with terrible user
interfaces bristling with options.

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR
GOOD.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Facts, please, not handwaving [Re: Its about mandate RE: Why cant the IETF embrace an open Election Process]

[Brian E Carpenter]

We could argue this interminably or you could simply grasp the nettle and align 
theory with reality.


It was clear in Montreal that there is no community consensus to spend
effort on doing this, so we have closed down this avenue for now.

   Brian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Calendaring Extensions to WebDAV (CalDAV)' to Proposed Standard (draft-dusseault-caldav)

[Julian Reschke]

Julian Reschke schrieb:

Bernard Desruisseaux schrieb:

Julian Reschke wrote:


With respect to draft 14, I notice that the reference to RFC2518bis 
has been downgraded to RFC2518 (which I don't object to), but that 
references *into* RFC2518 now use broken section numbers (as they 
haven't been updated accordingly).


Hi Julian,

I'm sorry but all references into RFC2518 have been updated accordingly
as far I can tell. Am I missing something?


1) In 
, 
you don't want to refer to Appendix 4 of RFC2518 as the WG consensus is 
that this appendix is incorrect, and for that reason it was removed in 
RFC2518bis.

> ...

This problem is still present in the new draft 
().


Best regards, Julian


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

security features.... (Re: Facts, please)

[Harald Alvestrand]

Robert Sayre wrote:


On 9/19/06, Russ Allbery <[EMAIL PROTECTED]> wrote:


Robert Sayre <[EMAIL PROTECTED]> writes:

> Thankfully, the complete failure known as HTTP 1.1 would never make it
> to Proposed Standard under the unwritten process we have now. For
> example, it doesn't contain a mandatory, universally interoperable
> authentication feature.

That's right, it doesn't, and the lack of that feature is a first-rate
pain in the ass.



I don't disagree. The IETF might first try to design an authentication
feature worth requiring. None of the current options are at all
satisfactory.


In fact TLS + HTTP Basic Auth is pretty interoperable, secure against 
quite a few attacks, and widely deployed.


The requirements needed to be "satisfactory" depend very much on your 
viewpoint; last week I talked to the guy who implemented Freenigma (PGP 
for web mailers, http://www.freenigma.com), and he commented that "this 
will never get past the security gurus in the IETF because it's so 
simple, people might actually use it".


That says something frightening about the kind of impression we give to 
people who work on making usable security. "Usable" needs to be an 
important component of "satisfactory".


(He's quite aware of the obvious security defects of his scheme, btw. 
It's a tradeoff.)


  Harald

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf