Hi Bron,
On 01/09/2023 02:02, Bron Gondwana wrote:
Fact: recipient spam filter has more information than sender spam filter
I've no axe to grind here, but wondered - is there e.g. a
peer-reviewed publication that conclusively demonstrates
that?
Not saying that that's necessary, but I
On 12/02/2023 17:28, Murray S. Kucherawy wrote:
Have they not been getting consideration? I know I've been replying to
many of his comments.
I didn't mean to imply he was being ignored, sorry if
it sounded that way.
Cheers,
S.
OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public
Hiya,
FWIW, as this discussion has a bit of a flavour of one person
arguing with a bigger bunch of people, I'd like to say that
Mike is asking good questions that deserve consideration.
I don't have a position as to what may or may not be worth
doing in this space, but I figure I'll find it
Hiya,
On 03/12/2022 06:38, Murray S. Kucherawy wrote:
I've placed what I believe is the text that is closest to consensus in the
datatracker:
https://datatracker.ietf.org/doc/charter-ietf-dkim/
Please provide comments or criticism soon. Once it appears to be stable
relative to this
On 17/04/2022 20:14, Christian Huitema wrote:
This submission raises an interesting question for the IETF: how to
treat anonymous (or pseudonymous) submissions?
Perhaps if the author wishes the draft to proceed they will
be happy to self-identify, or perhaps not. I'd not worry
too much about
t
publishing private keys when one is finished with
'em (plus a bit).
S.
>
> ==Mike
>
>> On Aug 10, 2020, at 7:06 PM, Stephen Farrell
>> wrote:
>>
>>
>>
>>> On 10/08/2020 23:36, Brandon Long wrote:
>>> Isn't publishing the private
On 10/08/2020 23:36, Brandon Long wrote:
> Isn't publishing the private key the opposite of recovery?
>
> Ie, it's basically a mechanism for plausible deniability.
>
> "The key is public, anyone could have made that message."
Yep. And for DKIM, it's a mechanism I'd myself like to see
Hiya,
Had a quick flick through the paper. Good work but
not something that could yet be immediately used
(which is entirely reasonable). Nonetheless it'd be
good to see work done in this space.
I do however disagree with some of the motivations
for the smarter crypto:
- The authors say: "The
Hiya,
On 02/10/2019 22:01, Mark Delany wrote:
> What might give it more strength is if many people adopted key swap
> otherwise a solitary Snowden-like operative publishing a private key
> in an essentially obscure location on the Internet is unlikely to
> convince a judge that security thru
Hiya,
On 02/10/2019 20:29, Jon Callas wrote:
> Thus, any discussion of it is good. I really liked it. Please read it.
I will (but haven't yet:-).
Personally I'd advocate for implementations that regularly
cycle signing keys and publish previous private key values,
also in the DNS perhaps, or
Hiya,
I didn't read the drafts, but Nick's comments make sense to
me so I'd give those a +1 (modulo not having read the draft
of course:-)
One other thought...
On 19/08/2019 17:07, Kai Engert wrote:
> If the client
> supports it, and if the connection is encrypted, then the client
> sends
Hiya,
On Monday, 27 November 2017, Fred Baker wrote:
> Interesting article, cross-posted from ISOC Public Policy list
I'm not sure it's that interesting, but regardless of that the article is v. US
centric and I'm fairly sure such traditional nationalisms are less important
than previously.
On 05/05/16 15:53, Alissa Cooper wrote:
> +1. If people want to consider privacy as a heading under which we
> group a bunch of different kinds of attacks, that works perfectly
> well I think.
In the case of privacy, not all the bad things are correctly
described as attacks IMO. E.g. leaving
Hi Cyrus,
On 30/01/15 16:39, Cyrus Daboo wrote:
Whilst that is true I don't think we should be required to deal with
issues that are generic to HTTP itself (and in some cases already
covered in the base HTTP specs - e.g. server log information).
I think that's fair, but could you also
Hi SM, Linus,
On 15/06/14 13:14, Linus Nordberg wrote:
S Moonesamy sm+i...@elandsys.com wrote
Thu, 05 Jun 2014 23:39:53 -0700:
| I suggest that the BCP be reconsidered given the lack of privacy
| considerations.
+1
Q: How will that happen?
A: Someone will need to write an I-D:-)
If
Hiya,
On 15/06/14 19:38, S Moonesamy wrote:
Hi Stephen,
At 05:51 15-06-2014, Stephen Farrell wrote:
Q: How will that happen?
A: Someone will need to write an I-D:-)
If someone does such an I-D that is reasonable and improves
privacy, I'll be happy to help that progress.
Ok.
Not sure
On 11/06/14 15:54, Joe Touch wrote:
On 6/7/2014 6:20 AM, Stephen Farrell wrote:
Yes, source addresses leak information that affects privacy. But
we do not have a practical way to mitigate that. So therefore
BCP188 does not call for doing stupid stuff, nor for new laws of
physics (unlike
Hiya,
On 11/06/14 15:38, mohamed.boucad...@orange.com wrote:
Re-,
Please see inline.
Cheers, Med
-Message d'origine- De : ietf-privacy
[mailto:ietf-privacy-boun...@ietf.org] De la part de Stephen
Farrell Envoyé : samedi 7 juin 2014 15:21 À : Dan Wing Cc :
ietf-privacy
On 09/06/14 14:46, Brandon Williams wrote:
Would you please indicate where the draft proposes a new identifier? If
you are seeing a proposal for protocol changes somewhere in the draft,
editing work is required in order to either clarify or excise the
associated text.
Fair enough that its
Hi Dan,
On 07/06/14 02:38, Dan Wing wrote:
Stephen,
It seems NAPT has become IETF's privacy feature of 2014 because
multiple users are sharing one identifier (IP address and presumably
randomized ports [RFC6056], although many NAPT deployments use
address ranges because of fear of
I think Ted answered this but one little bit more...
On 05/06/14 21:28, Brian E Carpenter wrote:
Stephen,
On 06/06/2014 00:48, Stephen Farrell wrote:
Hiya,
On 05/06/14 08:05, Hannes Tschofenig wrote:
If you want to review a document with privacy implications then
have a look
: ietf-privacy
[mailto:ietf-privacy-boun...@ietf.org] De la part de Stephen
Farrell Envoyé : jeudi 5 juin 2014 14:48 À : Hannes Tschofenig;
int-a...@ietf.org Cc : ietf-privacy@ietf.org; Zuniga, Juan Carlos
Objet : Re: [ietf-privacy] NAT Reveal / Host Identifiers
Hiya,
On 05/06/14 08:05
On 22/05/14 07:44, Christian Huitema wrote:
As I mentioned before, the lottery should only return RFC that are on the
standard track and are not obsolete. Otherwise, we are wasting the
reviewers' efforts.
Fair point. Also raised by Karen earlier. [1] If people keep
using it, I'll add a
Hiya,
A while back Scott and Avri sent out a link [1] to
where you can put reviews of old RFCs. So far, that
hasn't seen overwhelming activity, which is a pity,
but maybe understandable, since we're all busy and
doing this is probably not top of anyone's todo list.
As a reminder, the goal is to
On 06/05/14 13:23, Scott Brim wrote:
On Tue, May 6, 2014 at 12:57 AM, Christian Huitema huit...@huitema.netwrote:
I wrote 6 of those. I could go on reviewing more stuff, but the lack of
feedback made me believe that the exercise was futile...
Thanks for doing those btw.
Channeling
Hiya,
On 11/19/2013 09:46 AM, Stephane Bortzmeyer wrote:
On Tue, Nov 19, 2013 at 10:39:00AM +0100,
Eliot Lear l...@cisco.com wrote
a message of 55 lines which said:
in fact there are several different forms.
I find three:
1) Encryption without a peer-specific arrangement. This is
Hiya,
On 10/12/2013 01:02 PM, Noel Chiappa wrote:
The thing is that I (and I suspect much of the IETF) feel that such I*
leadership attendees need to make it _very_ clear at such events that they are
there to present (as best they can) the views of the IETF as a whole, but they
cannot
Hi Ralf,
On 10/07/2013 09:23 PM, Ralf Skyper Kaiser wrote:
Hi,
Is it still possible to submit a talk? I would like to speak at the IETF/88
and a 15-30 minutes slot would be sufficient.
The topic of my talk is Transport Layer Security in a Post-Prism Era.
We don't really schedule talks
Hi Caspar,
On 09/29/2013 02:52 PM, Caspar Bowden wrote:
Although partly EU-specific, this http://t.co/X4j9iCE6Ox research Note
on FISA/NSA for European Parliament PRISM inquiry might interest list
members (35 pages, interdisciplinary). It was presented on 24th Sep and
has now been accepted,
Hi Avri,
On 09/25/2013 01:08 PM, Avri Doria wrote:
Hi
Very much support the draft and the idea of creating a BCP.
Have also appreciated the discussion on opportunistic encryption,
which I consider akin to a holy grail. Been thinking about it in a
DTN context for a while, but don't feel
Phill,
On 09/24/2013 05:25 PM, Phillip Hallam-Baker wrote:
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.
This is still in use, I
On 09/21/2013 02:42 PM, Roger Jørgensen wrote:
On Fri, Sep 20, 2013 at 6:54 AM, Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
I got my arm slightly twisted to produce the attached: a simple
concatenation of some of the actionable suggestions made in the
discussion of PRISM and Bruce
On 20 Sep 2013, at 05:54, Brian E Carpenter brian.e.carpen...@gmail.com wrote:
I got my arm slightly twisted to produce the attached:
Thanks for getting that done
S
On 09/20/2013 10:59 AM, Josh Howlett wrote:
I confess that I am confused by much of this discussion. As I understand
it, PRISM is not a signals intelligence activity; it only addresses that
data at rest within those organisations who have partnered with the NSA.
As such, improving protocol
Hiya,
On 09/18/2013 10:22 AM, Riccardo Bernardini wrote:
With
limited resources (not only funds, also students are nowadays a scarce
resource) we must concentrate our efforts where the return for unit of
work is larger.
While I sympathise, that must above is a choice.
Since an academic
On 09/16/2013 02:20 PM, Romascanu, Dan (Dan) wrote:
I have doubts myself, doubts that I shared with the IESG that this
question is really needed. Asking this question at the end of the
process after the conformance with BCP 78 and BCP 79 was explicitly
declared with each version of the I-D
- Original Message -
From: IETF Chair ch...@ietf.org
To: ietf@ietf.org; ietf-annou...@ietf.org
Sent: Sunday, September 08, 2013 10:53 PM
Here are some thoughts on reports related to wide-spread monitoring and
potential impacts on Internet standards, from me and Stephen Farrell
...@ietf.org wrote:
Here are some thoughts on reports related to wide-spread monitoring and
potential impacts on Internet standards, from me and Stephen Farrell:
http://www.ietf.org/blog/2013/09/security-and-pervasive-monitoring/
Comments appreciated, as always.
Jari Stephen
Summarising a *lot* :-)
On 09/06/2013 11:30 AM, Stewart Bryant wrote:
There is a whole bunch of stuff we can do
I fully agree. Some more detail on one of those...
We setup the perpass list [1] as a venue for triaging
specific proposals in this space. A few weeks in, we
have one I-D [2]
On 08/21/2013 11:13 PM, Barry Leiba wrote:
The general point is that the new people whom we want
to draw in as productive participants will be watching how we treat
each other and deciding whether they want to wade into that pool.
Yes, that is a factor that merits attention.
But not the
On 08/17/2013 02:43 AM, Henning Schulzrinne wrote:
Thus, I think this is worth exploring, as an experiment, just
like we started the day-pass experiment a number of years ago.
I don't know what this refers to in the above sentence, but I
agree with everything else in your note.
Offer
Hi Sandy,
I'm not sure how or if it plays into the SoW but your diagram
shows errata handling in the publisher part.
Many people find the current errata process not that great, but
we've collectively not gotten around to figuring out something
better.
I think the possible consequence is that
On 08/10/2013 03:33 AM, Dave Crocker wrote:
On 8/9/2013 6:09 PM, Stephen Farrell wrote:
So some kind of statement that CBOR is one point in a design
space (as opposed to an optimal solution for some set of
design objectives) would be worthwhile.
huh?
That's fair. My suggestion above
Hi Carsten,
As a no-hats, IETF-LC comment...
On 08/10/2013 01:42 AM, Carsten Bormann wrote:
Specialized binary formats like this TLV format are invented a dozen a day
all over the industry.
Each of them has their own little set of unwarranted complexities, bizarre
features, and little
On 08/05/2013 10:07 AM, Dave Cridland wrote:
One such hoop might be acknowledging the (privately sent) Note Well message
(thus equating XEP-0045 Participant with IETF Participant to some degree).
Another might be that we tell them to go away if their XEP-0054 vCard
doesn't include sufficient
On 08/05/2013 12:31 PM, Hadriel Kaplan wrote:
but at least one anonymous jabber participant (named Guest) did
remotely speak multiple times at the mic on one of the RAI working
group sessions this past week (at RTCWEB if I recall). I was
personally ok with it, but it was awkward.
Ah. I
On 08/04/2013 09:20 PM, Brian E Carpenter wrote:
Finally: a deadline one week before the meeting is no harder to meet
than one minute before the meeting.
Disagree. I often end up updating stuff late in the day and that
should continue to be fine.
Secondarily, its my impression that people
Wrt privacy in general...
On 07/20/2013 02:56 PM, John C Klensin wrote:
Any volunteers
to get in front of the mic lines?
I'd welcome that discussion. I'd love to see us have a
BCP61-like [1] RFC on the topic of privacy and I also
reckon that that'd help short-cut a number of IETF LCs
and
On 07/20/2013 04:06 PM, Scott Brim wrote:
On Sat, Jul 20, 2013 at 10:51 AM, Stephen Farrell
stephen.farr...@cs.tcd.ie wrote:
Wrt privacy in general...
On 07/20/2013 02:56 PM, John C Klensin wrote:
Any volunteers
to get in front of the mic lines?
I'd welcome that discussion. I'd love
On 07/20/2013 04:31 PM, John C Klensin wrote:
--On Saturday, July 20, 2013 15:51 +0100 Stephen Farrell
stephen.farr...@cs.tcd.ie wrote:
...
But, even if the outcome wasn't a BCP along the lines
I'd prefer, I think such a beast would still be worth
having if it meant we could avoid
On 07/19/2013 11:53 PM, Andrew Allen wrote:
the IMEI URN MUST NOT be included in messages intended to convey any level of
anonymity
That seems both perfect RFC 6919 fodder and disingenuous at
the same time (how can a message convey a level of anonymity?).
I need to read the draft but this
Hi Bernard, Patrik,
Thanks for the comment. Checking that out now and will
get back.
Cheers,
S.
On 07/17/2013 05:29 AM, Patrik Fältström wrote:
On 16 jul 2013, at 21:42, Bernard Aboba bernard_ab...@hotmail.com wrote:
After reading this document, I believe that this document omits
On 07/11/2013 03:22 PM, Cyrus Daboo wrote:
In iCalendar (RFC5545) we have properties to represent the organizer and
attendee of meetings. A parameter (attribute) of those properties is
CN - defined to be the common name of the corresponding calendar
user. Obviously that is a single string
On 06/27/2013 10:50 AM, S Moonesamy wrote:
Hello,
RFC 3777 specifies the process by which members of the Internet
Architecture Board, Internet Engineering Steering Group and IETF
Administrative Oversight Committee are selected, confirmed, and recalled.
draft-moonesamy-nomcom-eligibility
On 06/27/2013 02:24 PM, Michael Richardson wrote:
Stephen Farrell stephen.farr...@cs.tcd.ie wrote:
However, before getting into that I'd like to hear from
folks who've been on or chaired nomcoms. I know a lot of
it is done remotely, but how important is the f2f part
On 06/18/2013 07:42 PM, Peter Saint-Andre wrote:
On 6/18/13 12:08 PM, Phillip Hallam-Baker wrote:
The issue was raised in the IETF plenary I would have expected mention
of a followup mailing list to be made here on the ietf discussion list.
Fair enough.
Not quite. My local ietf@ietf.org
On 06/12/2013 10:56 PM, l.w...@surrey.ac.uk wrote:
Are the IESG people who disagree with you speaking for the IESG, or for
themselves?
That's really not clear already? In any case, I was disagreeing
with Pete as an individual since he was wrong regardless of hats.
He and I do that all the
Hi Pete,
I think you err when you say this:
A statement such as the above is almost entirely useless to me as an
IESG member trying to determine consensus. It is content-free.
In fact, you do know Russ. If you did not, then the above would be
far closer to correct. But in reality you do know
A couple of minor comments:
- For some unfathomable reason IEEE people seem to call mailing
lists reflectors - that might be worth a mention. Section 4
otherwise seems repetitive.
- 3.3.1.4 says: Since it is
possible to participate in IETF without attending meetings, or even
joining a
On 05/23/2013 09:38 PM, Antonio M. Moreiras wrote:
Hi. That's great news!
I think that a meeting in Buenos Aires will foster the participation in
our region. Including Brazilian participation. Probably it will be a
great opportunity for a lot of people to participate for the first time,
On 05/17/2013 10:18 AM, Yoav Nir wrote:
On May 16, 2013, at 11:55 PM, Stephen Farrell stephen.farr...@cs.tcd.ie
wrote:
I think Dave's idea is worth looking at, but have one comment:
On 05/16/2013 09:46 PM, Yoav Nir wrote:
There is a problem, though, that this will increase the load
I think Dave's idea is worth looking at, but have one comment:
On 05/16/2013 09:46 PM, Yoav Nir wrote:
There is a problem, though, that this will increase the load on ADs.
There is that. But don't forget that ADs mostly read everything
in IESG review and often comment. Even leaving aside
On 05/15/2013 07:38 PM, John C Klensin wrote:
So, what would you have me (and others like me) put on
registration forms so that I'm not part of that undifferentiated
180 names?
How about 7 densely worded paragraphs?
Sorry, couldn't resist:-)
S.
Hi Cullen,
On 05/14/2013 02:58 PM, Cullen Jennings (fluffy) wrote:
I would like to see the whole IESG say they agree with the Discuss Criteria
document and will stay within that (or change it if they disagree).
That I'm pretty sure is the case. When I started as a new AD
one of the first
Joe,
On 05/14/2013 09:45 PM, Joe Touch wrote:
As important as the DISCUSS criteria are, there are NON-DISCUSS criteria
that ought to be more carefully followed - including the point that
disagreements with the WG or clarifications are not justification for
DISCUSS.
I had assumed that the
On 05/03/2013 01:59 PM, Thomas Narten wrote:
If you look at the delays documents encounter (both in WG and in IESG
review), the killer is long times between document revisions. Focus on
understanding the *why* behind that and what steps could be taken to
make improvements.
Good point. I
On 05/02/2013 03:54 PM, Fred Baker (fred) wrote:
I your blog, you wrote:
Having been involved in the process for many years, often the bigger changes
at this stage relate to cross-area issues, or the fact that the careful
reviews from the IETF last call, directorates, and 15 ADs often
On 05/02/2013 04:19 PM, Fred Baker (fred) wrote:
On May 2, 2013, at 8:12 AM, Stephen Farrell stephen.farr...@cs.tcd.ie
wrote:
When asked if more could be done, (without any specific proposal
for what to do) the response was that increasing the workload
would maybe lead to a significant
On 04/26/2013 10:23 PM, Josh Howlett wrote:
OK, pardon the cheap shot, but I don¹t think SDOs that have some sort of
stewardship relationship to the Internet should ever play any part
whatsoever in the facilitation of DRM.
So it's ok to define protocols that manage access to services
On 04/15/2013 05:26 PM, Joe Touch wrote:
We can continue to appoint groups with additional rounds of review, but IMO,
they are scoped (and the IESG review guidance appears to back up that point).
I think Joe is correct there. Another data point is that we
asked secdir (who currently have an
On 04/13/2013 01:09 PM, Lou Berger wrote:
gender bias
...
western white guys.
It may be that the latter phrase is a common term in
north America, (I dunno) but fwiw it grates on me at
least.
If the issue we're talking about relates to gender,
then I think sticking to that is better and
On 13 Apr 2013, at 18:05, Michael StJohns mstjo...@comcast.net wrote:
Maybe what we do is ask some of the large network companies to fund a few
research fellowships on topics that might be of interest to the IETF in the
3-5 year time frame for post-doc types?
They actually do that
Hi Lloyd,
On 03/25/2013 10:03 PM, l.w...@surrey.ac.uk wrote:
(i'm just commenting on this thread so that when it results in an I-D
recommending how to write acks, I get acked...)
Thanks! Yours is the first useful thing anyone's said in this
thread that I recall. (Most previous mails made me
On 03/23/2013 02:22 AM, Melinda Shore wrote:
Sorry, Martin, but you're not describing how the IETF actually
works.
FWIW, seems to me you're describing one leg of the elephant
each. From my experience I'd say you both actually have an
appreciation of the overall elephant but that's not
On 03/07/2013 09:34 AM, Carsten Bormann wrote:
Oh, and one more data point:
The Internet-Draft archive also functions as a timestamped signed public
archival record of our inventions.
(Which are often trivial, but triviality won't stop patenting of copycats,
while a good priority more
On 03/06/2013 05:05 PM, Melinda Shore wrote:
On 3/6/13 4:57 AM, Dave Crocker wrote:
Candidates could choose to circulate the first part publicly.
I'm really, really against turning this into an election-like process
Speaking as someone who's filled in these things and both been
selected
On 03/02/2013 10:54 AM, Fred Baker (fred) wrote:
From my perspective, an important technical challenge in coming years might
be a variation on delay-tolerant networking. We have done a fair bit of work
in this area, for some definition of we - SOAP, Saratoga, and the NASA/JPL
DTNrg work.
On 03/01/2013 05:48 AM, SM wrote:
At 18:25 28-02-2013, David Singer wrote:
in 'privacy considerations' I think we need to explore the privacy
consequences of using protocols 'appropriately'. And there are, and
it's no longer OK not to worry about them as we design protocols.
Yes.
+1
Responses to Cullen below, but this is getting to the point
where unless someone else who likes the idea wants to join
the discussion, I'm going to conclude that we're collectively
either unwilling or unable to consider 3933 experiments and
regard this one as dead, which maybe means 3933 is
Hiya,
On 01/29/2013 05:49 PM, SM wrote:
Hi Stephen,
At 01:59 29-01-2013, Stephen Farrell wrote:
Responses to Cullen below, but this is getting to the point
where unless someone else who likes the idea wants to join
the discussion, I'm going to conclude that we're collectively
either
On 01/28/2013 04:27 AM, Joe Touch wrote:
About the idea of an experiment:
Right. The context being its an RFC 3933 IETF process
experiment.
On 1/25/2013 5:07 AM, Stephen Farrell wrote:
Responses to some points below but I'd really like to ask
people to consider a few things here
On 01/27/2013 11:19 AM, t.p. wrote:
- Original Message -
From: Stephen Farrell stephen.farr...@cs.tcd.ie
To: m...@sap.com
Cc: John C Klensin john-i...@jck.com; Thomas Narten
nar...@us.ibm.com; ietf@ietf.org; adr...@olddog.co.uk
Sent: Friday, January 25, 2013 10:47 PM
Hi Martin
Responses to some points below but I'd really like to ask
people to consider a few things here:
- what's proposed is an experiment, it'd likely get tried out
a few times and won't consume any huge resource anywhere
- its optional, WG chairs that want to try it could, those
that don't can
On 01/25/2013 03:27 PM, John C Klensin wrote:
In the context of draft-farrell-ft, the above makes the idea of
WG LC in parallel with IETF LC either irrelevant or bad news.
If the WG Chair (or AD) concludes that a WG LC is needed, then
the procedure should not be invoked. If a WG LC is not
Hiya,
On 01/25/2013 04:37 PM, John C Klensin wrote:
If I correctly understand the above, it lies at the root of the
problem I was trying to describe. This is really an experiment
if the effect of deciding we didn't want to make it permanent
was that we were at status quo ante, i.e., as if
Hi Martin,
On 01/25/2013 09:36 PM, Martin Rex wrote:
I don't know about the last time it happened, but I know about
one time in Nov-2009 in the TLS WG (now rfc5746).
I recall that and agree with the sequence of events you
describe, but I'm not sure that that situation is
relevant when
Hi Joe,
On 01/22/2013 04:39 PM, Joe Touch wrote:
Hi, all,
On 1/11/2013 8:21 AM, Adrian Farrel wrote:
Hi Alexa,
Please be aware of this document that has just entered a four-week
IETF last
call. The document describes a proposed IETF process experiment under
the rules
of RFC 3933.
On 01/22/2013 05:14 PM, Joe Touch wrote:
On 1/22/2013 9:00 AM, Stephen Farrell wrote:
Hi Joe,
On 01/22/2013 04:39 PM, Joe Touch wrote:
...
This is a silly idea.
So you're in two minds about it eh:-)
First, running code should already be considered as part of the context
Hiya,
On 01/22/2013 05:14 PM, Joe Touch wrote:
It puts more work on the community at large to review an idea that could
have been either rejected or significantly improved in a smaller
community before wasting the larger communities time.
Actually it occurs to me that there might be
Hi Thomas,
On 01/22/2013 09:31 PM, Thomas Narten wrote:
FWIW, I share Joe's concerns. And Stephen's responses don't really
change my mind.
Ah well. I'm willing to keep trying:-)
This document seems to have a bit of missing the forest for the
trees. In the overall scheme of things, I don't
Hi John,
Bits and pieces below...
On 01/22/2013 07:04 PM, John Leslie wrote:
Joe Touch to...@isi.edu wrote:
On 1/11/2013 8:21 AM, Adrian Farrel wrote:
The proposed experiment calls on the IETF Secretariat to take specific
actions under certain circumstances in corner cases of the
Hi Ned,
On 01/16/2013 03:40 AM, Ned Freed wrote:
Actually I think you make a couple of great points that ought be
mentioned in the draft about implementability. (No chance you'd
have time to craft a paragraph? If not, I'll try pinch text from
above:-) Now that you point it out like that, I'm
Martin,
On 01/15/2013 02:10 AM, Martin Rex wrote:
John Leslie wrote:
...
But more to the point, I think that in a lot of cases where
the IETF has done a good job, there has been running code
before the WG even started...
This perhaps explains where Stephen is coming from. Such
cases
Hi Brian,
On 01/15/2013 10:55 AM, Brian E Carpenter wrote:
On balance I think this experiment is safe to carry out, and therefore
probably should be carried out. There are a few comments below.
However, I would urge the IESG to update the page at
Hiya,
On 01/15/2013 11:49 AM, Brian E Carpenter wrote:
I hate it when we end up legislating for common sense, so I
agree that for the experiment, this point could be put in the
wiki.
Great. I'm accumulating stuff like that in the changes
section (9.1) of the working version [1] for now, so
Hi Ned,
at the end...
On 01/15/2013 10:31 PM, ned+i...@mauve.mrochek.com wrote:
Martin Rex wrote:
John Leslie wrote:
I'm pretty darn uncomfortable _ever_ picking a fight with any
sitting AD, But I feel obligated to say this seems like a terrible
idea to me.
As a background, I'm
Hiya,
On 01/14/2013 07:50 AM, Stephan Wenger wrote:
rant
...
I understand that this is a rant. And, I'm not ranting back, even if
tempted.
...
Yes, its tempting, but I'm going to resist since its irrelevant IMO.
...
/rant
I'm not at all sure what concrete suggestion you're making,
Hi Bernard,
I'm sorry, I have no idea what it is that you agree with.
Can you elaborate?
Thanks,
S.
On 01/12/2013 10:47 PM, Bernard Aboba wrote:
+1
[IAB Chair hat off].
Date: Fri, 11 Jan 2013 22:25:38 +0100
Subject: Re: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC
Standard and running code for advancement along the
standards track. I do not believe the two mix well.
A standard needs to be as simple as possible (but no simpler);
running code needs to be complex.
Stephen Farrell wants to speed up our process by adding an
incentive for having running
needs to be as simple as possible (but no simpler);
running code needs to be complex.
Stephen Farrell wants to speed up our process by adding an
incentive for having running code. Specifically:
]
] This memo describes a way to fast-track some final stage reviews for
] a working group draft
1 - 100 of 264 matches
Mail list logo
