Re: Stopping loss of transparency...

[Peter Dambier]

Roland Bless wrote:

Hi,

just yesterday a larger german DSL/Internet provider activated
- without a real notice - a feature as "field trial" in my city,
so that HTTP(S) requests of customers are redirected to their own
web portal (apparently using some soft state timeout).
I'm also aware of several other dial-up providers who do that.
This breaks IMHO a lot of applications, e.g., DynDNS
registrations of DSL routers (which would not be necessary
with IPv6 but that is another issue), automated Windows/Linux
updates, anti-virus database updates, RSS and presumably many
more. Though they sell it as a "service to
customers" (luckily you still can turn this feature off
if you know how to do it...), I see it as very dangerous
since automated security updates etc. will fail, i.e. they
even decrease the security of their cutomers! Is there
anything newer than RFC 2775 that one could give as
strong technical advice to abandon that feature and to
not turn it on for all other users?



Hi Roland,
I have seen the Heise forum is shaking up because of that. Today
it is GMX or United Internet but tomorrow it could be DTAG.DE and
in fact it is DTAG.DE who does offer this "service" to its clients
like United Internet. Obviously they (DTAG.DE) offered this
"service" as a trojan horse to get some of their T-online desserteurs
back. They did not only break software but they did break hardware too,
routers. Some of the end users are locked out. Switching off that
"service" means changing user id's. After that some routers did
not login again, neither using the old nor using the new user id.
I guess marketing is not amused.


Regards,
 Roland

P.S.: please don't comment that I should just switch
the provider in this case. I like to raise the awareness of
the provider that this feature is _technically_ dangerous,
though it may make a lot of sense for the marketing people...


In fact things like that did stop me from changing. My isp is
not the cheapest nor do they offer the best service but they are
so predictable. Normally you dont need to be afraid of changes
from burocrates. :)

Oh, yes there have been changes too with DTAG.DE they changed
"my" DSLAM to 84.xxx.xxx.xxx and 84.xxx.xxx.xxx is still very new.
A lot of routers treat it as bogon. Of course United Internet
got that very same address range. They too do worry why some
ip addresses can no longer ftp, scp or VoIP.

Introducing a new "service" was just a means of throwing sand
into their customers eyes and keeping them from seeing the
big picture.


Regards,
Peter and Karin Dambier
--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


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

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier]

Stuart Cheshire wrote:
The IESG has received a request from the DNS Extensions WG to consider 
the following document:


- 'Linklocal Multicast Name Resolution (LLMNR) '
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2005-08-24.


I really would appreciate do think IESG should postpone or reject.

This protocoll is untested!

Its implementation could result in a loss of lives!

There is no reference implementation.


Apple's mDNS protocol differs from LLMNR (and DNS) in more than
half a dozen ways.


1. It is emplemented.

2. Mostly everybody does use it.

3. mDNS did not result in the loss of lives.



Apple mDNS and LLMNR use different ports, as well as different
multicast addresses, and because of the many protocol
differences, do not interoperate.



Consider:

RFC 1149 - Standard for the transmission of IP datagrams on avian carriers

Everybody thinks of implementing RFC 1149 on birds only or at least on
living beeings with feathers.

How about insects? How about bats?

Here in Germany we have accidently closed the entrance to a tunnel used by
bats. To save their lives we opened a new entrance into that tunnel.

The bats did not know. Millions lost their lives crashing into the debries
from the old entrance.

Moving wellknown ports and addresses is like randomly opening and closing
tunnel.

In my honest oppinion this draft does violate RFC 1149 and it knowingly
riscs the loss of lives ...

Forget about bats and bees now. Think of existing programmes and appliances.
Do you want to kill them?

Kind regards,
Peter and Karin Dambier


--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


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

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier]

Stuart Cheshire wrote:


Putting service discovery requirements aside for a moment, the other big 
difference between mDNS and LLMNR is that mDNS facilitates local-scoped 
names, analogous to RFC 1918 addresses. LLMNR lets you look up a host 
name without a DNS server, but it pre-supposes that you HAVE a globally 
unique fully-qualified host name in the first place. In contrast, mDNS 
says you can call your television "tv.local" if you want, and you don't 
need to pay anyone for that name, or ask permission, or know how to 
register it in some global database, but at the same time the name has 
only local significance so don't expect it to be usable worldwide.


What's weird about LLMNR is that it blurs what's global and what's local. 
With LLMNR you can call your television "tv.ietf.org" if you want, and as 
long as the IETF's name server returns NXDOMAIN (which it does today) 
then a LLMNR-compliant host will fail over to local multicast and resolve 
that name to your television's address. This sends a very strange message 
to end users -- it suggests they can use any name they want in any domain 
they want without having to communicate with any registry. It also means 
that every failed DNS query will result in a LLMNR multicast on the local 
network, and (worse) every intentional LLMNR query needs to be preceded 
by a failed DNS query to some unsuspecting DNS server somewhere.




Here we did have a problem:

In The Public-Root there used to exist a domain ".local". I know at least
of one ISP who complained we did break a lot of windowed PCs.

I dont know why queries for ".local" would leave their private LANs and
reach even our root servers. They did!

That is why we set up a dummy and returned localhost, to get rid of those
bogus queries. That is what finally broke their windows and dropped our
root server traffic some 25%. :)

mDNS says that "local" is a free-for-all playground where anyone can use 
any name and no one has any more right to a particular name than anyone 
else. LLMNR didn't want to do that, but what they've effectively ended up 
doing instead is saying that the root of the DNS namespace (and 
everything below it) is a free-for-all playground where anyone can use 
any name they want.


Stuart Cheshire <[EMAIL PROTECTED]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org



--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


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

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier]

Keith Moore wrote:
What is this document for? No one has implemented this LLMNR protocol. No 
one has any plans to implement this protocol. No company plans to ship 
products using this protocol. Even Microsoft has not even hinted at plans 
to use LLMNR in Longhorn/Vista. 



I don't see anything in RFC 2026 criteria that hinges on whether
Microsoft intends to implement a protocol.



I have seen windows boxes use it. They left traces on our root servers
and they cried when we hit them treating ".local" like "localhost"

It was windows users who complained not Macintoshes.


Local name lookup is useful, but trying to overload DNS names to serve
two different purposes, without breaking apps and/or making DNS appear
to be inconsistent, is fairly difficult.  There's an inherent conflict
between wanting local name lookup to be transparent to apps
(perhaps even by changing the semantics of existing and well-established
APIs to do local lookup in addition to DNS lookup), and having the two
lookup services produce inconsistent results (thus confusing apps that
quite reasonably expect that they should be consistent).  If you try
to make the two kinds of names look different you risk breaking apps
that expect everything to look like a DNS name.  And if you overload
DNS syntax then you subject DNS servers to bogus queries.  



Bogus queries do sabotage our root servers. They make 90% of our traffic.
That is what "root-servers.net" say. I have seen traffic reduced on
"a.public-root.net" by some 25% when we showed them a dummy for ".local".


The primary reason IETF exists is to try to sort out those kinds of
conflict in an open, neutral setting. 


For whatever reason, you chose to ship code without waiting for IETF to
finish its deliberations on how to resolve those conflicts. Maybe you
were right to do so.  I wish I could say that IETF always produces
superior results, but we all know that it desn't always succeed.  And
yet, by doing so you were essentially disregarding others' legitimate
concerns about the problems associated with your approach, and/or
unilaterally deciding, on behalf of not only your customers but
everyone who might be affected by deployment of your protocol, that you
are in a better position to know what is good for them than everyone
else who participated in IETF.


They are restricted to their local LANs. I have never seen them in the
wide, wild internet.



Now you are arguing  that people who attempted to consider a wide range
of input, and to do a responsible job of engineering a DNS-compatible
name lookup solution should abandon the results of their efforts in
favor of your ad hoc solution, merely because you were irresponsible
enough to ship it in product before the issues were widely understood
and the conflicts resolved in an open forum.

Well, maybe you're right, and maybe mDNS is better than LLMNR.  Or
maybe mDNS is only slightly worse, and not enough worse to make it
worth the confusion that standardizing LLMNR will create.  But you're
not going to convince anybody of that with your current line of
argument.

IMHO, if you can't provide a thorough analysis indicating that mDNS
works better than LLMNR,  that mDNS resolves those conflicts in a
superior way to LLMNR, and that your solution will do less harm to
applications and DNS consistency than LLMNR, and that mDNS conforms to
2026 criteria, you don't have much of a gripe, and you certainly don't
have justification for saying that LLMNR should be abandoned.

You ask about running code.  Running code is useful.  A single
impelmentation serves as a proof of concept.  Multiple implementations
derived from a single spec and tested against each other serve as a
clarity check on the specification.  But mere existence of running code
is not a reliable indicator of sound design.  In the ARPAnet days, when
there were only a few dozen hosts, a few interoperability tests were
generally enough to give a reliable indication of full-scale behavior.
In an Internet with a billion hosts, producing an implementation is
just a baby step.  These days, there's no substitute for thorough
analysis of the effect of a protocol based on a large number of use
cases.  So mDNS's running code and deployment do not trump LLMNR, and a
comparison of mDNS and LLMNR implementations would not yield much
useful data unless one were grossly more inefficient than the other.



I'd say 25% of traffic on root servers is grossly inefficient and it does
violate a couple of RFCs.



As for this Last Call - I think there are two questions that should be
asked:

1. does LLMNR meet 2026 criteria?  no known technical omissions,
conflicts resolved, etc. 


2. is LLMNR enough better than mDNS to make it worth approving it as a
standard even though mDNS exists and has some limited deployment?   If
the answer to #1 is yes, then I suspect the answer to #2 is also yes,
but an explanation is needed.

Furthermore, if there is rough consensus, supported by analysis, that
mDNS is harmful, 

[Re: regarding IETF lists using mailman: nodupes considered harmful]

[Peter Dambier]

Hi Jeroen,

I forwared your message - not replying to show your headder:

From: Jeroen Massar <[EMAIL PROTECTED]>
To: Keith Moore 
Cc: ietf@ietf.org

So you had sent to [EMAIL PROTECTED]
ietf@ietf.org received only a copy. Some people might have got nothing.

My own Mozilla/Thunderbird behaves the same way:

I would have had to manually change to/cc for all recipients.

That is what we all need to do now if I got it correctly.

Regards
Peter and Karin


 Original Message 
Return-Path: <[EMAIL PROTECTED]>
X-Flags: 
Delivered-To: GMX delivery to [EMAIL PROTECTED]
Received: (qmail invoked by alias); 26 Aug 2005 07:24:30 -
Received: from megatron.ietf.org (EHLO megatron.ietf.org) [132.151.6.71]  by 
mx0.gmx.net (mx032) with SMTP; 26 Aug 2005 09:24:30 +0200
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)   
by megatron.ietf.org with esmtp (Exim 4.32) id 1E8YRC-0004bw-Fw; Fri, 26 
Aug 2005 03:15:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)by 
megatron.ietf.org with esmtp (Exim 4.32) id 1E8YR9-0004ao-Fl for [EMAIL 
PROTECTED]; Fri, 26 Aug 2005 03:15:39 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) 
with ESMTP id DAA02085  for ; Fri, 26 Aug 2005 03:15:38 
-0400 (EDT)
Received: from 213-136-24-43.adsl.bit.nl([213.136.24.43] 
helo=purgatory.unfix.org ident=postfix)by ietf-mx.ietf.org with esmtp 
(Exim 4.43) id 1E8YRo-0002xE-QX  for ietf@ietf.org; Fri, 26 Aug 2005 03:16:22 
-0400
Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45])	(using SSLv3 with cipher RC4-MD5 (128/128 bits))	(No client certificate requested)	by purgatory.unfix.org (Postfix) with ESMTP id 7A73D7FAD;	Fri, 26 Aug 2005 09:14:59 +0200 
(CEST)

From: Jeroen Massar <[EMAIL PROTECTED]>
To: Keith Moore 
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Organization: Unfix
Date: Fri, 26 Aug 2005 09:14:55 +0200
Message-Id: <[EMAIL PROTECTED]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: ietf@ietf.org
Subject: Re: regarding IETF lists using mailman: nodupes considered harmful
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,  
List-Post: 
List-Help: 
List-Subscribe: ,
Content-Type: multipart/mixed; boundary="===0208067608=="
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-GMX-Antivirus: 0 (no virus found)
X-GMX-Antispam: 0 (Sender is in whitelist: [EMAIL PROTECTED])
X-GMX-UID: 4aZ8Y7wSeSEkUtTJ43QhaXN1IGRvb0Ch

On Thu, 2005-08-25 at 18:20 -0400, Keith Moore wrote:



Specifics:  Mailman has a per-recipient setting called "nodupes".  The
effect of this setting is that any recipient address that has the
nodupes flag set, and which appears in a To or CC field of a message
sent to the list, will not receive a copy of the message from the
list.


But they _should_ be getting the message directly already, because of
the CC: or To:. Or is there something which causes the person not to get
it?

Indeed when some 'malicious' person would add Cc's/To's and would
instruct his SMTP to not forward to the additional addresses in the
Cc/To the users will effectively not receive the message.

Or when the recipient doesn't accept messages to [EMAIL PROTECTED] +
himself, and expects everything to come from the list directly.

But how exactly does this cause a problem?

Greets,
 Jeroen




--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


signature.asc
Description: PGP signature
___
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: [Re: regarding IETF lists using mailman: nodupes considered harmful]

[Peter Dambier]

Iljitsch van Beijnum wrote:

On 26-aug-2005, at 10:33, Peter Dambier wrote:


Hi Jeroen,




I forwared your message - not replying to show your headder:




From: Jeroen Massar <[EMAIL PROTECTED]>
To: Keith Moore 
Cc: ietf@ietf.org




So you had sent to [EMAIL PROTECTED]
ietf@ietf.org received only a copy. Some people might have got  nothing.




My own Mozilla/Thunderbird behaves the same way:




I would have had to manually change to/cc for all recipients.




That is what we all need to do now if I got it correctly.



No, what needs to happen if we collectively decide we don't want the  
current behavior is that the mailinglist software sets a "reply-to"  
header, so when you hit "reply" or "group reply" your reply is sent  
with the list in the "To:" field and nothing else. This used to work  
well, not sure if modern clients handle this correctly, though. Try  to 
reply to this message to see what happens.


Great, it works!



(BTW I got so fed up with receiving endless CCs for each discussion  
thread I've ever posted to (you can actually manually remove those,  
people!) that I now have procmail remove all messages with duplicate  
msgids.)


Iljitsch



Makes things a lot easier.

Regards,
Peter

--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


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

Re: NAT/Proxy combinations

[Peter Dambier]

Iljitsch van Beijnum wrote:

On 28-aug-2005, at 8:51, Atul Sabharwal wrote:

Generally, people use NAT or Proxy as firewalls.  Would it be more  
secure to use a NAT Proxy combination ?




In the hand of a hacker NAT is a very useful device. He can safely hide
behind a NAT that rapidly switches ip addresses. Nobody can follow him.



Basically, a NAT is just a simple and general-purpose way to  implement 
a proxy.


It does play the role of a proxy nobody has ordered and nobody does
even no it exists. So it does breake security by providing a
proxy that should bo be there in the first place.



If you define "more secure" as "less likely that random packets will  be 
delivered": sure, put in as much stuff that makes everything less  
transparent as you can.


In fact it provides a loophole destroying every attept to security from
end to end.



Obviously this won't help against many popular attack vectors which  
prey upon the gullibility of the typical user, which mostly happen  over 
HTTP or through mail, which don't need a transparent  communication 
channel.


But it provides a great way to break into any established secure link.

Just wait for them to exchange passwords. Break the connection and do
your evil. Dont care any longer and let the connection drop to the
floor. NAT and windows will cope and nobody will ever see a trace in
their logs.



And please don't expect the IETF to make its protocols work through  
your multiple layers of NAT and proxies.




NAT was never designed for security. NAT was designed as a loophole.
That loophole has improved greatly over time.

All bad things said I would like to mention that a windows computer
wont stay long in the internet if you dont hide them behind NAT

It really does not make a difference wether you proxy on the NAT or
somewhere else except when you proxy after the NAT you proxy after
a proxy. You can replace several proxies by a tunnel through a
low speed data line. In fact that will break SSH wordbook attacks.
Just delay everything longer than the hacker probably waits

Regards,
Peter Dambier


--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


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

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier]

[EMAIL PROTECTED] wrote:


LLMNR has waded through the lengthy IETF standardization
process to get to where it is.  That Microsoft has been patient and 
spent
the money needed to keep people on this task long enough to get it here
should be rewarded with the IETF imprinture.  Of course even Microsoft 
has
hedged its bets (even they are aware of the need to ship products) wrt
LLMNR.  But that is no reason for the IETF to not sanction this work.

--bill



How about a protocol to remotely control the explosion of bombs. It could
even be built on top of LLMNR. It is not necessaryly more harmful than
LLMNR. Nobody intends to build bombs anyhow not to mention remotely explode
them. So would you consider publishing this protocol harmful?

Terrorists - I am sorry, weapons researches have spent a lot ...

We should really reward them by publishing this parodicol :)

Is that what you meant?

Regards
Peter

--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


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

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier]

Ian Jackson wrote:

Brian E Carpenter writes ("Re: Last Call: 'Linklocal Multicast Name Resolution 
(LLMNR)' to Proposed  Standard"):


Ian Jackson wrote:


Sorry to be pejorative, but as a DNS implementor[1] I'm amazed to find
senior IETF/IESG people seriously contemplating the kind of namespace
confusion which is fundamental in the LLMNR protocol design.


Can you spell that out please? Since it uses a different port number,
where does the confusion occur?


The confusion occurs on the root servers.

I dont really know if it was some LLMNR enabled windows machine, but
they definitely asked DNS first and on port 53. If we supply a dummy
zone like we do for localhost then those boxes do break.


What does the port number have to do with it ?  That's an
implementation detail (from the point of view of this complaint; many
other complaints might well be about these kind of details).

The LLMNR model supposes that when an application asks for data of a
certain type associated with a certain name (ie, when the application
thinks it's asking for a DNS query) answers may come from either the
real DNS system or, even if the real DNS is authoritative for the
relevant name but denies that it exists, from LLMNR.


You name it: The implementation asks DNS for garbadge.local and if we
say 127.0.0.1 then windows breaks.

If we dont supply the krutch then 25% of our root server traffic is
for .local because they repeat their question again and again on all
13 if the root servers.


See draft-ietf-dnsext-mdns-42 s2 bullet point [2].

It is not true that separating LLMNR out on a different port, and
introducing other incompatibilities, prevents confusion between LLMNR
and the real DNS.  Applications will still see a bizarre mix of real
and LLMNR data.

On the other hand, mDNS has a much better scheme: the mDNS
specification defines the tree under `.local' for mDNS use.  Names in
.local are looked up with mDNS and names elsewhere via the real DNS.
This means that applications always either see the data intended for
them, or (transient) failure if the relevant mechanism isn't
available.

Stuart Cheshire makes IMO a very cogent argument in
<[EMAIL PROTECTED]>, where he says:
] What's weird about LLMNR is that it blurs what's global and what's local.
] With LLMNR you can call your television "tv.ietf.org" if you want, and as
] long as the IETF's name server returns NXDOMAIN (which it does today)
] then a LLMNR-compliant host will fail over to local multicast and resolve
] that name to your television's address. This sends a very strange message
] to end users -- it suggests they can use any name they want in any domain
] they want without having to communicate with any registry. It also means
] that every failed DNS query will result in a LLMNR multicast on the local
] network, and (worse) every intentional LLMNR query needs to be preceded
] by a failed DNS query to some unsuspecting DNS server somewhere.
] 
] mDNS says that "local" is a free-for-all playground where anyone can use

] any name and no one has any more right to a particular name than anyone
] else. LLMNR didn't want to do that, but what they've effectively ended up
] doing instead is saying that the root of the DNS namespace (and
] everything below it) is a free-for-all playground where anyone can use
] any name they want.

In addition, mDNS's limitation to `.local' means that deliberate
additional incompatibilities to avoid cache pollution in the real DNS
is not necessary; since mDNS is only used for names in `.local',
normal precuations against unsolicited DNS replies will prevent the
main DNS namespace being polluted with mDNS data.

If we are to so strongly fear pollution, mDNS's wide deployment ought
to provide some evidence for this from operational experience !  Where
is that evidence ?


mDNS is mostly free of bugs. The dont ask DNS for garbage.local . That is
why we dont see them.


Regards,
Peter Dambier

--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


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

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier]

Brian E Carpenter wrote:

Peter,

I'm afraid I don't understand. As far as I can understand,
mDNS uses the .local pseudo-domain and LLMNR does not.
So how can LLMNR be blamed for bogus queries for *.local?


I cannot garantie it was LLMNR. I was told these are windows boxes
using the default enabled LLMNR and it defaults to ".local". I know
that newer windows boxes do have LLMNR but it is not normally used.
Nevertheless it comes up.

MAC systems with mDNS may use ".local" too but they never ask for
".local" via DNS. They stay with mDNS on the direct link.

It was only windows boxes who complained when we returned 127.0.0.1
for *.local



I can easily configure my Windows box to default to *.local.
But why would I want to?

   Brian


The problem is that windows users plug their box in and cry if it does
not work. They dont know how to configure or why.

Well, if you do not use ".local" on your box why not try ".com" ?
It might be fun. :)



Peter Dambier wrote:


Ian Jackson wrote:

Brian E Carpenter writes ("Re: Last Call: 'Linklocal Multicast Name 
Resolution (LLMNR)' toProposed  Standard"):



Ian Jackson wrote:


Sorry to be pejorative, but as a DNS implementor[1] I'm amazed to find
senior IETF/IESG people seriously contemplating the kind of namespace
confusion which is fundamental in the LLMNR protocol design.




Can you spell that out please? Since it uses a different port number,
where does the confusion occur?




The confusion occurs on the root servers.

I dont really know if it was some LLMNR enabled windows machine, but
they definitely asked DNS first and on port 53. If we supply a dummy
zone like we do for localhost then those boxes do break.


What does the port number have to do with it ?  That's an
implementation detail (from the point of view of this complaint; many
other complaints might well be about these kind of details).

The LLMNR model supposes that when an application asks for data of a
certain type associated with a certain name (ie, when the application
thinks it's asking for a DNS query) answers may come from either the
real DNS system or, even if the real DNS is authoritative for the
relevant name but denies that it exists, from LLMNR.




You name it: The implementation asks DNS for garbadge.local and if we
say 127.0.0.1 then windows breaks.

If we dont supply the krutch then 25% of our root server traffic is
for .local because they repeat their question again and again on all
13 if the root servers.


See draft-ietf-dnsext-mdns-42 s2 bullet point [2].

It is not true that separating LLMNR out on a different port, and
introducing other incompatibilities, prevents confusion between LLMNR
and the real DNS.  Applications will still see a bizarre mix of real
and LLMNR data.

On the other hand, mDNS has a much better scheme: the mDNS
specification defines the tree under `.local' for mDNS use.  Names in
.local are looked up with mDNS and names elsewhere via the real DNS.
This means that applications always either see the data intended for
them, or (transient) failure if the relevant mechanism isn't
available.

Stuart Cheshire makes IMO a very cogent argument in
<[EMAIL PROTECTED]>, where he says:
] What's weird about LLMNR is that it blurs what's global and what's 
local.
] With LLMNR you can call your television "tv.ietf.org" if you want, 
and as

] long as the IETF's name server returns NXDOMAIN (which it does today)
] then a LLMNR-compliant host will fail over to local multicast and 
resolve
] that name to your television's address. This sends a very strange 
message
] to end users -- it suggests they can use any name they want in any 
domain
] they want without having to communicate with any registry. It also 
means
] that every failed DNS query will result in a LLMNR multicast on the 
local
] network, and (worse) every intentional LLMNR query needs to be 
preceded

] by a failed DNS query to some unsuspecting DNS server somewhere.
] ] mDNS says that "local" is a free-for-all playground where anyone 
can use
] any name and no one has any more right to a particular name than 
anyone
] else. LLMNR didn't want to do that, but what they've effectively 
ended up

] doing instead is saying that the root of the DNS namespace (and
] everything below it) is a free-for-all playground where anyone can use
] any name they want.

In addition, mDNS's limitation to `.local' means that deliberate
additional incompatibilities to avoid cache pollution in the real DNS
is not necessary; since mDNS is only used for names in `.local',
normal precuations against unsolicited DNS replies will prevent the
main DNS namespace being polluted with mDNS data.

If we are to so strongly fear pollution, mDNS's wide deployment ought
to provide some evidence for this from operational experience !  Where
is that evidence ?

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier]

Yes, that is exactly what our unvolontary experiment has shown.
And it makes 25% of our root server traffic. It is stealing resources
from us. That is why we consider this protocol harmful to the
internet society.

Kind regards,
Peter and Karin


Stuart Cheshire wrote:

As I understand it, one of three things will happen:

(1) If the system implements mDNS, the .local domain is treated 
specially, so this just goes out as a link-local request.


(2) If the system implements LLMNR, there will first be a global DNS 
lookup for "twiki.local", which will fail.  Then, a link-local name 
request will be tried.


(3) If the system doesn't implement any link-local name resolution, 
there will be a global lookup for "twiki.local" which will fail.


So, if people use .local domains on systems that implement LLMNR 
instead of mDNS, this can result in lookups for .local in the global 
DNS.


But, given that choices (2) and (3) involve the same interaction with 
the DNS, I'm not sure how one can argue that LLMNR makes things any 
worse than things would be without it.  Perhaps you could argue that 
mDNS makes things better, but that is only true for this one 
non-existent TLD -- all three systems would generate a bogus global 
DNS query if I did a DNS lookup for "isoc.frog".


Margaret



There's one other relevant difference to note here: If you do a DNS 
lookup for "isoc.frog" you generate a bogus global DNS query. This is 
true. But... do you habitually do DNS lookups for "isoc.frog"?


Well, in case 1 (mDNS), no, because it won't return a useful result, so 
why keep doing it?


In case 3 (conventional DNS), no, because it won't return a useful 
result, so why keep doing it?


In case 2 (LLMNR) the answer is yes, all the time, if you chose to call 
your printer "isoc.frog", which LLMNR allows and encourages.


Stuart Cheshire <[EMAIL PROTECTED]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org



--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


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

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier]

Russ Allbery wrote:

Margaret Wasserman <[EMAIL PROTECTED]> writes:



Other than a few minor issues that are being dealt with in a -43 update,
I don't think that anyone has raised a blocking technical issue with the
LLMNR specification during this IETF LC.  If you (or anyone else) has
intended to raise a blocking technical issue, either with LLMNR itself
or with its ability to coexist with mDNS, please make that clearer to
me.




Sorry I overlooked this:

I dont count 25% of the root server traffic a minor issue.
With 90% of root server traffic used to be for localhost and with
25% of root server traffic already for local, we are looking into
a major DoS attack. This might overload ISPs DNS servers it might
even bring the root servers down if they let it free!



I'm getting the impression from the IETF list discussion that several
people do consider the behavior of querying regular DNS first for names
that will be handled by LLMNR to be a blocking technical issue.  I'm not
sure that I've reached the point where I would say that personally, but
the descriptions here have at least been concerning.

I think it is very useful to have a clear distinction between DNS
namespaces, with one namespace clearly identified as being link-local so
that people are not under the impression that they can use arbitrary DNS
domains for link-local resolution and so that software knows not to try to
resolve link-local names against regular DNS servers.  It sounds like mDNS
does this as part of the protocol specification.



On the other hand, the DNSEXT WG has worked for several years to produce
the LLMNR specification, and I don't see anything fundamentally wrong
with the mechanism that we have produced (people should respond to the
IETF LC if they see blocking technical issues). The authors of that
specification gave change control to the IETF community, and they have
gone through 40+ document iterations, working towards a document that
would achieve DNSEXT consensus.  That process was not followed for mDNS
(because it was not the chosen solution), and we currently only have one
document (LLMNR) that has reached IETF WG consensus and has been
submitted for standards publication.



As near as I can tell, the authors of the mDNS specification also gave
change control to the IETF community, so I wouldn't raise that as a
distinction.  The only distinction appears to be working group consensus;
the protocols otherwise look to be in the same place legally and
process-wise.



It is possible, in an IETF LC, that we could learn that we do not have
IETF consensus to publish something that was produced by an IETF WG.



At the moment, based on the discussion in the IETF list, I don't believe
that LLMNR should be published on the standards track unless mDNS is also
being published on the standards track and we agree we really want to have
two standards for this (which I think everyone is agreed would be bad).
Publishing them both as experimental and then seeing which gains more
general acceptance and works better in practice sounds reasonable to me.



I agree.

Regards,
Peter and Karin Dambier


--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


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

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier]

Hi Bill,

I am speaking of this root-server system:

a.public-root.net.  900 IN  A   205.189.71.2
b.public-root.net.  900 IN  A   61.9.136.52
c.public-root.net.  900 IN  A   68.255.182.111
d.public-root.net.  900 IN  A   205.189.71.34
e.public-root.net.  900 IN  A   216.138.219.83
f.public-root.net.  900 IN  A   66.15.237.185
g.public-root.net.  900 IN  A   199.5.157.131
h.public-root.net.  900 IN  A   64.198.89.245
i.public-root.net.  900 IN  A   203.187.202.205
j.public-root.net.  900 IN  A   57.73.7.89
k.public-root.net.  900 IN  A   81.19.74.67
l.public-root.net.  900 IN  A   195.214.191.125
m.public-root.net.  900 IN  A   205.189.71.26

and I am beeing told by experts that there is no difference to
what other root-server operators have found on their servers.

ICANNed root-server operators look with interest into what
Public-Root has experienced because in the near future they will
have to support more domains than they do today. We do share
information.



I dont count 25% of the root server traffic a minor issue.
With 90% of root server traffic used to be for localhost and with
25% of root server traffic already for local, we are looking into
a major DoS attack. This might overload ISPs DNS servers it might
even bring the root servers down if they let it free!



i'm going to have to raise the point that Peters "root-server" system
is his private "walled-garden" and not representative of the Internet's
authoritative root servers.   Just for clarification.

--bill




--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


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

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier]

Brian E Carpenter wrote:

Peter,

Peter Dambier wrote:


Russ Allbery wrote:


Margaret Wasserman <[EMAIL PROTECTED]> writes:


Other than a few minor issues that are being dealt with in a -43 
update,
I don't think that anyone has raised a blocking technical issue with 
the

LLMNR specification during this IETF LC.  If you (or anyone else) has
intended to raise a blocking technical issue, either with LLMNR itself
or with its ability to coexist with mDNS, please make that clearer to
me.






Sorry I overlooked this:

I dont count 25% of the root server traffic a minor issue.



Can you point to publicly available data about the rate of .local
queries to *all* the root servers (including the anycast servers)?

 Brian



Hi Brian,

I would really like to do.

We have been alarmed by ISPs that we did kill some customers applications
and we stopped publishing the ".local" immediately.

From the data gathered by our root-server operators at that moment we
estimate that the traffic for ".local" must have been some 25%

At this moment we have to sort out a couple of things but I promise
we will make our data publicly available soon.

Kind regards,
Peter and Karin Dambier

--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


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

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier]

Steven M. Bellovin wrote:

In message <[EMAIL PROTECTED]>, Marc Manthey writes:


   i'm going to have to raise the point that Peters "root-server" 
system
   is his private "walled-garden" and not representative of the 
Internet's

   authoritative root servers.   Just for clarification.

--bill



i want to correct  bills concern  that  , " peters public root server
system" is
an alternative for  the existing ones  and there are several others .




At the risk of starting down a tangent, the IETF does not, as a 
technical matter, accept the validity of so-called alternate roots.  
See RFC 2826.


--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



Dear Steven,

the Public-Root is not an alternative root but a solution.

Kind regards,
Peter and Karin


--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


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

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier]

Paul Hoffman wrote:

At 2:47 PM +0200 8/31/05, Brian E Carpenter wrote:


That is about 1/3 of the total. It doesn't surprise me at all that
so many bogus queries arrive - everybody who mistypes a TLD or
misconfigures a default domain generates bogus queries, and this isn't
going to change. The question is whether .local is a *significant*
part of this load. The limited data I have suggest not, but I'd like
to see publicly available data: what fraction of those NXDOMAINs are
due to .local?



The question maybe should be whether .local will become, not is, a 
significant part of this load. If you prevent mDNS, the main proponent 
of the .local namespace, from becoming a standard, the number of those 
names will remain low. If it becomes a standard and implementers use 
that namespace more, the load will of course increase.




Sorry it was not mDSN that provoced these lookups. It was some prerelease
of LLMNR.

There is no LLMNR on apples. The machines that complained were windows
only.


Regards,
Peter and Karin Dambier


--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


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

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier]

A friend just called to teach me how to spell LLMNR.
Sorry I can not do that without looking it up.

And he told me not to be so harsh with it. Yes they
need it. Their bot controler needs it.

No, you dont need a windows for the controler, MAC
or Linux does nicely. But the total cost of ownership
of a hijacked windows - you know ...

And he asked my not to tell you the details, like
windows caching used horseshoes or Netbios packets
remotely looking like DNS, or he would shot me or
ask the Apple Music Company (no, not the MAC people)
to do it :)




Kind regards,
Peter and Karin Dambier

--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


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

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[Peter Dambier]

Dave Singer wrote:
I'm a by-stander on this discussion, maybe off-base or out of it -- but 
something other than the undesirable traffic struck me.


Isn't it also true that I might *deliberately break* all sorts of things 
by introducing 'blocking' names into DNS responses, so that an LLMNR 
request is never issued.  So an ISP could 'grab' traffic that the users 
thought was local, by replying to a DNS request in a proxy (or 
converting a negative reply into an answer).


Yes,

we have done that accidently. We were told we have broken things on
windows by publishing ".local" in the Public-Root.

We stopped publishing that domain immediately. But yes, all you have
to do is send some random packets, resolving '.local' to the windows
box. The thing will happily cache them and next time ...



Also, ISPs might be tempted to start turning around DNS requests in 
their proxies for names that they *think* should be answered by LLMNR, 
returning resolution failure, so as not to send too much traffic 
outbound.  This pre-empts the real DNS from ever actually replying.


The whole idea that 'real DNS' can arbitrarily pre-empt local name 
resolution seems, well, wrong, and needs serious study for security 
implications for the services using those names, no?





--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


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

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' toProposed Standard

[Peter Dambier]

JFC (Jefsey) Morfin wrote:

At 10:45 05/09/2005, Christian Huitema wrote:


> My greatest concern is that the document as it stands is likely to
> cause a large number of bogus DNS queries.  If the protocol is widely
> adopted, it seems probable that many clients will have LLMNR enabled
> on an interface in a situation where a DNS server has been configured
> (as described in section 2).  In that case, every LLMNR query will
> entail (possibly more than) one DNS query, because of the provision,
> "All attempts to resolve the name via DNS on all interfaces have
> failed after exhausting the searchlist."  Such DNS queries will become
> commonplace if the protocol is widely adopted and widely used.  This
> feature of the design appears to increase the burden on the entire
> Internet infrastructure in order to support unshared infrastructure.

Uh, no.



Christian,
I am not sure I understand you correctly. What Andrew fears, if I am 
correct, is an increase of the number of resolution requests. I feel you 
answer on the number of DNS querries per resolution request?


I would be interested in better understanding the details of the Windows 
mechanism: where to best find it described? It could be used for similar 
needs (registry distribution) I work on. I understand that what you name 
the "search list" is Hosts.txt? and that the idea is to either add a 
smarter database or a broadcast t querry to complete the local Host.txt 
service? However I fail to see what this really brings that a local 
dynamic name server would not provide with more security and services?


thank you
jfc





LLMNR does not create additional DNS queries. Applications do not issue
LLMNR requests, they issue name resolution requests. When a name
resolution request is issued, the current behavior is to submit the
request to the DNS, possibly applying a "search list". LLMNR does not
change that. LLMNR adds an additional transaction at the end of the
search list, falling back to local multicast resolution if the
infrastructure could not resolve the query authoritatively.



Can I translate this:
   A gun does not kill anybody. It is the mafia employee how does ...

An application using LLMNR does create additional DNS queries.

Well, no it doesnot. It asks the resolver to do it.

Asking the resolver for "gurgleblaster.bar.com" is dangerous. There
might be a record "*.bar.com 24.24.24.24". So you get the answer
24.24.24.24 and your host gurgleblaster.bar.com on ip 169.254.11.12
will never be looked up via LLMNR. So using other domains than
".local" does not make sense.

Asking the resolver for "gurgleblaster.local" will ask my resolver
to ask my ISPs resolver to ask all 13 root-servers about
"gurgleblaster.local" because none of them will find it, probably
more than once.

Oh, yes LLMNR will never ask anything from the root-server. Only
the applications using it will.

That is disgusting!


The part about multiple interfaces is also the current behavior in
multi-homed hosts. In theory, DNS requests sent to different servers
over different interfaces should all be equivalent. In practice, they
are not. Some names can be resolved through some interfaces, and not
through others. To be sure, systems end up sending the requests on
multiple interfaces.

-- Christian Huitema




--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


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

Re: UN

[Peter Dambier]

Alexis Turner wrote:

I don't want to clutter up everyone's inboxes with dozens of rants that
amount to hyperventilating and lots of "Iiii's!," but if anyone would
like to e-mail me off list with their thoughts on the UN's WSIS conference
and why having them replace ICANN would be a good/bad thing for the
Internet, I would love to hear it.  I'm not looking to pick a fight or
argue - I'm just honestly interested in hearing the various opinions.  The
issue is a lot bigger than anything I can get my head around right now,
and hearing what other people have to say would help me think about it
more constructively.

I myself am on this list more or less "Just for kicks," or, as I prefer to
think of it, "personal edification," but do note that it is possible
quotes from your e-mails will make it onto a personal site that I use for
my own rambling and probably incoherent research.  If you don't want
this, just say so.
-Alexis

PS: Bonus points if you actually read what they are proposing before you
respond.



Hi Alexis,

I followed the discussion list. I could hardly follow it.

Is there a UN?

To me it looks like a bunch of small and not so small dictators at the table
and several rooms full of intelligent people outside.

It might be interesting to give them the internet. But how should you do
that? What could they do with it?

Give them the root. The root operators will laughingly stand up and go away.
Each of them will start running his own root on his own hardware.

The internet hardware? Belongs to companies that were not allowed to join.
How should all the internet operators find out what "the UN" want them to
do if they dont allow them in?

I dont think anything but a lot of wasted paper will come out of that meeting.


Kind regards,
Peter and Karin Dambier


--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


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

Re: UN plans to take over our job!

[Peter Dambier]

Johan Henriksson wrote:

Will McAfee writes:



http://www.theregister.co.uk/2005/09/28/wsis_geneva/
This is not their place to be deciding as if they ever
owned the Internet. They have no rights to the Internet,
by the very nature of it's structure.


Placing governments in charge of the Internet would be a disaster, the
worst possible thing that could happen to it.


Gouvernements are not in charge of DNS and they probably never
will be. Who pays for the root-servers? With whom do they have
contracts?

As long as nobody pays for them they will do what they want.

MIL and ARPA will close their service. So will do EDU. The rest
will join The Public-Root, ORSC, opennic, ...

The UN will talk and talk and ...




a peer 2 peer replacement for DNS tops my internet wish list;
with such, we would not need the top organizations we have today,
it would be much harder for anyone to claim the net and thus
we wouldn't be having this discussion.

of course, a p2p net of that size is a challenge but it's that
kind of thing that make engineering fun :)



Please have a look at

http://iason.site.voila.fr
http://www.kokoom.com/iason

especially the part about bifurcation. Part of it is in english.

It is science fiction but it is strong and maybe it will
replace DNS some time.

There used to be NIS as a competitor to /etc/hosts.

DNS has broken a lot of things that used to work with /etc/hosts.
NIS did not break anything but it did not scale the way DNS was
supposed to.

DNS did not scale either. With some 80% of all domains living in
".com" we face a flat file not a tree :)


Kind regards,
Peter and Karin Dambier


--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


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

Re: Anyone not in favor of a PR-Action against Jefsey Morfin

[Peter Dambier]

Randy.Dunlap wrote:


Just for clarification, can you tell me who qualifies as
"Any IETF member" ?



Anyboy who has enough brains to share.

Right now ICANN and IETF have to face their end comming in 2006 because
the contract does end.

There has been nothing that would suggest the contract will be lengthend.

Vint Cerf has gone.
Paul Vixie has gone.

It does not make sense to shy away everybody who still has got his own
working brain - especially if he is a critic.

WSIS/WGIG have produced a mess that cannot replace ICANN or IETF.
So somebody has to do it.

Who?
Why?

Did you notice right now the Public-Root is comming down? They will
not do this work!

Who else?
Turkey?
China?
Bin Laden?

Dont talk about Problems!
Dont vote for critics!
Leave the ship before it is sinking!

That is not my choice!

After signing, here is another P-R action you might want to see:

http://www.cynikal.net/~baptista/P-R/


Peter and Karin Dambier


--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


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

Re: Anyone not in favor of a PR-Action against Jefsey Morfin

[Peter Dambier]

Bill Manning wrote:


i for one, am not in favor of a PR action against anyone.

--bill



Let Karin and me join your list, Bill.


Peter and Karin


--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason


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

Fwd: The Root has got an A record

[Peter Dambier]

See with your own eyes:

; <<>> DiG 9.1.3 <<>> -t any . @a.public-root.net
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18588
;; flags: qr aa rd; QUERY: 1, ANSWER: 15, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;.  IN  ANY

;; ANSWER SECTION:
.   172800  IN  SOA a.public-root.net. 
hostmaster.public-root.net.\
2005101006 43200 3600 1209600 
14400
.   172800  IN  A   57.67.193.188
.   172800  IN  NS  k.public-root.net.
.   ...
.   172800  IN  NS  j.public-root.net.

;; Query time: 81 msec
;; SERVER: 205.189.71.2#53(a.public-root.net)
;; WHEN: Mon Oct 10 16:01:11 2005


 Original Message 
Return-Path: <[EMAIL PROTECTED]>
X-Flags: 
Delivered-To: GMX delivery to [EMAIL PROTECTED]
Received: (qmail invoked by alias); 10 Oct 2005 13:07:54 -
Received: from LAIR.LIONPOST.NET (EHLO LAIR.LIONPOST.NET) [199.5.157.32]
  by mx0.gmx.net (mx072) with SMTP; 10 Oct 2005 15:07:54 +0200
Received: from list.public-root.com ([199.5.157.32])
by LAIR.LIONPOST.NET with esmtp (Exim 4.24) id 1EOx3o-ny-HQ
for [EMAIL PROTECTED]; Mon, 10 Oct 2005 08:47:20 -0400
Received: from [206.254.45.93] (helo=ruby.cynikal.net ident=qmremote)
by LAIR.LIONPOST.NET with esmtp (Exim 4.24) id 1EOx3n-nt-5J
for [EMAIL PROTECTED]; Mon, 10 Oct 2005 08:47:19 -0400
Received: (qmail 9881 invoked by uid 1018); 10 Oct 2005 13:10:36 -
Received: from localhost ([EMAIL PROTECTED])
by localhost with SMTP; 10 Oct 2005 13:10:36 -
Date: Mon, 10 Oct 2005 09:10:36 -0400 (EDT)
From: Joe Baptista <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [Pr-plan] BAD NEWS Re: IASON Root Domain Observatory (fwd)
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: 
List-Unsubscribe: <http://LAIR.LIONPOST.NET/mailman/listinfo/pr-plan>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://LAIR.LIONPOST.NET/pipermail/pr-plan>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Help: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <http://LAIR.LIONPOST.NET/mailman/listinfo/pr-plan>,
<mailto:[EMAIL PROTECTED]>
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-GMX-Antivirus: 0 (no virus found)
X-GMX-Antispam: 0 (Mail was not recognized as spam)
X-GMX-UID: /QI4Y8R1eSEkOtTJ43QhaXN1IGRvb4Di


Folks - got some bad news.  The Public-Root has aquired an A record - yup
thats right - an A record.  Which see below.  Have tried to contact Paul
Scheepers - our absent minded root operator - who now hovers very close to
criminal conspiracy - to get him to fix this mistake.  Noone is at home at
the inn.  Not good.  See appened message to Peter Dambier and our
public-root associates.

I have no idea how a root will respond with an A record in it.  Should be
interesting - but have no doubt a few things out in the wild have been
broken.

regards
joe

-- Forwarded message ------
Date: Mon, 10 Oct 2005 09:03:04 -0400 (EDT)
From: Joe Baptista <[EMAIL PROTECTED]>
To: Peter Dambier <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED],
 [EMAIL PROTECTED]
Subject: Re: IASON Root Domain Observatory


Report this to NANOG and the IETF.  Make sure you send them a copy of my
response and the headers of this message.  I am holding UNIDT personally
responsible for this technical nightmare.

regards
joe

On Mon, 10 Oct 2005, Peter Dambier wrote:


Kewl, '.' has got an A record :)

; <<>> DiG 9.1.3 <<>> @a.public-root.net . axfr
;; global options:  printcmd
.   172800  IN  SOA a.public-root.net. 
hostmaster.public-root.net. 2005100906 43200 3600 1209600 14400
.   172800  IN  A   57.67.193.188
.   172800  IN  NS  a.public-root.net.


Joe Baptista, Official Public-Root Representative and Lobbyist to the
United States Congress and Senate / Tel: +1 (202) 517-1593

Public-Root Disclosure Documents: http://www.cynikal.net/~baptista/P-R/
Public-Root Discussion Forum: http://lair.lionpost.net/mailman/listinfo/pr-plan



___
Pr-plan mailing list
[EMAIL PROTECTED]
http://LAIR.LIONPOST.NET/mailman/listinfo/pr-plan


--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.kokoom.com/iason



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

Re: can we please postpone the ipv6 post-mortem?

[Peter Dambier]

Martin Rex wrote:

> 
> most home users in Germany can not even get IPv6 from their ISP,
> even when they had an IPv6-capable DSL-router.
> 

Curiously enough, our biggest and almost monopoly because most
others depend on them - dtag.de - released:

first half of 2011 they will start upward and peering IPv6.
Second half of 2011 everybody will be connected dual stack
and fixed addresses for both IPv4 and IPv6.

There is rumour that home users will get IPv4 addresses only
in the 10.x.x.x address space. IPv6 will be /56.

Kind regards
Peter


-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: pe...@peter-dambier.de
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
ULA= fd80:4ce1:c66a::/48
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: The IETF and the SmartGrid

[Peter Dambier]

Sorry if I misunderstand something,
but I thought it was already working.

e.g. chinese hackers successfully proofed they can switch off all
power companies in Australia whenever they want.

I remember some places in the world have forbidden to connect
lethal devices like powerplants to the internet.

I thought germany and the us where among these places.

Well, with germany I have heard rumors that palaestinians could
switch off the Biblis nuclear power plant whenever they felt the itch.
I know that is not true. Biblis is offline most of the time because
it is raining in.

Kind regards
Peter


Richard Shockey wrote:
> The general internet community needs to be aware of activities in North
> America that directly relate to the use of IETF protocols in the Electric
> Utility industry. This activity is generally referred to as the SmartGrid.
> Though the issues immediately deal with technical and policy decisions in
> the US and Canada, the SmartGrid concept is gaining significant momentum in
> Europe and Asia as well.
> 
> http://www.smartgrids.eu/
> 
> http://en.wikipedia.org/wiki/Smart_grid#Countries
> 
> 
> The SmartGrid has many definitions but as a practical matter it is a
> substantial re-architecture of the data communications networks that
> utilities use to maintain the stability and reliability of their power
> grids. Many of the requirements for the SmartGrid in North America came out
> of the 2003 North East power outage which demonstrated a substantial lack of
> investment in Utility IT systems.
> 
> http://www.ferc.gov/EventCalendar/Files/20040915141105-blackout.pdf
> 
> Of particular note, is the desire by utilities to extend the reach of their
> communications networks directly to the utility meter and beyond ultimately
> into the customer premise itself. This is generally referred to as the
> Advanced Meter Interface (AMI).  One of the use cases driving this
> requirement is the next generation of plug-in hybrid electric vehicles. The
> utilities, correctly IMHO, want to precisely control the timing of how these
> vehicles are recharged so not to create a unique form of DOS attack and take
> out the grid when everyone goes home at night.  This is a principal use case
> in 6lowpan ( ID below ). Increasingly energy flows are becoming
> bi-directional creating needs for more computational intelligence and
> capability at the edge.  
> 
> What is going on? Why should the IETF community care?
> 
> The United States Government, as part of the Energy Independence and
> Security Act of 2007 gave the National Institute of Standards and Technology
> ( NIST ) principal responsibility "to coordinate development of a framework
> that includes protocols and model standards" for the SmartGrid.
> 
> http://www.nist.gov/smartgrid/
> 
> 
> After several meetings sponsored by NIST in recent months, NIST released a
> preliminary report. Several folks from the IETF community attended those
> meetings, myself included. There multiple troubling stories about how those
> meetings were organized but I'll leave those tales to others. 
> 
> http://www.nist.gov/public_affairs/releases/smartgrid_interoperability.pdf
> 
> One of the requests from NIST and the SmartGrid community was a list of Core
> Internet protocols that NIST could refer to.  Fred Baker has been working on
> that task. ( below )  
> 
> Myself and others are deeply concerned by how this effort is developing.
> There is no current consensus on what the communications architecture of the
> SmartGrid is or how IP actually fits into it.
> 
> The Utility Industry does not understand the current IPv4 number exhaust
> problem and the consequences of that if they want to put a IP address on
> every Utility Meter in North America. 
> 
> What is equally troubling is that many of the underlying protocols that
> utilities wish to deploy are not engineered for IPv6. We have an example of
> that in a recent ID.
> 
> http://tools.ietf.org/html/draft-c1222-transport-over-ip-01.txt
> 
> 
> Obviously, there are significant CyberSecurity issues in the SmartGrid
> concept and NIST has produced a useful document outlining the requirements
> and usecases.
> 
> http://csrc.nist.gov/publications/drafts/nistir-7628/draft-nistir-7628.pdf
> 
> How the SmartGrid interfaces with or bridges with Home Area or Enterprise
> Local Area networks is unclear, to put it mildly. 
> 
> I want to use this message to encourage the community to read the attached
> documents and get involved in this effort as appropriate.  Additional NIST
> documents will be published shortly with a open public comment period. 
> 
> I strongly urge members of the IETF community to participate in this comment
> period and lend its expertise as necessary. 
> 
> It's useful and important work. 
> 
> 
> 
> 
> Title  : Core Protocols in the Internet Protocol Suite
>   Author(s)   : F. Baker
>   Filename: draft-baker-ietf-core-03.txt
>   Pages   : 32
>   Date

Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC

[Peter Dambier]

Cullen Jennings wrote:
> 
> Can someone walk me through the pro/cons of this being standards track
> vs informational?
> 

Apple supports it.
Linux supports it (mostly).
BSD supports it (mostly).

So half the world supports it.
When Microsoft too supports it, it is a standard.

I do support it (becomming a standard).

Well, making this a standard keeps people from building something
colliding with existing implementations.

Kind regards
Peter

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: pe...@peter-dambier.de
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
ULA= fd80:4ce1:c66a::/48
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: a modern-day SNMP use

[Peter Dambier]

David W. Hankins wrote:
> On Thu, Oct 23, 2008 at 09:41:49AM -0700, Randy Presuhn wrote:
>> All very good reasons why doing blind, single-variable MIB walks
>> makes no sense.   Are there any commercial products that
>> do this routinely?  I'm not aware of any.

Adding to David,

IASON originally did a lot with SNMP, because of catalysts :)

We used Open Source snmpwalk because that was the easiest way to go.

When we added boxes and MIBs we got into trouble and out of memory.

As David observed, SNMP used to be slow and consumed a lot of cpu on
both the monitor and the monitored boxes.

We dropped SNMP finally when we moved away from the catalysts.

IASON never went commercial but is in the Open Source now and still very
pre beta.

Kind Regards
Peter

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: several messages

[Peter Dambier]

Hi Steve,

sorry to mention spamhaus again,
but that is the reason why many german and especially austrian
mailoperators had to give up blacklisting completely and turned
to graylisting.

Greylisting is mostly the same as blacklisting except you dont
depend on somebody else to maintain the list.

As one of my clients has put it:

"The makers behind a blacklist feel like god because they decide
live or death of an email address. The users of this list believe
it too and that is why they never understand how a blacklist could
ever see the end of its live. God is eternal and so must be his
blacklist. As happened once and again mailers break their sysop
breakes too and nobody knows who ever turned their mailers to use
this particular blacklist."

When we could not exchange emails with atnic for quite some time
we had to very quickly switch from blacklist to greylist. We did
not have a reason to switch back.

The girl who runs the mailer is mostly the girl who empties the
wastepaper baskets and sweeps the court. She does not live long
enough in a company to touch that mailer more than once. The next
girl who comes to touch the mailer has not even heard about
blacklists.

Kind regards
Peter


Steve Linford wrote:
> Ehm, I don't think I want to enter into the 'issues' in Mr Anderson's
> post, but I do like his "I hate John Levine" web page, I think all of
> those who become graced with their own "I hate you" ranting web page
> have verifiably achieved greatness (well done John ;)
> 
> This bit though I can elaborate on:
> 
 Unlike you, I don't see "overwhelming community consensus for
 this mechanism".
>>>
>>> Aw, come on.  There's a billion and a half mailboxes using the
>>> Spamhaus DNSBLs, on systems ranging from giant ISPs down to hobbyist
>>> Linux boxes.
>>
>> This 1.5billion number is just more unsubstantiated BS.
> 
> Actually that is user numbers we have signed contracts for (i.e:
> contractually-declared numbers of end users of the Spamhaus Datafeed
> service), the actual figure being 1,425,440,000 users currently. I
> would  say that is a level of usage that strongly suggests "overwhelming
> community consensus for this mechanism".
> 
>   Steve Linford
>   The Spamhaus Project
>   http://www.spamhaus.org
>  
>  
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: uncooperative DNSBLs, was several messages

[Peter Dambier]

Windows is one of the most prominent users of DNS.

I remember you could send them netbios packets and
windows would put them into the DNS cache.

Be asured they will put dnsbl into the cache and
then the famous IE will look for cnn.com on 127.0.0.1

It makes sense after all because the spammers do host
malware sites too. Looking up a dnsbl will prevent
your browser from accidently showing malware sites :)

Be asured sooner or later some silly bugger will try
and it works - no more malware and no popups either.

Kind regards
Peter

Tony Finch wrote:
> On Thu, 13 Nov 2008, Ted Hardie wrote:
>> Thanks for the pointer. I had missed this technical comment in the
>> crowd, and I think it is very important indeed.  By re-using RRs with
>> context-specific semantics, the proposal does serious harm to
>> interoperability.
> 
> Is there any evidence for that?
> 
> Tony.

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: uncooperative DNSBLs, was several messages

[Peter Dambier]

e.g. the ".local" TLD.

When microsoft introduced the ".local" TLD for "rendezvous"
incompatibility, their windows boxes started to query the
root-servers for nonsense like "refrigerator.local"

When some hearty nameserver operators fighted back, loading
a zone file for ".local" they brought campus networks down.

Zeroconfig was never meant to query port 53 - but they do.

As soon as some windows gurus see an official document
about dnsbl they will put it into the windows dns.

Looking for cnn.com on 127.0.0.1 will be fun.
Some of those boxes do serve http.

Kind regards
Peter


Ted Hardie wrote:
> At 11:04 AM -0800 11/13/08, Matthias Leisi wrote:
>> The suggestion to use a dedicated RRTYPE is nice, but many others have
>> failed in this endeavour before.
>>
>> -- Matthias
> 
> 
> What do you mean "failed in this endeavour"?  failed to get an RR
> assigned, or failed in deployment?
> 
>   regards,
>   Ted
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Detecting and disabling bad DNSBLs

[Peter Dambier]

Maybe I am a bit late with this idea.

I remeber dns roots switching off and DNSBLs switching off.

Users wont notice until broken - or not even then.

The sysop has been fired.


There should be a means for the DNSBL to tell its client

1) I am not a DNS-server

2) I am going to switch off soon

3) There should be a serialnumber or timestamp on the DNSBL
   to show when it has last been maintained.


When the client sees the wrong type of server it should
warn both the sysop and the user. Today it has no means
to decide so.

Kind regards
Peter

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[Peter Dambier]

Hi Eric,

I would like to be part of that group.

My little network is connected to the internet
via a NAT router and I could not live without
it because daily renumbering wont do.

On the other hand that NAT-box is the biggest
obstacle between my network and IPv6.

I would like to help design a NAT that is not
an obstacle but a stepping stone.

Kind regards
Peter


Eric Klein wrote:
> 
> 
> On Sat, Nov 22, 2008 at 7:07 AM, Fred Baker <[EMAIL PROTECTED]
> > wrote:
> 
> 
> On Nov 21, 2008, at 9:39 PM, Tony Hain wrote:
> 
> The discussion today in Behave shows there is very strong
> peer-pressure group-think with no serious analysis of the long
> term implications about what is being discussed.
> 
> 
> Yes, there is a very clear anti-NAT religion that drives a lot of
> thought. It's not clear that any other opinion is tolerated.
>  
> 
> Fred,
>  
> I pesonally would be open to a real discussion about the needs and then
> about the solution. But for now NAT has taken on religious connotations
> with those who are for it being as single minded as those who are
> against it.
>  
> We need a team made up of both sides to sit down, spell out what are the
> functions of NAT (using v4 as a basis) and then to see if:
> 1. If they are still relevant (like number shortage from v4 is not the
> same issue under v6 for example)
> 2. Do they already exist in v6 without adding NAT
>  
> Then we need to check:
> 1. Is there is a solution by using NAT
> 2. Is there is a better solution than using NAT
>  
> Only then can we make a proper and informed decission on what is needed
> and what is unneeded legacy.
> Eric
> 
> 
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers

[Peter Dambier]

Keith Moore wrote:

> absolutely it's too onerous.  why in the world should an application's
> deployability depend on the existence of a server that lives in global
> address space -- or for that matter, on a bank of servers that exist to
> do nothing but forward traffic?  isn't that what the network is supposed
> to do?

That is what bothers me too. sip is mostly peer to peer, so for most
of your communication (in megabytes) no server in a rack needed.

Email, with fixed IPv6 addresses will become peer to peer again too.

html? html is not much traffic. Many people do html hehind their NAT44
boxes today.

There is still a lot to be done for zeroconf, so DNS still is ok
with a server in a rack.

Oh, I forgot. For DNS you are still dependent on IPv4.

All the enthusiasts with their linux and freebsd boxes using ISATAP
to communicate don't see a need for NAT66. It is the big guys with
big windows servers who really need NAT66 to hide their fragile
machines from the bad wild internet.

I am one of those poor guys who has never been told what good NAT66
can do for him. I am still troubled by NAT44 preventing me from
connecting with my ISATAP interface.

I am running more than one computer. That is why I am imprisoned
behind my NAT44 and I am afraid NAT66 will be yet another prison.

I have seen with tunneling (slow as molasses) I get only a single /128.
So I guess a bilingual router will sit on both his single IPv4 and
another single IPv6 and keep all the traffic for himself letting
me do the guesswork how to drill the holes I need to connect to
the internet.

I see with IPv6 I do have to compete with my fridge and the
central heating drilling holes to talk to the butcher, the baker
and the oil-tanker. None of them is living in a rack in a colocation.
They all have to drill holes into their NAT66 to talk to my home.

There is a hole industry living from selling me super excluse
and expensive drilling machinery, I would not need if there was
not a NAT66 in the first place.

I know NAT44 is like my front door and keeps the bad internet out.
But it is not NAT44, it is the firewall who keeps them out.

Only a vague feeling for symmetry keeps telling me I should have
a NAT66.

Math is telling me that need not be true. IPv4 brought us from
point to point clothes line to 2-dimensional space spanning
continents. IPv6 will bring us 3-dimensional space spanning
the globe and DNT will bring us even further. I do not know if
there is such a thing as NAT66 existing.

In  2-D space we do have trigons, squares, pentagons, hexagon...
In  3-D space live stops with things built from pentagons.

The guys with their big windows servers behind NAT44 are living
in a 2-D world, dreaming their 2-D dreams bout selling us
3-D NAT66 boxes without even knowing the math.

Kind regards
Peter

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Why the IETF is irrelevant to the future of e-mail

[Peter Dambier]

That reminds me of no-ip.com.

name belong to them. typo belongs to a gangster.

I used to have a workstation myname.typo with their dynamic dns.

When a friend sent me an email to myname.typo a lot of peculiar
things happened.

I informed no-ip about that gangster abusing their name.

That is when I lost my account.


I did not know what happened until I sent a dig or a whois
about typo to somebody else.


I don't dare spelling that domain in an email again.


That is all you need to get yourself on a blacklist.


Kind regards
Peter


John Levine wrote:
> Nothing personal, but you could hardly ask for a better
> illustration.
> 
> For one thing, this isn't a case of broken DNSBLs, it's a case of
> getting what you asked for.
> 
> Rather than using shared DNSBLs, this tiny host on a non-profit public
> access network is desperately trying to run its own spam filters.
> Maybe you sent him blowback from spam with forged addresses, maybe he
> just mistyped someone else's address.  Whatever it was, in the absence
> of shared DNSBLs, the option isn't no filtering, it's a million local
> filters on a million mail hosts with millions of mistakes that can
> only be corrected one by one.  At least this one was competent enough
> to let you know that he'd rejected your mail.  A lot of the million
> mail admins aren't.
> 
> For another, "I'm too important to block" is not a winning long term
> response.  We're all important in some areas and unimportant in
> others.  Spam sucks, spam filtering sucks, DNSBLs suck, but in a world
> where >95% of all mail is spam, not filtering spam sucks way more, and
> it even sucks way more than filtering with occasional mistakes.
> 
> If, rather than trying to do his own filtering, this guy used some of
> the popular reliable DNSBLs (none of which list 69.25.196.31) both he
> and you would have avoided this screwup.
> 
> Much though we might wish otherwise, spam and spam filtering aren't
> going away, and by their nature, spam filters make errors.  Anyone who
> claims otherwise is way, way, out of touch.  Some of us would rather
> try to figure out ways to improve the delivery of real mail and
> minimize the errors than rant about it.
> 
> R's,
> John
> 
>>  [EMAIL PROTECTED]
>>Delay reason: SMTP error from remote mailer after end of data:
>>host rhun.apana.org.au [64.62.148.172]: 451-sender IP address
>> 69.25.196.31 is locally blacklisted here. If you think
>>451 this is wrong, please call +61289874478.
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
ULA= fd80:4ce1:c66a::/48
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: How I deal with (false positive) IP-address blacklists...

[Peter Dambier]

There is one thing I could proof when counting the emails going
through the mailer I am responsible for.

When we started blocking emails from dynamic addresses we
reduced spam by 50%.

The gurus would not believe but I could show thenm, when we
blocked all but the dynamic addresses we could reduce spam
by 50% too.

The bad side, we could not show how many legitimate mails
did not come through in either case. They were lost.

Mailblockers maintained by humans are never perfect. spamhause
proofed that when they knowingly blocked atnic.at allthough
atnic.at had never sent spam.

There is little difference between a mailblocker maintained
by humans and a greylist maintained by your own computer
except you can correct problems yourself.

When I see mailblockers usually blocking all dynamic addresses
then I can conlude from my observations that they have at
least 50% false positives.

There is a minor annoyance with greylists - broken mailers
and people with 50 outgoing mailers.

Broken mailers are mostly spammers, more than 50%.

People with more than 50 outgoing mailers are mostly the
source of all that spam. So the greylist is no worse than
a mailblocker and it always gives you a second chance.
A mailblocker does not.

Looking into my exim4 log I can see more than 90% of spam
gets lost when some bot on a hitch-hiked machine tries to
imitate a mailer.

When you try TLS on an incoming mail they all get lost.

So why do they setup expensive machines in a colo to run
a mailblocker?

Money!

And you can put those few people with 50 outgoing mailers
on your whitelist.

Kind regards
Peter


Dave CROCKER wrote:
> 
> 
> Theodore Tso wrote:
>> This doesn't work for most people, but I had fun composing this
>> response, and coming just a few weeks after people claiming that
>> IP-based blacklists work well, and rarely result in false positives, I
>> felt I just had to share.   :-)
> 
> 
> Ted,
> 
> Evidently you believe that the anecdote you posted proves something, but
> I am not sure what.
> 
> Some others have suggested that it proves something which, I strongly
> suspect, is not what you had in mind.
> 
> Perhaps you can clarify the purpose of your note.  How should it be
> incorporated into the IETF's deliberations?
> 
> If you believe that it demonstrates that blacklists do not work well
> and/or do not rarely result in false positives, perhaps you can document
> the basis for that assessment.
> 
> I feel confident that you do not intend a single anecdote, about minor
> email service participants, to serve as the basis for such a global
> conclusion about a mechanism that is implemented and relied on by
> virtually every professionally-run email receiving service on the planet.
> 
> Thanks.
> 
> d/
> 

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
ULA= fd80:4ce1:c66a::/48
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: How I deal with (false positive) IP-address blacklists...

[Peter Dambier]

[EMAIL PROTECTED] wrote:
> 
> Like it or not, sample size reallly does matter. But if you really do prefer
> individual anecdotal evidence, I'll point out that in practically every bogus
> blocking incident I've seen of late, the fault lies not with an operation like
> Spamhaus, but with some local yokel who thinks he's come up with the FUSSP.
> 

In the case government of austria contra spamhaus that local yokel must have
been  Bundeskanzler Gusenbauer  ?

Neither the austrian government nor their atnic.at is or has been sending
spam nor are they selling domains.

But spamhaus blocked them.

All mailblockers are primarily mailblockers and sometimes they do hit spam.

But it is in this list like in real spam live.

One party believes in the holy blacklist also there are different cults who
believe in their very own blacklist -

and the other party knows all mailblockers are run by the devil and they
can proof it. But a proof is nothing against a belief.

Kind regards
Peter

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
ULA= fd80:4ce1:c66a::/48
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: LORAN is making a comeback..

[Peter Dambier]

How about a workgroup and a mailinglist?

Maybe it has nothing to do with IETF
it definitely has to do with DTN, UDP, IPv6 and BEHAVE.

I am interested.

Peter


Lyndon Nerenberg wrote:
> Take it off line. This has nothing to do with the IETF.
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: pe...@peter-dambier.de
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
ULA= fd80:4ce1:c66a::/48
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: If you install Mail Filters how is the list integrity to be documented?

[Peter Dambier]

Sam Hartman wrote:
>> "TSG" == TSG   writes:
> 
> TSG> There is a serious concern that when individuals are
> TSG> 'filtered out of IETF lists' whether by official or
> TSG> unofficial means, that their voices are prevented from being
> TSG> included into the IETF standards process. 
> 
> I'd feel this issue was a higher priority if the people who are being
> filtered had written internet drafts.  
> 
> I definitely think that we should be very careful about filtering
> internet draft submissions.
> 
> I think that if someone writes a credible internet draft that we need
> to make sure that it receives appropriate discussion.

I vaguely remember draft-jefsey-mltf-cctags
but nevertehless I remember Jefsey Morfin beeing banned.

How about draft-anderson-reverse-dns-status and Dean Anderson?

I cannot rid myself of the feeling that non english speakers do
have a little problem and non latin writers do have a big problem
to express their views in IETF.

And there are both financial and political interests too.

We have left a decade with no need for communication with opposite
ideas behind us. It is a wonder that IETF survived.

Today we talk again to each other. I am glad the IETF survived.


Or seen the other way round - what happened to ISODE?


The ISO code was not free so people preferred to stay with tcp/ip
and IPv4. Now we are talking about IPv6. ISO never made it.


Yes, all that guys shouting me too and filling my mailbox is annoying.
It would be so easy to cancel my subscription.

No I won't. I'll stay on the list.


Kind regards
Peter



-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: pe...@peter-dambier.de
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
ULA= fd80:4ce1:c66a::/48
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: How security could benefit from high volume spam

[Peter Dambier]

Hadmut Danisch wrote:

How security could benefit from high volume spam


The parliament of the European Union today has passed a law that
electronical call detail records, such as phone numbers, e-mail addresses,
web accesses of all 450 million EU citizens are to be recorded and
stored for 6 to 24 months. So everyone will be subject of
complete surveillance of telecommunication. No place to hide.

The given reasons are the need to investigate and prosecute terrorism
and severe crime. But there is no evidence that this law
actually has this effect, and that it is worth to sacrifice democracy
and civil rights. Our constitution protects the right to communicate
confidentially, for all citizens, and especially for lawyers,
journalists, priests, etc. So terrorists finally begin to
succeed in destructing our european, modern, democratic, and free way
of life and civil rights. It is ridiculous that the modern world has
not been attacked by a large army, but by just about 30-40 people with
knives and a few bombs. The attack is not the primary attack
itself. The main attack is to provocate overextended counter
measures. Technically spoken, a denial-of-civil-rights-attack. And the
EU proved to be vulnerable to this kind of attack. A patch is not
available yet.

Another threat to privacy and civil rights is the intellectual
property industry. We have seen Sony attacking and sabotaging private
computers, revealing private data, taking secretly control over
people's communication and working equipment. We have seen a mother of
five been sued into bankruptcy in the USA just for listening to music.
This is perverse. We currently see governments considering to outlaw
open source software or any kind of data processing or communication
device without a digital rights management. There are good reasons to
assume, that the European Union's collection of all telecommunication
details will be abused to allow the intellectual property industry to
completely track every communication. Just having received any e-mail

from someone who had illegally downloaded music could be enough to have

your home searched, your computer confiscated, and find yourself sued
or prosecuted. 



The art and science of communication security will have to realign and
focus on new goals. When designing telecommunication protocols we have
to take much more care about what communication could reveal about the
communication parties and the contents. It is not enough to just put
some kind of simple encryption on a message body. We need to protect
against traffic analysis, in particular the one without democratic
legitimation. 


What does that mean?

When designing a protocol we should take more care than we did to
describe its vulnerability for and resistance against traffic
analysis. Not just whether the contents are encrypted, but what an
eavesdropper can tell about the communicating parties.  We need to
incorporate techniques like oblivious transfer and traffic hiding.

An important component of such protection methods is noise. Plenty of
noise. Something to hide in, to cover, to overload recording of call
details. We should think about and research how to produce noise. 

We already have some noise. Its called spam. 


I would not call this SPAM. It is potentially sensitive information.
Secret messages of Al Kaida could be in there - without our service
people even beeing aware of it :)



Some of you might know that I am one of the early days fighters
against spam. I tried to eliminate as much spam as possible. 


But now, there could be a positive aspect about spam, virus mails, and
other mass mails. Maybe it could become an advantage to receive a
million mails per day from any senders. Maybe that is what is needed
to hide my personal e-mails. Maybe that's the answer I have to give
when someone blames me to have received e-mail from the wrong person:
"I have no idea what you are talking about. I received about 150,000
virus and spam e-mails that day from arbitrary addresses, and didn't
read a single one of them. I have just deleted them." When designing
measures against spam, we should take this into consideration.



Maybe in near future the advantages of that noise produced by millions
of bots will outweigh the disadvantages?


Comments are welcome.

Hadmut Danisch



I see. No more need to hide my email address. :>

Next I will switch my spam filter off, at gmx. It was counterproductive anyhow.

How can I convince them to get rid of sorbs? I filters my own emails but it does
not filter spam.

Cheers
Peter and Karin

--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr


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

Pro SPAM WG: How security could benefit from high volume spam

[Peter Dambier]

A WG?

Karin and me are interested.

JFC (Jefsey) Morfin wrote:

At 23:10 14/12/2005, Hadmut Danisch wrote:


On Wed, Dec 14, 2005 at 04:46:42PM +0100, Frank Ellermann wrote:
>
> The best way to hide a signal is noise, is that's your idea ?
> Makes sense from my POV.


Not necessarily the _best_ way, but one that works under many
circumstances.
Some questions are:
How do we deal with the total surveillance?
Do anti-spam measures make surveillance easier?


No, I dont want to bash the one and only root again, but never did I
receive any SPAM an my [EMAIL PROTECTED] address.

This too could improve our position. Which root does the guy use - or
has he simply freaked his /etc/hosts?

Hadmut, I agree with your idea and I switched my spam filter off from all
my GMX mail accounts. They are worthless anyhow, because I permanently
have to read the spam folder to find lost emails. I still have to fight
sorbs, because they dont even accept my own emails from my host
echnaton.serveftp.com wich has a dynamic ip.




Hadmut,
not much success with your suggestion! Too much European centric at the 
moment. Your proposition is of real interest as part of a picture to 
study the noise as a general protection (conflicting information, spam, 
revamping web sites 1000 times a day, meta-spam, tags, EUCD, civilrights 
protection, bandwidth cost, site legal registration, multiligualism, 
debate orientation, etc.). The French law related debate make it very 
interesting, and important, however too complex for current users at 
this time. This fits the interests I have in the emergence of an "over 
the ISO layers" Internet through a grassroots process. How to use the 
Internet? But the IAB discuss list leads to nothing.


The French law made me move the sources from IASON

http://iason.site.voila.fr/
http://www.kokoom.com/iason/

to sourceforge. I dont want to fight the music industry with a law I dont
even understand. IASON has nothing to do with music but it has to do with
copyright.



Why not to try to shape a WG Charter on this? I do not believe the IESG 
is able to follow. But when I see all the ICANN, IETF, Unicode, etc. 
meetings, publications, etc. etc. about "internationalization", partly 
to oppose my long enough opposition which permitted me to reach Tunis. 
One could expect that Brussels could be interested at the end of the 
day. And if the IESG does not follow, we will have made our duty, before 
going elsewhere? I do not think that the balkanization they impose on us 
is a good thing.


jfc



Karin and me helped building two balkan DNS roots. Why not do something
serious now :)

Cheers
Peter and Karin


--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr
http://www.peter-dambier.de
http://peter-dambier.site.voila.fr


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

Re: Alternative formats for IDs

[Peter Dambier]

Yaakov Stein wrote:
 



It does not matter how many people can read MSWord. 
The only supported formats should be the ones where you know 
what the format is (and not the ones that depend on particular


program).


They are written to be readable by everybody.

Sun-cenrtic, IBM-centric and real computercompanies tend to receject mails
and documents that need a special Operating System together with a special
wordprocesser in a special version to be able to process, read or write a
document. I remember there used to be several versions of Microsoft Word
beeing incompatible over Mac, Dos, Windows and OS/2 . That was the time
when companies decided a document has to be 7-bit ASCII without country
specifics extensions. Alternatively EBCDIC was welcome to. There still
exist programmes like kermit that can be used to transfer documents
between flatfile ASCII and structured file EBCDIC over hardware borders.

Even html is designed 7-bit ASCII and breaks when you use 8-bits and
change hardware.

With 7-Bit ASCII it does not matter wether you use an X-BOX with 8-bit
words or a mainframe with 36-bit words. Using 16 bit words breaks when
you move from the X-BOX to the X-BOX/360 both from the same company
but building on different processors.



Why ?

If you take that as an axiom, then indeed it is easy to rule
lots of formats out.


Otherwise you rule a lot of participants out. There was never a
good reason for IBM to move from SNA to tcp/ip. On SNA they had
document exchange. There was never a good reason for DEC to move
from DDCMP to tcp/ip. DDCMP was much more flexible. Why should
Microsoft move from NetBIOS to tcp/ip. They never got it working
without quirks. So you rest with a handful of unix-centric
companies, mostly sun and next. They do speak ASCII what now?



But, what is the justification of the axiom?
Why not say - only use formats for which there are decent
editors easily available?

And why do all the other SDOs get along with non-ASCII formats?
On my intranet I have a list of 120+ SDOs in the communications
and computer-science fields, and although I haven't gone through
them all (I have asked someone to do so) I haven't found another
group that uses ASCII files.


I usually dont bother. If I cannot read it I delete it. Probably
you never got an answer for documents I could not read.



If the axiom is so strong, then why doesn't it bother anyone else?

Y(J)S



You see, they delete it :)
Maybe their virus scanner did in the first place :)

Cheers
Peter and Karin

--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: Alternative formats for IDs

[Peter Dambier]

David B Harrington wrote:
 




Lets go ahead and ask then -
  Does anyone else think that IETF should allow documents which
  format/structure is not publicly known as one of the ways to
  distribute IETF specifications?



Not me (or not I, whichever)

David Harrington
[EMAIL PROTECTED]




Not for us either

Peter and Karin



--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: Troubles with UTF-8

[Peter Dambier]

Tim Bray wrote:

On Dec 28, 2005, at 12:46 PM, Randy Presuhn wrote:


Reserving NUL as a special terminator is a C library-ism.  I think  that
history has shown that the use of this kind of mechanism, rather than
explicitly tracking the string's length, was a mistake.




I guess variably lenght V-records of type

string {int type,
int length,
int data[] );

would be horror. That will lose you 4 bytes per word and 2 bytes for
every printable sign.

C-ASCII "Randy Presuhn" = 14 char + '\0'.

Compare it to

 9, " R"," a"," n"," d"," y",
 9, " P"," r"," e"," s"," h"," u"," n"

That is 28 characters now. No alternative.




I used to think so too, but I don't any more; twenty years of doing  
text processing has convinced me that C's null-terminated strings  
simply cannot be improved on in a low-level programming language.   For 
more on the subject see http://www.tbray.org/ongoing/When/200x/ 
2003/04/13/Strings  -Tim



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





--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: Alternative formats for IDs

[Peter Dambier]

John C Klensin wrote:


--On Thursday, 05 January, 2006 06:57 +0200 Yaakov Stein
<[EMAIL PROTECTED]> wrote:



...
I have never had a problem opening an old file
with an up-to-date version of the SW. The problems
arise when you try to do the reverse. That makes sense
of course, since if you could do everything with the
old version, then no-one would buy the new one.
After all, a company with 95% market has to be inventive 
in order to continue selling.




I have had that very same experience, only worse:

There was no way of accessing documents from word for OS/2 after somebody
had been reading them with winword. Winword cold, but for word for OS/2
they were lost. Only transfering them to CP/M 86 with kermit and processing
them with wordstar and then transfering back with kermit again made them
workable again. Dont ask what happened to the typesetting.



Well, our experiences differ.  Let's put philosophical and
individual economic issues aside for a moment.  Let's also
temporarily ignore the observation that many members of our
community do their work on operating systems on which the
current version of Word is not supported.  I continue to
consider those issues to be showstoppers, but perhaps the
compatibility argument is worth pursuing a bit.   I think there
are two problems here, plus one raised in a note by Lars-Erik.  


(1) I have had problems opening and using documents from
sufficiently old versions, sometimes as recently as two versions
ago.  I even know the source of some of those problems.   For
example, I have never had a problem opening, in a clean and
unmodified current version of Word, an old document that uses
exactly one template and that one unmodified as if out of the
box, contains no macros and no workarounds for obscure bugs, and
does not use cross-references or a host of other specialized
features.  For the record, I don't suggest that any document
that uses any of those features runs into trouble, only that a
sufficiently complex combination of them do.  It has often
appeared to me that the machinery that converts from the formats
of an older version of Word to a newer one will handle the
simple cases well but, especially when the original document is
several versions older, there seems to be some tendency for Word
to get itself into trouble.  And, if the old document contains
macros or styles that are already present in the normal document
template of  the new version but with different definitions for
some of the set... my experience has been that occasionally
things work without side-effects.

For some of these cases, one even has to be careful about what
it means to successfully open an older document.  For example,
there was a considerable period in which a document written in
the then-current (not even previous-generation) version of
Windows Word could be opened just fine with the then-current
version of Mac Word... as long either the Windows version
contained no comments or one did not care that they disappeared
in the transition.

Now, you could reasonably suggest that good document hygiene
would argue for avoiding most of those features, or removing
them in the old system before trying to move documents to the
new one.   You would, of course, be correct.  But to avoid all
of those features eliminates much of the power of Word relative
to, e.g., ASCII editors that are available for all platforms at
negligible cost.  And those extended features, once inserted in
a document, are not easy to remove.  It is, for example,
possible to configure Word 2003 to issue a warning every time
one tries to save a document containing change-tracking or
comments to a file.  But, at least as far as I have been able to
discover, there are no warnings for macros, styles, and the
like.  And, while one can say "don't save", there are, as far as
I know, no options built into Word for cleanly removing all of
that stuff and getting a document into the safest of
forward-compatible forms.  Similarly, there is a configurable
warning when one opens a document with embedded macros.  But the
effect of "run safely" is not "remove all of those macros
forever" but "disable them in this session".  If they are
hostile and if, for one reason or another, the macro-removal
tool (which I'd lay good odds most users of Word don't even know
where to find) won't touch them because of how they are
installed (a common case), they just lie around as traps for
some future unwary person.

(2) If I understood correctly, one of the main arguments you
made for Word was its change-tracking and collaboration
facilities.  I certainly agree about the change-tracking.  But,
as for collaboration, it seems to me that you cannot
simultaneously argue that it is unreasonable to expect
version-downgrading to work and also argue that Word provides
good and useful support for collaborative work in a
heterogeneous community.  Again, even putting aside economic and
similar constraints, we have no way to get everyone in the
community to do

Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin

[Peter Dambier]

Stephane Bortzmeyer wrote:

On Fri, Jan 20, 2006 at 07:03:52AM -0500,
 Margaret Wasserman <[EMAIL PROTECTED]> wrote 
 a message of 155 lines which said:




I also have found that Jefsey's posts have a higher signal-to-noise
ratio than many peoples' posts, but I am willing to chalk some of
that up to the fact that he is a non-native English speaker who is
trying to make himself understood, and so I try to be patient with
that, too.



I can testify that Jefsey Morfin's posts in french are as long, as
off-topic and as undecipherable than in english. 



Maybe it is a question of time. It is not always obvious on first
sight what Jefsey means. But it is not obvious on first sight why
protocols break from time to time but break they do.

Internet Engineering is done on NANOG. IETF is far too slow and too
esoteric. The real problems do happen in operations and they must be
dealt with immediately.

What did happen does get into IETF slowly. People like Jefsey do
remember "I have seen that before. It is not noise. It will happen
again".

People like Harald dont have the time to think about it. They stick
in operations down to their elbows. Of course those people have
different views of course they have problems communicating. But
that is exactly what Jefsey says.

The internet has changed slowly. It is no longer research. It has
become operations. But at the same time the internet has drifted
away from IETF to NANOG, RIPE and others.

How about the ROOT? You cannot discuss DNS here or at NANOG.

Nameresolution is done adhoc mostly from peer to peer systems.
The most popular operating systems of two companies do what they
feel is correct. The have the power/number of users to do it.

Outside IETF and NANOG we have ORSN, ORSC, unnamed chinese root,
OpenNic, New.Net, Cesidian root, Public-Root, Unified-Root,
United-Root and others. Dont forget the people who take their
laptop out of their box switch it on and run their own network
without even knowing it. Those people dont speak english.
But those people are our costumers.

I dont want to miss either Jefsey or Harald. We need them both.

--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin

[Peter Dambier]

Anthony G. Atkielski wrote:


This entire fiasco tells me that the people nominally participating
in it have a lot of time on their hands and very little to do, and
they choose to waste it bickering like preschoolers on a playground
rather than spend it trying to do the actual work of the IETF.  And of
course they will argue with this, because they don't want to recognize
their own failings.

Instead of seeing a stream of posts from this target of opportunity, I
see multiple streams of posts from people complaining about him.
Sorry, but the "cure" is a lot worse than the "disease."


I never complained. I respect Jefsey. Without him it does not make
sense to stay on this list. Without Jefsey you can read everything
in books. No need to reiterate it by bureaucrats.

On the other hand, if I had written this book I could understand
everybody trying to suppress new ideas to prevent anybody from writing
a new book that might replayece the old one :)

--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: FW: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Mor fin

[Peter Dambier]

For the no-tv people like Karin and me:

Harper Valley P.T.A

USA / NBC/ 36x30m-e / 1981-82

First Episode: Friday 16 January 1981 / 8.00pm
 Last Episode: Saturday 14 August 1982 / 8.30pm
 Theme Music: Harper Valley P.T.A. by Tom T. Hall

Sitcom starring Barbara Eden as Stella Johnson a widow with a 13 year old
daughter, Dee. The pair lived in Harper Valley, Ohio, a Stepford Wives kind
of a place, sweet on the surface but with a sleazy undercurrent.
Stella was a very pro-active member of the school P.T.A. board a fact which
obviously gave the show it's title. The rest of the board thought Stella was far
too radical for them and were determined to be rid of her.
Leader of the PTA was the highly snooty Flora Simpson Reilly who hated Stella
with a passion. Reilly and her family played a big part in the series.
For season two there several changes (most notably the shortening of the title
to simply Harper Valley) with the PTA side of things taking a back seat and the
setting becoming more a traditional suburban one. Stella's inventor Uncle Buster
moved in with her and Dee for this season.
The show was actually based on the hit record of 1968 Harper Valley PTA by
Jeannie C. Riley which in turn led to the 1978 film of the same name which also
starred Barbara Eden as Stella.

Sorry for the long, long quote but yes that is exactly Harper Valley P.T.A

Thankyou King Harald from Norway for playing the most important role.

Thankyou Jefsey for playing the litning rod or
Thors Hammer Mjoelnir might have hit me.

We enjoyed the show but enuf is enuf.

Cheers from Peter and Karin


Anthony G. Atkielski wrote:

[EMAIL PROTECTED] writes:



[EMAIL PROTECTED]  I take a look at the IETF email after four months and
it's still the same discussion as when I left!



I notice the same thing.  The Harper Valley PTA is still very much at
work, but technical issues seem to be few and far between.



What, are you going to convince someone that indeed they really were
bothered by someones posts?



The idea is not to convince them, but to override them, so that what
they think doesn't matter.



--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/



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

Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin

[Peter Dambier]

I am against this action.

Harald Tveit Alvestrand <[EMAIL PROTECTED]>

is notorious for swinging for Thors Hammer Mjoelnir just see his postings

Date: Tue, 21 Jun 2005 16:34:48 +0200
From: Harald Tveit Alvestrand <[EMAIL PROTECTED]>
To: Spencer Dawkins <[EMAIL PROTECTED]>, ietf@ietf.org
Message-ID: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>

Let me offer a simplistic metric.

if a WG chair has posted nothing to the WG mailing list for a week, and
that WG chair has not told the WG he's on holiday, that WG chair is
probably not doing his/her job.

If NOBODY's posted to the WG mailing list for a week, it's time to close
the WG.


Date: Sun, 26 Jun 2005 21:02:19 +0200
From: Harald Tveit Alvestrand <[EMAIL PROTECTED]>
To: ietf@ietf.org
Message-ID: <[EMAIL PROTECTED]>

Since I'm no longer responsible for anything that Dean Anderson has a
legitimate role in, and Dean Anderson has proved that he irritates me, I
can stop listening to Dean Anderson.

Goodbye, mr. Anderson.


Date: Fri, 22 Jul 2005 14:08:46 +0200
From: Harald Tveit Alvestrand <[EMAIL PROTECTED]>
To: Francois Menard <[EMAIL PROTECTED]>, ietf@ietf.org
Message-ID: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>

You have of course read RFC 2826, "IAB Technical Comment on the Unique DNS
Root"?

Of course, this is specifically about the DNS, and doesn't answer your
question as it pertains to non-DNS systems


Date: Sat, 06 Aug 2005 20:43:13 +0200
From: Harald Tveit Alvestrand <[EMAIL PROTECTED]>
To: shogunx <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>

Thanks for confirming that you have totally missed what the IASA process
was all about.

This community has a number of people who wish to say how things need to be
done - whether it is meeting location, IPv6 or cookies during the breaks -
while absolutely refusing to spend any thought cycles whatsoever trying to
find out how this organization is actually put together, who will have to
make the decisions to implement their wishes, and who those people are
accountable to.

You have thoroughly confirmed that you are among that group.


Date: Sat, 06 Aug 2005 19:25:50 +0200
From: Harald Tveit Alvestrand <[EMAIL PROTECTED]>
To: Iljitsch van Beijnum <[EMAIL PROTECTED]>, IETF General Discussion Mailing 
List 
Message-ID: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>

I think IPv6 can wait until we have the formalities straight.


Date: Sun, 07 Aug 2005 00:13:22 +0200
From: Harald Tveit Alvestrand <[EMAIL PROTECTED]>
To: shogunx <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>

It seems that you missed the publication of BCP 101, RFC 4071, which
explains exactly what the IASA is.

Once you say something that indicates that you have done anything at all to
understand the organization you claim to be working in, I might find a
reason to engage in debate with you again.

...

There are a lot more.

But please understand I dont want to open a case against Harald here.

The quotes are taken out of context. I enjoy Haralds direct language.
I am shure he did not mean it insultive.

But please understand people who speak a different language might
feel insulted and bite back.

Speaking in an international and multicultural society need respecting
eachother - not shooting on first sight.

Regards,
Peter and Karin Dambier


Scott Hollenbeck wrote:

The IESG has received a request from Harald Alvestrand to approve an RFC
3683 PR-action  ("posting rights" action) for JFC (Jefsey) Morfin as a
result of a pattern of prior warning and posting rights suspensions for
off-topic postings to the LTRU working group and ietf-languages mailing
lists that have not produced a change in behavior.  This behavior has been
characterized as a "denial-of-service" attack to disrupt the
consensus-driven process as described in Section 1 of RFC 3683.  A timeline
of warnings and posting rights suspensions related to this request is
included below.

The IESG will consider this request.  If approved, the PR-action described
in Section 2 of RFC 3683 includes provisions to allow list administrators to
suspend Mr. Morfin's posting rights to the LTRU working group and
ietf-languages mailing list for at least one year.  Maintainers of other
IETF mailing lists may also remove posting rights to their mailing lists at
their discretion.

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action.  Please send any comments to the iesg@ietf.org or
ietf@ietf.org mailing lists by 17 February 2006.

For the IESG,
Scott Hollenbeck
Applications Area Director
--

Private warnings sent for LTRU working group mailing list postings:
7 July 2005
16 July 2005
23 September 2005
26 October 2005

Public warnings and suspensions for LTRU working group and ietf-languages
maili

Re: suggestion on distributed systems

[Peter Dambier]

Stephane Bortzmeyer wrote:

On Mon, Jan 23, 2006 at 12:44:11AM +0530,
 Neil Harwani <[EMAIL PROTECTED]> wrote 
 a message of 128 lines which said:




I am not sure whether this idea that I am about to write has been
implemented before




"Operating Systems, Design and Implementation" by
Andrew S. Tannanbaum and Albert S. Woodhull,
ISBN 0-13-638677-6 Prentice Hall

Not only do the discuss every aspect of an operating system but
they include as an example and for homework practice the complete
Minix operating system plus source.

Tannenbaum has already written a distributed operating system and
you can find many of his ideas in this book.

Minix is also the origin of the linux operating system.

Minix is really modular. You can easyly take it apart and play
with the peaces. In particalur the devide between memory manager
and filesystem suggests to run the pieces distributed over
many computers.

Minix is designed as an academic exercise. I guess it might
give you ideas if not more.


The idea is interesting but it is clearly underspecified. Before a
serious discussion can take place, you really have to specify it more
completely. If you want the discussion to occur at the IETF, an
Internet-Draft is the proper form:

http://www.ietf.org/ietf/1id-guidelines.html

Technically, I would suggest to think seriously about the Security
Considerations of your Internet-Draft...



1. Have a variable system built into all OSes which have internet
interface which can allocate space and resources as per what amount
of space and resources are free on the OS.



The big problem is to create a jail strong enough so that the hosted
programs do not compromise or DoS the machine. This is *not* a trivial
problem.



Dr. Bernstein has written an intersting stack of modules

daemontools-0.76

is a stack for building demons. It provides a mechanism that
unifies the world of different unixes, linuxes and bsds broviding
a common interface and getting rid of any special treatment for
demons that differenciates them from "normal" programmes.

ucspi-tcp-0.88

provides a different tcp/ip stack that gets rid of most security
holes in common tcp/ip and socket libraries.

djbdns-1.05

finally gets rid of the "Buggy Internet Name Deamon" bind. Bind
before the version 9 did show several problems. Bernstein shows
an alternative for bind and resolver libraries.

http://lifewithdjbdns.org/




Example : Suppose a server of paypal has to process millions of
records every month. If a high percentage of this processing is
encrypted and sent to container on various systems running on
internet, the same work can be done with less powerfull paypal
servers.



Very bad example: first, all Paypal requests require access to the
central database. And, second, Paypal would certainly not trust random
Internet machines for its processing.


The example is good. It is management that is bad :)


Cheers
Peter and Karin Dambier


--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/



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

Re: Questions for those in favor of CoS in general

[Peter Dambier]

To make a long debate short.

When you no longer know what is real and what is imagination,
that is a clear sign that the Church of Scientology might
be involved.

When you have facts in front of your eyes but people keep
telling you different.

When new facts start aperaring but you have no clue of their
origin.

Would it not be easier to ask about cult membership and
then to decide whom to exclude and whom not?

By the way, Scientology is a history of censoring.

I am sorry if I am terrybly off topic now,
but all threads around Jefseys posting rights are.

regards,
Peter and Karin Dambier


--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: What's an experiment?

[Peter Dambier]

Joe Baptista wrote:

JFC (Jefsey) Morfin wrote:


Dear Brian,
ICANN ICP-3 document called for a DNS test-bed to carry experiments in 
a given framework (to test various DNS evolutions including the end of 
the root). The document lists interesting criteria/conditions. Some 
are related to the DNS (non profit, ultimate agreement by the 
community). Of the head two are important: reversibility and no harm 
to the current operations. The "non profit" can be generailised: if a 
community effort is carried to commonly consider an evolution, every 
option should be considered and equally supported. Experiments must 
not be a way to impose personnal or affinity group doctrines and DoE 
(Denial of Evolution). Reversibility would also mean the result cannot 
be published as BCP. It may reflect the practice of a group. But it 
would not be acceptable to impose it to non participants as there is 
no proof it would scale - before the experience convers the whole 
network. This means that experience may be a way to deploy or to 
transition. Should the IETF has started a large scale IPv6 
experimentation, may be would we have IPv6 by competition to the RIRs. 
This has been considered.

jfc



Thats happening regardless of the IETF - www.public-root.com, 
www.inaic.com and www.unifiedroot.com.  Failed experiments result in 
successful evolution.


regards
joe




Dont forget

http://www.opennic.unrated.net/
http://dot-root.com/
http://root.5wc.ch/

Those who are not commercial are difficult to reach sometimes.
E.g. http://www.opennic.unrated.net/ sometimes can be reached
only as http://www.opennic.glue and you have to add

host_name("131.161.247.68","www.opennic.glue").

to your /etc/hosts to find them.

Still they have nameservers and they happily communicate with
each other without ICANN even nowing about their existence.

Cheers

Peter and Karin





At 16:06 15/02/2006, Brian E Carpenter wrote:


When considering some recent appeals, the IESG discovered that
we have very little guidance about the meaning of "experiments"
in relation to Experimental RFCs. RFC 2026 refers to work which
is "part of some research or development effort" and the IESG
has adopted some guidelines to discriminate between Experimental
and Informational documents (see
http://www.ietf.org/u/ietfchair/draft-iesg-info-exp-01.html ).
But beyond that, we do not know what constitutes an acceptable
experiment on the Internet.

The IESG notes that the community could establish a variety of
guidelines describing what is and is not acceptable in experiments.
Historically, the IESG has made decisions based on its perception
that there is a strong desire in the community to publish technology
that is being deployed experimentally.  We encourage community 
discussion

and development of more specific guidelines on operational conflicts
caused by experiments and how this should affect what we choose to
publish.  (However we recommend that such discussion
focus on the general issue rather than the specifics of any case.)

  Brian Carpenter
  for the IESG



--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: Is round-trip time no longer a concern?

[Peter Dambier]

Dave Cridland wrote:

On Sun Feb 19 23:23:59 2006, Dave Crocker wrote:


Folks,

Eric said:
> 1. It is slower because it requires two handshakes.
> 2. The client may have to authenticate twice (this is a special
>case of (1)).
>
> The second case can be easily ameliorated by having the client send an
> extension (empty UME?) in the first handshake as a signal that it wants
> to do UMDL and that the server should hold off on demanding client
> authentication until the rehandshake happens.
>
> The performance issue is quite modest with modern servers.


as long as you are living in the same rack with them. If you are connected
via UMTS it is a different thing.


> Indeed, it's
> quite common for web servers to do a first handshake without cert-based
> client auth and then rehandshake with client auth if the client asks 
> for sensitive page.


Indeed there are some webservers around that take so long until my
browser times out.



This raised a flag with me.  Within the Internet protocol context I 
have always seen significant concern for reducing the number of 
exchanges, because additional exchanges (hand-shakes) can -- and often 
do -- have painful round-trip latencies.  (Server capacity can be a 
concern, of course, but not for this issue.)



Well, for those of us looking at Lemonade, etc, I think we're still very 
concerned about every round-trip. Server capacity, too, is a very real 
problem, and, while I admit to not having looked at this specification 
yet, given what I've read thus far, I'm assuming this has some 
applicability to email protocols as well as HTTP, which would affect 
Lemonade.



For all of the massive improvements in the Internet's infrastructure, 
my impression is that round-trip delays can still be problematic.



Yes, I believe it has something to do with the difficulty of changing 
the speed of light. Probably requires standards action on a bunch of 
normative references, or there's a global upgrade problem.



Is it true that we no longer need to worry about regularly adding 
extra round-trips to popular protocols that operate over the open 
Internet?




A typical traceroute for me and many, many, many customers of major
german ISPs

 1  echnaton.peter-dambier.de (192.168.48.228)  4.594 ms   5.464 ms   6.267 ms
 2  DARX41-erx (217.0.116.49)  96.478 ms   101.004 ms   111.541 ms
 3  sepia (217.0.67.102)  115.774 ms   123.485 ms   131.139 ms
 4  62.154.15.2  147.919 ms   155.120 ms   162.845 ms
 5  gb-10-0-0.saams.nl.easynet.net (195.69.144.137)  171.365 ms   178.635 ms   
187.107 ms
 6  213.201.252.10  267.804 ms   270.174 ms   272.507 ms
 7  Scylla (213.201.229.65)  269.246 ms   272.058 ms   274.653 ms
 8  Charybdis (84.22.96.250)  98.668 ms   107.666 ms   111.906 ms
 9  Bifroest (84.22.96.246)  124.170 ms   128.057 ms   138.825 ms
10  tourelle (84.22.100.150)  148.487 ms   158.490 ms   163.288 ms

Except for (192.168.48.228) 4.594 ms (my old 486-SLC/2 router, 66 MHz) all are
fast modern machines. That DARX41-erx (217.0.116.49) 96.478 ms is a top model.

So 300 msec forward + 300 msec backward will become 1.2 seconds.
Vaja con dios VoIP.



No.

As far as I'm aware, there is no protocol in existence which somebody, 
somewhere, does not actively use over a mobile phone link, or a slow 
analogue modem, and this is especially true of TLS enabled protocols 
such as HTTP, email protocols, etc.


Dave.



Peter

--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: [RFC 959] FTP in ASCII mode

[Peter Dambier]

Once upon a time the used to be computers speaking ASCII or EBCDIC. The
ASCII computers where unix mostly. The EBCDIC where mainframes. ASCII
mode meant that EBCDIC card decks with fixed lenght of mostly 80 characters
per line would be translated into variable lenght records terminated by
CR/LF before sending them. Also they would be translated from 8 bit
EBCDIC code to 7 bit ASCII code. Unix would have to replace their single
LF character by a CR/LF sequence before sending. The result could be
punched to 7 bit punched tapes automatically adding a parity bit to the
tape. Or you could print it directly on an ASR-33 terminal.

Binary means take it as it is. Dont touch the formatting or character
set.

As the ASR-33 terminal did not know UTF-8 it is not a good idea to use
ASCII mode for UTF-8. But you can send it only to systems who understand
UTF-8.

Regards
Peter and Karin Dambier


Sandeep Srivastava wrote:

Hi,

RFC 959, says that FTP supports two modes to transfer files -- ASCII and 
Binary. Now, if I have a UTF-8 (or any other encoding) encoded text 
file, containing, say Japanese characters, would it be correct to choose 
the transfer mode as ASCII? And if I choose the transfer mode as ASCII, 
is there a possibility that the content of the file on the receiving end 
is garbled?


In a nutshell, does ASCII mode means that only ASCII encoded text files 
are supported?


Thanks,
Sandeep.




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



--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: [RFC 959] FTP in ASCII mode

[Peter Dambier]

Sandeep Srivastava wrote:

Thanks John. Please see my response in-line...

On 2/21/06, *John C Klensin* <[EMAIL PROTECTED] 
> wrote:




--On Tuesday, 21 February, 2006 12:53 +0530 Sandeep Srivastava
< [EMAIL PROTECTED]
> wrote:

 > First of all thanks to everybody for the response.
 >
 > I knew that a FTP transfer in ASCII mode does EOL and EOF
 > conversions based on the OS of the receiving system.

No, it doesn't.  That was part of the point.  It does no EOF
conversions at all.   The command and data channels were
separated for several reasons, but the desire to stay out of the
EOF business was an important one. 



Right. I understand the command/data channel part -- i.e. instead of 
sending the EOF as a data, it is sent as a command, and the receiver can 
then use the OS specific EOF. The overall affect to the end user is as 
if both EOL and EOF are converted to the receiving OS defaults.



And the server is required
to convert whatever line-end convention it uses to CRLF, and any
characters it uses to ASCII, and transmit that over the wire.


I don't understand this point very well. Does it mean that as per the 
FTP RFC the server reads 8-bits at a time, and sets the most significant 
bit to zero (because ASCII is 7-bits) before transmitting it in ASCII 
mode? If this is the case, then how did a UTF-8 encoded file containing 
Devanagri characters (i.e. characters greater than 7F) got FTPied over 
(and back) correctly in ASCII mode.


If not, -- i.e. it does not sets the msb to zero, then how does ASCII 
mode differs from Binary mode?


Scenario:
I am using WS-FTP pro as the client on my windows 2000 machine, to FTP 
to and back from a Solaris box (acting as FTP server).


Thanks,
Sandeep.



Sending ASCII from DOS/Windows means nothing to do for DOS, replace
CR/LF by LF only before storing on Solaris.

Receiving ASCII on DOS/Windows means for the Solaris box to replace
the lone LF by CR/LF before sending. If both DOS/Windows and Solaris
are lazy enough not to mask the 0x80 bit, then you are lucky.

Problems could arise when you have character sequences including
printable CRs or LFs. You will only find them when you least
suspect them :)


I remember having sent umlauts (ae=ä) (oe=ö) (ue=ü) between DOS and
Windoes. They do use different character sets. The result looked
nasty. If Solaris and Windows use the same character set, the same
printer? you could be lucky again.


Peter



If the client then converts from CRLF and ASCII to some local
convention, that is its business, not that of the protocol.  In
other words, there are, at most, conversions to and from CRLF
and ASCII. There are no FTP-specified conversions based on the
properties of the receiving system.

 > And I
 > very much expected my UTF-8 encoded file to get garbled when I
 > FTPied it in ASCII mode. But guess what, it was not garbled on
 > the receiving system. Maybe I was lucky, or maybe its because
 > UTF-8 is backward compatible with ASCII. But then, as ASCII is
 > purely 7-bits, the FTP in ASCII mode should have corrupted the
 > UTF-8 encoded file, because UTF-8 is 8-bits.

"Should have corrupted" is what I referred to as an ambiguity in
my note.   First of all, because of the robustness principle,
you can never guarantee that bad things will happen when they
might -- proper implementation of protocols around her often
argues for never trashing a string because one can or because a
correct string wouldn't have the problem.

So, in practice, if an FTP server was implemented on an ASCII
system that used the "right justified in octets" model but with
LF as line-end, the authors might have well said "the character
codes don't need any conversion for ASCII mode, we just need to
implement conversion to CRLF".  If they had done that, and UTF-8
(or ISO 8859 Latin-1 or...) were added to the system, those CCSs
would go through nicely in ASCII mode, with the right
line-endings.  Substantially the same thing would occur, as
Ohta-san points out, with many of the ISO 2022-based encodings
of non-ASCII characters: completely safely with some of them and
at least as safely as UTF-8 with the others although, as with
UTF-8, the claim of strict ASCII would be technically false.
Now that wouldn't happen with a system that was natively EBCDIC,
or ASCII stored in seven bit chunks without padding, etc.: those
systems would need to do real conversions to get to network
ASCII and, if you thought you were getting UTF-8 over them, you
would be in big trouble.

 > Moreover, in ASCII code page, code point 13=CR and code point
 > 10=LF, but that might not be the case in every other code
 > page. Hence the EOL conversion (in FTP ASCII mode) might
 > corrupt that text file if it is encoded using a non-A

Re: Beyond China's independent root-servers -- Expanding and Fixing Domain Notation

[Peter Dambier]

Kurt Erik Lindqvist wrote:


On 2 mar 2006, at 09.26, Mohsen BANAN wrote:


More than 5 years ago I predicted what the Chinese
government announced today.

What happened today:

http://english.people.com.cn/200602/28/eng20060228_246712.html
http://www.interfax.cn/showfeature.asp?aid=10411&slug=INTERNET- 
POLICY-MII-DOMAIN%20NAME-DNS

http://www.domainesinfo.fr/vie_extensions.php?vde_id=859
http://politics.slashdot.org/politics/06/02/28/1610242.shtml
http://news.com.com/China+creates+own+Internet+domains/ 
2100-1028_3-6044629.html


was obvious and quite easy to foresee.

Addressing the requirements of a very real
international multi-root environment is also not
all that hard and will likely naturally evolve.



To best of my knowledge, that there are no new Chinese root-servers -  
despite what the press says. And at least we have not seen a drop in  
queries to our anycast instance in Beijing yet so there even seems to  
be data to support that...


But what do I know...

- kurtis -



Hi Curtis,

at least we can see these domains. Can you see them too, on the
nameservers you are using?


; <<>> DiG 9.1.3 <<>> -t any XN--55QX5D. @hawk2.cnnic.net.cn.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46417
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 3

;; QUESTION SECTION:
;XN--55QX5D.IN  ANY

;; ANSWER SECTION:
XN--55QX5D. 3600IN  SOA hawk2.cnnic.net.cn. 
root.cnnic.cn. \
2006030104 3600 900 604800 3600
XN--55QX5D. 3600IN  NS  hawk2.cnnic.net.cn.
XN--55QX5D. 3600IN  NS  cdns3.cnnic.net.cn.
XN--55QX5D. 3600IN  NS  cdns4.cnnic.net.cn.
XN--55QX5D. 3600IN  NS  cdns5.cnnic.net.cn.

;; ADDITIONAL SECTION:
cdns3.cnnic.net.cn. 38  IN  A   210.52.214.86
cdns4.cnnic.net.cn. 518 IN  A   61.145.114.120
cdns5.cnnic.net.cn. 518 IN  A   61.139.76.55

;; Query time: 410 msec
;; SERVER: 159.226.6.185#53(hawk2.cnnic.net.cn.)
;; WHEN: Fri Mar  3 17:53:18 2006
;; MSG SIZE  rcvd: 215



; <<>> DiG 9.1.3 <<>> -t any XN--FIQS8S. @hawk2.cnnic.net.cn.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61182
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 3

;; QUESTION SECTION:
;XN--FIQS8S.IN  ANY

;; ANSWER SECTION:
XN--FIQS8S. 3600IN  SOA hawk2.cnnic.net.cn. 
root.cnnic.cn. \
2006030104 3600 900 604800 3600
XN--FIQS8S. 3600IN  NS  hawk2.cnnic.net.cn.
XN--FIQS8S. 3600IN  NS  cdns3.cnnic.net.cn.
XN--FIQS8S. 3600IN  NS  cdns4.cnnic.net.cn.
XN--FIQS8S. 3600IN  NS  cdns5.cnnic.net.cn.

;; ADDITIONAL SECTION:
cdns3.cnnic.net.cn. 574 IN  A   210.52.214.86
cdns4.cnnic.net.cn. 451 IN  A   61.145.114.120
cdns5.cnnic.net.cn. 451 IN  A   61.139.76.55

;; Query time: 399 msec
;; SERVER: 159.226.6.185#53(hawk2.cnnic.net.cn.)
;; WHEN: Fri Mar  3 17:54:25 2006
;; MSG SIZE  rcvd: 215



; <<>> DiG 9.1.3 <<>> -t any XN--IO0A7I. @hawk2.cnnic.net.cn.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35342
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 3

;; QUESTION SECTION:
;XN--IO0A7I.IN  ANY

;; ANSWER SECTION:
XN--IO0A7I. 3600IN  SOA hawk2.cnnic.net.cn. 
root.cnnic.cn. \
2006030104 3600 900 604800 3600
XN--IO0A7I. 3600IN  NS  hawk2.cnnic.net.cn.
XN--IO0A7I. 3600IN  NS  cdns3.cnnic.net.cn.
XN--IO0A7I. 3600IN  NS  cdns4.cnnic.net.cn.
XN--IO0A7I. 3600IN  NS  cdns5.cnnic.net.cn.

;; ADDITIONAL SECTION:
cdns3.cnnic.net.cn. 493 IN  A   210.52.214.86
cdns4.cnnic.net.cn. 370 IN  A   61.145.114.120
cdns5.cnnic.net.cn. 370 IN  A   61.139.76.55

;; Query time: 400 msec
;; SERVER: 159.226.6.185#53(hawk2.cnnic.net.cn.)
;; WHEN: Fri Mar  3 17:55:46 2006
;; MSG SIZE  rcvd: 215


regards
Peter and Karin


--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: Beyond China's independent root-servers -- Expanding and Fixing Domain Notation

[Peter Dambier]

Kurt Erik Lindqvist wrote:


On 3 mar 2006, at 18.15, Joe Baptista wrote:


Kurt Erik Lindqvist wrote:

To best of my knowledge, that there are no new Chinese root- servers 
-  despite what the press says. And at least we have not  seen a drop 
in  queries to our anycast instance in Beijing yet so  there even 
seems to  be data to support that...




There are. Check Peter Dambiers messages for details.



Exactly what does he prove there? Please explain



Take this one

; <<>> DiG 9.1.3 <<>> -t any xn--8pru44h.xn--55qx5d @ns5.ce.net.cn.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11465
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;xn--8pru44h.xn--55qx5d.IN  ANY

;; ANSWER SECTION:
xn--8pru44h.xn--55qx5d. 1800IN  SOA ns5.ce.net.cn. tech.ce.net.cn. 
2004072009 3600 900 1209600 1800
xn--8pru44h.xn--55qx5d. 1800IN  A   210.51.169.151
xn--8pru44h.xn--55qx5d. 1800IN  MX  10 mail.xn--8pRu44H.xn--55Qx5D.
xn--8pru44h.xn--55qx5d. 1800IN  NS  ns5.ce.net.cn.

;; ADDITIONAL SECTION:
mail.xn--8pRu44H.xn--55Qx5D. 1800 INA   210.51.171.29

;; Query time: 460 msec
;; SERVER: 210.51.171.200#53(ns5.ce.net.cn.)
;; WHEN: Sun Mar  5 10:52:41 2006
;; MSG SIZE  rcvd: 205


They obviously have got email and they use it.
And they have got a homepage too.

http://xn--8pru44h.xn--55qx5d/

Every shoemaker in the Netherlands can see them and order
their soles from them. Look at your soles (the inside :)

Maybe the root has changed and you are on the wrong server.

Chinese students do use these domains to communicate home.

Tiscali have updated their nameservers to be able to cope
with those emails.

Maybe anycast has played a trick on you and you cannot see
the right nameservers :)




Second - you will notice an increase in what you guys at the roots  
call I think illegal or erroneous TLDs - which see


http://www.theregister.co.uk/2003/02/05/dud_queries_swamp_us_internet/



I see no increase in these, but we do see a lot of them in general...



Incidentally - since my article was written I have not seen any  
further studies concerning root traffic from CAIDA or anyone else.   
In fact root operators don't really share much with the world - do  they?




Of query data? No and this a complex issue, at least for us that  
involves local laws regarding privacy and personal integrity. As for  
qps data, sharing that in real-time is at least by us considered a  
security issue. That said, we will as of the end of this quarter  start 
publishing a quarterly newsletter that among other things will  include 
some data over the past quarter.


- kurtis -

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




--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: Turkish secret service and a url to follow up Re: Could this be the next China Root

[Peter Dambier]

[EMAIL PROTECTED] wrote:

Joe Baptista wrote:


Turkish secret service operative discovered in Public-Root.



http://www.netkwesties.nl/editie140/artikel1.html



Is there an English-language version?  Ik spreek geen nederlands (aside


from that), and search for "engels" came up empty.



-Dave



http://cyberterra.com/root/artikel1.html


Kind regards
Peter and Karin

--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: Turkish secret service and a url to follow up Re: Could this be the next China Root

[Peter Dambier]

Hallam-Baker, Phillip wrote:

I fail to see how being infiltrated by the Turkish secret service is
something to boast about.


Not do boast about, but to warn - because the other roots are infiltrated
as well. That is why China is running their own root in the first place
and that is why Turkey started running their own root.

Ever asked yourself who is paying for that big root infrastructure?





From: Joe Baptista [mailto:[EMAIL PROTECTED] 




On Thu, 9 Mar 2006, Joe Baptista wrote:



Turkish secret service operative discovered in Public-Root.


http://www.netkwesties.nl/editie140/artikel1.html





Kind regards
Peter and Karin Dambier


--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: Guidance needed on well known ports

[Peter Dambier]

Steven M. Bellovin wrote:

On Sat, 18 Mar 2006 12:41:25 -0800, "Christian Huitema"
<[EMAIL PROTECTED]> wrote:


If there is a reserved range, then it
is easy to start dynamic allocation outside the range.



Yes -- this is my point.  I don't care about Unix-style privileged
ports (and have never liked them anyway), but putting most services
outside the well-known dynamic range is a good idea.


Yes, I agree, http should never have been assigned port 80. Randomly
looking for ports would make a lot more fun.

Maybe it is archaic, that all operating systems treat ports below
1024 special. But still they do. A normal user cannot gain access
to these ports.

Windows?

Is just a randomly changeing mess of dynamic link libraries that is
permanently modified by applications, viruses and the so called
operating system proper. The api is kept a trade secret.

VM, MVS, BS2000, VMS, all flavours of Unix including Minix, MAC OS-X,
BSD and Linux treat ports below 1024 special.

Special ports are required by servers running on real operating
systems. A windows client might be the user of such a port but
not the server. Or do you want to install a "trunk monkey" on
every host who takes care of an emerging error window and gives
the mouse a push?

How about a portmapper. It works with NIS and NFS. Yes the
port mapper needs a reserved port too, but that is already
allocated. Portmapper is a security hole but so is a randomly
changeing mess of DLLs.




Starting services quickly also helps with the "voluntary collisions"
between system services and applications, but is not foolproof. In any
case, it does not help with collisions between applications, e.g. two
applications trying to use the same port. What does help there is an
easily accessible registration system, so application developers can
easily "do the right thing", i.e. reserve a port and avoid collisions.
Note the emphasis on "easily accessible": if there are too many hoops to
jump through, the developers will likely just pick a number at random.



The portmapper is such a registration system.

I guess the port 42 nameserver was very early allocated and it still
works nicely for me but that could not prevent a collision with the
peculiar use of port 42 by windows.



Right, though it's a delicate dancce.


I agree, and please keep http on port 80 :)



--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

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



Cheers
Peter nd Karin
--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: veni vidi exi

[Peter Dambier]

Harald Alvestrand wrote:


"Eduardo", if there is one person I know who is willing to say that he 
knows who you are, and that you are a different person from Jefsey 
Morfin, I'll stop thinking you're a Jefsey sock puppet.


What difference does it make?

King Harald from Norway, no other member of IETF has spoken so much
about censoring or banning people who believe different from your
point of view. I hope it will not hurt too very much when you wake
up one day and find you cannot communicate any longer because you
are using an outdated character set and the root-servers you use
have gone offline.



Until then... "by their fruits shall you know them".



Just google for postings from King Harald Alvestrand

Apropos If you think Eduardo Mendez, Joe Baptista, Jefsey Morphin
and me are one person:

Look at my and Karins homepge.

My french is horrible with quebecois accent. My castellano is
mixed with both itlian and french. And I dont speak portuguese
yet. Maybe I shall learn.

--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: Guidance needed on well known ports

[Peter Dambier]

Ned Freed wrote:

Stephane Bortzmeyer wrote:
> On Sun, Mar 19, 2006 at 12:42:17PM -0800,
>  Ned Freed <[EMAIL PROTECTED]> wrote
>  a message of 35 lines which said:
>
>
>> The privileged port concept has some marginal utility on multiuser
>> systems where you don't Joe-random-user to grab some port for a well
>> known service.
>>
>
> "had", not "has". The concept was invented at a time where multi-users
> machines were rare and expensive monsters. So, a request coming from
> source port 513 probably was "serious". Today, any highschool student
> is root on his PC and therefore this protection is almost useless.
>




But does that student have access to the root account on servers which
are part of the networking infrastructure?   Who cares if Joe User
blows up his own config. on a PC that nobody else depends on but Joe?



But if nobody has local access to these servers, why is it is necessary or
useful for servers to run with root access in order to bind to these ports?

This is why I referred to the utility of this feature as marginal. Its 
realm
of utility is being squeezed on one side by the trend to run critical 
network
services on tightly locked down systems rather than on multiuser 
machines, and

on the other by users who want to run their own stuff doing so on their own
machines.

I simply don't have enough insight into global usage patterns to agree 
totally
with Staphane's asssrtion that this now has no utility at all. But I 
think the

trends are pretty clear.

I find the argument flawed -- that because Joe User can be root on his 
own PC,
the concept of privileged access to shared system-critical 
infrastructure is

somehow obsolete.


Joe User is not running critical servers - at least not under windows.
And if he really does, he will not do it very long :)

That is what my log on echnaton says. Echnaton used to be dsl-router
and still is my (local) dns-server, my ftp server, mail-server and
ssh-server. Echnaton is automatically running a bunch of things and
sending reports.

Nothing is done as root, because I am the sysop.

ssh, ftp, dns and other nameservices (port 42) all use privileged
ports - sometimes not the ports you would guess :)


djbdns the part about daemon-tools and tcp can help you out of
the user-root crisis.


With XEON, VM, CoLinux and others you can run a couple of virtual
machines on your one real machine. Running each of your servers
on its own virtual hostdoes not cost you much cpu or memory.
But running each of your servers in its own virtual machine will
protect your real machine from getting hacked.

So we still have the privileged ports even if they are distributed
over virtual machines.

User me still has no reason to bind to a privileged port - and if
I do I am shure it is a bug.

It does not make sense removing bug protection only because
some unfamous collection of bugs cannot be fixed.

Believe me it is a dynamically changeing collection of bugs only.
It has no operating system structure built in. There is nothing
you can relibly run a server on. I tried to.

It does not make sense to bend rules breaking systems that do
work as servers. Windows is not a player in the server business.


Regards
Peter and Karin Dambier

--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: Guidance needed on well known ports

[Peter Dambier]

Hallam-Baker, Phillip wrote:

The idea of requiring a privillege to access certain ports can have utility.

The idea of requiring root in a monolithic two level system like unix is 
a very bad one indeed. Http and smtp servers should not run as root. 
Forcing them to is bad o/s design.


Bind is chrooted into directory /usr/lib/named and runs as user named.
Apache is chrooted into /usr/lib/www and runs as user wwwrun.
Exim is chrooted into /usr/lib/exim and runs as user exim.
...

There are even systemcalls in all flavours of unix for doing this.
There is (almost) no need to run anything as root.

Bernstein too has ideas too, how not to run things as root ...
Works under all flavours of unix, including MAC OS-X. I guesstimate
that works for some 70% of all servers.

--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: Guidance needed on well known ports

[Peter Dambier]

Steven M. Bellovin wrote:

On Mon, 20 Mar 2006 12:47:46 -0500 (EST), [EMAIL PROTECTED] (Noel
Chiappa) wrote:



Another option, now that I think about it, though, is a TCP option which
contained the service name - one well-known port would be the "demux port",
and which actual application you connected to would depend on the value in
the TCP option.



Like tcpmux, port 1, RFC 1078?

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

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



How bout the NIS portmapper on port 111 and RFC 1057

--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: Guidance needed on well known ports

[Peter Dambier]

Simon Leinen wrote:

Stephane Bortzmeyer writes:


On Sun, Mar 19, 2006 at 12:42:17PM -0800,
Ned Freed <[EMAIL PROTECTED]> wrote 
a message of 35 lines which said:



The privileged port concept has some marginal utility on multiuser
systems where you don't Joe-random-user to grab some port for a
well known service.




"had", not "has". The concept was invented at a time where multi-users
machines were rare and expensive monsters. So, a request coming from
source port 513 probably was "serious". Today, any highschool student
is root on his PC and therefore this protection is almost useless.




It never was a protection against malevolent students but it still is
a protection against silly mistakes.

Just try "accidently" 'cd / ; rm -R *'

You know what I mean with silly mistakes. It makes a difference beeing
root or beeing user joe when you "accidently" execute the shown command.
Mistakes like that do happen.



Stephane, you are thinking of a different "security mechanism" based
on ports <1024 - the one used by the infamous Berkeley r* utilities to
decide whether to trust a client's credentials.  This mechanism
doesn't use well-known ports, but "ephemeral" ports <1024 on the
client side.  I think it is fairly much consensus that this kind of
mechanism has become useless years ago, for the reason you state.


Behind closed doors and on virtual machines they still work remarkebly
well. It would be overkill to run an sshd on each of the virtual machines.
So would be logging in as root to directly access the virtual root
directories.


What we are collecting input on is for which kinds of use (if any) a
privileged/well-known (as opposed to just IANA "registered") *server*
port makes sense.


Some 70% of all server machines run operating systems that have a
notion of multiuser and of privileged user. Only servers are allowed
access to the privileged well-known ports. Allowing non-privileged
programmes access to the privileged ports leads to desaster

Moving the 1K border for well-known ports up to 16K would be nice in
the long run.

I agree, on the client only machines the distinction between well-known
and not so well-known ports does not make much sense. But those clients
cannot live without their servers and the servers would not survive
very long without their well-known ports.


--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: Why DNS sucks for referrals (was Re: Stupid NAT tricks and how to stop them.)

[Peter Dambier]

Francois Menard wrote:


Are you saying that ENUM is a dead end?

F.

--
[EMAIL PROTECTED]
819 692 1383



ENUM is a dead born child.

ENUM is supposed to be good for VoIP. Well, I do have VoIP but my VoIP
does work allthough ENUM does not. My router could use ENUM - but which
one should I ask, "e164.arpa" or "e164.org"?

Neither of them does know any of my phone numbers.


I am told I could buy the domain that corresponds to one of my phone
numbers but I would have to bring in a birth certificate of both me
and my landlord to proove legal ownership of that phone number. The
gouvernement of germany would hold an election about the matter and
if everything was allright I might put my phone number on my tombstone
finally.


In the meantime you can call me on

If your VoIP provider talks to sipgate.de

+49(6252)750-308

If your phone allows to do that

sip:[EMAIL PROTECTED]

or via no-ip.com dynamic DNS

sip:[EMAIL PROTECTED]

Please allow for my local time. It is Québéc + 6 hours
or Paris time :)


I guess, right now ENUM could not do that no-ip.com trick.
I would have to ask parliament every time my ip changed,
to update my A record.


Hope I was not too cynical.

Kind regards
Peter et Karine

--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: Stupid NAT tricks and how to stop them.

[Peter Dambier]

Austin Schutz wrote:

On Wed, Mar 29, 2006 at 01:00:44AM +0200, Iljitsch van Beijnum wrote:


1996199719981999200020012002200320042005
2.7 1.2 1.6 1.2 2.1 2.4 1.9 2.4 3.4 4.5

(The numbers represent the number of addresses used up in that year  
as a percentage of the 3.7 billion total usable IPv4 addresses.)


Those years where the growth was smaller than the year before never  
happened twice or more in a row.


This basically means that unless things take a radical turn, the long- 
term trend is accelerating growth so that remaining 40% will be gone  
in less than 9 years. Probably something like 7, as Geoff Huston  
predicts.





This is much less time than I have seen in previous reports. If
this is accurate and consistent there is a greater problem than I had
previously thought.
If that is indeed the case then the "enhanced nat" road for ipv6
begins to make much more sense, even in the nearer term.

Austin



I am afraid the problem is even bigger.

I have seen again and again that cable providers are giving out
ip-addresses in the 10.0.0.0/8 area to save ip address space.

Not to mention wireless hotspots. The hotspots I have been playing
with own only a single one ip-address.

You notice something is awfully wrong, when your VoIP phone is not
working but your neighbar keeps telling you, his skype does.

--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: Stupid NAT tricks and how to stop them.

[Peter Dambier]

Anthony G. Atkielski wrote:

John Calcote writes:



I'll just jump in here for a second and mention also that vendors
offer what they have to, not what they can. They want to provide the
most "bang for the buck", so to speak. These companies don't offer
the multiple-static-ip-address option today because most ISP's don't
offer it to home users and home (SOHO) users represent the target
market.



It is unlikely that ISPs will ever offer static IPs or multiple IPs to
home users at any time in the future for free.  They will continue to
charge heavy premiums for such "professional" features, with or
without IPv6.



http://www.manitu.de/

They offer you:

fixed IPv4 address with reverse lookup at 9.99 Euros per month.

You must have already T-DSL to use this servevice and you will
keep that. Means the 9.99 Euros get you a second PPPoE link over
your old modem and you can have a fixed plus a dynamic IPv4 address
at one and the same time.

t-online.de offer a similar service but it is more expensive.


--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: Reality (was RE: Stupid NAT tricks and how to stop them.)

[Peter Dambier]

Noel Chiappa wrote:


Many years ago now, a funny thing happened on the way to "complete exhaustion
of the IPv4 address space (Version 1)". Some clever people worked out this
ugly hack, which the marketplace judged - despite its ugliness - to be a
superior solution to the forklift upgrade to IPv6. It's been selling like
hot-cakes ever since, while IPv6 languished.


Wasn't there a thing called ISO or OSI?

The think that was meant to revolutionize the internet. I still have my
ISODE kit running on my old machines that probably never will run IPv6.

ISODE could seamlessly run over IPv4 and directly on the ISDN interface.
Only today ISDN runs over IPv4 itself :)



I've become rather disenchanted with my crystal ball, which seems quite
cloudy of late (if you'd told me, in 1986, we'd still be running a
Destination-Vector routing architecture for a routing table of this size 20
years later, I'd have *known* you were bonkers), so I have no specific
prediction to make, but...



Exactly here thems to be IPv6 biggest problem.

The people playing with IPv6 could not but connect via IPv4 tunnels.
Nobody had a clue about routing. In the old 3fff:: network network1/64
was in Stockholm, network2/64 in Newyork, network3/64 in Stockholm again
and so on. This was not a problem because everybody was connected by
point-to-point links and the routing was done by IPv4.

Now they have changed to the 2001:: network but they still have no clue
about the routing issues at all.

To make things worse site local IPv6 addresses were deprecated. So you
dont have a chance to number your machines locally and play with IPv6
for learning. You have to get an official /64 network to run your site.



Don't be surprised if the world, facing "complete exhaustion of the IPv4
address space (Version 2)" decides, yet again, that some sort of Plan B is a
better choice than a conversion to IPv6.



RFC 1347   TUBA: A Proposal for Addressing and Routing   June 1992


I have no idea exactly what it will be (maybe a free market in IPv4
addresses, plus layered NAT's, to name just one possibility), but there are a
lot of clever people out there, and *once events force them to turn their
attention to this particular alligator*, don't be surprised if they don't
come up with yet another workaround.

Noel



The chinese internet with its own root and TLDs like
XN--55QX5D, XN--FIQS8S, XN--IO0A7I
and the Great Firewall Router is researching into TUBA and I dont
beleave we will like the outcome. Every dictator will like it.


Peter and Karin

--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/



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

Re: Stupid NAT tricks and how to stop them.

[Peter Dambier]

John Loughney wrote:

Lars-Erik,



From: Michel Py [mailto:[EMAIL PROTECTED]
Unfortunately some protocol purity zealots still have to realize
that Linksys, Netgear, Belkin and consorts don't sell NAT boxes
because they think NAT is good, they sell NAT boxes because
consumers want to buy them. 


I do not think consumers in general want to buy NAT boxes, but
they are forced to do so by ISP's who do not give them a choice.



We're over-analyzing things. The last 3 WLAN APs I bought had NAT on by default; 2 of them it was impossible to turn this off.  I got into long discussions with tech support who were telling me it is impossible to design a WLAN AP-router combo that didn't NAT.  



Just for curiousity: The TI chipset AR7 is the core of a couple of boxes.
The all run linux and you can telnet them. They can route. No need for NAT

My box is an Eumex 300 IP from t-online.de
It is the same as the Fritzbox from AVM.

Netgear, Siemens, Linksys and D-link produce similar boxes.

I remember some people at RIPE loudly thinking about writing their own
software for the Netgear or the Linksys.

My DSL provier offers me 5 DHCP address for free (consumer grade connection) and my mobile carrier is now using real IP address for GPRS (they had too many problems caused by NATed IP addresses).  



DHCP is almost as bad as NAT is. Best get an aDSL-modem, if you are connected 
by aDSL
then distribute the line via a switch and let your five coputers to the PPPoE 
stuff.
So your computers are the DHCP clients and can dyndns or whatever.

In practice, I've needed to power-cycle these NAT boxes every few weeks, to clear out the garbage.  The most common things most ISP tech support lines are "unplug your router/AP/box", count to 60 and plug it back in.  



I have had that same power-cycle problems with a GrandStrem ATA for my VoIP.
My ISP dtag.de or t-online.de forces a disconnect every 24 hours. Sometimes
they dont disconnect very cleanly and the Grandstream breaks.

Best forget GrandStream. It breaks ICMP and it has problems with ssh and
telnet passing through. Problably it does not get MTU correctly from
people living behind tunnels. Their support never cared to answer.

A Siemens router is now connected for half a yaer without any power-cycles.
I guess the box is one of those AR7 linux boxes.

My eumex too did not show any problems except for nagging about undisciplined
disconnects form my ISP.


However, if I am just a normal user, go to Best Buy and pickup a home WLAN Access Point, 
I'll have a NAT by default.  There is no "NAT inside" logo on the box, nor are 
there clear instructions on how to turn this off.  Vendors have turned NAT on by default 
because it is easier for them; not because the market has asked them to.



I guess if you are a normal user then you are a loser anyhow.
Those people normally have open windows and they dont know
how to close them :)

Putting those people behind triple NAT would not only save their
harddisk some viruses but it would save our bandwidth too -
keeping them from p2p each other :)

As for reference, my local paper started, computer stores started advertising "NAT firewalls" around 1998-99.  When NATs first came to a the market, the marketing message was that NATs provided a security feature.  Still, I have far too many tech support discussions where there is common confusion between NAT & firewall features.  I don't think it is really intellectually honest to say the market has chosen NATs because it is what they wanted - it is a band-aid fix for a couple of different problems, which it kind of solved, but creates some ugly side effects.  


To get around these side effects, people are deploying ALRs, B2BUA and SBCs to 
help fix the side-effects (and to do other things).  Human nature being what it 
is, we'll probably keep applying these quick fixes, until it gets far to messy 
and someone comes in and wipes these away with a new solution.  Circuit 
switching, ATM, ISDN, etc. all have been useful for some solutions - but when 
you try to go beyond what they have been designed for, you tend to have to 
apply patches and hacks to get things working.

John



Cheers
Peter and Karin


--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/



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

Re: Stupid NAT tricks and how to stop them.

[Peter Dambier]

Cullen Jennings wrote:

On 4/11/06 12:33 AM, "John Loughney" <[EMAIL PROTECTED]> wrote:



In practice, I've needed to power-cycle these NAT boxes every few weeks, to
clear out the garbage.



I'm curios to understand more of what you mean by this? Are you running out
of ports? Do you have any ideas what is causing this? (I have a strong
interest in the many ways NATs fail :-)



Linux: http://www.eisfair.org/
host_type("echnaton","(none)","Linux echnaton 2.2.19 #15").

No problems, but from time to complains about not so clean seesion
termination by dtag.de

_


Fritz_Box_Eumex300IP
cpu model   : MIPS 4KEc V4.8
BogoMIPS: 149.91
Linux version 2.4.17_mvl21-malta-mips_fp_le

No problem either, but from time to time I find in my telnet session:

Apr 11 05:22:04 dsld[381]: Channel 0 closed (physical)
Apr 11 05:22:04 dsld[381]: EVENT(36): Zeitüberschreitung bei der 
PPP-Aushandlung. (PPP_LCP)
Apr 11 05:22:04 dsld[381]: internet: PPP_LCP TIMEOUT
Apr 11 05:22:04 dsld[381]: starting autodetection
Apr 11 05:22:04 voipd[402]: connstatus 4 -> 2
Apr 11 05:22:07 dsld[381]: autodetect: failed
Apr 11 05:22:07 dsld[381]: atm socket rmem 65534
Apr 11 05:22:07 dsld[381]: PPPoEFW: set_snd_mtu: 1492
Apr 11 05:22:07 dsld[381]: PPPoEFW: set_rcv_mtu: 1492
Apr 11 05:22:07 dsld[381]: PPPoE forwarding for lan enabled.
Apr 11 05:22:07 dsld[381]: internet: set_rcv_ipaddr: 192.168.179.1
Apr 11 05:22:07 dsld[381]: internet: connecting
Apr 11 05:22:07 dsld[381]: internet: 00:04:0e:6d:8a:43
Apr 11 05:22:07 dsld[381]: internet: 00:04:0e:6d:8a:43
...
repeating

_


Grandstream ATA-486
Red lite blinking, saying VoIP is dead.
HTML does not connect at all.
No Ping either.

Only unplugging power get the box back.


_


dtag.de forces session termination every 24 hours. Sometimes
they are nasty and terminate the session several times within
a short time or they simply go dead. Happens rarely.

Everytime I get a new ip-address after reconnecting. That is
all what this silly session termination is about. Just to
anger the VoIP people. They are selling VoIP themselves those
silly buggers :)

The Grandstream goes bonkers when session terminations is
forced but the session is not terminated propperly but simply
broken.

There is another problem with the GrandStream: It does not
handle ICMP properly. It breaks MTU discovery and traceroute.


Cheers
Peter and Karin


--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: Reality (was RE: Stupid NAT tricks and how to stop them.)

[Peter Dambier]

 Michel Py wrote:


That being said, I do acknowledge that larger companies such as global
ISPs do have a problem with the RFC1918 space being too small. This
brings the debate of what to do with class E, either make it extended
private space or make it global unicast.



When develloping IASON, first I found out, CISCO boxes would not allow me
to use class E addresses nor would HP boxes.

Next I found out Linux boxes would not either.

I guess most boxes will not allow you to use these addresses.


Cheers
Peter and Karin


--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]

[Peter Dambier]

Michel Py wrote:

Iljitsch van Beijnum wrote:
However, geographic addressing could give us
aggregation with provider independence.


 


Brian E Carpenter wrote:
You'll have to produce the BGP4 table for a pretty compelling
simulation model of a worldwide Internet with a hundred million
enterprise customers and ten billion total hosts to convince me.



The problem with geo PI aggregation is expectations: if we set any
aggregation expectations it won't fly because too many people have
legitimate concerns about its feasibility. Personally I think that some
gains are possible, but I'm not sure these gains will offset the amount
of work required.

My $0.02 about geo PI: a strategy change is needed. Instead of
presenting geo PI as the solution that would give PI without impacting
the routing table (this will not fly because there are too few believers
and too many unknowns), present it as the icing on the cake of a
comprehensive non-geo PI proposal.



The best possible way to prevent IPv6 is give prefix::1 to somebody in
Newyork, prefix::2 to somebody in Kapstadt, prefix::x to Newyork again ...
and wait for the routers to crash because of memory exhaustion.

Next wait for somebody to build routers with Gigabyte memory and wait for
them to find an entry. If it really can find it you might try to retract
and renew it in 2 hour intervalls. I am shure you will bring them down :)





Michel Py wrote:
That being said, I do acknowledge that larger companies such as
global ISPs do have a problem with the RFC1918 space being too
small. This brings the debate of what to do with class E, either
make it extended private space or make it global unicast.



Eliot Lear wrote: 
I think we bite the bullet and go to IPv6.



I just rubbed my desktop lamp and I regret to report that no genie came
out of it to grant your wish.



Screwing around with Class E address space at
this late date is counterproductive.



Not screwing around with it means more dirty tricks and more double NAT.
IMHO the strategy of keeping class E reserved hoping that it will
accelerate the deployment of v6 is futile.




Iljitsch van Beijnum wrote:
[ARIN PI policy]
and now just as these efforts are getting close to paying off
(shim6) a small group of people decides to throw caution in the
wind and adopt a policy that opens the door to exactly the
problems the IETF has been working so hard to avoid.



These people are tired of hearing the broken record "getting close to"
that they heard consistently for the last 10 years.



We already have a solution.

IPv9 TUBA

China has deployed it already.

TUBA is the only way for both the USA and China each of them to
have 75% of all ip addresses.

Every country will have 75% of all ip addresses.

There is no way to prevent this because there is no better way for
total control and censorship.

And everybody can keep and run his old IPv4 stuff. No need to
learn semething new.

Dictators will love it. They even will pay for it. They can,
because it is us who will pay the bill finally.





Kevin Loch wrote:
In case you (IETF) didn't get the memo, the operational
community has flat out rejected shim6 in it's current form
as a replacement for PI.
This failure of leadership from the IETF to provide a
roadmap for a viable alternative to PI is a factor in the
support for going with the current technology.



I have to agree with Kevin here.

Michel.


A little late and off-topic:


Iljitsch van Beijnum wrote:
Peer-to-peer isn't a good example, because of the high built-in
redundancy. Even someone who can only set up outgoing sessions
can run BitTorrent without too much trouble because there are
plenty of peers without NAT or portmappings of some kind (manual,
uPnP or NAT-PMP) that can receive the incoming sessions. When the
sessions are up, traffic can flow both ways.



Technically speaking you are correct (this is called tit-to-tat I
believe), but it does not work in the real world, reason being UL/DL
ratios. Many "interesting" (use your own definition of it) torrent sites
have dedicated trackers that enforce ratios; relying on the mechanism
you describe can never achieve a UL:DL of 1. I do acknowledge that there
are scores of leechers out there, but most of them sooner or later will
open the ports in order to be able to seed completed torrents and up
their ratio. Demographics show large number of teens who are technically
savvy enough to get into the Web interface of their NAT box with
admin/admin and open the ports.


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





--
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


___
Ietf mailing list
Ietf@ietf.

Re: The Emperor Has No Clothes: Is PANA actually useful?

[Peter Dambier]

Joel M. Halpern wrote:

I have to disagree.
Firstly, if many of us reading the document can not figure out what 
problem it is solving, then the framework is not doing its job.
Secondly, if there are existing, viable, deployed solutions to the 
problem that the WG is attempting to solve then the WG needs to explain 
somewhere (the framework document would seem the obvious place) why 
there is a need for a new solution.


I am not claiming that the PANA protocol can't work.  As was said many 
years ago "with sufficient thrust, pigs will fly."  But that does not 
make flying pigs a good thing.




Flying pigs would add RFC 2549 a totally new meaning, incrementing
put through dramatically :)


Joel M. Halpern wrote:

EAP over IP (or UDP, or link) is about authenticating the user.  If a 
media independent technique better than just using a browser is 
needed, then solve that problem.  Personally, I would find the work 
far more persuasive if it did not also try to solve the problem of 
creating an IPSec association to the access device, nor of the 
authorization selection problem.

And spell out in clear English what use case needs that problem solved.
I can read between the lines and start to guess.  But the document is 
quite unclear.  The appendix about DSL is not helpful in that regard.




Here in germany DTAG.de, the infrastructure supplier for most aDSL providers
does use PPPoE exclusively, authorization by PAP. It would be nice to
connect an aDSL modem directly to a WLAN and let everybody use his own
personal account via the AP. Alas - eavesdropping ...

If PANA could come in here?

I dont know PANA at all right now. That is why I dont know what harm it does.
Can anybody tell me what to look for?


> At 11:34 AM 5/26/2006, Dave Crocker wrote:


Although not a guaranteed way to distinguish among criticisms, it can 
be helpful to categorize them as either "It will not work" versus "I 
don't like it". The former indicates a basic technical flaw, and the 
latter a matter of preference.


If it is common for readers of a specification to fail to understand 
what it is for then it has, perhaps, the most basic kind of technical 
flaw.  How can a specification succeed if there is confusion about its 
implementation or use?


By contrast observations such as "there are better solutions" moves 
into the fuzzier and more subjective realm of trying to predict market 
preferences. The IETF is not very good at making these predictions.  
Absent any indication of actual harm that would ensue


from publishing a specification, fear that no one will adopt it or 


that there will be multiple solutions seems an inappropriate basis for 
denying publication.  (On the other hand, strong indication of 
community interest in deplying a specification is supposed to be a 
factor in deciding whether to charter the work in the first place; 
however as Sam noted, we are rather late in the process.)


In any event, I would claim that concerns over who will use PANA fall 
into the "I don't like it" category, since it basically seeks to make 
statements about market preferences, which is a small step



from personal preferences.



Having looked over this thread and the -framework document a bit, I 
find myself unclear which of the two lines of concern is being 
pursued, although I impressed by the degree of confusion about PANA 
after what appears to be considerable effort to understand it.  This 
does not bode well for community understanding, and that of course 
does not bode well for adoption and use.




There are more complicated protocols that have been implemented, like
netbios over tcp, without thought of their impact on security.

I have burnt my fingers running netbios (samba) on a system (linux) I
deemed imune against hackers. I dont want to run that risk again.

I dont see the pit I might fall in - but I cannot see very far right
now, because of thouse high walls around me :)

Still that is not a reason against documenting it. Just giving more
insight would be welcome.


I would find it particularly helpful to have a concise statement

from someone who says that PANA will not work.  Cannot be 


implemented (properly) by virtue of technical errors or documentation 
too confusing to understand.  Or cannot be deployed and used, by 
virtue of administrative complexity or, again, documentation too 
confusing to understand.


Absent this, I will ask why it is productive to note that the emperor 
is pursuing an idiosynchratic sartorial style?





Kind regards
Peter and Karin

--
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: The Emperor Has No Clothes: Is PANA partly useful?

[Peter Dambier]

Bernard Aboba wrote:

My question is more why do they need EAP in situations where they are
not running at the link layer than why do they want or not want PANA.



The simple answer is that there are situations which IEEE 802.1X cannot 
handle on wired networks.  As specified, IEEE 802.1X is "network port 
control", which means that authorization is controllable only at the port 
level.  If there is more than one host connected to a switch port, then 
that model no longer applies. 



That is exactly the problem of aDSL here in Germany. The line ends in a
modem at my home and I can connect as many clients as I want, using
different accounts on one ISP or even connect me to different ISPs. So aDSL
here is a many to many connection with people tunneling via PPPoE.

For example, consider a user with two machines attached to a hub on a 
single port - a laptop and a desktop machine.  The desktop authenticates 
via machine credentials, and for some reason the certificate has expired 
without being renewed.  The laptop has up to date credentials.  However, 
because they are both connected to the same port, they will each attempt 
to authenticate; since the desktop machine no longer has up to date 
credentials, its authentication will fail, causing port access to be 
denied, throwing the laptop off the network.  The two machines will 
continue to cycle through authentication attempts, causing the port to 
alternatively be open and closed.


Some of the solutions that have been discussed include:

a. For the switch to keep MAC state on each port, which requires a 
additional CAM, and therefore a forklift upgrade, OR


b. For the switch to support protected Ethernet (802.1ae) and associated 
key management (802.1af) so that traffic from each host can be 
cryptographically separated, also requiring an (even more expensive) 
forklift upgrade; OR


c. For the host and routers to support EAP over UDP.  Typically this works 
by having the router recognize a new host (e.g. new entry in the ARP 
table), then challenging it via EAP over UDP.  If the host successfully 
authenticates, packets from that IP address are allowed to pass through 
the router filter; otherwise not. 

Of these approaches, b) is the most secure since it enables cryptographic 
separation between traffic from different MAC addresses, preventing
MAC address piggyback attacks as well as enabling reliable "shared media" 
operation. However, it is also the most expensive approach, since each 
port now needs to support encryption; at lines rates of 1+ Gbps this can 
be pricey. 

Approach a) is less expensive (and less ecure) than b), but also requires 
a forklift upgrade. 

Approach c) is probably the least secure, but it is also the 
least expensive approach, since no switch ports need to be upgraded. 

One might argue that approach c) is likely to represent a short-term fix 
until switches supporting a) or b) are commonly available, and therefore 
that EAP over UDP has no long-term future.  I would tend to agree with 
this, but would also observe that switches tend to have long replacement 
cycles. For example, it is common to see customers with Cat 5K switches 
that have been in place for a nearly decade with no immediate prospects 
for replacement. Those kind of customers are likely to find EAP over UDP 
appealing. 




--
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12

[Peter Dambier]

Julian Reschke wrote:
I noticed that the ID tracker now has a comment from the authors (see 
), 
which I'd like to comment over here...:



Author's response to Last Call comments on ETags

1) Best common practice in WebDAV

Currently very few, if any at all, WebDAV servers change the content 
of resource data during a PUT request. Most WebDAV servers do return 
an ETag on PUT. Thus clients have come to rely on the presence of the 
ETag to effectively mean that the resource data was stored unchanged 
and that the ETag can be used in subsequent GET requests etc. This 
justifies our statement that servers SHOULD return an ETag in a 
response when the data has not changed.




I am one user of webdavs://mediacenter.gmx.net/

I dont know how many subscribers they serve but they are one of the biggest
ISPs in germany. They belong to United Internet, 1und1, GMX and Schlund.

I dont know what they use but I guess Appache and Linux.

They do change content.

I am running Konqueror on Linux and I can both move and copy documents using
drag and drop. I can delete or rename using the mouse and I can edit and
write back using the browsers builtin editor.

I cannot see ETag flag from my userinterface. But my browser shows me
the before and after. So normally I can see if anything has changed.



I have my doubts that this statement is based on actual testing. In 
particular it seems to me that making claims about "most" servers isn't 
useful here; servers that do rewrite content do exist, but they are 
certainly outnumbered *installation-wise* by IIS and Apache/moddav/fs 
which implement WebDAV as a "dumb" store (in that they don't support 
special semantics on specific content types). But that doesn't mean that 
being incompatible with that class of servers (being fully compliant to 
RFC2616 and RFC2518) is acceptable.


That being said, I just tested:

- Microsoft IIS 5.1 (as shipping with XPSP2): No ETag returned upon PUT

- Apache/moddav 2.0.55 (WinXPSP2): No ETag returned upon PUT

- Xythos WFS (on www.sharemation.com): ETag returned

- SAP Netweaver KM: ETag returned although content may be rewritten

It seems to me that this shows that the statement above is misleading.

Now we have CalDAV servers where the resource data MAY be changed. 
Therefore to be compatible with existing client behavior a server MUST 
NOT send the ETag in a PUT response when the data changes, otherwise 
clients will misinterpret it. This justifies our 'MUST NOT' statement.



It would be helpful if you could provide an example of a *shipping* 
client that breaks if an ETag is returned upon PUT although content was 
rewritten.



2) Restricted behavior

The ETag behavior we are talking about is restricted solely to 
calendar object resources being stored in calendar collections - i.e. 
it is very specific to CalDAV. This is not 'redefining' HTTP behavior 
by rather extending it for this one specific application need.



But it's still an HTTP and WebDAV resource. A CalDAV server that also 
happens to be a generic WebDAV server may need to make this a special 
case then. And this may be hard to do should there be another 
HTTP/WebDAV related specification making an incompatible requirement.


As a matter of fact, in February the IESG has decided to solve that very 
problem in a separate activity (see draft-whitehead-http-etag-00), 
independently of WebDAV and CalDAV. And, indeed, RFC2518bis (the 
revision of WebDAV) delegates resolution of the question to that very 
spec, instead of coming up with it's own. This is what CalDAV should 
also be doing.



3) Future conflicts

One of Julian's arguments is that our requirement will "risk making 
CalDAV incompatible with other specs extending HTTP (or HTTP itself, 
for that matter)". Since we have been careful to require only behavior 
that already exists in deployed WebDAV servers, CalDAV adds no further 
incompatibility. If future work to better define the meaning of ETag 
on PUT ever happens, it will need to take into account the deployed 
base, and the subset of CalDAV servers will simply happen to be a 
consistently behaving subset. We believe that our requirements improve 
the interoperability of CalDAV, without making the future/potential 
incompatibility problem any worse than it already is.



See notes above. The behavior required by CalDAV is *not* what current 
servers do. At least not the majority.



4) Need/usefulness

In addition to the authors' evaluation of the usefulness of this 
feature for keeping an offline calendar correct, there have been other 
requests for predictable behavior w.r.t. PUT and ETags and calendar 
resources. This was one of the first feature requests from client 
implementors, including Dan Mosedale and Grant Baillie.



I totally agree that clients may be interested in finding out whether 
content was rewritten. The solution to this is to either put more energy 
into dra

Re: ASCII is dead, long live ASCII (was: Image attachments to ASCII RFCs)

[Peter Dambier]

Michael Thomas wrote:

Hallam-Baker, Phillip wrote:


John,

You mean that we should update the current medieval print format 
to take advantage of the best technology available to the Victorians?


Why go to all that trouble to create infrastructure to support an 
obsolete document format when we can get all the infrastructure 
required to support a modern, open format that delivers professional 
results for free?


Moreover there is a much higher probability that third party tools 
will support a common W3C/IETF format than an IETF only format.  

Which tools would those be? Cat, tr, emacs, vi, grep, cut, sed, curses, 
wc, more or less?


I absolutely need vi and grep. PDF is nasty because is lacks these tools.



Am a Luddite. I like ASCII. I despise PDF, and most especially its 
hideous anti-aliased
fonts. As software engineer, I don't need drawings that I can use to run 
a lathe or a
milling machine. Simple stick figures, ladder diagrams, and boxes for 
bits and bytes
are about all I really need to see to transform an RFC into code. As 
protocol designer,
the fewer Paper Clips sent by Beelzebub himself, the better. If it can't 
be edited using

the buffer gap method, I'm not interested.

Victorian? Pah. The death of Prince Albert of Ascii would require a 
minimum of a
year of  mourning, and a smart new black wardrobe for Phill. Not to 
mention a

cross sovereign.

  Mike, we are not amused.


By the way, might we - - - perhaps EBCDIC ???

It is much better than ASCII because it sorts numbers where they belong,
behind the letters and not in front of them.

And please keep a space not a tab and no printable character in column one.
I need it for printcontrol.

EBCDIC has got all the graphic characters you  ever need. It is a standart
and it is multiplatform.

Both kermit and ftp can handle EBCDIC. Even the PC and Apple addicts can
use it.

You can use dd to translate between ASCII and EBCDIC

http://www.scit.wlv.ac.uk/cgi-bin/mansec?1M+dd

So it is already present on all decent operating systems.

Using the 3270 telnet option, all decent browsers allow reading EBCDIC
pages. No need for plugins.

Any comments? lol and rofl favoured :)

apropos

There exist readers for ASCII and EBCDIC either Braille or literally
readers for the blind and for people with reading disabilities.

Internet sans frontiers.


Cheers
Peter


--
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))

[Peter Dambier]

Hallam-Baker, Phillip wrote:
From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] 



When I was 16 years old, I wrote a text editor in BASIC that 
would probably have allowed me to edit RFCs. 



I wrote a text editor in Basic for the ZxSpectrum that was published 
commercially when I was 15.

I guess I could use it to edit RFCs as well if I could find a ZxSpectrum that 
still worked to read the program off the cassette tape.


My computing needs have grown somewhat since then. 



You are not programming in APL, are you?

That is the only programming language I know, that does not use either ASCII or 
EBCDIC.

The modern, not so algorithmic languages like lisp or prolog do rely on ASCII 
or EBCDIC.
They cannot use wordstar or word documents. I tried it only once in old MSDOS 
times :)


Cheers
Peter

--
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Peter Dambier]

Clement Cherlin wrote:

On 6/17/06, Eliot Lear <[EMAIL PROTECTED]> wrote:



I do think that ASCII art has its limits, particularly when it comes to
mathematics.  But I think a more gradual evolution is called for in this
case, with more consideration given to not only the normative issue but
all the others Joel raised.

Eliot



I believe one gradual approach that hasn't been discussed is using
Unicode instead of ASCII.  Many of the problems of representing
mathematics and diagrams could be resolved that way, while still
retaining the compatibility and portability advantages of plain text.
The majority of the solutions I've seen proposed would end up using
Unicode as their base character set, so why not cut out the elaborate
markup languages and use Unicode directly?

I just whipped up some sample fixed-width Unicode art, to illustrate
the possibilities:

Unicode Math

   __
-b±?b²-4ac
??
   2a



The Math I could see, except for the divider line, Iguess.



Unicode Box Drawing

??
? This is a box  ?
??
?With another box?
?   underneath   ?
??



There were no boxes but a peculiar line below.








How about Tex?

It is as old as the internet and you can use vi to read and edit.
You still can use grep to scan all old documents to find something.

ASCII has its limits, yes.

All the alternatives mentioned are even more limited.
Except EBCDIC of course :)

I dont mind getting something new - if somebody else pays for it :)
But I dont like to lose something I need.

--
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Why not PDF: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Peter Dambier]

Just try this good example:

http://www.nasa.gov/pdf/133654main_ESAS_charts.pdf

It is a nice promotion for the successor to the space shuttle.
Best store it localy before viewing.

It is a nice document with wonderful pictures. But building
the screens takes me hours.

That is one of the reasons why I am afraid of pdf.


Cheers
Peter and Karin Dambier

Yaakov Stein wrote:
 


Because it's sufficient to generate the ASCII version once on


publication and then keep it. 


Keeping the source is essential for completely separate tasks (meta


data extraction, document revision, generating other formats such as
HTML or PDF).

You are using "the ASCII version" as a proxy for a printed page 
(and as I once complained, it is not a faithful proxy on all platforms).

However, the problems we wanted to solve were precisely those where
ASCII
is not sufficient, namely graphics and equations, and so we need
to return to the printed page as the final word.



So far the IETF hasn't done that. The format is ASCII.



See above.



One good reason to use a specific XML grammar is that when the only


thing that's available is a presentation-oriented format 


(such as Word or PDF), it gets *much* harder to do meaningful things


with the source. 

You are making assumptions about presentation formats.  
It is quite easy to do meaningful manipulations on TeX source.




And that's one of the reasons why volunteers maintain xml2rfc (both


the format itself and various implementations). 


And here is precisely where we are expending efforts.
I too enjoy coding, but why are we recreating for the XML2RFC
environment
mechanisms that exist in available tools?

The zenith of these efforts is a script to extract TeX-style math
expressions, run TeX on each separately, 
create images, and then embed them into a PDF created from the xml.

... and all that just to avoid using TeX.

Y(J)S




--
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: IETF Chair tasks

[Peter Dambier]

Lyndon Nerenberg wrote:


On Jul 8, 2006, at 12:27 PM, Barry Leiba wrote:


I'm not completely convinced that beer is the appropriate choice
in Montreal



La Fin du Monde... or anything else by Unibroue.



Just don't try ordering a Molson Canadian :-P



You can try La Militante. Karin and me have never tasted it but
we have been told it is blue or makes you get a blue nose or
something.

Just to know, this is a parody of the Molson Song :)

http://www.neuvel.net/Audio%20files/iamnotcanadian.mp3

and somewhere here you might find the written text.

http://forums.plentyoffish.com/1227125datingPostpage2.aspx


One thing we have found out the hard way, be careful with non french
speaking taxidrivers. If you are speaking french and they are speaking
french then you are lucky. They are really amiable.

But if you are speaking french and they are not - whe where given
economy lessens in indian (like Bombay, not red indian) how the
price is calculated. Take the price of the beer plus the time of the
day. Add canada tax. Add québec tax to the sum. Now calculate and add
the tip. Add the monthly rate for the taxi and add canada tax and
québec tax again ...

But nevertheless the hanglish speaking taxidriver was very polite too :)


Cheers
Peter and Karin

--
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/


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

Re: IANA XML registries

[Peter Dambier]

Just as an idea, China has a single ccTLD '.CN'.

I can see them experimenting with three others

Status China Root

soa("XN--55QX5D.","2006092104","CDNS3.CNNIC.NET.CN","210.52.214.86").
soa("XN--55QX5D.","2006092104","CDNS4.CNNIC.NET.CN","61.145.114.120").
soa("XN--55QX5D.","2006092104","CDNS5.CNNIC.NET.CN","61.139.76.55").
soa("XN--55QX5D.","2006092104","HAWK2.CNNIC.NET.CN","159.226.6.185").

soa("XN--FIQS8S.","2006092104","CDNS3.CNNIC.NET.CN","210.52.214.86").
soa("XN--FIQS8S.","2006092103","CDNS4.CNNIC.NET.CN","61.145.114.120").
soa("XN--FIQS8S.","2006092104","CDNS5.CNNIC.NET.CN","61.139.76.55").
soa("XN--FIQS8S.","2006092104","HAWK2.CNNIC.NET.CN","159.226.6.185").

soa("XN--IO0A7I.","2006092104","CDNS3.CNNIC.NET.CN","210.52.214.86").
soa("XN--IO0A7I.","2006092104","CDNS4.CNNIC.NET.CN","61.145.114.120").
soa("XN--IO0A7I.","2006092104","CDNS5.CNNIC.NET.CN","61.139.76.55").
soa("XN--IO0A7I.","2006092104","HAWK2.CNNIC.NET.CN","159.226.6.185").


To enable the chinese views, all I had to do was adding three stub
zones in my Bind 9.4.0b2 named.conf file and I could use them.

We have put them into the Cesidian Root and I know other Racines Libres
are doing the same.

I must admit this is not XML yet, but I am shure it would work with
XML just the same.


Kind regards
Peter and Karin Dambier


JFC Morfin wrote:

At 20:38 20/09/2006, David Conrad wrote:
 >The implication of this is that the entire registry would need to be
 >fetched, right?  Given I'm told the registry under discussion is a
 >bit on the large-ish size, this might be somewhat problematic.  Can
 >you give me an idea of the anticipated scale of the number of
 >applications that will be wanting to fetch this registry?

David,
let think in terms of network for once (IETF is about networking).
You have currently 500 millions users. I think a conservative figure
for the ten years to come we discuss, is a Multilingual Internet is 2
billions CPU. These CPU must be able to check if they are up to date,
on a regular basis. Best practice would be at connect time and once 
every day.


The IETF registry adds complexity (extlangs, comments, changes) on
top of the ISO 639 series. The ISO 639-3 7,500 items table will not
be printed because it will be constantly maintained (please, Peter,
can you comment). This will be the same (and probably more ) for the
ISO 639-6 tables which may range in between 15 and 30.000 items
(please, Debbie, can you comment). Peter commented that one or
several updates a week is most probable.

This means an updating scheme comparable to a DNS root system with
40.000 TLDs. You probably have the figures of the rs.internic.org to
compare with, plus the access to the RSSAC root servers. Except that
the root file is 65 K and we talk of a file probably 100 to 10,000
larger. And that the root file is supported by the DNS protocol (the
root servers are only occasionally called upon by users - in case of
a TLD typo or when their ISP nameserver has not yet/no more
information on a called TLD).

Fetching the file would be like carrying an axfr of the root or an
FTP access to rs.internic.org. A DNS like protocol I proposed in vain
could permit to decrease, organise, and distribute that load.
Langtags are probably like TLDs: some will never be queried in some
geographic areas. Many will have a very long TTL (reasonably
equivalent to root real life TTL). But many reasons may call for a
shorter system TTL.

Obviously caching the registry at the user end would help a lot (each
user would probably need a limited number of languages to be
documented [those in his filters and those in his relational area].
The others representing pollution to him.

However, this must be considered in an interoperable context with
other language codes. RFC 4646 does not care about interoperability,
but "x-tags" are enough constrained to permit to build a partial
strategy based upon 8 alphanum tags + signature.

These private tags will need to be verified and validated the same.
Either you support them and queries go to you and your mirrors. Or
you don't and necessarily queries will go to private resolvers (much
like for the DNS root, so an equivalent top system load). I initially
explained that langtags had to document referents to be of interest
to computers and extended services (to the content). Now, a simple
format for private langtags can be x-8 alphas (three for languages, 2
for script, 2 for country, one by referent in that context - 36
possibilities is large enough until RFC 4646ter which will adapt) - a
langtag private library signature. The size of the central registry
will be quite large with more information. But the checking traffic
can be limited to a warning on changes through the distribution of a
regex of the 8 alpha change and a compacted date. This means 12
alphanum per change announcement. This may mean a 100 to 2000 chars
message a day at login time, obtained by the ISP from the IANA. This
information could even be added at the root footer, sinc

Re: Something better than DNS?

[Peter Dambier]

DNS is broken since people started disallowing AXFR transfers.

DNS is no longer about publishing information about hostnames and numbers
but about keeping this information a seecret.

So not using DNS at all and distributing host files is much better than
DNS and more reliable :)

On the other hand, in good old /etc/hosts days you could always reverse
query and get all aliases to every ip address. E.g. NIS still works like
that. And NIS has mostly the same bells and whistles DNS has, like MX
records and unimaginable additional record types.

In addition DNS is designed with a single one root scope. So if you
have to deal with chinese, arab and russian namespaces then DNS probably
is not the right choice :)

If ISPs were not starting to block port 53 DNS the I would guess somebody
will come up with a totally new idea and implement this using the port
53 DNS interface but even bonjour/rendezvous work with a port different
from 53.


Kind regards
Peter and Karin


Pekka Savola wrote:

On Tue, 21 Nov 2006, Keith Moore wrote:

p.s. rather than adding more and more burdens to DNS, what we really 
need to be doing is figuring out how to replace it with something more 
robust and more flexible.  (Yes, you'd have to arrange that DNS 
queries and queries to the new database would return consistent 
results; you'd also have to make sure that DNSSEC didn't break, but 
those are both doable.)


DNS is getting very long in the tooth, and is entirely too inflexible 
and too fragile.  The very fact that we're having a discussion about 
whether it makes more sense to add a new RR type or use TXT records 
with DKIM is a clear indicator that something seriously is wrong with 
DNS. Adding a new RR type should not require a single line of DNS 
server or client library code to be recompiled, nor any changes to the 
configuration of any server not advertising such records.



Keith,

I've seen you say this for many years now, but I'll bite now.
Do you have ideas what a more flexible, less fragile, and in general a 
better mechanism would:


 1) be or look like, or

 2) what requirements we should have for building and deploying it?
(if such a thing or a close likeness doesn't exist)

I wonder if there are practical alternatives.  A bit more dialogue on 
"what else" instead of "DNS is a bad idea" might help in figuring out 
whether there is anything the IETF could do about it.





--
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Von-Erthal-Strasse 4
D-64646 Heppenheim
+49(6209)795-816 (Telekom)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
http://www.cesidianroot.com/


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

Re: do it yourself roots, was Something better than DNS?

[Peter Dambier]

John Levine wrote:

If they can suck down all the top level zone files then it is easy
for them to publish an ALTERNATIVE DNS VIEW that contains their own
additions. Anyone who uses their view will then see the so-called
official DNS info as well as the overlay.



When I see claims like this, I really have to wonder how well people
understand the way that the DNS works.  If you want to publish your
own root that merges the real root (the one that the A through M root
servers publish with advice from ICANN) with stuff of your own, you
can do it now, and it wouldn't make any practical difference if you
could AXFR every zone in the world.

If you want to add your own TLDs, the easiest way to do it is to FTP
the root zone, which is easy and quite legal to get, add in your own
TLDs, and try and persuade people to use your servers.  The root zone
changes slowly, so downloading and remixing your root once a day would
be plenty.


...
 >

The real reason that alternate roots haven't caught on is that there
is no demand for them from the people who use the DNS.  (There's
plenty of demand from people who imagine they would get rich if they
could own .WEB or .SEX or whatever, but that's irrelevant.)  For all
of the failings of the current roots and of ICANN, with which as a
member of the ICANN ALAC I am extremely familiar, it works well enough
for the things that people use it for, and that shows no sign of
changing despite occasional efforts to screw it up like wildcards in
TLD zones.



John, there is demand for it.

To find out why, look at these domains:

Status China Root

soa("XN--55QX5D.","2006112704","CDNS3.CNNIC.NET.CN","210.52.214.86").
soa("XN--55QX5D.","2006112704","CDNS4.CNNIC.NET.CN","61.145.114.120").
soa("XN--55QX5D.","2006112704","CDNS5.CNNIC.NET.CN","61.139.76.55").
soa("XN--55QX5D.","2006112704","HAWK2.CNNIC.NET.CN","159.226.6.185").

soa("XN--FIQS8S.","2006112704","CDNS3.CNNIC.NET.CN","210.52.214.86").
soa("XN--FIQS8S.","2006112704","CDNS4.CNNIC.NET.CN","61.145.114.120").
soa("XN--FIQS8S.","2006112704","CDNS5.CNNIC.NET.CN","61.139.76.55").
soa("XN--FIQS8S.","2006112704","HAWK2.CNNIC.NET.CN","159.226.6.185").

soa("XN--IO0A7I.","2006112704","CDNS3.CNNIC.NET.CN","210.52.214.86").
soa("XN--IO0A7I.","2006112704","CDNS4.CNNIC.NET.CN","61.145.114.120").
soa("XN--IO0A7I.","2006112704","CDNS5.CNNIC.NET.CN","61.139.76.55").
soa("XN--IO0A7I.","2006112704","HAWK2.CNNIC.NET.CN","159.226.6.185").

Status Arab Root

soa("XN--IGBHZH7GPA.","12","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--LGBBAT1AD8J.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--MGB2DDES.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--MGBA3A5AZCI.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--MGBA5B5CCEU.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--MGBAH1A3HJKRD.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--MGBAXP8FPL.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--MGBB7FJB.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--MGBB7FYAB.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--MGBC0A9AZCG.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--MGBCPQ6GPA1A.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--MGBERP4A5D4AR.","2006111409","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--MGBG8EDVM.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--MGBU4CHG.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--NGBEE7IID.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--WGBL6A.","5","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--YGBI2AMMX.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").

soa("XN--MGBAAM7A8H.","12652","NS1.UAENIC.AE","213.42.0.226").
soa("XN--MGBAAM7A8H.","12652","NS2.UAENIC.AE","195.229.0.186").

soa("XN--PGBS0DH.","2005062700","NS.ATI.TN","193.95.66.10").
soa("XN--PGBS0DH.","2005062700","NS2.ATI.TN","193.95.67.22").

Status I-DNS.NET

soa("XN--3RC8E2BB9H.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--81B8B9A9C.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--C1AVG.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--E1APQ.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--G2B9A1A.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--I1B6B7E.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--J1AEF.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--P1AG.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--P1AI.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--QLC9A5A.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--USC8B9A.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--USCN1BV9BH3H.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--VF4B131B.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--ZB0BNW.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--ZV4B74Y.","2006112608","NSA.I-DNS.NET","64.62.142.131").

Those people dont talk english and they dont use latin keyboerds.
That is why you never heard of them.


Kind regards
Peter and Karin

--
Peter and Karin Dambier
Cesidian Root - Radice C

IPv6: Do you want to have more meetings outside US ?

[Peter Dambier]

Stewart Bryant wrote:


Do we have any firm evidence that we would get more work
done if we had more meetings outside the US?

Stewart



Is there any IPv6 activity inside the US?
Or multilingual namespace?

Kind regards
Peter and Karin

--
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
http://www.cesidianroot.com/


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

Re: I-D ACTION:draft-wilson-class-e-00.txt

[Peter Dambier]

Brian E Carpenter wrote:

On 2007-08-07 16:15, [EMAIL PROTECTED] wrote:

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.



Title: Redesignation of 240/4 from 'Future Use" to 
"Limited Use for Large Private Internets'

Author(s): P. Wilson, et al.
Filename: draft-wilson-class-e-00.txt
Pages: 4
Date: 2007-8-7

   This document directs the IANA to designate the block of IPv4

   addresses from 240.0.0.0 to 255.255.255.255 (240.0.0.0/4) as unicast
   address space for limited use in large private Internets.



It seems to me that we first need a discussion about why this space can't
be released as public address space. Is it known to be already deployed
as de facto private space?

I'd be a bit nervous about unintended side effects if
DHCP assigned me 255.255.255.255/32.

Brian

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


I remember trying it. I wanted to clandestinely communicate between
linklocal boxes. I could use it with Unifix linux 2.0 and kernel 2.0.48

I did not find any other operating system, not even linux, who could
use it.

I did not find any hardware except nonmanaged switches who could use it.

I tried to "fix" the tcp/ip stack of a more modern linux. Sideffects.
I did not get it working. To many places in the software.


Kind regards
Peter and Karin Dambier


--
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
http://www.cesidianroot.com/


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

Re: IPv6 addresses really are scarce after all

[Peter Dambier]

Arnt Gulbrandsen wrote:

Hallam-Baker, Phillip writes:

I don't see how such an architectural limitation can be enforced. 
There is no way that the IETF can prevent an ISP issuing IPv6 
customers a /128 if they choose.



Not directly, but there's the indirect route: a) IETF designs IPv6 
autoconfiguration. b) Linksys, D-Link, Netgear and friends make boxes 
that support autoconfiguration. c) ISP hand out /128s. d) 
Autoconfiguration doesn't work well. e) Customers call ISP support. f) 
ISP loses $$$. g) ISP starts issuing /48s instead.


I don't know the first thing about how IPv6 autoconfiguration works. It 
worked very well in my previous office. Will it work better when the 
router has a /48 at hand than a /64 or /128?


Arnt

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


I remember working with my own little  lan:

three Site Local and one tunnel networks.

radvd or SuSE 7.1 and SuSE 8.2 did expect /64

The tunnel would either give me a /64 without local router
or a /48 if I had a local router.


Today Site Local is given up. So I changed to 192.168...
addresses with 6to4 addressing.


RFC 2462 says we normally have EUI-64 addressing that is
either a funtion of the MAC address or a random number.
With EUI-64 (64 bits) the prefix must be /64 for an
autoconfigured network segment.


The tunnel used to be a /124 network segment
overlapping my /64 with ..0 the net, ..1 the other
end of the tunnel, ..2 me and ..3 broadcast.

Theoretically ..2 would have been a router for anything
in my /64, but that never worked. So practically I
ended up with a /128


If you have a LAN with servers you need predictable
addresses for your servers. Renumbering is not an
option. Site Local does not exist any longer. 182.168..
with 6to4 addressing is the only way I see. But
that means - no autoconfiguration.

Without autoconfiguration /124 and NAT is good enough
for me. But how about my aunt with her laptop?


Kind regards
Peter and Karin


--
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
http://www.cesidianroot.com/


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

Re: Representation of end-users at the IETF (Was: mini-cores (was Re: ULA-C)

[Peter Dambier]

Interesting discussion.

I am envolved in two groups develloping around OpenWRT.

One group (some 2000 members) is trying to TORify a < dollar 150 router
the other group (some 30 members) is trying to IPv6 that very same
software. I dont know how big the OpenWRT devellopers group is.

They are end-users, all of them.

They use a large range of hardware that mostly has its own unuseable
software.

e.g. dtag.de // t-online.de

they use a branded AVM router with outdated software and a backdoor
to remotely manage the box. I dont know if they really manage - but
I can see they have disabled port 8085 just in case.

AVM is as famous for routers in germany as Mircrosoft is for PCs.
I dont mean the pubo-coccygeus muscle :)

AVM software seems to be better but the brands see no maintainance.

Our gouvernement is very hot on talking about poisoning every router
and every PC to listen into our VPNs and local harddisks. So nobody
who has got a brain wants to rely on the original software.

I guess it is a good idea to get those end-users envolved.

Cheers
Peter and Karin

--
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
http://www.cesidianroot.com/


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

Sorry double post: Representation of end-users at the IETF

[Peter Dambier]

Sorry for the double post.

My mailer either sends it double - or nothing at all :(



Cheers
Peter and Karin




--
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
http://www.cesidianroot.com/


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

Re: Representation of end-users at the IETF (Was: mini-cores (was Re: ULA-C)

[Peter Dambier]

Daniel Senie wrote:

At 04:18 AM 9/20/2007, you wrote:


Interesting discussion.

I am envolved in two groups develloping around OpenWRT.

One group (some 2000 members) is trying to TORify a < dollar 150 router
the other group (some 30 members) is trying to IPv6 that very same
software. I dont know how big the OpenWRT devellopers group is.

They are end-users, all of them.



End users? Interesting. Though I've been in the software, systems and 
networking business for 25 years, I don't know what "TORify" means. Step 
back and look around. Getting more of us geeks providing "end user" 
feedback is not functional. That's how we get to having cameras, cell 
phones and most other electronics with user interfaces that non-geeks 
can't understand.


TOR is "The Onion Router".

The people are afraid of the gouvernement spying on them, that is why
everybody is talking about anonymisation tools. Some people do provide
them for free.



We are not good models of the term "end user."




I guess you are right :)

Cheers
Peter and Karin

--
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
http://www.cesidianroot.com/



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

Re: Representation of end-users at the IETF (Was: mini-cores (was Re: ULA-C)

[Peter Dambier]

Daniel Senie wrote:

At 04:18 AM 9/20/2007, you wrote:


Interesting discussion.

I am envolved in two groups develloping around OpenWRT.

One group (some 2000 members) is trying to TORify a < dollar 150 router
the other group (some 30 members) is trying to IPv6 that very same
software. I dont know how big the OpenWRT devellopers group is.

They are end-users, all of them.



End users? Interesting. Though I've been in the software, systems and 
networking business for 25 years, I don't know what "TORify" means. Step 
back and look around. Getting more of us geeks providing "end user" 
feedback is not functional. That's how we get to having cameras, cell 
phones and most other electronics with user interfaces that non-geeks 
can't understand.


TOR is "The Onion Router".

The people are afraid of the gouvernement spying on them, that is why
everybody is talking about anonymisation tools. Some people do provide
them for free.



We are not good models of the term "end user."




I guess you are right :)

Cheers
Peter and Karin

--
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
http://www.cesidianroot.com/



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

Re: I18n of email addresses (Was: Representation of end-users at the IETF (Was: mini-cores (was Re: ULA-C)

[Peter Dambier]

How about

http://xn--8pru44h.xn--55qx5d/

and their email can be found:

; <<>> DiG 9.4.0b4 <<>> -t any xn--8pru44h.xn--55qx5d @ns5.ce.net.cn.
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59227
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;xn--8pru44h.xn--55qx5d.IN  ANY

;; ANSWER SECTION:
xn--8pru44h.xn--55qx5d. 1800IN  A   210.51.169.151
xn--8pru44h.xn--55qx5d. 1800IN  NS  ns5.ce.net.cn.
xn--8pru44h.xn--55qx5d. 1800IN  MX  10 mail.xn--8pRu44H.xn--55Qx5D.
xn--8pru44h.xn--55qx5d. 1800IN  SOA ns5.ce.net.cn. tech.ce.net.cn. 
2004072009 3600 900 1209600 1800

;; ADDITIONAL SECTION:
mail.xn--8pRu44H.xn--55Qx5D. 1800 INA   211.157.122.194

;; Query time: 405 msec
;; SERVER: 210.51.171.200#53(210.51.171.200)
;; WHEN: Thu Sep 20 23:18:00 2007
;; MSG SIZE  rcvd: 196


I remember exchanging emails with them at least once.

Standard Thunderbird, Linux.
Mailer exim 4.0
Bind 9.4.0

I remember it worked with djbdns too.

No, I did not have a language tag.

There were no tricks besides using the Cesidian Root for DNS.
I guess the chinese used their native root.


Kind regards
Peter and Karin



Stephane Bortzmeyer wrote:

On Thu, Sep 20, 2007 at 04:13:01PM +0100,
 [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote 
 a message of 49 lines which said:




In fact, it may be necessary to attach a language tag (defined in
RFC 4646 and 4647) to these addresses in order to make this fully
possible.



That would be a very bad idea. Email deals with scripts, not with
languages. What language should be attached to my name? (I'm french
but my name is german.) And to coca-cola.com?



I'm sure that many people are working on this problem,



Sure, specially in the Far East, demos of I18N software for email are
common but all use non-standard tricks, they do not interoperate and
they do not fallback gracefully when encountering an old email
gateway.

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



--
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
http://www.cesidianroot.com/


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

Re: IPv6 will never fly: ARIN continues to kill it

[Peter Dambier]

Noel Chiappa wrote:

> From: Keith Moore <[EMAIL PROTECTED]>

> any relief for the Internet before IPv4 space is exhausted.

I am so tired of this "when IPv4 space runs out, civilization will fall"
vibe. I'm almost ready to suggest that we just hand out all the remaining
IPv4 address space today, now, just to get it over with - and to show that
life will continue, people will adapt.

Noel



Just in case -

IPX will survive.

IPX has just as many networks as IPv4 has hosts plus
IPX has 64 K as many hosts as IPv4 has.

IPX has proved to be a woking protocol, it can route,
it exists and every major operating system can use it.

IPX over IPv4 is existing as well as IPv4 over IPX.

So they can coexist and internetwork.


I dont know what happened to ISO?
ISODE 8 is still hidden somewhere in the wild internet.
It is still working although knowbody nows how to configure.
It reminds me of SNA.


SNA is plug and play!

Just plug in your applications and links and play
until it is working.


The internet as we have it was never meant to be.
Every gouvernement is happy it comes to an end.
That is why nowbody wants IPv6.

We have more than enough IPv4 addresses for the USA.
We have more than enough IPv4 addresses for China.

Neither the USA nor China want to share a common
internet with the rest of the world.


If there was not that silly old telephone!

We could still live with telephone and modems if
telephone had not moved to IPv4 VoIP.

I guess it is internal mostly. So we can NAT the
phone and everything else.

Lets move Google and CNN to rfc 1918 address space
and give the rest to national end-users.


Have a nice weekend
Peter and Karin

--
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
http://www.cesidianroot.com/


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

Re: Patents can be for good, not only evil

[Peter Dambier]

There are 2 people who own every right on computers

http://en.wikipedia.org/wiki/Charles_Babbage

and programming

http://www.agnesscott.edu/Lriddle/women/love.htm

All patents therafter are infringements of the work of
these two people.

Well even those two people built on the work of other people.


Kind regards
Peter and Karin Dambier


Steven M. Bellovin wrote:

On Mon, 29 Oct 2007 16:02:10 -0700
"Lawrence Rosen" <[EMAIL PROTECTED]> wrote:



Eric Burger wrote:


I specifically applied for patents underlying the technology behind
RFC 4722/RFC 5022 and RFC 4730 specifically to prevent third
parties, who are not part of the IETF process, from extracting
royalties from someone who implements MSCML or KPML.  


That was a waste of your time and money. Publication of those
inventions by you, at zero cost to you and others, would have been
sufficient to prevent someone else from trying to patent them. Next
time, get good advice from a patent lawyer on how to achieve your
goals without paying for a patent.




You're obviously right in theory on this point.  I wonder whether
you're right in practice.  We've all seen far too many really bad
patents issued, ones where prior art is legion.  The (U.S.) patent
office seems to do a far better job of searching its own databases than
it does the technical literature.

I know there are many philosophical reasons why many people oppose
software patents.  But for others, there are very practical reasons:
there are too many bad patents issued.  I think we can all agree that
stopping bad patents is a worthwhile goal, even if for some it's just
an intermediate goal.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

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



--
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
http://www.cesidianroot.com/


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

Re: AutoCAD file transfer over WAN

[Peter Dambier]

The digital signature as a mens to check integrity of the file,
same as the signature in emails.

Disabling the digital signature brings the risk of corrupted files.

Kind regards
Peter

symonds thompson wrote:
> Hi ,
> Ever since our company has located servers at remote locations, I am
> experiencing a lot of problems while opening/closing/saving AutoCAD
> files. After the "upgradation" to a WAN optimizer, I have had to deal
> with significant delay/lag in opening/saving and transferring DWG files.
> I searched net, and the only recommendation I could find was to disable
> AutoCAD's digital signature. How do I disable AutoCAD's digital
> signature?Are there any repercussions or drawbacks in doing this?
> 
> Any help would be greatly appreciated.
> 

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [EMAIL PROTECTED]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
http://www.cesidianroot.com/
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf