Re: sasl in beep or payload

Stephen,

I agree wholeheartedly.

The SACRED group have invested a lot of time chasing a new strong-pw authentication
option (PDM) that was being pushed actively by it's proponents.  More recently it
has been suggested we should take on a much larger technical issue -- namely that
http is not suitable for the transfer of SACRED authentication protocols and
credential data.  I'd suggest there are oceans of empirical data that indicate this
conclusion is highly debateable.

Keith Moore, among others, has clearly articulated http-specific technical issues
that should be dealt with by those who would like to create a http-SACRED binding.

Others may want to create a BEEP-SACRED binding or a TCP-SACRED binding.

In "Blown to Bits", Evans and Wurster have said:

"However the shift in standards is not just from proprietary to open.  The Internet,
extranets, and intranets are all variants of the same thing.  They use a set of
lowest common denominator standards.  These trimph because of the principle of good
enough:  at some point in the advance of technology, generic standards become good
enough for their advantages in universal acceptance to outweigh their disadvantages
in any specific application."

I'd suggest "universal acceptance" is an important dynamic specifically with respect
to what SACRED is trying to do.
I also suggest that http, BEEP, TCP can all be made to work well for this very
simple task.


Stephen Farrell wrote:

> Dave,
>
> Are you reading the text of the messages I send? Seems like
> you're not. Well to make it clear, wrt sasl-in-beep, I said:
>
> "If there are enough people unhappy with this, I'll start a
> straw poll on the list in a few days so we can sort it out."
>
> So far, we've two people unhappy, as far as I can tell. Feel
> free to send references to other postings that contradict
> this. When & if there's a bunch (particularly if they're from
> people who're interested in what sacred's trying to achieve!)
> we'll do the strawpoll on the list.
>
> You seem to think that I support changing the protocol to
> include sasl in the payload and I get the impression that
> you've also guessed that I'd prefer to use http. Its
> interesting that you got that so wrong! In fact, I'd be
> quite happy with sasl-in-beep, but am following what I
> see as the consensus.
>
> You also seem to think that polling just those who'd
> implement sacred isn't valid. Well, in the case of
> where the sasl pdus are placed, I disagree, but would
> of course welcome arguments to the contrary.
>
> Finally, I think the use of terms like "self-serving" is
> entirely inappropriate and unjustified. Luckily (for me),
> I'm happy to ignore such verbiage, but in future, I'd
> appreciate it if you'd stick to technical argument.
>
> Stephen.
>
> Dave Crocker wrote:
> >
> > At 04:12 PM 12/19/2001 +0000, Stephen Farrell wrote:
> > >Well, I don't think so. A week ago I posted [1], and only Marshall (and
> > >now you) seemed to differ from that. If others do, then I'd have hoped
> > >they'd have spoken up by now.
> >
> > Stephen,
> >
> > The principle of having a chair declare a decision and wait for objections
> > is well-established in the IETF.  However, to succeed, the use of the
> > technique needs to have some basis in the recent history of the working
> > group.
> >
> > For example, it is not reasonable for a chair to literally ignore arguments
> > they dislike and declare a decision that they DO like.
> >
> > That you are both editor and chair, involving a matter of some controversy,
> > is a point that needs to concern you a great deal.
> >
> > As to the lack of response to your declaration, alternative explanations are:
> >
> > 1.  Post-IETF syndrome.
> >
> > 2.  Shock at the arbitrary (and frankly self-serving) declaration,
> > resulting is a feeling that it is not worth commenting, since serious
> > issues and serious points of view are going to be ignored by the chairs.
> >
> > I'll also add that the reason I did not post anything earlier was that I
> > sent my comments to the ADs, suggesting they fix the rather abherrent
> > process that is clearly present in this working group.
> >
> > > > In fact I seem to recall a presentation that argued for this re-use.
> > >
> > >Yes (and I liked your presentaion btw). There was also another one
> > >(Magnus') calling for a quite different approach.
> >
> > You appear to be offering that as an excuse for literally ignoring the
> > presentation you did not like.
> >
> > > > Please note that if the working group takes the very strong AD guidance to
> > > > choose a single "transport" then there is no reason at all to create sasl
> > > > integration into the application, unless the working group chooses a
> > > > "transport" that does not already supply that functionality.
> > >
> > >I have some sympathy for this myself, but judging by the raised
> > >hands, the consensus amongst those who'd implement sacred was to
> > >include the sasl pdus in the payload.
> >
> > I commend to you some study in survey research methodology and statistical
> > sampling an analysis.
> >
> > d/
> >
> > ----------
> > Dave Crocker  <mailto:[email protected]>
> > Brandenburg InternetWorking  <http://www.brandenburg.com>
> > tel +1.408.246.8253;  fax +1.408.273.6464
>
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) +353 1 881 6716
> 39 Parkgate Street,                     fax: +353 1 881 7000
> Dublin 8.                mailto:[email protected]
> Ireland                             http://www.baltimore.com