-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi John,
On 09/26/2010 04:34 AM, John R. Levine wrote:
But we have real situtations where the opposite is true,
quite possibly more often than the other way around.
Not really. There turn out to be a significant number of domains, in
the
In the context of a long thread about style and readability[*] Joel M. Halpern
summarized:
I do want to re-iterate two points I have seen that are important. Both are
relevant no matter what style of posting you like.
1) People need to read the whole email before composing their
NEW NON-IETF LIST ANNOUNCEMENT
IETF Meta-Discussions
This group is dedicated to the discussion of ancillary issues of
interest to the IETF community, especially discussions about how IETF
discussions and meetings should work.
-- IETF meeting locations / travel
-- Email composition design
The point raised by John Levine is amongst my concerns.
And one of the reasons that I have been looking at a different approach to
the use of DNSSEC information that does not change the DNS model as
radically as the end to end DNSSEC model.
The idea of using DNS resolver as a proxy is a good one
That is not the right question.
The question should be, who chooses for me?
My answer to the question does not have to be the same as other people's.
Some people will want the full ICANN registry with every scammy malware site
and every DNS name registered five minutes ago. Others will prefer to
actually, it was the right questions... and the answers all distill
down to your reply. security and trust are in the eyes/validator
of the beholder. Sam Weiler borrowed the term local policy - which
trumps any middleman. Steve B. suggests VPNs (or their functioal
eqivalant) between the
I don't see why DNSSEC makes dropping out zones impossible.
All DNSSEC does is to enable the end point to know that there is data
missing. It does not provide the end zone with any way to find the missing
data, nor is there any user interaction that makes any real sense in that
situation.
But
On Mon Sep 27 15:37:56 2010, Richard L. Barnes wrote:
This group is dedicated to the discussion of ancillary issues of
interest to the IETF community, especially discussions about how
IETF discussions and meetings should work.
Oh, I thought it was the technical rubbish that was off-topic
On Fri, 24 Sep 2010, Phillip Hallam-Baker wrote:
DNSSEC is a mechanism for establishing inter-domain trust. It is not an
appropriate technology for intra-domain trust.
Why not?
Tony.
--
f.anthony.n.finch d...@dotat.at http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST
I'm not closely involved with ROLL but I am working on devices using the CORE
work that would likely make use of and depend on this protocol. I have some
concerns about the practically of using ROLL given the IPR. My understanding of
the IPR is that one would be required to use certificates
On 27September2010Monday, at 7:48, Tony Finch wrote:
On Fri, 24 Sep 2010, Phillip Hallam-Baker wrote:
DNSSEC is a mechanism for establishing inter-domain trust. It is not an
appropriate technology for intra-domain trust.
Why not?
Because the atomic unit of DNSSEC is a
The IAOC approved it's updated administrative procedures on 16 September 2010.
They can be found at:
http://iaoc.ietf.org/docs/IAOC-Administrative-Procedures-9-16-2010.pdf
The change from what was discussed on this list was to add a requirement that
any reimbursement of expenses to IAOC
So, I came across a interesting recent (June 24, 2010) article on the US
DoD's news site (http://www.defense.gov/news/), which quote Kris Strance,
the chief of internet protocol for the [Dod], as saying:
{the DoD} philosophy is one that when a component has a mission need or a
business case
On Sep 27, 2010, at 7:31 PM, Noel Chiappa wrote:
So, I came across a interesting recent (June 24, 2010) article on the US
DoD's news site (http://www.defense.gov/news/), which quote Kris Strance,
the chief of internet protocol for the [Dod], as saying:
{the DoD} philosophy is one that
On 2010-09-28 13:59, Marshall Eubanks wrote:
On Sep 27, 2010, at 7:31 PM, Noel Chiappa wrote:
So, I came across a interesting recent (June 24, 2010) article on the US
DoD's news site (http://www.defense.gov/news/), which quote Kris Strance,
the chief of internet protocol for the [Dod], as
Phill,
On 2010-09-28 16:25, Phillip Hallam-Baker wrote:
The US DoD is running out of IPv4 space?
Where did I say that?
I very much doubt it.
Maybe, maybe not... how would we know?
Problem with the idea that resource depletion will drive adoption of IPv6 is
that it ignores the fact
GOSIP
http://tools.ietf.org/html/rfc1039
Ole J. Jacobsen
Editor and Publisher, The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972 Mobile: +1 415-370-4628
E-mail: o...@cisco.com URL: http://www.cisco.com/ipj
___
Ietf mailing
The IESG has approved a request to register image/ktx MIME media types
in the standards tree. This media type is a product of the Khronos Group
(www.khronos.org). The IESG contact persons are Alexey Melnikov and
Peter Saint-Andre. The registration template can be found at this
location:
The IESG has approved the following document:
- 'Overview and Framework for Internationalized Email'
draft-ietf-eai-frmwrk-4952bis-10.txt as an Informational RFC
This document is the product of the Email Address Internationalization
Working Group.
The IESG contact persons are Alexey Melnikov
The IESG has approved the following document:
- 'An Architecture for Network Management using NETCONF and YANG '
draft-ietf-netmod-arch-10.txt as an Informational RFC
This document is the product of the NETCONF Data Modeling Language Working
Group.
The IESG contact persons are Dan
The IAOC approved it's updated administrative procedures on 16 September
2010. They can be found at:
http://iaoc.ietf.org/docs/IAOC-Administrative-Procedures-9-16-2010.pdf
The change from what was discussed on the IETF list was to add a
requirement that any reimbursement of expenses to IAOC
The IESG has approved the following document:
- 'PKCS #5 Password Based Key Derivation Function 2 (PBKDF2) Test Vectors '
draft-josefsson-pbkdf2-test-vectors-06.txt as an Informational RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG
rfc-...@rfc-editor.org
Subject: Re: Experimental RFC to be: draft-dzis-nwg-nttdm-04.txt
The IESG has no problem with the publication of 'The Network Trouble
Ticket Data Model' draft-dzis-nwg-nttdm-04.txt as an Experimental RFC.
The IESG would also like the RFC-Editor to review the comments in
The IESG has no problem with the publication of 'The Network Trouble
Ticket Data Model' draft-dzis-nwg-nttdm-04.txt as an Experimental RFC.
The IESG would also like the RFC-Editor to review the comments in
the datatracker
24 matches
Mail list logo
