I support publication of this document.
josh.
> -Original Message-
> From: ietf-announce-boun...@ietf.org
> [mailto:ietf-announce-boun...@ietf.org] On Behalf Of The IESG
> Sent: 14 January 2009 16:18
> To: IETF-Announce
> Subject: Fourth Last Call: draft-housley-tls-authz-extns
>
> On
of us have been aware of its gestation).
FWIW I've personally never understood what niche(s) PANA was
expecting to fill, but I assumed it was me being dim.
josh.
Josh Howlett, Networking Specialist, University of Bristol.
email: [EMAIL PROTECTED] | phone: +4
>
>OK, pardon the cheap shot, but I don¹t think SDOs that have some sort of
>stewardship relationship to the Internet should ever play any part
>whatsoever in the facilitation of DRM.
So it's ok to define protocols that manage access to services (e.g., TLS,
GSS, SASL, etc), but not to the content
> Since we expect a reasonable attendance at IETF from
> eduroam-connected sites, IETF participants with an eduroam account
> configured, should get connected to the wireless network right away
> with their usual credentials.
And it's working flawlessly on my laptop and phone. Thank you to everyon
As someone who is involved in eduroam, I'm curious how many people found the
availability of eduroam at IETF 78 useful.
If you believe that you are eligible to use eduroam - irrespective of whether
you tried it at IETF 78 - please consider completing the form at the following
URL (it's only thr
(I sent this yesterday as a response in some other thread, but as a result I've
had reports that it has been overlooked. I'm sending it again more explicitly
to solicit more responses).
As someone who is involved in eduroam, I'm curious how many people found the
availability of eduroam at IETF
Legislation exists for some jurisdictions, such as the EU eSignatures
Directive, that controls the legal effect of a qualified digital signature.
Does anyone know of any analyses of the implications of such legislation and
DNSSEC?
Josh.
JANET(UK) is a trading name of The JNT Association, a com
Hannes wrote:
> Melinda wrote:
> >
> > and that there are
> > some non-trivial advantages to carrying authorizations in-band.
> Namely...
I don't wish to speak for Melinda, but this is a view shared by many
within my own community.
I have a long list of applications, collected from within this
c
Hi Hans,
> >Hannes wrote:
> >> Melinda wrote:
> >> >
> >> > and that there are
> >> > some non-trivial advantages to carrying authorizations in-band.
> >> Namely...
> >
> >I don't wish to speak for Melinda, but this is a view shared by many
> >within my own community.
> >
> >I have a long list o
Sam Hartman wrote:
> The Kerberos community has many years of experience that
> within an infrastructure, carrying authorizations in-band has
> been useful and has reduced the effort required to fit an
> application into a larger infrastructure.
Just a quick plug, following Sam's comments: aug
Hi Hannes,
> My fear about SAML in TLS was a history like the following one:
> * Hmmm. SAML becomes popular. We should put it in every protocol.
> * There isn't an extension for TLS defined yet. Let's do it.
> * Now, let's search for the problems it could solve.
If the argument that you're ma
Hi Hannes,
Hans wrote:
> Josh wrote:
> > Hans wrote:
> > > Josh wrote:
> > > >I have a long list of applications, collected from within this
> > > >community, with which they would like to use SAML-based
> > > > authorisation;
> > >
> > > Interesting. Any interest to share it with us?
> >
> > I'
Sam wrote:
> We plan to discuss the general problem and a proposed
> solution at the bar BOF. I've already prepared a feasibility
> analysis for JaNet(UK)'s solution; the analysis does discuss
> the problem some, gives an outline of the solution and
> discusses technical issues and required st
Eliot,
> Klaas Wierenga, Hank Mauldin, Hannes Tschofenig, and I have
> submitted several drafts for consideration in the context of
> SASL, and we will be presenting a short version of them at
> the APPS Area meeting and perhaps something longer in SASL in
> advance of consideration of a chart
>> Day passes have nothing to do with it.
>
>I disagree. Day passes encourage the notion that it's normal to
>parachute into the IETF to attend a single session. I think that the
>IETF's strength is that we don't totally compartmentalise work items.
I am perplexed that there is, on the one hand,
Section 3.2 of draft-wierenga-ietf-eduroam describes the issues presented
by EAP's spartan support for error condition handling. Although these are
described in the context of a particular roaming operator's experiences, I
believe this is also likely to be true for other non-trivial deployments.
T
>
>Though of course an underlying problem is that no vendor wants to sell
>hardware that will obsolete itself, unless of course it obsoletes itself
>by requiring the customer to purchase even more expensive hardware than
>it replaces.It's hard to see how IETF could fight against vendors who
>we
>>
>> Personally I would characterise this as a demand-side problem, not
>> supply-side: most users plainly aren't willing to pay for Internet
>> transparency.
>
>I don't think that's the problem; I think the problem is that most users
>don't realize how much lack of transparency is harming them.
I confess that I am confused by much of this discussion. As I understand
it, PRISM is not a signals intelligence activity; it only addresses that
data at rest within those organisations who have partnered with the NSA.
As such, improving protocol security will achieve nothing against PRISM;
it is a
Jari,
>It is important to understand the limitations of technology in this
>discussion. We can improve communications security, and in some cases
>reduce the amount information communicated. But we cannot help a
>situation where you are communicating with a party that you cannot
>entirely trust wi
20 matches
Mail list logo
