Jari,
Inspired by two of your recent notes and Dave Crocker's long
one last weekend (with which I almost completely agree should
that be notable), let me make a few observations:
(1) To the extent to which the IETF's focus is on protocols that
we hope vendors and others (producers in the
OK, I think Dave and I are going to discuss this.
I see a wedge :-)
The problem is where to stop.
I completely agree that the current I-D does not cover everything and I can see
that *some* things can usefully be added.
OTOH, if we don't draw lines, mission creep will lead us, step-by-step,
Lloyd,
http://www.arkko.com/tools/recrfcstats/d-contdistr.html
(Jari, what time period is that across? Oceania doesn't rate a mention…)
Recent RFCs is anything from RFC 5400 onwards. An arbitrary definition.
And Oceania is listed under Australia per
http://en.wikipedia.org/wiki/Continent...
Mark:
I would take those numbers with a HUGE grain of salt (as Jari documents).
Indeed
For example, I've lived in Australia since 2006, and yet am only listed as
producing RFCs in the USA.
My apologies. I added a data item to recognise you…
Jari
On 5/29/13 10:53 PM, Adrian Farrel wrote:
I see a wedge :-)
The problem is where to stop.
Well, I don't know. Maybe the problem is where to
start. That is to say, I don't know what problem
this document is trying to solve, or if there even
is a problem. I know that we've had some major
Thanks :)
On 30/05/2013, at 5:06 PM, Jari Arkko jari.ar...@piuha.net wrote:
Mark:
I would take those numbers with a HUGE grain of salt (as Jari documents).
Indeed
For example, I've lived in Australia since 2006, and yet am only listed as
producing RFCs in the USA.
My apologies.
Hi John,
this is a great summary.
Regarding the question about the type of standardization we want I would argue for amixture of both since inpractice there are, of course,a lot of grey areas. I suspect that setting the expectations right at the beginning of starting the work (in a group or
Hi Melinda,
Funny, but I agree.
To be honest at this point I'm sort of reflexively
anti-process-documents, unless there's an actual problem
that needs actual solution.
Which is why this isn't a process document.
The origin is a WG chairs Edu session. Turns out there was not a lot of clarity
On 5/29/13 11:16 PM, Adrian Farrel wrote:
Which is why this isn't a process document.
Are you sure?
Melinda
On 5/30/2013 9:06 AM, Melinda Shore wrote:
On 5/29/13 10:53 PM, Adrian Farrel wrote:
I see a wedge :-)
The problem is where to stop.
Well, I don't know. Maybe the problem is where to
start. That is to say, I don't know what problem
this document is trying to solve, or if there even
is a
Which is why this isn't a process document.
Are you sure?
Oooh, a quiz. I like quizzes.
Let me see. Yes or no. Hmmm.
Yes, I'm sure.
Your turn now.
Are you sure?
Ciao,
Adrian
On 5/29/13 11:56 PM, Adrian Farrel wrote:
Yes, I'm sure.
Your turn now.
Are you sure?
No, not at all.
Melinda
On 5/30/2013 9:58 AM, Melinda Shore wrote:
On 5/29/13 11:56 PM, Adrian Farrel wrote:
Yes, I'm sure.
Your turn now.
Are you sure?
No, not at all.
Let me try to help...
A process document is a normative statement of structure and sequence
for a process. It is the organization's means of
At 15:21 29-05-2013, Ted Lemon wrote:
I didn't say that I support the draft; just what I think could be
done to somewhat mitigate its scope. My personal (non-hat) feeling
about the draft is that if there is
I did not read those messages as meaning that you support the draft
or that there
On May 30, 2013, at 2:45 AM, Mark Nottingham m...@mnot.net wrote:
I would take those numbers with a HUGE grain of salt (as Jari documents).
I appreciate Jari's effort and use his page extensively. However, I agree taht
geography data should be taken with a grain of salt.
In my case I created
Joe == Joe Abley jab...@hopcount.ca writes:
Okay, I felt a bit embarrassed about having said this, so I went
back and reviewed the justification for bringing this forth as an
IETF document. The stated reason for publishing the document as
an IETF document is that there is a
(2) As far as I can tell, the operators in most regions are
generally well represented in, and collaborate using, the
various *NOGs.
the first derivative is generally positive. a lot of fluff, machismo,
and posturing, but that seems to come with any endeavor involving us
funny monkeys.
We
Yes, I'm sure.
Your turn now.
Are you sure?
No, not at all.
did you somehow miss the pdu data formats and exchange ladder diagram?
if this is not a process document, then what the heck is it, chopped
liver?
randy
On May 29, 2013, at 11:53 PM, Adrian Farrel adr...@olddog.co.uk wrote:
I can also see potential for adding some info to the Tao, but the danger
there is that document becomes too big and too detailed to be of use.
Many would claim it already is. We discussed that here a few years ago, and
Forwarding a discussion that started offlist for operational
reasons with permission. I've tried to elide some irrelevant
material; I hope that, if Eliot thinks it was relevant after
all, he will add it back in once he gets to an appropriate
machine.
--On Thursday, May 30, 2013 09:20 -0400 John
To be honest at this point I'm sort of reflexively
anti-process-documents, unless there's an actual problem
that needs actual solution.
Which is why this isn't a process document.
Watching this thread, I sense the authors trying hard not to make a
process document, presumably because that
Hi John,
At 10:23 29-05-2013, John C Klensin wrote:
The IETF has traditionally chosen the first model and a great
deal of our thinking and public rhetoric are based on it. Even
when we have adopted proposals, sometimes implemented ones,
from elsewhere, we have insisted on change control and
On May 30, 2013, at 1:24 PM, John C Klensin john-i...@jck.com wrote:
Forwarding a discussion that started offlist for operational
reasons with permission. I've tried to elide some irrelevant
material; I hope that, if Eliot thinks it was relevant after
all, he will add it back in once he
--On Thursday, May 30, 2013 15:31 -0400 Warren Kumari
war...@kumari.net wrote:
The below is not a direct response to John, it is more my
general views on IETF interaction with operators.
So, I've been a long time participant in some NOG's and still
(perhaps incorrectly) view myself as an
Hi,
This thread is helpful to me.
This is somewhat of a vicious cycle -- operators participate
less, and so the IETF understands less about how their
networks run. This leads to solutions that don't understand
the real world, and so operators lose faith/interest in IETF,
and
On 5/30/13 4:37 PM, John C Klensin wrote:
ultimately call the IETF's legitimacy and long-term future into
question. As you suggest, we may have good vendor participation
but the operators are ultimately the folks who pay the vendor's
bills.
Here in Alaska was the first time I'd worked in an
Hi -
From: Adrian Farrel adr...@olddog.co.uk
...
But who pays the operators' bills, and do we need to encourage participation
at
that level as well?
Participation as:
RFC uptake:
- using something based on an RFC?
- deploying something based on an RFC?
-
Melinda Shore, all at sea:
Here in Alaska was the first time I'd worked in an environment
that had technologists at a considerably less than elite skill
level, and I'd previously had no idea the extent to which
average operators/data centers rely on vendors (worse: VARs
and consultants) to
On 5/30/13 6:21 PM, l.w...@surrey.ac.uk wrote:
You'd love the Pacific.
Few IETFers get exposed to these kinds of environments.
I'd had no idea. The point here isn't to derogate techies
working in this kind of environment, but that because the
sorts of informal technology and skills transfer
On May 30, 2013, at 7:08 PM, Melinda Shore melinda.sh...@gmail.com wrote:
On 5/30/13 4:37 PM, John C Klensin wrote:
ultimately call the IETF's legitimacy and long-term future into
question. As you suggest, we may have good vendor participation
but the operators are ultimately the folks who
On 5/30/13, John C Klensin john-i...@jck.com wrote:
difficult problems arise when someone comes to us with a spec
that might be ok but isn't how we would do it and tries to say
you can have this and we will turn over change control as long
as you don't really want to make any changes. When a
Total of 283 messages in the last 7 days.
script run at: Fri May 31 00:53:02 EDT 2013
Messages | Bytes| Who
+--++--+
6.71% | 19 | 6.76% | 149502 | abdussalambar...@gmail.com
5.30% | 15 | 4.74% | 104777 |
On 5/30/13, George Michaelson g...@algebras.org wrote:
At risk of alienating my comrades from locations seeking to attract an IETF
for local development/inclusiveness and the like reasons, I think John gets
to the nub of the matter: the wider community cost, borne by all attendees
as a 'silent
Greetings,
This is to announce a(nother) virtual interim meeting for the MMUSIC
Working Group to take place on Monday, June 17, from 7:00 am - 10:00 am
Pacific Time. The goal of this meeting is to come to a resolution on the
so-called Plan A or Plan B approach related to SDP signaling needed
by
34 matches
Mail list logo
