The document
- 'Memorandum for multi-domain Public Key Infrastructure
Interoperability'
draft-shimaoka-multidomain-pki-11.txt as an Informational RFC
creates the impression that trust anchors must always be
self-signed CA certificates.
What is a trust anchor MUST remain completely up
The IESG wrote:
The IESG has received a request from the Public-Key Infrastructure
(X.509) WG (pkix) to consider the following document:
- 'Traceable Anonymous Certificate '
draft-ietf-pkix-tac-04.txt as an Experimental RFC
I'm having a serious problem with the terminology!
The
The IESG wrote:
The IESG has received a request from the Public-Key Infrastructure
(X.509) WG (pkix) to consider the following document:
- 'Traceable Anonymous Certificate '
draft-ietf-pkix-tac-04.txt as an Experimental RFC
I'm having a serious problem with the terminology!
The
Theodore Tso wrote:
On Wed, Jul 01, 2009 at 09:00:48AM +0300, Yaakov Stein wrote:
I would not be surprised if with my next machine I would find it impossible
to print correctly using any of the standard utilities provided,
and that I would be forced to write a program to do so.
The
Stefan Winter wrote:
I'll have a go at it (I am not a working group, but I hope you allow me
to express my opinion anyway). Plain ASCII makes work on drafts which
deal with internationalisation very hard. I have just uploaded a draft
with an example second-level domain containing the German
Stefan Winter wrote:
Plain ASCII makes work on drafts which
deal with internationalisation very hard. I have just uploaded a draft
with an example second-level domain containing the German small u-Umlaut
[U+00FC] as input to an algorithm.
Sorry, in fact
Yaakov Stein wrote:
... and don't get me started on LaTeX.
I am not sure what problems you had with LaTeX, but as someone who has
written thousands of pages using TeX,
I can't imagine anything better for professional document preparation.
I bought the TeXbook in 1989 and liked it,
Julian Reschke wrote:
Martin Rex wrote:
...
Personally I don't like XML at all, and the IETF should NEVER standardize
on a particular tool, if any, but only on a very restricted subset of
XML tags, if any. (So that tools more mainstream languages can be
produced and used
Nikos Mavrogiannopoulos wrote:
I'd propose to add this text to the standard:
This protocol MUST NOT be used with RFC4492, RFC5289 and
draft-rescorla-tls-suiteb.
How much longer are we going to beat that dead horse?
I'm not aware of information that the Certicom patents apply to
TLS
The Certicom IPR disclosure says that their patent claims cover
pretty much all of the TLS documents when TLS is used with ECC Crypto.
You're constantly arguing that Certicoms patent claims *APPLY*
to TLS extractors -- which it is not, and which no one from
Certicom seems to claim.
The
Simon Josefsson wrote:
One attack could works like this:
1) Client establish an client-authenticated HTTPS session with a TLS SNI
for blog.example.org and sends a HTTP GET with a Host: header for
internal-website.example.org.
2) The server TLS code authenticate and authorize the client
Michael D'Errico wrote:
I do not see why you consider this a vulnerability in the _server_!
Because a malicious client could theoretically establish a secure
connection using one server domain and then ask for pages from a
different domain. If the server does not check for this, it
Stephen Farrell wrote:
7. 6.2 says: If servers wish to avoid attack they MUST
NOT do stuff Isn't that equivalent to servers SHOULD
NOT? I think a SHOULD NOT is better. (And that's the form
used in section 7.)
This might be confusion with ISO terminology.
MUST == SHALL
MUST
Chris Newman wrote:
Evaluation relative to draft-mrex-tls-secure-renegotiation-03:
Kudos to Martin Rex for producing such a good alternate proposal. The
introductory text up to and including section 4.1 is very good and would
improve draft-ietf-tls-renegotiation. While I would support
Chris Newman wrote:
--On December 2, 2009 15:19:53 +0100 Martin Rex m...@sap.com wrote:
1. Running code: multiple implementations and interop testing was
performed on an earlier version of draft-ietf-tls-renegotiation.
Even EKR admitted that implementing the update
Marsh Ray wrote:
Martin Rex wrote:
Even EKR admitted that implementing the update is an insignificant
amount of work.
Pushing this point, that there were interoperable implementations
when this proposal was made in the IETF smells very much like
a request for rubber stamping
Chris Newman wrote:
Evaluation relative to draft-mrex-tls-secure-renegotiation-03:
Kudos to Martin Rex for producing such a good alternate proposal. The
introductory text up to and including section 4.1 is very good and would
improve draft-ietf-tls-renegotiation. While I would support
pasi.ero...@nokia.com wrote:
- Whether to prohibit sending the extension (in initial ClientHello),
or require the magic cipher suite even if the extension is sent (in
initial ClientHello): The consensus is again a bit rougher than we'd
normally hope to see, but the current text (either is
Paul Hoffman wrote:
At 4:05 PM +0100 12/16/09, Martin Rex wrote:
I do not agree to your determination of rough consensus.
Are you saying that in general, or are you saying you intend
to appeal the decision? The two are quite different.
I believe this still captures my position adquately
First, we need to fix the Definition of the TLS_RENEGO_PROTECTION_REQUEST:
This cipher suite value is the Client to Server signal that the client
is updated and asks to apply the strict rules of secure renegotiation
applied to the current handshake -- no excuses.
If SCSV is received by a server
Nelson B Bolyard wrote:
On 2010-01-27 07:37 PST, Martin Rex wrote:
Yoav Nir wrote:
Actually it's easier to hard-code the ciphersuite list on the client,
because it never changes with most applications. Adding logic to
differentiate between initial handshakes and repeated handshakes
pasi.ero...@nokia.com wrote:
The detail in question is whether the Signalling Cipher Suite Value
(SCSV) can be included when performing secure renegotiation (in
addition to the renegotiation_info extension).
Currently, the SCSV is not included. In the version that went to IETF
Last Call
Paul Hoffman wrote:
At 6:57 PM +0100 1/26/10, Martin Rex wrote:
The two MUST NOTs that popped up in -03 are in violation of rfc2119 section
6!
...as are about half of all MUSTs and SHOULDs in modern IETF standards.
what do you want to say with this?
That implementors should ignore
Kemp, David P. wrote:
Rationale:
Version -01 states that the semantics of SCSV is identical to the
semantics an empty RI, namely: this client is capable of supporting
secure renegotiation, and this ClientHello message is an initial
handshake, not a renegotiation handshake.
But you do
Peter Gutmann wrote:
Martin Rex m...@sap.com writes:
That implementors should ignore at least half of the MUSTs and SHOULDs
in IETF documents, because they don't make any sense, create unnecessary
interop problems or are otherwise harmful -- and should not be in the
document in the first
Bob Braden wrote:
Martin Rex wrote:
what do you want to say with this?
That implementors should ignore at least half of the MUSTs and SHOULDs
in IETF documents, because they don't make any sense, create unnecessary
interop problems or are otherwise harmful -- and should
pasi.ero...@nokia.com wrote:
Martin Rex wrote:
I have never seen an IETF AD fight so passionately for the
addition of rfc-2119-violating and unreasonable imperatives into
a document such as Pasi is doing it now.
Now? Addition?
I would like to remind you that version -01
(2) I prefer *NOT* publishing the specification as-is, and instead
prefer to remove the 4 accidentally added rfc-2119-incompliant
imperatives from -03 back to the technically sensible semantics
which had the original WG and IETF consensus. The document editor
has proposed
Marsh Ray wrote:
No matter how hard I try, I can't find the security problem and I can't find
the interoperability advantage.
Hence, the MUST abort requirement seems like an unmotivated restriction.
I'm not saying that we have to change the current draft, I'm just curious to
Michael Richardson wrote:
Melinda == Melinda Shore sh...@arsc.edu writes:
Melinda suppose explains the 2544 packages. I'd certainly never
Melinda deny people the ability to easily maintain unused and
Melinda unnecessary software and we're headed *way* off-topic, but
Stephen Kent wrote:
I recommend that the document not be approved by the IESG in its
current form. Section 6.1 states:
6.1. Support for GOST signatures
DNSSEC aware implementations SHOULD be able to support RRSIG and
DNSKEY resource records created with the GOST algorithms as
Sean Turner wrote:
Is the real problem the lack of English language documentation?
If so, I'm sure that the people who would like to use these algorithms
could arrange for translations of the two documents, and perhaps even
make that an individual submission as an Internet draft.
Basil Dolmatov wrote:
Martin Rex пиÑеÑ:
Admittedly, I know very little about the cryptographic
details, but there are two GOST signature algorithms
(GOST R34.10-1994 and GOST R34.10-2001). The earlier
appears to bear some similarity with DH, the newer appears to bear
similarity
Basil Dolmatov wrote:
Martin Rex пиÑеÑ:
Whether and how much the -1994 version is
deprecated is also a complete mystery.
It is written in the text of GOST -2001
Which document are you refering to when you say text of GOST -2001 ?
This document:
http://tools.ietf.org/html
Basil Dolmatov wrote:
Martin Rex пиÑеÑ:
I'm still quite confused.
All references to GOST signature algorithms of the kind
[GOST3410] ought to be fixed to say [GOST3410-2001].
I think that can de done, despite the fact that there is no other
algorithm coded as GOST 3410
Basil Dolmatov wrote:
Martin Rex пиÑеÑ:
I'm still quite confused.
All references to GOST signature algorithms of the kind [GOST3410]
ought to be fixed to say [GOST3410-2001].
I think that can de done, despite the fact that there is no other
algorithm coded as GOST 3410
Mark Andrews wrote:
In message 201002151420.o1fekcmx024...@fs4113.wdf.sap.corp, Martin Rex
writes
:
OK, I'm sorry. For the DNSsec GOST signature I-D, the default/prefered (?)
parameter sets are explicitly listed in last paragraph of section 2
of draft-ietf-dnsext-dnssec-gost-06
Andrew Sullivan wrote:
On Tue, Feb 16, 2010 at 01:18:48PM +0300, Basil Dolmatov wrote:
Martin Rex пиÑеÑ:
I am somewhat illiterate to crypto math, so I'm wondering whether
it is technicall possible to use a GOST R34.10-1994 key agreement
(ephemeral keys) in conjunction
Phillip Hallam-Baker wrote:
It is now generally accepted that PEM was undeployable because the
single root model is not workable. Nobody was going to trust IANA as
the ultimate root of trust, nor were they going to trust RSA.
ICANN has accepted responsibility for the DNS infrastructure.
Dmitry Burkov wrote:
On 16.02.10 4:21, Phillip Hallam-Baker wrote:
deploy as at present does not seem to have occurred to them. It is
quite possible that what is driving the GOST issue is that the GRU
really has a thing about vanity crypto. But I think it much more
likely that they are
Alfred =?hp-roman8?B?SM5uZXM=?= wrote:
(Apparently, the subject lines have been messed up entirely
on this list these days. I tried to return to the actual
subject, GOST signatures for DNSSEC.)
I fear you are in danger of drawing the wrong conclusions based
on incomplete information.
Basil Dolmatov wrote:
But, the most serious defect of DNSSEC, or PKI in general, is that,
despite a lot of hypes, it is not cryptographically secure.
Social attacks on trusted third parties makes the parties
untrustworthy, which means PKI is merely socially or weakly
secure.
There
Noel Chiappa wrote:
From: Dmitry Burkov db...@burkov.aha.ru
I think that it is not a constructive way to discuss this issue
following some conspiracy theories.
Understood, but at the same time there may be some value to being curious as
to why the Russian authorities have
Masataka Ohta wrote:
Ignore DNSSEC.
Technically, it is poorly designed unnecessarily causing a lot of
technical problems such as large message sizes.
But, the most serious defect of DNSSEC, or PKI in general, is that,
despite a lot of hypes, it is not cryptographically secure.
Social
Masataka Ohta wrote:
Martin Rex wrote:
DNSsec, as far as I can see, does not use a PKI in the traditional
sense. There are _NO_ persons involved in the process,
FYI, zones are operated by people.
That is missing the point.
From what I've seen, the whole architecture of DNSsec
Phillip Hallam-Baker wrote:
I took a look at DNSCurve. Some points:
* It could certainly win.
* It is designed as a hack rather than an extension.
* It considers real world requirements that DNSSEC does not.
What does DNSCurve additionally provide
compared to a combination of traditional
Tony Finch wrote:
On Thu, 25 Feb 2010, Martin Rex wrote:
What does DNSCurve additionally provide
compared to a combination of traditional DNS with IPsec?
DNS-based keying.
That appears to be an illusion.
My impression is that DNScurve can only distribute public keys
of authoritative
Richard Shockey wrote:
I do get the arguments in favour of ASCII, though I think there are
some pretty serious countervailing arguments (like, for instance, that
we can't spell many contributors' names, to take an easy one). But
the RFC format _is not_ plain ASCII. Just ask anyone whose
Jorge Amodio wrote:
I'd potentially agree if the format we actually use wouldn't have useless
page breaks that leave 25% of the pages unused. At least over here. I'd also
agree if that format would actually be usable on small devices like ebook
readers (where it's essential that you can
Julian Reschke wrote:
Actually, the page breaks _are_ useful. Like when referencing specific
parts/paragraph in a document with an URL in a long section, e.g.
http://tools.ietf.org/html/rfc5246#page-36
which contains the message flow of a full TLS handshake.
And that message
Andrew Sullivan wrote:
On Thu, Mar 11, 2010 at 11:37:55PM -0500, Donald Eastlake wrote:
PDF/A is a deliberately-limited format designed specifically for
archival purposes.
And is clearly a non-starter because I have no idea how to produce PDF
so limited, not idea how to test a PDF
Julian Reschke wrote:
I'm at the end of your mail, but you haven't told me how printing the
example document I pointed to worked for you. Did you try? If not, why not?
You mean this one:
It would be nice if you could elaborate on what the problem is. Try, for
instance, printing
Tim Bray wrote:
On Fri, Mar 12, 2010 at 10:43 AM, Martin Rex m...@sap.com wrote:
Martin describes a planet on which nroff formatting semantics are
considered to have current relevance, in which it's hard to look at 4
or 5 HTML documents simultaneously, in which people don't care which
Julian Reschke wrote:
On 14.03.2010 19:45, Phillip Hallam-Baker wrote:
Since the preferred submission formats are XML or nroff, I see no reason
that the HTML version could not be generated from the XML.
Are there numbers available from the RFC Editor about the
use of XML vs nroff for
Julian Reschke wrote:
On 13.03.2010 16:13, bill manning wrote:
ISO not withstanding, its still confusing if only because other cultures use
yyddmm. If the IETF website used something like ISO-2010-01-02 maybe.
This format is less confusing: 02jan2010
As far as I recall -MM-DD
Julian Reschke wrote:
Printing the documents with Microsoft Word is not that difficult.
Load it as .txt, remove two newlines at the beginning of the
title page, select page margins at 1/1 leftright, font
courier new and font size 10 throughout should work on A4 paper.
Printing them
Dave Cridland wrote:
The IAB made a clear statement that we need i18n support, yet over a
decade after RFC 2130 or RFC 2825, the RFCs themselves still have a
strict ASCII limitation. Sure, that wasn't mentioned at the time, but
does nobody else find this plain shameful?
You taking
SM wrote:
One of the effects
of this proposal is that the programmer will be complying with the
IANA registry to cherry pick which protocol or algorithm to implement.
I don't understand what you mean by implementing an IANA registry.
I do
You have a pretty strong accent, I'm having severe difficulties
understanding your language:
Your statement bespeaks a certain degree of na=C3=AFvet=C3=A9, =C3=A0 la =
those whose
heads are planted firmly in the sand. When shall we strip away the mere
fa=C3=A7ade of global participation that
Andrew Sullivan wrote:
On Fri, Mar 19, 2010 at 01:39:38PM -0700, Bob Braden wrote:
It would be good if RFC authors put atleast as much care into the
clarity and organization of their contents as you are devoting to a
discussion of the formatting. The contents are what matter, and
Julian Reschke wrote:
I don't buy that. We've got something like 1 billion people on the
planet running web browsers, and I'm pretty confident we can find a few
non-ASCII characters everybody can display which could be used in examples.
What exactly is the purpose of a few non-ASCII
Donald Eastlake wrote:
Martin Rex m...@sap.com wrote:
And if we should change anything about the Author's Address section,
then it would be to replace the contact information with URLs
to an IETF web server where each author can update/maintain his
contact information.
No. I have
What I found strange that for many many years it was difficult to
get started on writing an I-D, because of a lack of a decent tool
to facilitate writing I-Ds.
The processing steps in producing an I-D are rougly this:
1. get document template
2. edit document
3. spell checking
4.
Andrew Sullivan wrote:
On Sat, Mar 20, 2010 at 02:55:56PM -0800, Bob Braden wrote:
Drafts. That always seemed counter-productive to me. I am not sure I
would characterize the problem as serious, but it does seem t o warp
common sense for the sake of bureaucratic uniformity.)
I
I live in Germany, and I had ordered all the Credit cards (Master and Visa)
which I used during 1994-2008 explicitly _without_ PIN -- because I did _NOT_
want them to be usable to draw cash from an ATM, only for signature
based transactions. Going into a bank and obtaining cash
with card,
The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Additional Random Extension to TLS '
draft-hoffman-tls-additional-random-ext-01.txt as a Proposed Standard
I'm somewhat confused to see a Last Call for this proposal.
Julian Reschke wrote:
I was recently pointed at:
http://tools.ietf.org/html/rfc5226#section-4.2:
All such URLs,
however, will be removed from the RFC prior to final
publication.
I have to say that I think
Paul Hoffman wrote:
At 12:05 AM +0200 4/22/10, Martin Rex wrote:
The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Additional Random Extension to TLS '
draft-hoffman-tls-additional-random-ext-01.txt as a Proposed
Paul Hoffman wrote:
Without a rationale for when the extension is useful, it is impossible
for implementers to know when use of this extension is warranted or not.
The environment I described in the earlier thread is TLS with
Diffie-Hellman. I thought that saying that was sufficient, but
Paul Hoffman wrote:
In Diffie-Hellman key establishment with static keys, even if the PRNG
of one side is bad, the resulting pre-master secret is still sound.
TLS needs _more_ than the secrecy of the pre-master secret to be secure.
Snippets from rfc-5246 (TLS v1.2):
Nicolas Williams wrote:
On Wed, Apr 21, 2010 at 10:27:03AM -0700, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Additional Master Secret Inputs for TLS '
draft-hoffman-tls-master-secret-input-01.txt as a
Brian E Carpenter wrote:
There can be a difficulty, however,
if the apparently obvious and correct technical fix actually has
implications beyond the obvious that might be picked up by renewed
WG discussion or even a repeat Last Call.
But I think we would be
Marsh Ray wrote:
On 4/23/2010 12:12 PM, Nicolas Williams wrote:
Irrelevant: if the random octets being sent don't add entropy (because
they are sent in cleartext) then this extension is completely orthogonal
to PRNG failures.
Even though they are sent in-the-clear, the random data
Russ Housley wrote:
From the discussion at the plenary, it was clear to me that some people
expected the purchase of a day pass to count as participating in that
IETF meeting, and that others had the opposite expectation. Both views
have been expressed on this thread. Thus, an
Douglas Otis wrote:
On 5/17/10 10:06 AM, Joe Touch wrote:
My point here is that if you're discussing alternatives, you need to
address why this alternative was not used. There may be useful reasons
(in specific, using a separate command allows you to reuse some error
codes more
ned+i...@mauve.mrochek.com wrote:
As I've stated previously, I believe the main piece that's missing is a
SOHO-grade router that has full IPv6 support, 6to4 support, full
IPv4/NAT/firewall support, plus a readonably intuitive GUI to administer it
all. If such a product exists I continue to
Arnt Gulbrandsen wrote:
What I've never understood is why (almost) everyone tries addresses in
sequence instead of in parallel.
Even applications that routinely open two or more concurrent connections
to the server first try IPvX, then wait many seconds, then try IPvY. Why
not try both
David Conrad wrote:
On Jun 17, 2010, at 12:18 PM, Martin Rex wrote:
Maybe because it would be a big waste of network bandwidth and close
to a Denial of Service (DoS) attack if every client would try every
IPv4 and IPv6 address in parallel that it can get hold of for a hostname
Dave CROCKER wrote:
Interoperability testing used to be an extremely substantial demonstration
of industry interest and of meaningful learning. The resulting repair and
streamlining of specifications was signficant. If that's still happening,
I've been missing the reports about lessons
RJ Atkinson wrote:
Rather than quibble about the details of this, I'd
urge folks to support the move to 2-track.
If it becomes clear later, after experience with 2-track,
that 2-track needs to be further refined later, then
the community can always do that. In the meantime, it
is
David Conrad wrote:
On Jun 18, 2010, at 7:21 PM, Martin Rex wrote:
What you described is a client with a pretty selfish attitude
that doesn't care about network, servers and the other clients
put into code.
Well, no. What I described was my understanding of a proposal
Joel Jaeggli wrote:
On Jun 23, 2010, at 6:06 AM, Martin Rex m...@sap.com wrote:
What you described results in a negative incentive for servers to
become accessible under IPv6 as an alternative to IPv4. That is a real
problem. If a large number of clients would follow your proposed
Phillip Hallam-Baker wrote:
What really worries me is that there are people who are busy inventing new
discovery mechanisms for Internet protocols via HTTP who are completely
ignoring the existing DNS infrastructure.
Well, I'm worried about the security nightmare that is going to
happen when
Phillip Hallam-Baker wrote:
The fact remains that RFC 821 has the STANDARD imprimatur and the better
specification that was intended to replace it does not.
It seems pretty basic to me that when you declare a document Obsolete it
should lose its STANDARD status. But under the current
Ole Jacobsen wrote:
I have been told that an IETF meeting does not have security guards
at the door to verify who has a badge to determine whether the person
is registered for the meeting.
The fashion in the IETF is to have an open network. There isn't any
admission control and
Russ Housley wrote:
Yes, the slips obtained from the IETF registration desk and the network
help desk are anonymous. You show your badge, and then you can pick one
or more slips from the container. The people at the desk will not know
which registration ID you got.
Thank your for the
jean-michel bernier de portzamparc wrote:
However, from our own JEDI's (so-labelled Jefsey's disciples) experience I
would suggest some kind of ietf privacy netiquette. It could be equivalen
to architectural quotes like dumb network, end to end, protocol on the
wire, rough consensus, etc. It
Phillip Hallam-Baker wrote:
The simplest, cleanest solution to this problem is to either have a
device cert installed during manufacture or to employ my alternative
scheme designed for low performance devices that does not require them
to perform public key cryptography on the end point
Dave CROCKER wrote:
On 7/9/2010 4:32 AM, Hannes Tschofenig wrote:
The Fair Information Practices are a set of principles most of us are quite
likely to believe in, such as (copied from the Alissa's draft):
Likely, yes. But do any of us know how to translate those principles into
todd glassey wrote:
Martin Rex wrote:
As I previously mentioned, acceptable means different things to
different people.
Some people seem to hope that creation of a privacy policy is going
to improve things. Personally, I don't think so.
You mean that you think change
John Morris wrote:
1. As a general matter, many organizations that interact with lots of
people (especially collecting financial information from them) use a
broad range of written policies to reduce risk, by plainly stating a
position on an issue so that employees have clear guidance
todd glassey wrote:
On 7/21/2010 1:02 PM, Dan Schutzer wrote:
Can you briefly explain the relationship of Red Light Camera's to
DNSSEC?
What that means is any and all DNSSEC records operated out of a Root or
lower level system in the state of California who would operate under
these
todd glassey wrote:
Martin - since SAP's business is legally enforceable commerce are you
saying that there is no legal requirement for DNSSEC to return provable
content and if so where is the liability for it?
If the delivery of your yellow press subscription switches from
your neighborhood
Joel Jaeggli wrote:
On 7/25/10 6:21 AM, Fred Baker wrote:
A person's identity and their behavior are two different things. I
would presume that every IETF working group or BOF list has at least
one person on it who is lurking in the discussion for the purpose of
filing a frivolous
Aaron Stone wrote:
Additionally, the requirements to first check via HTTPS, then via
HTTP, and the requirements for identical contents, are not
requirements imposed by RFC 5785 -- though 5785 allows that a
registration ... MAY also contain additional information, ... or
protocol-specific
Joel Jaeggli wrote:
Depending on the popularity of your working group and the extent to
which the meeting itself is timeshifted from the vantage point of the
bulk of the remote participants, as much as 10% of of the partficipants
might be remote, generally less, almost never more.
There is
Shumon Huque wrote:
On Wed, Sep 08, 2010 at 08:44:56AM -0700, Bernard Aboba wrote:
If the reference identifier is _Service.Name then the match is being done
on the *input* to the SRV lookup process, not the output, and prohibition on
DNS lookups would not apply (or even make any
ned+i...@mauve.mrochek.com wrote:
On 9/7/2010 5:41 PM, Ross Callon wrote:
It's my sense that it's increasingly difficult to do work in the IETF
without being physically present at meetings, as well...
A significant amount of IETF meeting participants that have their
expenses sponsored
I'm also irritated by some of the offensiveness in the discussion.
To me, several issues appear to be accessibility issues,
even if the number of IETF Meeting participants affected
by them might be rather small. I think it is not appropriate
to universally apply a 80/20 good-enough principle
NomCom Chair wrote:
Nominations have slowed down dramatically, so this update is to enlist
the community in an effort to pick up the pace.
We are very far behind in nominations for all the open positions but in
particular we need nominations for the IESG and IAOC open positions.
[...]
1 - 100 of 332 matches
Mail list logo
