ugh.
We regret that we could not arrange better terms for you.
We do appreciate your effort.
Usually, free network access (Hotel one or not) was shutdown
at noon of Friday, which was inconvenient for some foreigners,
for example for those having Saturday flights.
Masataka Ohta
for a very good IETF
network.
I fully agree with you here, except that I also thank you. :-)
Masataka Ohta
Mark Smith;
> I'll continue reading, although I'm happy enough that my original
> understanding was correct.
Let's agree that you are as correct as PMTUD.
If you have further comments, do so offline.
; for PMTUD.
Read the RFC.
It says "To detect increases in a path's PMTU, a host periodically
increases its assumed PMTU".
Masataka Ohta
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
gt;>unreliable.
>>Can you tell me who said it with an appropriate reference?
> Err, _you_ said it:
I never said software unreliable.
Note that an example of unreliable software is Windows.
Masataka Ohta
__
Mark Smith;
> I'm keen to
> find out if my understanding of PMTUD purpose and operation is
> incorrect.
Read the RFC or my quotation of it.
Masataka Ohta
___
Ietf mailing list
[EMAIL PR
puters are, as
expected long ago, massively parallel ones to be able to
process a lot of interrupts without much performance loss.
Masataka Ohta
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
t I have heard that path mtu discovery software was
> unreliable.
PMTUD software is unreliable!?
Then, it is anther reason to avoid it.
Can you tell me who said it with an appropriate reference?
Masataka Ohta
ans that even under
extreme conditions rational operators won't turn on PMTUD.
In short, forget PMTUD.
Masataka Ohta
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
PMTUD is a broken concept.
Masataka Ohta
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
ed to look into TCP options,
they are likely to interoperate even with complex TCP options.
Masataka Ohta
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
Hadmut Danisch wrote:
> Is there any? If not, shouldn't there be one?
> E.g. as an RFC?
Here is an old Internet Draft, which IESG at that time refused
to make it RFC, because some wanted to call NAT providers ISPs.
Masataka Ohta
--
INT
rminology within IETF.
There are a lot of IETF standard track documents of little value
ignored by service providers and vendors. So, don't bother.
Masataka Ohta
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
orcing people within IETF
use your terminology even though you are fully aware that
"some members of the IETF community that some of these
connectively models are simply "broken" or "not really an
Internet service"".
users have no chance to know the
differences of the taxonomy.
Masataka Ohta
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
ou receive IP telephony call on your laptop?
Masataka Ohta
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
t service for room 1234 from Web Connectivity to
> Full Internet Connectivity."
And the hotel operator will say "Sure, you can now access all the
Web pages including those containing adalt contents".
Masataka Ohta
n NAT, you lose a lot of business chances.
I can proudly say that I helped the commercial company above get
global IPv4 addresses enough for millions of subscribers, which
was essential for their aggressive service.
The reality of life is that there are successful ISPs and there
are poo
r ISDN. :-|
IETF can not stop them claiming Internet capable.
So, let's call all the telephone companies ISPs.
Smart users can, just like having VPN servers, have modems at
home to establish dial-up connection to the Internet from
any PSTN telephone in the world.
Providers?
Masataka Ohta
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
e-base categories:
I think the difference is not on time-base but on who has the control
to choose the telecommunication service.
In John's cases seemingly, Hotels has the control.
Masataka Ohta
orcing people within IETF
use your terminology even though you are fully aware that
"some members of the IETF community that some of these
connectively models are simply "broken" or "not really an
Internet service"".
Tony Hain wrote:
> There is technical
> content, but no business content and the service providers are ignoring it
> as a waste of time.
So, it's almost identical to IPv6.
ardization of these options.
Multicast packets to RVP/Core are even more harmful.
Masataka Ohta
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
2.
As a result, IPv6 won't stably run over WLAN, multicast over which
has characteristics much different from wired Ether.
Masataka Ohta
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.o
ember asking about MIP :)
It's complimentary, as someone mentioned wrong reasoning of NAT.
Masataka Ohta
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
y basic reason to have
"adaptation", is a total failure.
It should be noted that MIPv6 is hopelessly tainted by ND.
Masataka Ohta
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
Michael Thomas wrote:
> I think that this begs the question of where the
> larger problem lies: while IP can run over pigeons,
> bailing wire and quite possibly chewing gum,
Both of IPs themselves can. ND can not.
Masa
ions.
> Since Ohta-san mentioned MIPv6 here, the router becomes the most
> relevant peer for neighbour discovery.
Such approach works if terminals moves very slowly, which
is unlikely the case with MIPv6.
Isn't it more productive than beating the dead horse?
If reasons are recognized, it will be useful information to
design alternatives, maybe by alternative standardization
bodies.
Masataka Ohta
___
n not be
controlled today.
Masataka Ohta
PS
I am promoting broadcast with several ISPs in Japan and knows how
they are operating.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
l the
users.
However, blank minded people thought Unicode were a good idea.
You are obserbing the inevitable consequances.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
than the 'C' shape.
> And when I explained my co-worker what was going on, he also wanted
> to see the punycode.
It means that you can do with GIF images and ASCII URLs without
false internationalization by Unicode.
However, I can also argue that TCP congestion control mechanisms
for best effort traffic has little to do with QoS assured
communication.
Masataka Ohta
PS
The fundamental problem is that management framework to have been
making IETF products less
Bob Braden wrote:
> Such decisions must be made very, very
> carefully, with considerable care and not a little wisdom.
That's the problem.
Take it easy.
Masataka Ohta
___
Ietf mailing list
Ie
re good enough.
Either (or both) the guidelines defined by the current process
or the management entities chosen through the current process
are wrong.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
be successful.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
ledge on the ongoing communication.
In a sense, "end" means a system with proper knowledge and control
on the ongoing communication.
For example, as for QoS, PDP, which definitely is not "end" with
limited knowledge and control, destroyed E2E property.
oper guarantee, based on the amount of money and risk
of each transaction, PKI (including SDNS) can not be used for
serious security purposes and is merely an overly complex way
for abstract security such as just checking IP addresses
through 3 way handshake.
nce by
implementors, that is, running code, imprecise proxy of which
is IETF consensus, which means there is little point for IETF
to standardize protocols.
Masataka Ohta
PS
It turns out that both the WG and I was wrong that DNSSEC is
not at all
Steven M. Bellovin wrote:
> If you have the zone key, you can do the verification offline.
How can you update the (root?) zone key timely, upon key rollover or,
worse, accidental publication of the key?
Masataka O
ernet, you are wrong.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
complex. In those
>> cases the design choice is where you put the complexity.
> This, however, is right on target.
In theory, maybe.
However, I have never seen such a design choice necessary
for network protocols.
We don't need 3GPP for the mobile int
a constraint that limits the clarity of expression.
It's good that protocols needing more than 72 ASCII characters
are forbidden.
For examples, see NGN diagrams.
For further improvement to forbid the work round, it is good if
RFCs more than 20 pages long are disallowed.
Stewart Bryant wrote:
> Which results in protocol definitions that are choped up into so
> many parts that no one can see how to put then back together.
That's fine.
Masataka Ohta
___
I
force much simpler protocols.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
. A better way is to make the document short.
Anyway, you are saying figures are not critical part of the document,
aren't you?
If so, just use diff.
Masataka Ohta
___
Ietf mailing list
I
5 languages) either.
ASCII art is not in English.
ASCII art involves no translation issues.
We can use ASCII art anywhere in the world, just as we can use ASCII
based computer languages (such as C) anywhere in the world.
Remember that trigraphs are not used.
Henning Schulzrinne wrote:
> This format is the long-term archival format, as it
> seems highly unlikely that the world will suddenly forget how to
> interpret XML in any timeframe we care about.
Can you say TeX?
Masa
tupidity that you can't recognize peoples' names correctly
represented in ASCII.
See how widely non-ASCII domain names and mail addresses are used.
However, if you insist, you may use ASCII art.
eople MUST be
spelled with characters recognized by all the international
participants, which means ASCII is the only choice.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/ma
.
ASCII is not English.
A charset is not tied to some content language.
For exmaple, the line below is in Japanese language spelled in ASCII.
Uso ha yasumi yasumi tsuke.
Masataka Ohta
___
IETF but ISO.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
rated into Japanese local characters. In either case,
we don't need Unicode. Note that major charsets used in Japan
are ISO-2022-JP, EUC-JP, Shift JIS but definitely not any variant
of Unicode.
So, for localized RFCs, that is, translated RFCs, local character
sets, which are
y where?.
Then, ISO 2022 is a lot more than enough.
On the other hand, with ISO 10646, I can't print Japanese characters
in China.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Doug Ewell wrote:
> Masataka Ohta wrote:
"at"? "dot"?
>> On the other hand, with ISO 10646, I can't print Japanese characters
>> in China.
> since most computers sold all over the world now
> come with at least one perfectly good Unicode-based
t attribution to me.
> Characters and glyphs are not the same thing.
Tweaking definitions on "Characters" does not change the
reality. PERIOD.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
onality in more complicated manner, it
involves nesting, which makes searching practically impossible
(it takes time proportional to the third power of length of
string being searched).
Masataka Ohta
___
Ie
e Unicode is no better and the
existing local schemes are more efficient.
There is no point to some form of local version of Unicode, as we
must specify which local version we are using. RFC1815 gives
examples of such local versions.
make text processing complex for any good
purpose.
> Anyone who wants to know what RFC 3066bis is really about is invited to
> read it themselves:
> http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-14.txt
It is as bad as 3066.
erpret UTF-8 ASCII.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
unilateral.
Wrong. First, RFC 3066bis has nothing to do with the
internationalization. Second, it has nothing to do with
the culture.
It, of course, has nothing to do with engineering.
It is purely political.
nd thin content of
the IDs.
There is no point to expand the character set only to make
the IDs illegible in most international environment and,
even if some environment support it, by most international
people.
Masataka Ohta
__
lvable.
OTOH, if you start from scratch, you can have encoding with
a lot shorter term and finite states.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
, your statement: "I have written a whole bunch of mission-
critical code that reads and generates UTF-8" is untrustworthy.
Of course, it is perfectly reasonable for an implementation to
declare a limitation, for example, that it will not process
non-ASCII characters, which may also be the
won't make similar mistakes.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
a
precedent by publishing RFC1347.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
nd often required, for example, for DNS and SMTP
clients.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
reduce
the number of the global routing table entries.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
nly interested
> in the standards work simply ignored the -interest list.
They ignored the -interest list and the technology.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
standards work simply ignored the -interest list.
>> They ignored the -interest list and the technology.
> Are you referring to the many vendors that implemented
> it, or the many enterprises that have deployed it?
I'm referring to re
mingly doing the same thing with request ID.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
u, the statement in RFC1035 is general about UDP.
It is a bug because it is considered to be illegal not by DNS
but by UDP.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
es of any ISO 2022 based encoding are just as simple
as those of ASCII.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
plicable for most use
of RFCs including 994 and 995.
Note finally that my answer is valid only for US domestic use. Of
course, copyright issues on materials distributed world-wide through
the Internet is too complicated to be discussed here.
Masataka
gt; were strongly opposed.
There was debate. But, 8+8 was rejected without any discussion or
reasoning.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
which would be prejudicial to his honor or reputation.
That is, in most countries including US, no one can distort the
real authorship (perhaps without spontaneous consent from the
authors).
Masataka Ohta
__
that all you need is EBNF, not
XML.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
gnment Plan
No IPv4 address space should be allocated to an ISP, unless the
ISP support fully operational fully transparent IPv6 service with
at least 64K IPv6 subnets to all the end users.
Masataka Ohta
PS
Your mist
ngle application.
Thanks to IETF attempts to dictate the Internet by making IANA
registration unreasonably difficult, people began to ignore
IANA.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https
mechanism to guarantee
What, do you mean, strong security?
Given that CAs of PKI can be compromised as easily as ISPs
of the Internet, PKI is merely weakly secure as weakly as
the plain Internet.
Masataka Ohta
__
isely one example.
That's a lot more than enough.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
p of but within PKI, which is why PKI
is merely weakly secure.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
ort
of IETF security area has been wasted in vain. But that's the
reality.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
erational controls are not likely to be acceptable to network
> administrators at your average ISP.
Nor to PKI administrators near leaf where keys must be accessed
often to generate CAs.
Masataka Ohta
_
but they should increase the cost of spammers.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
... :)
How do you think about the goverment of Iraq? Even USG is not very
special.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
TF
products high.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
lly any document ought to be able
> to be published as an Informational RFC or Experimental RFC.
I do agree with the idea.
And, it was the real practice in good old days when Jon was the
RFC editor.
Masataka Ohta
__
ons,
That's why the RFC is broken.
> Really solving this means communicating
> preference values and doing reachability tests and QoS measurments,
No.
Thank you for repeated demonstrations on your so poor understanding on
the problem.
se closed IP networks,
which will be connected to the Internet through NAT or something
like that.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
http://www.ietf.org/mailman/listinfo/ietf
27;s discussions???
NWG could be replaced by IETF or ISOC, but...
Are you all assuming that individuals can not submit RFCs?
Masataka Ohta
e, against which, the Internet is
operated.
Well organized standardization body such as IETF is an intermediate
intelligent entity between end users and the Internet.
That is, according to the principle, an intermediate intelligent
entity of IETF MUST be removed.
Masataka Ohta
ould charge less to its customers. It's not bad if ISPs are
competitive and backbone bandwidth were expensive.
Masataka Ohta
s providing an
> incentive for receivers to use multicast over unicast.
Prioritization is orthogonal to uni/mulitcast issue.
Users will favour those ISPs which prioritize unicast and pay more money.
Other users may use the prioritized multicast for 1:1 communication.
Masataka Ohta
to all
the receivers that all the receivers suffer from the bandwidth loss.
Masataka Ohta
er, in general, the
condition of "loss of connectivity" varies application by application
that the multihoming must directly be controlled by application
programs.
Masataka Ohta
PS
Layering is abstraction and not indirection at all.
> Negligence.
Exactly. But, see above.
Masataka Ohta
MIME developers arrogantly assumes OSes should support file type
using MIME content type.
And poor OS developers, such as Microsoft, actually did so.
> And of course they didn't. They merely insisted that the user agent at
> either end convert to/from the local format.
The local format does support ASCII file names but have no room
to store content type.
Masataka Ohta
oice should not be regulated?
It is.
Paradoxical reguration on voice in US is a US local issue.
Masataka Ohta
1 - 100 of 574 matches
Mail list logo
