Charles Lindsey wrote:
fixing the problem I shall describe would have repercussions in
draft-ietf-eai-smtpext-11.txt [EAI-SMTP-extension] and in
draft-ietf-eai-dsn-06.txt [EAI-dsn]
(especially the latter), it should be construed as a formal
objection to those as well.
[procedural
Apologies, I confused (1) and (2):
[...]
1 - The use of a nested CTE B64 if all else fails to send
DSNs to an EAI sender with a 7bit bit hop on the route.
2 - The use of UTF-8 in MIME version 1.0 part headers, this
can require to parse the MIME structure of a message to
figure
Marshall Eubanks [EMAIL PROTECTED] writes: [2]
On Feb 19, 2008, at 12:33 PM, Simon Josefsson wrote:
According to the trust administrative procedures:
http://trustee.ietf.org/docs/Trust_Procedures_12-15-2005.pdf
the trustees should hold at least three meetings per year, and shall
appoint a
Dave Crocker wrote:
Michael StJohns wrote:
At 10:46 PM 3/17/2008, Harald Tveit Alvestrand wrote:
*The names of people nominated should be made public.
*The names of the people who agreed to serve if selected should be kept
secret.
+1
Open enough to get feedback, but kind to
At Sun, 16 Mar 2008 19:44:12 +0100,
Iljitsch van Beijnum wrote:
On 16 mrt 2008, at 2:16, Mark Andrews wrote:
Enable DNSSEC validation on the network's servers. At a
minimum make them DNSSEC transparent.
Is there any software out there for common OSes that does
At Wed, 19 Mar 2008 22:59:52 +1100,
Mark Andrews wrote:
At Sun, 16 Mar 2008 19:44:12 +0100,
Iljitsch van Beijnum wrote:
On 16 mrt 2008, at 2:16, Mark Andrews wrote:
Enable DNSSEC validation on the network's servers. At a
minimum make them DNSSEC
I think Vidya has a good point.
My opinion is that, bootstrapping protocols from long-term credentials
used for network access authentication is not such a bad idea, but we
just do not know yet the best way to realize it:
On Tue, 18 Mar 2008, Ned Freed wrote:
Not really. The information environment supplies is, as the name implies,
about
the environment things are operating in. This includes information about the
Sieve interpreter, the host it is running on, and the network. The last item
includes connection
Eric,
I was referring to Iljitsch's suggestion about SSL and IPsec, not
the suggestion about DNSSEC.
Yes. FWIW, I don't think that would be interesting. DNSSEC experiments
by itself might be interesting, particularly if they could be combined
with some movement in getting the root signed.
Hi Jari,
we have already started todo the same with other protocols in GEOPRIV. See
http://www.ietf.org/mail-archive/web/geopriv/current/msg05453.html
http://www.ietf.org/mail-archive/web/geopriv/current/msg05468.html
http://www.ietf.org/mail-archive/web/geopriv/current/msg05472.html
Ciao
Hannes
Speaking as an individual:
Ned Freed wrote:
[...]
Now, there are several ways this could be handled, and I'm open to suggestions
as to which one makes the most sense. We could:
(1) Have the imap-sieve document update the environment specification with an
additional evaluation-agent value.
Just FYI, this draft is being AD sponsored as a report of a research effort
that certain people have done in the source address validation space. To
quote my ballot explanation:
This draft documents an experimental design implemented in
a research network for source address validation. The
The archives of the NomCom WG that generated RFC 3777 are now online:
http://lists.elistx.com/archives/ietf-nomcom/
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Hello,
My apologies for being obtuse. This Mother of All Root Keys I've been
describing is what the EMSK Key Hierarchy calls the DSRK.
The HOKEY key that the ERP/ERX draft uses can be derived in one of
two ways:
EMSK
|
USRK-- the HOKEY key, aka rRK
or like this:
The DSRK can be scoped just as the EMSK can be scoped.
regards,
Lakshminath
On 3/19/2008 9:45 AM, Dan Harkins wrote:
Hello,
My apologies for being obtuse. This Mother of All Root Keys I've been
describing is what the EMSK Key Hierarchy calls the DSRK.
The HOKEY key that the ERP/ERX
G'day,
The current discussion about Nomcom activities has been sufficiently
professional and constructive in tone to prompt me to raise a particularly
delicate point:
Just how realistic is our belief in confidentiality for the process?
It will be trivial to turn my query into an
On Wed, March 19, 2008 9:53 am, Lakshminath Dondeti wrote:
The DSRK can be scoped just as the EMSK can be scoped.
Really? Is there any context that it can be bound to?
Furthermore, what is the _purpose_ of this key? Why would someone choose
to derive a DSRK or choose not to derive a DSRK
I found that I have a (probably complete) copy of the archives of the
DNSSEC WG (http://www.ietf.org/html.charters/OLD/dnssec-charter.html).
(Where) does the IETF want them?
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
Dave,
I think I disagree with you on several of the details
in your discussion without necessarily disagreeing with
where you are going with it.
First of all, I think that the realistic view of the
possibility of something leaking is enough to ensure that
people do not make
Yes, that's excellent. In particular, I like your approach of making
things available for the IETF crowd, delivered by the folks who are also
delivering the standards.
Jari
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
On Tue, 18 Mar 2008, Ned Freed wrote:
Not really. The information environment supplies is, as the name implies,
about
the environment things are operating in. This includes information about the
Sieve interpreter, the host it is running on, and the network. The last item
includes
Hi Charles,
On a procedural point:
On 2008-03-19 04:13, Charles Lindsey wrote:
But RFC2045 is a Draft Standard, and
it is entirely outside the remit of the EAI WG to attempt to change what is
in a Draft Standard.
This draft does lack a couple of headers:
Updates: 2045 (if approved)
On 3/19/2008 11:12 AM, Eric Gray wrote:
Dave,
I think I disagree with you on several of the details
in your discussion without necessarily disagreeing with
where you are going with it.
First of all, I think that the realistic view of the
possibility of something leaking is
The IESG has received a request from an individual submitter to consider
the following document:
- 'EAP Tunneled TLS Authentication Protocol Version 0 (EAP-TTLSv0) '
draft-funk-eap-ttls-v0-04.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and
On Wed, Mar 19, 2008 at 10:11:09AM -0700, Dave Crocker wrote:
Add to this the fact that a) we have no detailed rules for
confidentiality but rather treat the word as having
implicit-but-total effect on behavior, b) we have no enforcement
powers over violations, and c) Nomcom members, IAB
The IESG has received a request from an individual submitter to consider
the following document:
- 'SAVA Testbed and Experiences to Date '
draft-wu-sava-testbed-experience-04.txt as an Experimental RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on
The IESG has approved the following document:
- 'Mobile IPv6 Fast Handovers over IEEE 802.16e Networks '
draft-ietf-mipshop-fh80216e-07.txt as an Informational RFC
This document is the product of the Mobility for IP: Performance,
Signaling and Handoff Optimization Working Group.
The IESG
The IESG has received a request from the Intellectual Property Rights WG
(ipr) to consider the following document:
- 'Advice to the Trustees of the IETF Trust on Rights to be Granted in
IETF Documents '
draft-ietf-ipr-outbound-rights-06.txt as an Informational RFC
The IESG plans to make a
28 matches
Mail list logo
