In your previous mail you wrote:
reprinting full RFCs has been permitted & encouraged ever since RFCs
were first published - the copyright on the RFCs makes that clear
=> no more since RFC 3667 which has made nothing clear for third
parties.
Thanks
[EMAIL PROTECTED]
PS: only 7.1b su
In your previous mail you wrote:
> i.e. the rights under 3667 are the same as under 2026 its just stated
> more clearly
Even if that is true, it would not change that the current copying
conditions are a problem for the free software community, and in my
opinion, consequently t
In your previous mail you wrote:
> What is your goal, here? What is it you want to do that you can't do
> because of either RFC 3667 or RFC 2026?
Eliot,
a few examples:
For IDN, I want to be able to extract the tables from RFC 3454 and use
them in my implementation
In your previous mail you wrote:
> => I can't understand why the copyright about a text is a problem
> for software when the documentation is explicitely "without
> restriction of any kind".
Where does it say this? Note that the quote I sent earlier was the
old RFC 2026 copyin
In your previous mail you wrote:
I am sorry to continue this, but I think it is valuable to have a
complete discussion in public on record of this. Especially since
Harald imply IETF hasn't been aware of this before.
=> I support you:
- as an employee of a school who could incorpor
In your previous mail you wrote:
> If you extract, say, a C header file, or an ASN.1 schema, from an RFC
> into an application, I believe that may be regard as a "derivative
> work".
see RFC 3667 Section 3.3 (a) (E)
(E) to extract, copy, publish, display, distribute,
In your previous mail you wrote:
> Could you describe why exactly IPv6 can't run on the (layer 2?) WLAN
> infrastructure?
That ND extensively, without any valid reason to do so, use
multicast, which is not acknowledged at WLAN L2, means IPv6
or its ND is unreliable over congest
In your previous mail you wrote:
Has anyone present on this list ever experienced a problem in getting a new
chunk of IP addresses from a RIR or from an ISP?
=> the administrative procedures used by RENATER, the French NREN, are
so heavy than nobody wants to follow them to get some addres
In your previous mail you wrote:
I deliberately wanted to make the poll binary, but my
assumption is that 'neither' must mainly represent that
proprietary solution. I can't imagine many people generate
I-Ds using a plain text editor,
=> why? I used a plain text editor before moving t
In your previous mail you wrote:
The IESG has approved the following document:
- 'Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) '
as a Proposed Standard
=> this document seems to go in the wrong way: pre-shared secrets
are known to be weaker than certificates
In your previous mail you wrote:
At 5:02 PM +0200 6/27/05, Francis Dupont wrote:
>pre-shared secrets
>are known to be weaker than certificates
That statement is false for many common uses of preshared secrets and
certificates. A preshared secret with even 80 b
In your previous mail you wrote:
What do other people think?
=> as an European I strongly agree!
Thanks
[EMAIL PROTECTED]
PS: the key point is "restaurants serve after 8pm"... This can be an
issue in some places in winter.
___
Ietf mailing li
In your previous mail you wrote:
The text in section 9.5 appear to me to make it permanently impossible
to incorporate portions of RFC in both free or proprietary products.
I believe that is unacceptable, and that it is counter to the needs of
many in the IETF community.
=> I
In your previous mail you wrote:
Specifically, the problem Dave encountered earlier was that the ietf mail
server was rejecting mail without reverse dns, and since the ietf mail
server and the mipassoc.org/dkim.org/bbiw.net mail servers all had ip6
addresses, and ip6 is used preferent
In your previous mail you wrote:
> There's a fairly long list of supported cards, some of which support
> 802.11a.
=> as I've currently a 12" PowerBook I'd like to find a "wordwide usable"
.11a USB dongle because:
- the only time I used an .11a card it was great!
- if enough persons are
In your previous mail you wrote:
A "Dictionary of mathematics" offers both definitions, first
what you found f(x) > f(y) for x > y. Followed by the other
definition f(x) >= f(y), where the first case would be called
"strictly monotone". I vaguely recall that "strict" (in the
Ger
In his previous mail Jari wrote:
> Maybe we can lobby for it to become the default.
+1
(I think it would be the right default, even if I agree with John
Klensin's concern.)
=> +1 too
[EMAIL PROTECTED]
___
Ietf mailing list
Ietf@iet
In your previous mail you wrote:
In any event, Alain Durand (Comcast) has just posted
an I-D with some requirements in this area. He also made a public
presentation asking for NAT+PT at the last NANOG. (I believe his
NANOG presentation is available online in PDF; it was a "ligh
In your previous mail you wrote:
Maybe reports of "the DNS is broken when you do go to pure IPv6"
=> it could be only if the solution was not known: it is enough to
set up a recursive dual-stack DNS server (with an access list to serve only
the local IPv6 as recursive servers are too easy to
In your previous mail you wrote:
The "nicest" solution that I can see is for the ISPs to transparently
proxy port 25 to their MTA. They should offer STARTTLS.
=> I don't understand the word "transparently" here (:-). If one of
my ISPs does such things, I'll sue it immediately: we have l
In your previous mail you wrote:
People, have you been reading the posts? The stubby SMTP daemon is not
an SMTP server, it is simply a program that returns the following set of
responses TO ANYTHING THAT IS PASSED TO IT.
=> IMHO it should reject SMTP connection from the beginning w
In your previous mail you wrote:
This morning I received a telephone call from Jason Cook
from an organization called ACM.
=> ICM (something like International Communications for Management)
I guess at least some of this is the broken telephone
effect from sales person to poten
In your previous mail you wrote:
Raw numbers of prefxies are pretty impressive. A IPv4 /20 is 4k "host"
addresses. An IPv6 /116 is the same sized "chunk" so, the total number of
/20s in the IPv4 world: 1024000 (stuff that into your router)
/116s in a /48 chunk:343597383
In your previous mail you wrote:
> But IP-layer interception has some fairly significant limitations
> for this application. ...
There's a technical problem with IP intercepting that I've not seen
mentioned, including in the draft. Any intercepting based on TCP or UDP
port nu
In your previous mail you wrote:
> One of the original reason that i-mode didnt go pure IP is they couldnt
> get enough IP address for it (they designed i-mode to handle 6M users
> originally) and that is quite huge for APNIC.
IPv6 has been around for quite some time now, do you
In your previous mail you wrote:
While I wouldn't go quite that far, I've been saying for years that the
IP header doesn't need any authentication if we have IPsec.
=> this is not true for IPv6 extension headers or IPv4 options.
... in a note explaining why I thought AH was useless
Vernon, I fully agree with you: there is no reason to get multipart
messages in technical discussion mailing lists. Even if your solution
seems drastic this is the way we should go.
Thanks!
[EMAIL PROTECTED]
In your previous mail you wrote:
It seems to me that Mobile IPv6 could go a long way towards
solving this problem, in conjunction with some sort of automatic
home address assignment capability.
...
Crucial to effective operation, however, will be the ability to
set up tempor
In your previous mail you wrote:
It's time to accept the fact that something is very wrong. I don't know
if the fatal flaws are in the basic idea, the routing, the greedy
shortsightedness of ISP's, or some evil conspiracy. Regardless of why,
if it is be dead dead, it's not alive.
In your previous mail you wrote:
This is not a technological problem - it is a social problem. We cannot
fix spam by technological means - it has to be fixed by social means.
=> thanks for this nice summary about the spam problem!
[EMAIL PROTECTED]
If you are not a French reader: this is SPAM!
In your previous mail you wrote:
>Including the people showing slides; at least
>with printed acetate technology you don't have people stopping to
>answer their Instant Messages.
=> I believe you are right for this point (banish power point! :-)
bit not for others.
Many
In your previous mail you wrote:
> In your previous mail you wrote:
>
> >Including the people showing slides; at least
> >with printed acetate technology you don't have people stopping to
> >answer their Instant Messages.
Francis got the quoting above wrong. I didn't
In your previous mail you wrote:
I *guess* you're joking, but...
=> no, Christian is right and the term was very successful in France.
-Original Message-
From: Christian Huitema [mailto:[EMAIL PROTECTED]]
Actually, the name is "brouteur", from the French verb "brout
In your previous mail you wrote:
I am trying to convince myself that the IEEE 802.3ah working group
working on FTTH should not consider a proposal to increase the MTU
size of Ethernet beyond 1500 bytes.
=> usually larger frames are better than the opposite: if IEEE 802.3ah
WG on FTTH (
In your previous mail you wrote:
Perhaps. Certainly stable IP address is preferable to being
constantly and needlessly renumbered all the time (although if the
practice became more prevelant, the silver lining is that it would
likely put an end to that abomination known as IP-addres
In your previous mail you wrote:
> If we are unwilling to bring "RFC" back to a place were it does not
> equal STD, then we need to create a new category of document which
> amounts to "fully baked ID". Things like IANA allocations could occur
> at that point.
=> IMHO the last point (IANA a
In your previous mail you wrote:
> We want the highest quality documents possible for developers to
> translate into implementations.
=> I am afraid this statement is not fully consistent.
Regards
francis.dup...@fdupont.fr
PS: note it is not an attack against you: in fact you gave a good su
In your previous mail you wrote:
My context is IPsec in the Internet, which excludes VPNs.
=> this is a bit unfair: VPNs are the natural model for IPsec use
(putting back an uniform I could talk about red and black :-).
Do you know some major application over the Internet using IPsec
I have a concern about no security usages of MD5 for practical reasons:
in some environments, including US Gov, crypto implementations (e.g.,
FIPS 140-2 HSMs) are required to not support MD5 so you can have to
choose between a compliant application and a conformant crypto,
for instance for DNS TSIG
In your previous mail you wrote:
The logic doesn't make sense in this position. "Crypto modules
can't use MD5, thus no protocols at all should use MD5."
=> this is a silly/bad/... consequence of the crypto label
attached to the MD5 name. I understand you are not happy with
this but wha
In your previous mail you wrote:
I think a published update to MD5 security considerations should
clearly say what it's still fine to do with MD5, in addition to
what it's not safe to do. This would mean adding a couple
sentences, and that's about all it would really take to be clear
I add a third option: enforce the fact the document is about "security
considerations" and add nothing about not security uses, one way or
the other.
Regards
francis.dup...@fdupont.fr
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/list
In your previous mail you wrote:
I'm OK with this text. I tried to come up with a way to briefly discuss
how error detection is very related to things like protecting against
substitution of content (the internet mirror case) but failed to come up
with something brief.
So, I'm fin
In your previous mail you wrote:
This is a late comment but I think it is worth raising it.
=> as the gen-art reviewer of the document I'd like to
understand the comment.
This I-D recommends to log the source port number for
internet-facing servers. But due to the presence of load-b
mail.ietf.org changed its IPv4 address (it was 64.170.98.32,
now it is 208.66.40.236) leaving at its previous address
something (i.e., a SMTP server) which blindly eats messages.
I strongly suggest to remove the SMTP server at
the previous address so it no longer misleads people
to believe their m
In your previous mail you wrote:
So I'm having trouble guessing why your systems are still seeing
64.170.93.22, much less sending mail to it.
=> a long time ago mail.ietf.org anti-spam dropped SMTP over IPv6
from a MTA address without a PTR. I put a workaround using the IPv4
address (th
In your previous mail you wrote:
I gather that this has something to do with French capitals. Would
that be whether a letter with an accent retains the accent when
capitalized?
=> this was and is the rule but because of typewriters the rule was
suspended during the 20th century. Now
In your previous mail you wrote:
I thought TCP was the default when the UDP message size is not enough.
=> with EDNS0 this is a bit more complex but IMHO this is the idea.
Note the recommended "connection management" (RFC 1025 4.2.2) suggests
multiple queries/responses too.
That's, AFAIK
In your previous mail you wrote:
Shouldn't be difficult. I'm not much into either technology, but since
SCTP can be tunneled through UDP, it should be possible to retrofit
SCTP adoption onto an existing DNS implementation. On an OS that
provides SCTP natively, a module inserted bet
In your previous mail you wrote:
=> I keep this because your answer is not about this...
> I don't understand your argument: it seems to apply to UDP over SCTP
> but here we have SCTP over UDP. BTW the easiest way to convert DNS
> over UDP into DNS over SCTP is to use an ALG (appli
In your previous mail you wrote:
> => not only this is very arguable (for instance about the resource
> exhaustion) but no hop-by-hop/channel security, even something as
> strong as TSIG, can provide what we need, i.e., end-to-end/object
> security (*).
> PS (*): I use the common m
In your previous mail you wrote:
> I hope a T-Shirt will feature my favorite French hero Super Dupont
>
> http://en.wikipedia.org/wiki/Superdupont
+1 (I should not have to explain why :-)
Thanks
francis.dup...@fdupont.fr
___
Ietf mailing list
In your previous mail you wrote:
> So zone suffixes are considered hateful.
=> in fact it is not the problem: link-local address
are considered hateful.
Regards
francis.dup...@fdupont.fr
PS: at least for use in standard applications.
Randy (oops, Jim), what is the meaning of the YES/NO?
BTW most NICs (AFNIC for instance) are also not-profit public benefit.
And you can add the few persons who pay themselves the registration,
Remi Despres, etc.
Regards
francis.dup...@fdupont.fr (also fdup...@isc.org)
In your previous mail you wrote:
> Looking at the link-local address, it appears to be constructed from
> the interface's MAC address, and basically nothing else.
^^^
=> note the IEEE spec says device MAC address and if the common
interpretation is device == NIC there is at leas
56 matches
Mail list logo
