Re: Feedback Requested on Draft Fees Policy

[Leif Johansson]

20 jul 2012 kl. 16:09 skrev "Richard L. Barnes" :

> +1
> 
> Although I wonder whether radical openness would be cheaper in the long run: 
> Put everything online and have an auto-responder at subpo...@ietf.org that 
> says "Go look it up yourself."
> 

I could think of some other things it could say too...

> --Richard
> 
> 
> 
> On Jul 20, 2012, at 10:05 AM, Warren Kumari wrote:
> 
>> 
>> On Jul 20, 2012, at 9:07 AM, IETF Administrative Director wrote:
>> 
>>> The IAOC is seeking community feedback on a proposed policy by the IAOC to 
>>> impose 
>>> fees to produce information and authenticate documents in response to 
>>> subpoenas and 
>>> other legal requests.
>>> 
>>> The IETF receives requests for information, documentation, authentication 
>>> or other 
>>> matters through subpoenas and less formal means that require manpower and 
>>> materials 
>>> to be expended.  These requests are on the rise. During the period 2005 to 
>>> 2010 the IETF 
>>> responded to nine subpoenas.  Since 2011 the IETF has received five 
>>> subpoenas and three 
>>> other legal requests for authenticated documents.  
>>> 
>>> Each such request is time sensitive and involves the IETF Counsel, the IAD, 
>>> and members 
>>> of the IAOC, who together form the Legal Management Committee, to rapidly 
>>> analyze and 
>>> identify the means for satisfying the request.  Often there is a need to 
>>> retain outside counsel, 
>>> especially in cases that might lead to depositions or court testimony. 
>>> 
>>> The IAOC believes a Schedule of Fees is an appropriate and reasonable means 
>>> to recover 
>>> costs associated with such efforts.
>>> 
>>> The draft policy entitled Draft Fee Policy for Legal Requests can be found 
>>> at: 
>>> 
>>> Before adopting a policy the IAOC would like feedback on this before making 
>>> a 
>>> decision.  Comments appreciated to ietf@ietf.org by 6 August 2012.
>>> 
>>> Ray Pelletier
>>> IETF Administrative Director
>>> 
>> 
>> 
>> LGTM++.
>> 
>> Seems like a grand idea -- who knows, may even help avoid nuisance suits 
>> (although the fees are so small (compared to all the other costs) that I 
>> don't hold much hope of this…).
>> 
>> W
>> 
>> --
>> For every complex problem, there is a solution that is simple, neat, and 
>> wrong.
>>   -- H. L. Mencken
>> 
>> 
>> 
> 

Re: [abfab] Last Call: (A GSS-API.Mechanism for the Extensible Authentication Protocol) to.Proposed Standard

[Leif Johansson]

fyi the applicability stmt version 00 was submitted by joe the other day.

19 jul 2012 kl. 13:19 skrev "Sam Hartman" :

>> "Stephen" == Stephen Farrell  writes:
> 
>Stephen> Sorry, I should've asked this before but I'm sometimes dumb:-)
> 
>Stephen> If I put in an RFC editor note adding a normative reference
>Stephen> to the new EAP applicability statement [1] would that sort
>Stephen> this out and not cause any problems for anyone?
> 
> I don't object to that, but it does hold up the doc.  I'm happy letting
> this doc go forward now so long as we're all on the same page on the
> applicability stament.  I realize we run the risk that somehow the
> applicability effort derails.  Personally, I'm willing to take that
> risk, so long as we believe today we do intend to publish the
> applicability statement.
> 
> If someone on the IESG or in the community wants that normative
> reference, I support adding it.  I'm just not asking for it myself.
> ___
> abfab mailing list
> ab...@ietf.org
> https://www.ietf.org/mailman/listinfo/abfab

Re: Gen-ART review of draft-johansson-loa-registry-05

[Leif Johansson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/11/2012 11:49 PM, david.bl...@emc.com wrote:
> The -05 version of this draft resolves all of the issues and
> comments raised in the Gen-ART review of the -04 version.

that was quick! thanks

Leif

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+F/KsACgkQ8Jx8FtbMZnfhbACglsmw8UwPI/90Sc2JGrBEzU0+
yfIAnRdgKK2vCkdEhJhB1HDaO3SU/cqV
=nQXL
-END PGP SIGNATURE-

Re: Gen-ART review of draft-johansson-loa-registry-04

[Leif Johansson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/02/2012 05:58 AM, david.bl...@emc.com wrote:
> Leif,
> 
>> The type of consistency you look for is extremely difficult to
>> ascertain and often rely on mapping the underlying policies.
>> However I do see your point. How about this:
>> 
>> "Protocol designers who want to reference this registry should be
>> aware that registered LoAs may depend on assumptions that do not
>> carry over to a new protocol."
> 
> Could you add "and that those assumptions may vary among the
> protocols for which the LoAs were originally registered" ?

yep

> 
> On RFC 2119 terms, I suggest that you talk to your AD (Sean).  The
> IESG recently approved an IANA registry creation draft that I
> co-authored, draft-ietf-storm-rddp-registries, and as part of that
> approval, removal of RFC 2119 terms was requested.  See:
> 
> http://datatracker.ietf.org/doc/draft-ietf-storm-rddp-registries/history/
>
> 
ok I'll do that. Thanks again!

> Thanks, --David
> 
>> -Original Message- From: Leif Johansson
>> [mailto:le...@sunet.se] Sent: Sunday, April 01, 2012 5:59 PM To:
>> Black, David Cc: le...@nordu.net; gen-...@ietf.org;
>> ietf@ietf.org; turn...@ieca.com; tim.p...@nist.gov Subject: Re:
>> Gen-ART review of draft-johansson-loa-registry-04
>> 
> On 04/01/2012 10:57 PM, david.bl...@emc.com wrote:
>>>> I am the assigned Gen-ART reviewer for this draft. For
>>>> background on Gen-ART, please see the FAQ at 
>>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>>> 
>>>> Please resolve these comments along with any other Last Call 
>>>> comments you may receive.
>>>> 
>>>> Document: draft-johansson-loa-registry-04 Reviewer: David L.
>>>> Black Review Date: April 1, 2012 IETF LC End Date: April 3,
>>>> 2012 IESG Telechat date: April 12, 2012
>>>> 
>>>> This draft establishes an IETF registry of SAML Level of
>>>> Assurance (LoA) profiles; it's short and clear, although it
>>>> does not contain any initial content for the registry -
>>>> presumably that will be supplied after the registry is
>>>> created via the expert review registration mechanism
>>>> established by this draft.
>>>> 
>>>> Summary: This draft is on the right track but has open
>>>> issues, described in the review.
>>>> 
>>>> Major issues: (1) My major open issue concerns the last
>>>> paragraph in the Introduction:
>>>> 
>>>> Although the registry will contain URIs that reference SAML 
>>>> Authentication Context Profiles other protocols MAY use such
>>>> URIs to represent levels of assurance definitions without
>>>> relying on their SAML XML definitions.  Use of the registry
>>>> by protocols other than SAML or OpenID Connect is
>>>> encouraged.
>>>> 
>>>> While this is good in principle, and one presumes that each 
>>>> registration of sets of profiles from an existing protocol
>>>> will be self-consistent, this text also encourages other
>>>> (e.g., new) protocols to draw upon this registry without
>>>> providing any guidance.  I'm concerned that it's probably
>>>> possible to make a serious mess in a new protocol by using an
>>>> LoA or two from multiple sets of registered LoAs without
>>>> paying attention to whether the resulting collection of LoAs
>>>> is consistent or coherent (or even sensible) for use in a
>>>> single protocol.  This concern is reinforced by the guidance
>>>> to expert reviewers in Section 4.1, which effectively conveys
>>>> a desire to get all of the reasonable LoA profiles registered
>>>> here, regardless of source or consistency with other
>>>> registered LoA profiles.
>>>> 
>>>> I'd like to see some guidance to protocol designers and
>>>> others for how to appropriately select multiple LoA profiles
>>>> from this registry in a fashion that results in a consistent
>>>> and (hopefully) usable collection.  For example, it may be a
>>>> good idea to use (or start with) a set of related profiles
>>>> already in use by an existing protocol in preference to
>>>> mixing/matching individual profiles from multiple existing
>>>> protocols.  At some level, this is common sense advice that
>>>> the presence of profiles in this registry does not obviate
>

Re: Gen-ART review of draft-johansson-loa-registry-04

[Leif Johansson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/01/2012 10:57 PM, david.bl...@emc.com wrote:
> I am the assigned Gen-ART reviewer for this draft. For background
> on Gen-ART, please see the FAQ at 
> .
> 
> Please resolve these comments along with any other Last Call
> comments you may receive.
> 
> Document: draft-johansson-loa-registry-04 Reviewer: David L. Black 
> Review Date: April 1, 2012 IETF LC End Date: April 3, 2012 IESG
> Telechat date: April 12, 2012
> 
> This draft establishes an IETF registry of SAML Level of Assurance
> (LoA) profiles; it's short and clear, although it does not contain
> any initial content for the registry - presumably that will be
> supplied after the registry is created via the expert review
> registration mechanism established by this draft.
> 
> Summary: This draft is on the right track but has open issues,
> described in the review.
> 
> Major issues: (1) My major open issue concerns the last paragraph
> in the Introduction:
> 
> Although the registry will contain URIs that reference SAML 
> Authentication Context Profiles other protocols MAY use such URIs
> to represent levels of assurance definitions without relying on
> their SAML XML definitions.  Use of the registry by protocols other
> than SAML or OpenID Connect is encouraged.
> 
> While this is good in principle, and one presumes that each
> registration of sets of profiles from an existing protocol will be
> self-consistent, this text also encourages other (e.g., new)
> protocols to draw upon this registry without providing any
> guidance.  I'm concerned that it's probably possible to make a
> serious mess in a new protocol by using an LoA or two from
> multiple sets of registered LoAs without paying attention to
> whether the resulting collection of LoAs is consistent or coherent
> (or even sensible) for use in a single protocol.  This concern is
> reinforced by the guidance to expert reviewers in Section 4.1,
> which effectively conveys a desire to get all of the reasonable LoA
> profiles registered here, regardless of source or consistency with
> other registered LoA profiles.
> 
> I'd like to see some guidance to protocol designers and others for
> how to appropriately select multiple LoA profiles from this
> registry in a fashion that results in a consistent and (hopefully)
> usable collection.  For example, it may be a good idea to use (or
> start with) a set of related profiles already in use by an existing
> protocol in preference to mixing/matching individual profiles from
> multiple existing protocols.  At some level, this is common sense
> advice that the presence of profiles in this registry does not
> obviate the need to apply good design judgment, but that does
> deserve to be stated.

David,

The type of consistency you look for is extremely difficult to ascertain
and often rely on mapping the underlying policies. However I do see your
point. How about this:

"Protocol designers who want to reference this registry should be aware
that registered LoAs may depend on assumptions that do not carry over
to a new protocol."

> 
> Minor issues: (2)
> 
> (1) This draft is intended to be an informational RFC, but it uses 
> RFC 2119 keywords.  That's only a good idea in exceptional
> circumstances. I suggest removing section 1.1 and replacing upper
> case MUST/SHOULD/MAY with their lower case versions or reworded
> explanations of rationale.  Most of the uses of RFC 2119 keywords
> are not protocol requirements, but requirements on IANA,
> registrants, and users of the registry for which RFC 2119 keywords 
> are not appropriate, e.g., see RFC 2119 section 6:
> 
> Imperatives of the type defined in this memo must be used with
> care and sparingly.  In particular, they MUST only be used where it
> is actually required for interoperation or to limit behavior which
> has potential for causing harm (e.g., limiting retransmisssions)

ok

> 
> (2) Section 4
> 
> OLD The initial pool of expert and the review criteria are outlined
> below. NEW The review criteria are outlined below.
> 
> The initial pool of experts is not designated by this draft.
> 

good catch

> Nits/editorial comments:
> 
> Section 3
> 
> OLD The following ABNF productions represent reserved values and
> names NEW The reserved element defined by the following ABNF
> productions represents a set of reserved values and names

ok

> 
> Section 4
> 
> The registry is to be operated under the "Designated Expert
> Review" policy from RFC5226 [RFC5226] employing a pool of experts
> 
> Nope, the actual RFC5226 name of that well-known IANA policy is
> Expert Review (or Designated Expert), see section 4.1 of RFC5226.
> If that well-known IANA policy isn't what was intended, this is a
> serious open issue.

that IANA policy was indeed intended.

> 
> Top of p.7 The presense of an entry in the registy MUST NOT be
> taken to imply ^ r ---/
> 

Here I actually

Re: Bar Bof on Federated Authentication Thursday at 9 PM during IETF week

[Leif Johansson]

On 03/10/2010 02:04 PM, Phillip Hallam-Baker wrote:




What I find sad about the whole identity/authentication area is the
way that we have so many frameworks and frameworks of frameworks and
complexity for what is a very simple problem. And I am sorry, but
doing the job the user wants done IS actually the easy part.


Josh is basing his idea on significant deployment of some of those sad 
frameworks. Running code is King Yoda!


Cheers Leif
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [Nea] WG Review: Network Endpoint Assessment (nea)

[Leif Johansson]

>>
>> >
>> Lets not forget that when (not if) NEA/NAP/NAC is deployed the IDSen
>> people have deployed today to
>> solve the lying-client-problem by scanning for common/current
>> vulnerabilities as part of the network admission
>> process will have to interface with PDPs part of a NEA intfrastructure.
>
> Could you rephrase please?  I am afraid I don't understand what you
> are saying.
>
It has been pointed out on this list that the main deliverable from NEA
might well turn out to
be the way host postures are described - the schema if you will. I'm
positive that if someone
deployes NEA/NAP/NAC etc the admin will want to combine data from the
on-client
posture client with information from external IDS (etc) services to a
common Policy Decision
Point. That means that a reason to do NEA is to get this schema
standardized even if some
people who care about lying clients to never use and/or trust client
posture clients.
> Oh, and lying endpoint problem cannot be solved by scanning for common
> vulnerabilities!  In fact, the two have no relation whatsoever.
They have the single relation of both expressing claims about the state
of a host.  

   Cheers Leif



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

Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)

[Leif Johansson]

Extreme clipping below:
> v) IDS/IPS to detect and prevent intrusions 
>
>   
NEA might help here by providing a common semantics for communicating the
result of IDS scans of hosts to policy decision points.

Cheers Leif

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

Re: [Nea] WG Review: Network Endpoint Assessment (nea)

[Leif Johansson]

Lakshminath Dondeti wrote:
> At 01:42 AM 10/7/2006, Harald Alvestrand wrote:
>>> 
>> Many universities require their students to buy their own laptops,
>> but prohibit certain types of activity from those laptops (like
>> spamming, DDOS-attacks and the like). They would love to have the
>> ability to run some kind of NEA procedure to ensure that laptops are
>> reasonably virus-free and free from known vulnerabilities, and are
>> important enough in their students' lives that they can probably
>> enforce it without a complaint about "violation of privacy".
>>
>> Just pointing out that there's one use case with user-managed
>> endpoints where NEA is not obviously a bad idea.
>
> My email ventures into a bit of non-IETF territory, but we are
> discussing use cases, and so I guess it's on topic.  Universities
> should be the last places to try antics like NEA.  Whereas an
> operational network would be a priority to them, it is also important
> that they allow students to experiment with new applications.  If we
> are believing that general purpose computing will be taken away from
> college students, we are indeed talking about a different world.
>
> In any event, the bottomline is NEA as a solution to "network
> protection" is a leaky bucket at best.
>
> NEA at best *may* raise the bar in attacking a "closed" network where
> endpoints are owned and tightly controlled by the organization that
> owns the network.
>
Lets not forget that when (not if) NEA/NAP/NAC is deployed the IDSen
people have deployed today to
solve the lying-client-problem by scanning for common/current
vulnerabilities as part of the network admission
process will have to interface with PDPs part of a NEA intfrastructure.

Cheers Leif

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

Re: reflections from the trenches of ietf62 wireless

[Leif Johansson]

As I wrote this it got longer and longer, so the abridged version is:
-  We had problems on Monday, but we believed the wlan to
be operational (albeit without IPv6) with a few obscure
problem reports from Tuesday onward. If people were
I mostly had no problems from Tuesday onwards with one exception: I had
to reload my kernel driver after each sleep - possibly this causes a
full reset of the hardware or something. This is something I seldom (but
not never) have to do.
I'd be willing to lay odds that the people who saw problems from Tuesday
share some hardware characteristics: for instance the same or a small
number of chipsets. My guess is that all AP-chipset combos are not
created equal.
MVH leifj
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Suggest new mailing list for IASA stuff

[Leif Johansson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Leslie Daigle wrote:
|
| Well, the choice to put this on the ietf-discuss list was deliberate:
| including making sure that a reasonable cross section of the IETF
| would see the discussion.  It's not at all clear that such a cross
| section would bother to subscribe to a new mailing list (and a new
| mailing list often just attracts the people who are interested
| for the wrong reasons).
|
| In my personal opinion, it would be better to leave the discussion
| here at least until the last call on the BCP is done.  At that point,
| we'll be into implementation, and if there are further
| matters to discuss, it would be reasonable to say "we are now into
| implementation phase, people who are interested can subscribe ".
|
| Also, the threads are pretty easily identifiable (and skippable).
Indeed. I'd much rather see the various NAT tro^H^H^Hdiscussions go
to the apropriate place. The restructuring discussion is important for
the community as a whole. This is exactly imo why we have an ietf list.
MVH leifj
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFBuYOS8Jx8FtbMZncRAqJfAKC8Aj64LM8q3rwzOgRQklTQW/g70QCgukBh
YX2p9ezahwO6N42mY3FI+bc=
=FW6B
-END PGP SIGNATURE-
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why people by NATs

[Leif Johansson]

Jeroen Massar wrote:
On Fri, 2004-11-26 at 10:11 +0100, Leif Johansson wrote:
For somebody administering a network of 100 machines, the hassle cost of
IP renumbering would be twenty times larger.  Given this, how could
anyone wonder why NAT is popular?
Wrong. If you administer 100's or 1000s of machines you build or buy
a system for doing address management. Renumbering is only difficult
if your system is called vi :-)

Wrong ;) Well at least, up to 1000 is probably doable.
But what if you are talking about 100s or 1000s of organizations with
each a 100 or 1000 machines.
My site is 10k+ addresses. Seems easy enough to manage to me :-)
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Why people by NATs

[Leif Johansson]

For somebody administering a network of 100 machines, the hassle cost of
IP renumbering would be twenty times larger.  Given this, how could
anyone wonder why NAT is popular?
Wrong. If you administer 100's or 1000s of machines you build or buy
a system for doing address management. Renumbering is only difficult
if your system is called vi :-)
MVH leifj
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: IPv6 in the network, please

[Leif Johansson]

This technology supports IPv6 but at the time the network came
up, we did not feel that the v6 implementation was stable enough
to run, we have disabled IPv6 on the wireless networks.
A separate ESSID wo this stuff would have been a solution...
MVH leifj
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Reminder: Poll about restructuring options

[Leif Johansson]

And trying to use a comment field, to compensate for a 
fundamentally biased multiple-choice form never works. What 
counts is the counting.  The numbers.
In which case you should have written a draft like Brian said.
I am sure that any reasonable alternatives would have been part
of the poll had they been on hand.
Cheers Leif
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Reminder: Poll about restructuring options

[Leif Johansson]

It is impressive that you confuse the difference between 
affirmatively embracing an absent alternative with a passive 
refusal to embrace the alternatives presented. 

Maybe I'm stupid but wasn't there a 'Yes I have an opinion
which I will express later' and a comment textfield? Why not
summarize your view on a webbpage and put the url in the
commentfield checking the 'later' radiobutton? Doesn't that
allow you to express your opinion while not beeing tied to
the predefined choices?
Cheers Leif
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: WG Review: Behavior Engineering for Hindrance Avoidance (behave) (fwd)

[Leif Johansson]

Who said anything about necessary state and reasonable timeouts?  I've
seen more than one brand of consumer-grade box with NAT features that
could not be turned off, and that even in their most permissive settings
kill ssh sessions after an hour or two whether the ssh sessions had
been active or not.
I have one that shot down my ssh sessions after 5 minutes of aparent
inactivity - "Hey this tcp session hasn't seen any pr0n in 5 minutes.
It must be a stalled http. Let's kill it!" This is a *major* supplier
of soho equipment. Moreover it was clear from the support-forum that
this was a concious choice. The question is what effect a BCP from the
BEHAVE-wg would have. Personally I am an optimist.

Cheers Leif
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: respect privacy please !

[Leif Johansson]

JORDI PALET MARTINEZ wrote:
Hi Harald,
I'm not expert in legal stuff, but I think the European regulations (at least in Spain 
because I needed to learn this in order to host web sites with any kind of 
registration or list of people and comply with the law), there is no difference in 
publishing it before, during or after. Just can't be published w/o the consent of the 
participant.
I think you are right, however that does not mean that a 'to use this
service you must agree to having your information published'-rule is
incompatible with EU privacy legislation. I think Haralds proposed
fix is probably fine.
MVH leifj
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: respect privacy please !

[Leif Johansson]

Maybe I'm using an alias... I could be Jim Fleming :)
Tim... Jim... the plot thickens!
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: 60th IETF - Registration

[Leif Johansson]

Dave Crocker wrote:
Leif,
LJ> Big hotels that are cheap and where the staff won't throw a fit
LJ> when we all turn up in force, laptops, duct-tape and all, don't
LJ> exactly grow on trees you know! I'm happy if it has a bar.
that must be why we are going to one that costs US$ 179/night,
with no secondary lodging listed.
Hey - I'm all for a permanent relocation to Minneapolis! But I have
seen worse. The LA IETF was >200$ per night. The 'throw-a-fit' bit
probably limits the choices a bit too. I remember working on the
Stockholm IETF. We (the local staff) were politely asked but the
staff of the Grand Hotel to please use the service entrances as we
were scaring the other guests :-)
MVH leifj
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: 60th IETF - Registration

[Leif Johansson]

JORDI PALET MARTINEZ wrote:
I think is unacceptably TODAY, specially for IETF, that we should use a phone instead 
of on-line or email confirmation.
We should not accept hotels that don't make usage of technology to arrange our 
meetings.
We aren't asking the hotel (today) to support IPv6, but at least just IPv4 !
Regards,
Jordi
Big hotels that are cheap and where the staff won't throw a fit
when we all turn up in force, laptops, duct-tape and all, don't
exactly grow on trees you know! I'm happy if it has a bar.
MVH leifj
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Adding SpamAssassin Headers to IETF mail

[Leif Johansson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Harald Tveit Alvestrand wrote:
| Keith,
|
| the reason the secretariat is doing this in stages is exactly because we
| want to see how big the false-positive issue is.
|
| I currently personally use Mailman 2.60 with Bayesian filtering and
| close-to-default rules; it seems to run at a very low rate of false
| positives.
|
In my experience lots of false positives from spamassassin+bayesian
is the result of the user making false assumptions about the linearity
of the spamassassin point-scale.
MVH leifj
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/4eT08Jx8FtbMZncRAnw6AJ46QS2hwy6KVNFtGwnKLtNZbjvEeACgtckS
ad+Jaiv8wJPjix7MV9NS0SE=
=e3+E
-END PGP SIGNATURE-

Re: PKIs and trust

[Leif Johansson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
|
| I think Keith has mixed up authentication with authorization.  It is
| true that I will only trust certain people in certain ways.  But whether
| those certain people are who they are, and whether a message from is in
| fact from them, is something we can determine with PKIs.  That having
| been said, they still don't work.
|
| Why?  Because nobody actually has the patience for them, so far as I can
|  tell.  CRLs are not managed at ALL on the Internet, and so far as I
| know, every Tom, Dick, and Jane will ignore PKI warnings.
Actually I think it may be said that pki's confuse a with a.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/3YFL8Jx8FtbMZncRAipvAJ4iN3jH8y4JYvOINWrVD4qmfxIX/gCgtMvA
y1G01ZBk2uQhiv3srGyVIJY=
=Okrx
-END PGP SIGNATURE-

Re: PKIs and trust

[Leif Johansson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
|
| You're talking about a problem with software, not with the standards.
|
We believe in running code.

MVH leifj
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/3PpZ8Jx8FtbMZncRAtDOAJ4m9VTYa9IngPo8I+K1pOAB8woIQACdHT75
tUCOlSsqTbp3BVJZ0D6NbPk=
=PACb
-END PGP SIGNATURE-

Re: PKIs and trust

[Leif Johansson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
| All of those statements, assertions, and so on can be made in simple
| signed messages. When you get a message with statements about your job,
| you verify that the message has been signed using your boss' public key.
| What's the problem here?
|
| --Paul Hoffman, Director
| --Internet Mail Consortium
|
There are several subtle problems in practice (or at least in my
admittedly limited experience). The major problem is that pki's tend
to have high life-cycle costs mainly due to the lack of widely deployed
management protocols. Compare the cost per user of operating a pki
and a kerberos realm for instance.
This leads deployers to opt out of using the various extensions which
could be used to decide weather a given certificate chain is ok to
use with application X. "We can't afford to re-issue certificates
whenever a new application is introduced...". The large-scale PKIs I
have seen (again - I expect to be refuted on this point) are only used
as identification mechanisms and identification is, as Keith points out
an easy problem compared to the policy decisions which have to be made
*by the client* in order to establish trust for a given application.
MVH leifj
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/3N3P8Jx8FtbMZncRAp0IAJsEV3aWYdYI+x5jxHVJDixDWh6pwQCcCeJH
ZTeAyJlO8eqX+uzCApbNw9c=
=xL45
-END PGP SIGNATURE-

Re: arguments against NAT?

[Leif Johansson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Moore wrote:
|>In many enterprise environments, this would be a feature not a bug.
|>There are some webcams that are definitely inappropriate in a business
|>setup; given the lack of good enterprise content filtering solutions for
|>IM, if NAT does break IM webcams I don't have a problem with it.
|
|
|>As of
|>file transfer, it does not bother me either as like a lot of other
|>network administrators I have a problem with users sharing their office
|>computer files with anyone unknown on the net.
|
|
|>For voice there's always
|>that thing called the telephone that has the advantage to work all the
|
|
| How nice for you to be able to determine what everyone else should be able
| to run on their networks.
|
Yeah. The level of clueloss boggles the mind.

MVH leifj
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/zlIj8Jx8FtbMZncRAuK0AKC9pb1scpTssHJtSbWuwM/AV/zCugCeIK6N
9XAfBN0fpbRH8AZGIiSs4/A=
=Rutg
-END PGP SIGNATURE-

Re: IETF58 - Network Status

[Leif Johansson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stig Venaas wrote:
| Just want to add that the network worked perfectly for me during the
| entire IETF, I didn't have any problems at plenary either.
Mee to. I even had good reception in my room at the doubletree.

leifj
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/vW7r8Jx8FtbMZncRAtJZAJ94JN+mjew9NdpmB/IPxZb2uzlxkQCfSwVW
07BOt7eJdtQkoJwGp1gmy9Q=
=xavr
-END PGP SIGNATURE-

Re: i18n name badges

[Leif Johansson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
JORDI PALET MARTINEZ wrote:
| Keith,
|
| I'm not sure if you are joking, but I think is an excellent idea ...
|
| A badge communication protocol ... if you start with the draft, I will
be happy to contribute !
|
bcp?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/u9QS8Jx8FtbMZncRAu81AJ9E8IxRHf43XOncGDDBwgoMf76QwgCgiKTH
w8pdUOOrxFYy2juaXR5YAiM=
=CBkj
-END PGP SIGNATURE-

Re: Implementing DNS client for support IPv6/IPv4

[Leif Johansson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
sasson, shuki wrote:
| Hi all, I have been reading the RFCs related to extending DNS support
| for IPv6 and I am a bit confused.
I believe that A6 is deprecated...
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/uUIQ8Jx8FtbMZncRAuhFAJ9Jz5F8fgyhtxPVt0d2ifz4kXSJPwCfcrd/
wMQitJ1j70+fEJ/ZUCuU6e0=
=l/cP
-END PGP SIGNATURE-

Re: rfc1918 impact

[Leif Johansson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


|
| Leif,
|
| I was speaking to the architectural issue, not the deployment one.  None
| of the three plug and play boxes I have here with NAT capability has any
| inside DNS capability (either enabled by default or available to be
| turned on).
Exactly! Now why is that?

| It does sound like a recommendation to the effect of "if you are going
| to use NAT, or construct a NAT box, then an 'inside DNS' mechanism"
| would be a reasonable idea.  And I would assume it would be an even
| better one if it made clear what the preferred way was to do an "inside
| DNS" -- I think there might be a couple of different ways to do it, and
| some might be less reprehensible than the others.
|
Of course (I am beeing intentionally obtuse) but isn't it quite unlikely
that any recommendation the we make at this point will have any impact
on how v4 NAT is deployed - we are after all talking about kazillions of
adsl modems, SOHO-routers etc etc? Do you believe that things will be
different with v6 NAT, I.e what are the interoperability problems a NAT
vendor will have unless they implement NAT 'correctly'?
Cheers Leif
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/jbek8Jx8FtbMZncRArnHAKCYL6ofsHt7AQHefjm7wx1XpD1dWwCgiMtZ
6HnYUNLxyduWc0MLHSB/OGw=
=wMD6
-END PGP SIGNATURE-

rfc1918 impact

[Leif Johansson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


|
| (2) But the typical plug-and-play NAT, at least the ones I have run
| across, is preconfigured with the addresses to be used on the "inside"
| and contains (or is intimately paired with) a DHCP server that gives out
| those addresses.  Installing a DNS filter in the thing that would
| intercept PTR queries for that address range, or any 1918 address range,
| and respond to them in some "canned" way while passing other DNS queries
| out to the network as intended is not rocket science and certainly
| doesn't violate any plug-and-play arguments.
So where is the the leak coming from? If what people claim is true and
if not all, but most NAT-boxes are configured with inside DNS, filtering
and extra cheese, where, I ask you do all of those root-zone requests
and other rfc1918 leaks come from?
Cheers Leif
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/jam58Jx8FtbMZncRAu9rAJ9V/vdGmY0UHYRs25IOf333NlSZDwCgohWV
LukIl7zvBBohV0dtG9hVUHs=
=/YAT
-END PGP SIGNATURE-

rfc1918 impact

[Leif Johansson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
We should keep nice and descriptive subject-lines...

Michel Py wrote:



| etc. Basically everything that triggers a reverse lookup adds to the
| pain, but if reverse lookup is configured correctly on the local DNS
A lot of the arguments seem to contain the phrase "If  is
configured correctly then ...". Now what does that teach us?
Cheers Leif
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/jRtv8Jx8FtbMZncRAg8eAJsEhg6/LOQgaZW3FtSkdiffbp2TvwCgx+x1
dpuw7nwHC2Z8BlAx+qoKyBc=
=7TZn
-END PGP SIGNATURE-

Re: Appeal to the IAB on the site-local issue

[Leif Johansson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
bill wrote:
| I'd like to ask an interesting question that might help the IETF, but
| not this debate unfortunately.
|
| The meta question is how did we get into a state where some people have
| very conflicting views on how well this topic was adjusted (discussed
A contributing factor might be that starting with Yokohama and certainly
by SF the issue had attracted attention by people who don't normaly pay
close tabs to ipv6. Why that is is a separate discussion. That is why
(imo) we saw the confusion - suddenly the all the people in the room
and on the list were not speaking the same language or driven by the
same motivation (for good and/or bad).
Cheers leifj
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/jI+s8Jx8FtbMZncRAgfKAKCsOPca/T2ozbxnaWJAbPF0tmBlpgCgkEgM
+SD0INMitSQ0LOtqlKY9vDs=
=ziFz
-END PGP SIGNATURE-

Re: accusations of cluelessness

[Leif Johansson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
|
| Well, who made us kings? It is one thing to work and publish designs
| that hopefully will be good. It is quite another to judge someone else's
| design and brand it bad. It is far better to let the market be judge.
|
I agree. But should we not as a community try to produce results
which attempt to be consistent? If a feature in the network layer
break assumptions in the application layer then (setting aside the
discussion of whose fault the inconsistency is) if we want to be
consistent one has to give. I put it to you that the difference
between 'keeping' and 'removing' in this case is just in our heads.
Eg. keeping SL in the original form (I agree this is a hypothetical
situation) would have implied removing features from several protocols.
Did we remove SL or did we keep those protocols intact?
	Cheers Leif

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/iR3Q8Jx8FtbMZncRAjjaAJ96ayKHER/PH/pZjXeeMHEqRR/cTgCdHE1p
1B77cE8kUFURCAO3DoUlMhk=
=Ofi4
-END PGP SIGNATURE-

Re: accusations of cluelessness

[Leif Johansson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vernon Schryver wrote:
|>From: Keith Moore <[EMAIL PROTECTED]>
|


| is also functionally indistinguishable from the talk about IPv8 and the
| foolisness of those someone likes to call "legacy internet engineers."
That is a bit below the belt isn't it? It's one thing to step up to
the mike and claim to channel Keith Moore but to be accused of beeing
functionally equivalent to a troll is a different kettle of fish
altogether.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/iDem8Jx8FtbMZncRAtw+AKC9GMvYXWHm2fT/awNnQX93Hjbj6gCfdSG9
H8zjjJ3KMlXbnMlF+CWlOuY=
=Lb2i
-END PGP SIGNATURE-

Re: Impact from rfc1918 leaks

[Leif Johansson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Iljitsch van Beijnum wrote:



|
| My argument was (is) that having RFC 1918 routes or packets escape
| doesn't add additional problems on top of the fundamental problem that
| routes or packets with the wrong addresses get out. Letting out wrong
| (non-RFC 1918) addresses hurts the legitimate holder of those addresses.
| With RFC 1918 addresses this isn't a problem.
In the DNS case this is incorrect. What happens is that you get a udp
packet with a return addr of 10.0.0.1 and not only don't you know what
to do with it so you have to throw it away but you can be sure of
getting the *same* query again, and again, and again, presumably from
the *same* client who can't figure out why the reply isn't coming back.
This happens in many protocols which are (contrary to popular belief)
deployed on the Internet today.
|
| I don't think another 10% load on the root nameservers is a huge deal,
| so I wouldn't use the word "harmful" but I guess this is a special case
Again. You'll have to ask the operators of the root-zone if they
consider 11-14% a big deal. Maybe some of them are listening
| I read a report that only 2% of the hits on the root servers is both
| legitimate and useful anyway.
~From the presentation I refer to which unfortunately is in Swedish but
you can probably read the numbers anyway... :
http://www.iis.se/Internetdagarna/2003/23-robust-dns/id03-23-lars-johanliman.pdf

this is clearly not the case. The rfc1918-queries consistute the bulk
of bad queries ("DUMMA frågor" on page 4 of the presentation). I must
however confess ignorance as to what queries are 'useful'. Presumably
even the rfc1918-queries were deemed useful for someone since they
were sent in the first place.
	Cheers Leif



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/h8xI8Jx8FtbMZncRAmLHAJ9gRWRPZ+oJRRG/Xr+EeLQLRM1FBwCgixT/
sf5v+ALitXYAaXHDGp8PCuM=
=KMeC
-END PGP SIGNATURE-

Impact from rfc1918 leaks

[Leif Johansson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michel Py wrote:
|>Leif Johansson wrote:
|>Tell that to the root zone operators and brace for the reaction.
|
|
| Root zone operators, meaning like Verisign?
|
| Michel.
|
Yes. I recently sat in on a presentation from the operators of
I.root-servers.net. Currently 8-10% of queries are from rfc1918
addrs and 3.6% of queries are for rfc1918 .in-addr.arpa records.
That is not an insignifficant number of queries.
	Cheers Leif

PS I changed the subject and trimmed the cc. It is sometimes
difficult to keep up when you are in a different timezone. I
appologize for the email you replied to which spilled over to
a thread where it did not belong. DS
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/h7PU8Jx8FtbMZncRAuNJAKCt/PyruJz7aLTIjxBSQvueGU3CwgCgokjc
9+0BukBcd0ySLugClYA/QqA=
=5JAc
-END PGP SIGNATURE-

Re: Appeal to the IAB on the site-local issue

[Leif Johansson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
|
| Don't take me wrong, I am not an air-headed academic who fails to
| understand the importance of beeing able to sell the solutions to
| people who are willing to pay for them.
Just to be very clear on this: I don't believe I have seen anyone
in the SL debate who presented an 'academic' argument without insight
into the commercial realities facing vendors. Even the most die-hard
opponents of SL I believe understand this. The failure to accept the
Furtune-500 argument is not the same as not understanding it.
Cheers Leif
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/h6at8Jx8FtbMZncRAqftAJ930kLekkwbg1LzbQJwnkCJdOZXsQCgg2ou
PNGLq07cMTfH94OX8cEJ44M=
=v36K
-END PGP SIGNATURE-

Re: Removing features

[Leif Johansson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Iljitsch van Beijnum wrote:

|
| This is based on the assumption that leaking RFC 1918 routing
| information or packets with RFC 1918 source or destination addresses is
| actually harmful in and of itself. This is a broken assumption. If
Tell that to the root zone operators and brace for the reaction.

Cheers Leif
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/h6cs8Jx8FtbMZncRAunXAJ9zQz+YXtdH6kjZy5BZL5CCYxU/JwCcCYjn
BD6+OpZS7L5Itcg1WfoPzGg=
=BRx5
-END PGP SIGNATURE-

Re: Appeal to the IAB on the site-local issue

[Leif Johansson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
| You know, I'd like to see a little more respect for people, and for the
| reports they make. Yes, it would be much better if operational staff
| from each of the Fortune 500 companies and larger tertiary operators
| came to the IETF and spoke for themselves. They don't, and that doesn't
| make their opinions or requirements irrelevant.
I do (sort of) apologize for the tone of my email but I simply don't
understand how the debate in the IETF will survive the trend to replace
technical argument with "My Fortune 500 customers tell me foo and thus
foo it must be.". Please tell me how that is fundamentally different
from voting based on (in some way) market share.
Don't take me wrong, I am not an air-headed academic who fails to
understand the importance of beeing able to sell the solutions to
people who are willing to pay for them.
Cheers Leif
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/h59V8Jx8FtbMZncRAscCAKCDb6j3shAQ5ImB1Z0P/j9X75sBMgCgq1iG
k3AN8B/NTdZuE4Vtn8wrdG0=
=NsYR
-END PGP SIGNATURE-

Re: Appeal to the IAB on the site-local issue

[Leif Johansson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eugene M. Kim wrote:



|
| With all due respect, it seems that it would be beneficial for both
| camps (for and against SL) to hear, even now, the real concerns directly
| from the operation people and to let them participate in the decision
| themselves. ... 
Been there. Done that. Didn't work. This vast Moral Majority of the
Site-Locals either don't exist or live entierly behind NATs or other
boxes which prevent them from receiving the call to arms to participate
in the debate. ;-)
Cheers Leif
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/hyUP8Jx8FtbMZncRAjBrAJ9mn99C+vUGrNifGl+moqvMz31qPgCfavjp
ZpDTz3E6/Z54/T4qRpL8W3o=
=LQPP
-END PGP SIGNATURE-

more stuff that was good

[Leif Johansson]

Coffee - transparency is not always a good thing :-) Food for thought 
for IETFs in the US.

  Cheers Leif

Re: in-addr.arpa missing

[Leif Johansson]

Randy Bush wrote:

If you think that is strange I got 81.160.251.0 just now
   

given the netmask, that is a perfectly legitimate interface
address
randy

 

True but I'm not getting any traffic through though...

Re: in-addr.arpa missing

[Leif Johansson]

Randy Bush wrote:

i received 81.160.221.53 via dhcp.  but

Host 53.221.160.81.in-addr.arpa not found: 3(NXDOMAIN)

randy

 

If you think that is strange I got 81.160.251.0 just now (!) but I am not
sure it isn't pocketpc 200x thumbing its nose at me :-)
  Cheers Leif

ssl jabber?

[Leif Johansson]

It would be nice to be able to speak ssl to the conference server...

 Cheers Leif

Re: jabber note-takers

[Leif Johansson]

Marshall Rose wrote:

What is the policy this time? Are chairs encouraged or strongly encouraged
to provide note-takers for the conference room?
   

in the absence of a specific request from the iesg, i'd say it's up to the
chair. little harm in asking at the beginning of the meeting, right?
/mtr
 

Unless you are not in the room but would like to listen in :-( This was 
maintained
very nicely in Atlanta.

   MVH leifj

jabber note-takers

[Leif Johansson]

What is the policy this time? Are chairs encouraged or strongly encouraged
to provide note-takers for the conference room?
 Cheers Leif

Re: trying to sweep namedroppers mismanagement under the rug

[Leif Johansson]

Dean Anderson wrote:

If list management weren't a problem, and the policy were being followed,
we wouldn't be having this discussion.



You are right! Escalating flame-wars on the IETF-list never happen
unless there is a real honest-to-god technical dispute and Elvis is
alive and well on Mars ;-)

	Cheerio Leif

the ascii discussion all over again...

[Leif Johansson]

For those who doubt the power of ascii graphics or believe you
need rtp to publish media on the internet try

telnet towel.blinkenlights.nl

Cheers Leif

Re: Kerberos Query.

[Leif Johansson]

Aneuya wrote:

>HI,
>
>This query is regarding Kerberos V5.
>
>I want to know in case of WAN, what the flow of
>request starting from the client to the application
>server will be when it doesnt have the ticket for it ?
>Does client have to know the adrress of Kerberos
>server ? 
>
>Your help will be immensly appreciated.
>
Most k5 implementations support discovering the location of the kdc through
SRV records. Many large installations I believe use this feature 
(including those
that use AD as their kdc). I am not sure if this answers your question...

Cheers Leif