On Thu, Oct 3, 2013 at 12:49 PM, Scott O Bradner s...@sobco.com wrote:
On Oct 3, 2013, at 6:34 AM, The IESG iesg-secret...@ietf.org wrote:
The IESG has received a request from the Routing Over Low power and Lossy
networks WG (roll) to consider the following document:
- 'Terms used in
On Tue, Sep 24, 2013 at 5:25 PM, Phillip Hallam-Baker hal...@gmail.comwrote:
Looking at the extreme breach of trust by US govt re PRISM, I think it is
time to do something we should have done decades ago but were stopped at US
Govt request.
Lets kill all support for X.400 mail.
Actually,
On Tue, Sep 17, 2013 at 10:47 AM, Olaf Kolkman o...@nlnetlabs.nl wrote:
Based on the conversation below I converged to:
t
While less mature specifications will usually be published as
Informational or Experimental RFCs, the IETF may, in exceptional
cases, publish a
On Tue, Sep 17, 2013 at 3:43 PM, John C Klensin john-i...@jck.com wrote:
Are we far enough down this rathole?
john
I'm not sure. Which John are you again? The car-buying psychiatric composer
who lives in Edinburgh, Georgia?
share a name - all poor comments
and suggestions are actually that other Dave Cridland of course - but it's
not clear that this is a problem requiring a centralised registration which
isn't even centralised under the auspices of either the IETF or ISoc.
That's not to say you can't put any particular
On Mon, Sep 16, 2013 at 8:24 PM, John Levine jo...@taugh.com wrote:
My name turns out to be fairly common. Over the years, I have been
confused with a comp sci professor in Edinburgh, a psychology
professor in Pittsburgh, another comp sci researcher in Georgia, a
psychiatrist in Cambridge
On Wed, Sep 4, 2013 at 10:25 AM, Lorenzo Colitti lore...@google.com wrote:
I'm just saying it here so that everyone in the community can see it. If
it's an IETF document it has to have IETF consensus, and since I feel that
the arguments were not properly taken into account in the WG (read:
On 23 Aug 2013 04:22, l.w...@surrey.ac.uk wrote:
LC should not be treated as a right of passage, to test the patience of
folks who have developed a document.
rite?
Right - right or rite?
Lloyd Wood
http://sat-net.com/L.Wood/
On Tue, Aug 13, 2013 at 2:00 AM, Douglas Otis doug.mtv...@gmail.com wrote:
10) Establish a reasonable fee to facilitate remote participants who
receive credit for their participation equal to that of being local.
I understand the rationale here, but I'm nervous about any movement toward
a
On Mon, Aug 5, 2013 at 9:37 AM, Peter Saint-Andre stpe...@stpeter.imwrote:
I don't want to promise too much, but in time for Vancouver I'll
probably finish some code that sends you all sorts of helpful
information when you join the jabber room. There is a standardized room
subject message but
On Tue, Jul 30, 2013 at 4:25 PM, Keith Moore mo...@network-heretics.comwrote:
On Jul 30, 2013, at 3:23 PM, Noel Chiappa wrote:
The IETF doesn't have a police force, or any enforcement mechanism.
That's true, but people do sometimes cite IETF specifications as
requirements for equipment
Yeah, but we don't actually count the clubs, so it's okay.
On Thu, Jun 27, 2013 at 2:21 PM, Michael Richardson
mcr+i...@sandelman.cawrote:
Arturo Servin arturo.ser...@gmail.com wrote:
Today it is possible to verify that somebody attended to an IETF
meeting. You have to register, pay and collect your badge. However,
in
remote
On Thu, Jun 27, 2013 at 3:54 PM, Michael Richardson
mcr+i...@sandelman.cawrote:
Alia Atlas akat...@gmail.com wrote:
I have attended one meeting remotely - and the experience is nothing
at all
like being at IETF. I can see modifying NomCom eligibility
constraints
slightly -
On Tue, Jun 25, 2013 at 1:33 AM, Phillip Hallam-Baker hal...@gmail.comwrote:
RECOMMENDED is a strong suggestion that the implementation may override at
the discretion of the implementer. SHOULD is normative.
Of course, they both mean the same, because the author has (one assumes)
explicitly
. This is beyond personal opinions.
Perhaps if I showed Dave Cridland an article on netiquete he could try
to be less patronizing. Unlike some here I do not regard the RFC
series as having divine inspiration.
I'm not claiming it's the traditional meaning of the term, just that
RFCs do tend
Phillip Hallam-Baker wrote:
There is a real problem with accountability and transparency in the
IETF constitution which was designed by a bunch of old boys to
maintain control in their own hands. Peter is a member of the IETF
establishment so of course he sees no structural problem.
PSA's
On Tue, Jun 11, 2013 at 11:20 PM, Ted Lemon ted.le...@nominum.com wrote:
On Jun 11, 2013, at 6:03 PM, Dave Cridland d...@cridland.net wrote:
... and how would we judge IETF consensus on a document that doesn't get
done under a charter (which would in turn have been granted consensus
without
On Mon, Jun 10, 2013 at 9:37 PM, Pete Resnick presn...@qti.qualcomm.comwrote:
A statement such as the above is almost entirely useless to me as an IESG
member trying to determine consensus. It is content-free.
I think this is, in part, due to the question asked.
The IETF's Last Call
On Tue, Jun 11, 2013 at 12:58 PM, Dave Crocker d...@dcrocker.net wrote:
If we want the statements of support to be meaningful, they need to have
the creator of the statement do some real work -- more than mechanically
checking boxes -- demonstrating the 'understanding' that Lloyd suggests.
On Tue, Jun 11, 2013 at 1:45 PM, Dave Crocker d...@dcrocker.net wrote:
On 6/11/2013 5:25 AM, Dave Cridland wrote:
We want understanding, of course, but I think requiring Russ to
demonstrate that by writing a paragraph or six on the finer points of
the proposal would be daft.
That's
On Tue, Jun 11, 2013 at 2:41 PM, Randy Bush ra...@psg.com wrote:
Re-formulating the LC text sounds like an excellent idea, to call for
more substantive comments.
perhaps we should go to the source of the problem and require a phd
dissertation and defense from draft authors.
how much
On Tue, Jun 11, 2013 at 8:45 PM, Pete Resnick presn...@qti.qualcomm.comwrote:
It's interesting to see that people are interpreting me to mean I want
more text. I don't. I want less. Save your breath.
Well, this thread is surely evidence that you don't always get what you
want.
But more
On Tue, Jun 11, 2013 at 9:33 PM, Ted Lemon ted.le...@nominum.com wrote:
On Jun 11, 2013, at 4:24 PM, Dave Cridland d...@cridland.net wrote:
But more seriously, what are you expecting Russ to do? What did you want
him to write?
If your answer is Nothing, then how do you read IETF
On Tue, Jun 11, 2013 at 10:54 PM, Ted Lemon ted.le...@nominum.com wrote:
It is presumed that some degree of consensus to do the work of a working
group existed when that working group was chartered; otherwise it would not
have been chartered. When the working group reaches consensus to
On Fri, May 31, 2013 at 1:38 PM, Carsten Bormann c...@tzi.org wrote:
Of course, this doesn't include time-to-airport, so you can immediately
discount London.
Well, you say that, but I now know why Alexey moved from Moscow to Kingston
(40 minutes to LHR on the X26).
Dave.
On 29 May 2013 18:42, Peter Saint-Andre stpe...@stpeter.im wrote:
/me wonders if we need a separate series for informational documentation
Or maybe multiple paths, with multiple entry points.
Perhaps instead of Proposed Standard, we have a Engineering Proposal for an
engineering consensus, and
Nice post.
I wonder whether a better mechanism for drawing newcomers into the inner
circle - which is what I think you're intent is here - would be to randomly
select people to be involved in a short online meeting to discuss the
draft, rather than review it in isolation.
It'd be a different
These aren't published by the IETF, but by the RFC editor directly. As
such, the IETF has little control.
Even if this were not so, I would be very much against discontinuing or
specially marking such documents. I appreciate Mark Crispin was always
proud that his randomly lose telnet extension
The message below suggests you still think that every RFC is published by
the IETF.
It's not, and this one explicitly nuts that it is not an IETF RFC at the
top.
On 6 Apr 2013 18:35, Abdussalam Baryun abdussalambar...@gmail.com wrote:
Hi Hector,
When I read the RFC on 1 April 2013 (my first
On 5 Apr 2013 09:47, Loa Andersson l...@pi.nu wrote:
Bob,
thinking about this and assuming that the FTL Communication are deployed
in a not too far distant future, wouldn't we have started to receive
packets that was sent in the future already now?
Indeed, and this tells us that
Actually, getting rich without implementing anything seems to happen quite
often enough these days - it's called acquisition.
On Fri, Apr 5, 2013 at 6:12 PM, Wes Beebee (wbeebee) wbee...@cisco.comwrote:
Or use the FTL to predict the company stock price so that you get rich
without
On Fri, Mar 22, 2013 at 1:28 AM, Eric Burger ebur...@standardstrack.comwrote:
Quite the contrary. I am interpreting a few of the 'diversity' posts as
saying the IETF has fewer companies participating and much fewer smaller
companies participating. And I am interpreting those posts as implying
On 19 Mar 2013 22:47, Ole Jacobsen o...@cisco.com wrote:
I can just see the list of MUST, SHOULD and MAY have attributes,
Tsk. RFC 2119 only applies to interoperability requirements, as you well
know.
So unless we're also swapping t-shirts...
Thanks. There have been a considerable number of messages on this topic,
you have made every one of them seem ill-informed by comparison, including
my own.
I can't help but worry that TSV is a leading edge case for a general
malaise within our community though, which is that we are reliant on a
I'd agree to the more general statement that people from large commercial
organisations are dominating, and I'd argue that this is due to the cost
(in time and finanically) of doing reasonably high level IETF work. This
also restricts the available pool, and furthermore means our leadership is
at
On Feb 26, 2013 2:24 PM, joel jaeggli joe...@bogus.com wrote:
Finding the current time in UTC could reasonably be left as an exercise
for the reader...
Simple. Go to the UK, ensure it's winter, and ask a policeman.
On 16 Feb 2013 07:03, Patrik Fältström p...@frobbit.se wrote:
On 15 feb 2013, at 23:45, Warren Kumari war...@kumari.net wrote:
Sure -- the DNS protocol *cannot* handle any value in the octets --
in fact, there are an *infinite* number of values it cannot handle *in the
octets*. For example,
On 10 Feb 2013 03:46, Dale R. Worley wor...@ariadne.com wrote:
In any case, if you are doing something incorrect in your review,
presumably people will call your attention to that fact, and explain
how you should change what you are doing and why you should change it.
And on this note, doing
On Jan 24, 2013 3:42 AM, Dale R. Worley wor...@ariadne.com wrote:
From: Carsten Bormann c...@tzi.org
I think in protocol evolution (as well as computer system evolution
in general) we are missing triggers to get rid of vestigial
features.
That's quite true. Let us start by
On Fri, Jan 4, 2013 at 8:03 AM, Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
This Gen-ART reviewer believes that words like must have well defined
meanings
in the English language, so shouting is not needed at every use. There are
standards track documents that don't use RFC 2119 at
On Tue Dec 4 22:19:14 2012, George, Wes wrote:
Is there an IETF standard format for handling inline quote replies?
Is it just not implemented in certain mail clients?
RFC 3676? (As used here).
It is admittedly primarily useful in simple replies rather than
quoting (and therefore
I am not NomCom qualified, but I do support the recall. I also suspect
that, given the total disappearance of Marshall Eubanks from all online
activity in early August, he is either ill, deceased, or otherwise unable
to fulfill his obligations. Whichever, the IAOC needs a functional member,
and so
Does anyone other than historians honestly care what the original was? I
mean, really?
Dave.
It seems entirely reasonable that there needs to be a version available
that's precisely as-published, for legal (and quasi-legal) reasons, as you
say - however, that's the version produced by the RFC Editor, and not the
tools version (which is already non-normative, technically, due to the
terminate
the session immediately.
Overuse of RFC 2119 language reduces its utility.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP
that whilst the XSF solidly trounces the IETF
in terms of the numbers of people below 40, it sorely lacks the
significant benefits of the rest of the age-range - the IETF's
combined experience is vast, and the ability to tap into that
expertise is a real plus point.
Dave.
--
Dave Cridland
. It's a fair cop, we should have involved them in the
discussion.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
merely suggests that large messages are a problem
in themselves - if they are genuinely a problem, how? And why on
earth are they a problem in this group?
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks
(d) Do nothing
(e) The IETF formally demands a royalty free, reasonable and
non-discriminatory license to the technology for anyone, for the
purpose of implementing the specification.
Have Huawei made any statement about their IPR screw-up?
Dave.
--
Dave Cridland - mailto:d
...@xmpp.org that'd be great too.
Dave. (Some parts of this message in some respects as XSF chair,
which isn't a parallel to IETF chair, so probably best I don't dwell
on it...).
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd
,
they're pretty good, relatively hard to spoof, and almost as easy to
obtain.)
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
On Thu Jan 5 14:48:54 2012, Dave CROCKER wrote:
If protocol corresponds with program or algorithm, then what
is the communications term that corresponds to process?
It's tempting to say port number, but that doesn't seem very
satisfying.
Session?
Dave.
--
Dave Cridland
. We have lots of
terms that require qualification to be of any use, and session,
protocol, and even connection all need this.
Dave.
(Sent over a mail session using both IMAP and ESMTP sessions in
concert with an ACAP session).
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d
).
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
___
Ietf mailing list
Ietf@ietf.org
https
-representative self-selecting group of technical
people.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
client is none of those
things. It's optional, open-standard, and open-source.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP
experienced, on
Windows 7.
The XSF maintains a list at http://xmpp.org/xmpp-software/clients/
that people may find useful.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net
probably
look.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
___
Ietf mailing
are configured not to have history - presumably to avoid
confusing when they're only used for three single weeks throughout
the year.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net
confusion above, I am
misunderstanding what the term offended means.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
On Mon Oct 31 20:07:54 2011, Brian E Carpenter wrote:
On 2011-10-31 23:18, Dave Cridland wrote:
That said, I think our existing chatrooms are configured not to
have history - presumably to avoid confusing when they're only used
for three single weeks throughout the year.
Indeed
rooms with auto-join to see what happens.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
of people you
wanted to raise the issue in front of.
Of course, we could even discuss this in hall...@jabber.ietf.org now.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net
.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
___
Ietf mailing list
Ietf
to do, as a remote participant, is
participate.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
more pain in meeting the bar - but lowering
it does have problematic knock-on effects.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP
in ACAP.
Do I win?
(I'm largely against subject prefixes, but not sufficient to jump up
and down about).
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer
(or negotiated masking), but that was ruled out long ago.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
what mechanism you're talking about.
Happy eyeballs - try everything as soon as you can, in parallel. Drop
everything else when one does.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http
request. So
for example, if you got:
_ws._tcp.example.com SRV 1 0 ws.example.com
You'd make the upgrade request on the HTTP URI of:
http://ws.example.com/foo/bar
Of course, if this failed to connect, you can find another HTTP URI
to try - something you cannot do without SRV.
Dave.
--
Dave
, you'll end up
with the same impact to user experience of a few extra RTTs at
startup as is seen in XMPP, SIP, and so on - that is, none.
100ms extra on a 100ms request/response would be bad, I agree, but
that's not what we're talking about.
Dave.
--
Dave Cridland - mailto:d
On Fri Jul 22 01:11:33 2011, Masataka Ohta wrote:
Dave Cridland wrote:
It's proven impossible, despite effort, to retrofit SRV onto HTTP;
Where is a proof?
Sorry, I've a habit of using the word proof in the English (and
indeed Welsh) sense of test or trial, rather than the
mathematical
policy, CORS, etc.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
___
Ietf mailing
concur, not a
function of a transport protocol - removed from this specification,
then we'll need a distinct document which adds them back in, as it
were.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd
is defined here, and absolutely must explain whether
it's a host (for direct address lookup), or a domain (for SRV).
It's proven impossible, despite effort, to retrofit SRV onto HTTP;
there is no way it'll be possible to retrofit onto WS.
Dave.
--
Dave Cridland - mailto:d...@cridland.net
',
there are 'mailto', which uses MX, 'sip' and 'xmpp', which both use
SRV.
I think opponents of SRV records need to mount a stronger argument
than the kind of luddite argument that if it's hard for one protocol
in use by the browser, it should be hard for them all.
Dave.
--
Dave Cridland - mailto:d
share a similar name resolution
mechanism.
My argument is that it cannot be made optional, so if we want to ever
take advantage of this awesome tool, we need to bake it in from the
start.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap
.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
___
Ietf mailing list
Ietf@ietf.org
https
alone looks like an improvement.
SIP survived because it was very small. I don't see WS making a
transition, in the same way that repeated attempts have failed to
move HTTP to SRV.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net
in the core protocol.
I think with HTTP's very short lived requests, then it's possible to
work around the lack of SRV support (at a cost), but the benefit is
markedly higher with the long-lived, stateful sessions we're
anticipating with WebSocket.
Dave.
--
Dave Cridland - mailto:d
On Wed Jul 6 16:38:47 2011, Cullen Jennings wrote:
Has anyone found a particularly good solution to reading drafts on
an ipad? What about markup and notes on drafts?
Print them out using your ASR-33, then stick them on top.
HTH,
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d
to SWLUG's mailing list, after
all.
HTH,
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
, but smart and helpful
people who craft their response to fit your ability, not theirs).
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP
up, assuming the original
instigator[s] of the proposal don't wish to.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
On Thu May 5 18:31:33 2011, Dave CROCKER wrote:
On 5/5/2011 10:22 AM, Dave Cridland wrote:
On balance, whilst I appreciate the aims of this document, I think
the proposals
are not suitable for adoption.
1) This document radically lowers the quality of Proposed
Standards.
What
.
The fact remains that vendors treat PS maturity RFCs as standards.
By reverting to the letter of RFC 2026, this will undoubtedly
increase confusion - indeed, it's apparent that much of the deviation
from RFC 2026 has been related to this very confusion.
Dave.
--
Dave Cridland - mailto:d
On Fri May 6 11:44:48 2011, John Leslie wrote:
Dave Cridland d...@cridland.net wrote:
To quote from draft-bradner-ietf-stds-trk-00 (paraphrasing
newtrk).
4/ there seems to be a reinforcing feedback loop involved:
vendors
implement and deploy PS documents so the IESG tries
- document what it *is*.
Then, we should have a clearer understanding of the problems we're
attempting to solve, and it should prove a lot less contentious.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd
) labelling proposal Keith
Moore made here.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
of
the world, for whom RFC means Internet standard.
Actually, for most of the world, it means Rugby Football Club. But
yes, for the majority of folk who know about protocol specs, then RFC
means Standard.
Dave Cridland sid...
It's also like the (much more versatile) labelling proposal Keith
Moore
drafts being announced on the SIMPLE
mailing list, which might go some way to explaining this.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP
, largely in favour of the central tenet of
reducing the standards-track to just PS and IS; I think the
implementation outlined in this proposal is, however, broken.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user
is that you can provide a
direct gateway into the XMPP federation and access standardized
services directly from the browser.
And this is reliant on several open standards running over the last
mile.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap
) what form.
I'm all in favour of this.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
not sure of the utility.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
___
Ietf
On Tue Mar 29 16:53:03 2011, Scott Brim wrote:
On Tue, Mar 29, 2011 at 14:14, Dave Cridland d...@cridland.net
wrote:
On Tue Mar 29 12:28:55 2011, Eric Burger wrote:
Would we not be better off just asking (mandating?) at least one
open
source implementation? That effort would produce
think.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
___
Ietf mailing list
currently, a NAT provides:
- A degree of de-facto firewalling for everyone.
- An immunity to renumbering for enterprises.
- Fully automated network routing for ISPs.
If technologies could be introduced to tackle especially the last
two, I think the advantages of NATs would vanish.
Dave.
--
Dave
On Fri Oct 8 17:49:28 2010, Keith Moore wrote:
On Oct 8, 2010, at 12:31 PM, Dave Cridland wrote:
On Fri Oct 8 17:10:56 2010, Keith Moore wrote:
Except that neither middleboxes in general nor NATs in
particular were a direct result of the decision to adopt IPv6.
NATs were
1 - 100 of 204 matches
Mail list logo
