It's really annoying when a thread drifts to a wildly different topic
without somebody thinking to change the Subject header.
My comments on nominees would be much less frank if I knew they
would be published. In fact, I doubt if I would make any at all.
Here's a comment I sent in a number of
On 2011-10-11 10:18, Stephen Farrell wrote:
...
(What's the relevant plural
for mea cupla I wonder? ;-)
Nostra culpa, if you want a single fault owned by us.
It's nostrae culpae for multiple faults by all of us.
Perhaps it should be added to the Note Well.
Brian
On 2011-10-07 04:01, Adrian Farrel wrote:
...
I am aware that there are comments that an IETF design team should not have
been
shut down without consent from the ITU-T. I find, however, that when the ITU-T
agreed to develop MPLS-TP in cooperation with the IETF within the IETF and
using
Malcolm,
I'm technically incompetent to comment on draft-tsb-mpls-tp-ach-ptn.
However, if we reframe the debate as how to reconcile OaM for
Ethernet-based PTN with OaM for MPLS-TP-based PTN, we might have
a more productive discussion.
Regards
Brian Carpenter
On 2011-10-07 03:00,
Hi Jian,
On 2011-10-06 03:53, yang.jia...@zte.com.cn wrote:
Dear All,
I do not support either.
In section 3.5:
If two MPLS OAM protocols were to be deployed we would have to consider
three possible scenarios:
1) Isolation of the network into two incompatible and unconnected islands.
Huub,
On 2011-09-30 20:19, Huub van Helvoort wrote:
All,
Section 1,1 also contains the text:
[RFC5317] includes the analysis that it is technically feasible that
the existing MPLS architecture can be extended to meet the
requirements of a Transport profile, and that the
Scott,
On 2011-09-30 05:30, Scott O Bradner wrote:
I'm having a hard time understanding just what this document is trying to do
I understand from the title that it is supposed to be telling the reader why
a single OAM
solution is a good idea for MPLS-TP
if that is the case I'm not all
On 2011-09-29 04:24, Russ Housley wrote:
Brian:
And to be clear, I (still the previous IETF Chair) think that
some such change is needed, which is exactly why I wrote the
above draft in 2006. Perhaps the difference is that I see
the IAOC/Trust role as very hard to separate from the IETF
On 2011-09-28 08:03, John C Klensin wrote:
snip
... Interesting it is exactly the
assumption that the IAB Chair will have first hand involvement
in everything that the IAB does that is cited an example of why
it is necessary to have the IAB Chair on the IASA. So, if the
IAB succeeds in
Please see attached review.
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments
you may receive.
Document:
On 2011-09-23 17:21, Benson Schliesser wrote:
However, I would like to make sure we don't lose sight of the need
for some urgency with draft-weil.
I'm a little puzzled by the claim of urgency; I remember hearing in
July 2008 that doom was imminent if this was not done immediately.
I thought
My version of the history is taken from the IAB's own web site,
and it is very specific that the original name was Advisory
from 1984 to 1986:
http://www.iab.org/about/history/
Not that it really matters; I just wanted to observe that the role
has evolved over the years.
Brian
On
I think this disagreement between two ex-IAB Chairs deserves its own thread.
On 2011-09-21 17:47, Olaf Kolkman wrote:
On Sep 20, 2011, at 11:09 PM, Brian E Carpenter wrote:
...exactly. I'm far from convinced about that. I think the real need is to
figure out how to make the IAOC an Oversight
On 2011-09-21 05:44, Olaf Kolkman wrote:
On Sep 20, 2011, at 6:25 PM, Marshall Eubanks wrote:
- Olaf's wording be changed to make the IAB Chair, IETF Chair and ISOC CEO
into ex-officio and non-voting Liaisons to the IAOC and the Trust.
- The TAP then be modified to recognize the status of
On 2011-09-19 20:05, Olaf Kolkman wrote:
snip
Also, the new section 2.3, which is incorrectly titled but presumably
is intended to be IETF Trust membership seems to me to be inconsistent
with the Trust Agreement. The Trust Agreement states that the Eligible
Persons
(to become Trustees) are
+4 and rotfl
Brian
On 2011-09-16 17:17, Hadriel Kaplan wrote:
I thought the counting of votes was finished on this topic but people seem to
keep emailing their support/lack-of, so naturally I will be a good lemming
and do the same.
1) I am in favor of the two-maturity-levels draft and
John,
I don't share your confusion. I do feel that to be able to
construct reasonably pleasant sentences, we need both the verb
SHOULD and the adjectival participle RECOMMENDED, and their
negatives, in various circumstances.
I could propose an alternative erratum, adding MANDATORY,
but I won't;
On 2011-09-11 08:11, Sam Hartman wrote:
snip
I do not think the following types of comments should be considered as
objections when judging this sort of consensus:
1) You are not solving the most important problem
2) This will not do any good
Exactly. A very large part of the discussion
On 2011-09-11 13:26, Eric Burger wrote:
So should we move to a one-step process?
There is a detailed proposal for that at
http://tools.ietf.org/id/draft-loughney-newtrk-one-size-fits-all-01.txt
I don't think the arguments have changed much since 2006.
Brian
On Sep 9, 2011, at 9:33 PM,
On 2011-09-07 09:35, Ted Hardie wrote:
...
My personal opinion for some time has been that we ought to recognize that
the previous PS moved into WG draft years ago and that anything named an
RFC should be recognized as something that market will consider a standard.
And who raised the bar? It
On 2011-09-07 10:12, Julian Reschke wrote:
On 2011-09-07 00:01, Brian E Carpenter wrote:
On 2011-09-07 09:35, Ted Hardie wrote:
...
My personal opinion for some time has been that we ought to recognize
that
the previous PS moved into WG draft years ago and that anything
named an
RFC should
On 2011-09-03 09:29, Ross Callon wrote:
...
I think that we should go to a two maturity level process, be done with
this little step, and also enthusiastically encourage people to write drafts
that propose *other* changes to the process. Then at least we can be debating
something different
On 2011-09-02 07:45, Melinda Shore wrote:
...
Can anybody point to an incident in which lack of clarity around
2119 language caused problems, and it was determined that 2119
itself was the problem and not authors or editors being careless?
(or implementors being careless)
Indeed. I'm in
On 2011-08-30 22:04, Iljitsch van Beijnum wrote:
On 30 aug 2011, at 9:22, Henk Uijterwaal wrote:
That is a 4.5 year difference in when the exact date is announced. This
increase the risk that there is a clash with another meeting and people
cannot plan much in advance.
Come on, the idea
On 2011-08-31 09:51, Fred Baker wrote:
...
If the AD raised a valid issue, the ball is in the author/wg's court to
address it. They can game this rule by not responding until after 45 days.
Not if the draft has been updated and the AD doesn't either cancel the DISCUSS
within
a reasonable
On 2011-08-31 08:18, Jari Arkko wrote:
...
Here are the suggested guidelines for documents that advance to IS:
http://www.arkko.com/ietf/iesg/discuss-criteria-advancing.txt
Comments appreciated.
To answer Jari's original request: +1 to these new guidelines.
Not worth nit-picking until we
On 2011-08-31 10:38, ned+i...@mauve.mrochek.com wrote:
On Aug 30, 2011, at 9:24 AM, Marshall Eubanks wrote:
I support adding the SHOULD ... UNLESS formalism (although maybe it should
be MUST... UNLESS). It would be useful as there will be times where the
UNLESS can be specified and has
On 2011-08-30 10:08, Eric Burger wrote:
I would assume in the text of the document. This paragraph is simply an
enumeration of Burger's Axiom:
For every SHOULD, there must be an UNLESS, otherwise the SHOULD is a
MAY.
And there can be cases where even a MUST needs an unless. These
On 2011-08-27 04:03, Scott Brim wrote:
On Fri, Aug 26, 2011 at 11:04, Worley, Dale R (Dale) dwor...@avaya.com
wrote:
There must be at least a few hundred million mobile phones with data
capability, and a similar number of homes and small businesses with
WiFi systems. So we can estimate that
On 2011-08-25 10:01, Stephen Farrell wrote:
On 08/24/2011 10:32 PM, Brian E Carpenter wrote:
It would be interesting if someone with historical data could plot IETF
hotel and meeting fee costs over the years since 1986, normalized to take
account of inflation and trade-weighted currency
On 2011-08-25 13:42, somebody other than Ole Jacobsen wrote:
I agree that IAOC should
ensure that there are inexpensive hotels nearby so that
those with a tight budget can save money.
This is the key point. The anchor hotel, especially when there
is a convention centre involved, is quite
+1 to Ned. I can't see why this draft seems to make some people
go defensive - it isn't saying IPv4 is evil or anything silly
like that, it's just saying IPv6 is the future.
RFC1122v6 is another matter entirely. We clearly aren't ready
for it yet, but draft-ietf-6man-node-req-bis is a step on the
Frank,
On 2011-08-23 00:09, Frank Ellermann wrote:
Nothing is wrong in BCP 104, it needs no updated by moving the definition
of the term version support from one of its sections to another section.
But there *is* something wrong with it - it makes IPv6 sound
like an optional add-on to basic IP
On 2011-08-21 19:02, SM wrote:
Hi Brian,
...
IPv6 node requirements are defined in RFC 4294. It's merely an
informative reference in draft-ietf-intarea-ipv6-required-01. The
discussion about IPV4 address pool exhaustion (Section 1) is a
distraction from a definition of an IP-capable node.
Hi Subramanian,
I think most of your comments will be dealt with by
wordsmithing, but...
On 2011-08-21 06:11, SM wrote:
...
From Section 2:
'Updates [RFC1812], especially sections 1, 2, and 4 which use the
generic IP synonymously with the more specific IPv4. Since
RFC1812 is an
On 2011-08-20 09:30, Peter Koch wrote:
...
o draft-bdgks-arin-shared-transition-space-01.txt would have to be elevated
to a normative reference, with all consequences
I don't think this is really required; it is after all an
explanatory document. However, I do think that *if* draft-weil-
is
I fully support this document. It could be tuned in the way
Keith suggested, but basically it is a Good Thing.
Regards
Brian Carpenter
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Regards
Brian Carpenter
On 2011-08-15 04:29, Keith Moore wrote:
On Aug 14, 2011, at 12:24 PM, Russ Housley wrote:
The IESG did make some changes to the voting procedures a couple of years
ago. The change was to make it clear that a single DISCUSS position could
not block a
1. I'm glad that the ballot now has an explicit 'recuse' option.
Sorry about that red herring in my previous message.
2. (Excuse front posting). You can call it 'abstain' or you can
call it 'no'. What it means is that the AD concerned has
objections to the document that *cannot* be fixed
On 2011-08-14 06:29, ned+i...@mauve.mrochek.com wrote:
...
I really have to wonder if the entire yes/no-obj/discuss voting model is
appropriate for document advancement. For initial approval at proposed, sure,
having the ability to discuss the document makes all sorts of sense. But
for
Hector,
On 2011-08-04 14:35, Hector Santos wrote:
Brian E Carpenter asked:
Can you be more specific? Are you talking about
a) drafts that appear in the WG with very mature text, so complete
the WG progress very quickly?
b) drafts that are direct submissions to the IESG, and go through
Hector,
On 2011-08-04 09:19, Hector Santos wrote:
I appreciate this exchange here. I have a better idea of the draft and
your intention I have a few comments.
What I have noticed of late are fast track RFCs are coming out of no
where, very fast and sometimes are indirectly related to a WG
On 2011-08-03 05:45, Mark Nottingham wrote:
snip
... Some people will still doubtless complain.
/snip
Could we take this as the conclusion of this discussion?
I'm being serious. Tuning the schedule in the light of feedback
should be a constant concern, amd it will always be a balancing
Speaking for myself, I *highly* value the existing twin cutoff dates.
It makes it possible to perform triage on the drafts before the meeting,
and to read a reasonable number of them that seem important with some care.
Allowing drafts to be posted right up to the start of the meeting would
make
On 2011-08-02 11:35, David Kessens wrote:
Margaret,
On Mon, Aug 01, 2011 at 07:02:22PM -0400, Margaret Wasserman wrote:
If we don't want to hold meetings on Friday afternoons due to conflicts,
I'd much rather see us eliminate one of the plenaries and hold meetings
during that time slot.
On 2011-07-27 00:52, Olaf Kolkman wrote:
Dear Colleagues,
Based on the discussion I've updated the draft:
http://tools.ietf.org/html/draft-kolkman-iasa-ex-officio-membership
Essentially I incorporated Dave Crocker's proposal to
1) replace the 'chairs' by voting members appointed
Hi Pete,
On 2011-07-31 04:55, Pete Resnick wrote:
...
I *really* want an answer to the issue that Scott raises. Eric and Brian
each refer to a baby step. A baby step toward what exactly?
If the answer is simply, to align documentation with current
procedure, that's fine, but then I want to
or octet except as superseded.
I think you will need to add a complicated footnote on this.
On 2011-07-29 01:10, Thomson, Martin wrote:
On 2011-07-27 at 18:03:13, Brian E Carpenter wrote:
The second byte in an IPv4 header is called the Differentiated
Services Field.
I believe
Keith,
On 2011-07-29 02:20, Keith Moore wrote:
On Jul 28, 2011, at 10:06 AM, Peter Saint-Andre wrote:
On 7/28/11 10:03 AM, Eric Burger wrote:
And the real question is, are we moving forward? I think that we are
not moving as far as we originally wanted. However, I offer we are
moving a
Dave, we are shouting past each other so I will not repeat myself
on all points. However,
...
Of course, there can be cases where that is not so - in fact, that's
the main reason that the IESG defined the DISCUSS criteria a few years
ago.
Have you seen a pattern of having a Discuss cite the
On 2011-07-28 18:45, SM wrote:
Hi Martin,
At 04:13 PM 7/27/2011, Martin Rex wrote:
According to rfc2026:
4.2.2 Informational
An Informational specification is published for the general
information of the Internet community, and does not represent an
Internet community
Looking at a trace that I got from Geoff Huston a month or two ago,
there are 25486 IPv6 TCP sessions of which 10748 have a 6to4 source
address.
That's surprisingly high, showing that the answer depends greatly on
the point of observation, and explains why operators really need
to try to run a
reserved, but without
conclusion.
Nevertheless, the words in RFC 2474 don't say that. They say that
DS Field refers to the entire octet, including the (then unused)
ECN bits.
We knew ECN was coming when this was published.
Brian
On Jul 28, 2011, at 16:58, Brian E Carpenter
brian.e.carpen
Dave,
On 2011-07-29 13:53, Dave CROCKER wrote:
On 7/28/2011 7:22 PM, Brian E Carpenter wrote:
Dave, we are shouting past each other so I will not repeat myself
on all points. However,
Brian,
I did not ask you to repeat anything -- and don't want you to.
Rather, I asked you to move
Alexa,
Writing from Auckland NZ, I wish to object to the fact that the regular
audio streaming is not avaialble for the plenaries. It's a signficant
inconvenience.
Meetecho requires login and is picky about browser versions and Java versions,
forced me to blindly accept a security certificate,
are
harder to recognise.
Brian
Cheers,
Gonzalo
On 27/07/2011 5:42 PM, Brian E Carpenter wrote:
Alexa,
Writing from Auckland NZ, I wish to object to the fact that the regular
audio streaming is not avaialble for the plenaries. It's a signficant
inconvenience.
Meetecho requires login
The second byte in an IPv4 header is called the Differentiated Services Field.
Quoting RFC 2474:
2. Terminology Used in This Document
...
Differentiated Services Field: the IPv4 header TOS octet or the IPv6
Traffic Class octet when interpreted in conformance with the
definition given
Responding to Glen Zorn's question in plenary:
Firstly, not all ADs review all drafts - that's why you will see
numerous no objection or missing ballot responses.
Secondly, the drafts are de facto reviewed by review teams
these days (gen-art, security area, etc.). This serves to alert
the ADs if
On 2011-07-28 11:13, Martin Rex wrote:
Brian E Carpenter wrote:
Responding to Glen Zorn's question in plenary:
Firstly, not all ADs review all drafts - that's why you will see
numerous no objection or missing ballot responses.
I can understand the resource contention when reading drafts
On 2011-07-28 10:34, Dave CROCKER wrote:
Firstly, not all ADs review all drafts - that's why you will see
numerous no objection or missing ballot responses.
Brian,
I've been repeatedly hearing from IESG folk for some year -- and seeing
reports relating to Nomcom -- that, in fact, ADs
in this misunderstanding.
Alexa
On Jul 27, 2011, at 3:27 PM, SM wrote:
Hi Alexa,
At 02:42 PM 7/27/2011, Brian E Carpenter wrote:
Writing from Auckland NZ, I wish to object to the fact that the regular
audio streaming is not avaialble for the plenaries. It's a signficant
inconvenience
agreed. The NomCom needs an overview of this.
Brian
Ciao
Hannes
On Jul 27, 2011, at 6:12 PM, Brian E Carpenter wrote:
Responding to Glen Zorn's question in plenary:
Firstly, not all ADs review all drafts - that's why you will see
numerous no objection or missing ballot responses
On 2011-07-28 09:46, Jari Arkko wrote:
After extensive discussion on this list and in the IESG Russ has decided
to make a reduced proposal. I am now initiating a new Last Call to gauge
consensus on the new version.
Thankyou. I fully support this version.
Brian Carpenter
.
-Original Message-
From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
Sent: Monday, July 25, 2011 11:09 PM
To: Ronald Bonica
Cc: ietf@ietf.org
Subject: Re: draft-ietf-v6ops-6to4-to-historic (yet again)
To be clear, I'd like to see exact proposed text before expressing
levels reach zero,
operators will probably begin to consider decommissioning.
The status of RFCs 3056 and 3068 should not be interpreted as a
recommendation to remove 6-to-4 at any particular time.
-Original Message-
From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com
Likewise, operators will decide whether/when 6-to-4 relays will be removed
from their networks.
This is, of course, an undeniable statement of fact (as it is for any other
feature
of the Internet). However, it needs to be made clear that doing so *prematurely*
would penalise existing
To be clear, I'd like to see exact proposed text before expressing
support for the proposal. The trick is to get 6to4 disabled by default
at the user end, without disabling it for users who are getting good
service from it.
Regards
Brian
On 2011-07-26 09:49, Brian E Carpenter wrote
On 2011-07-19 11:26, Erik Kline wrote:
Given that each of us reads something different into the definition of
HISTORIC, is there any hope that this thread will ever converge?
I don't see any progress.
We may just have to blacklist any resolvers that have 6to4 clients
behind them and
On 2011-07-16 03:55, John C Klensin wrote:
(2) Pull the -advice document back from the RFC Editor queue
and fold the actual substantive content of the -historic
document into it, preferably as a very clear and very prominent
Applicability Statement.
I am very strongly against this. The
Mykyta,
I think the draft is fine without this addition, which contains some statements
that I disagree with. I don't think analysis is needed; this all ancient history
anyway.
Regards
Brian
On 2011-07-13 04:50, Mykyta Yevstifeyev wrote:
Hello,
As Russ agreed to sponsor this document on
Richard,
Thanks for the review.
On 2011-07-12 01:17, Richard L. Barnes wrote:
I have reviewed this document as part of the security
directorate's ongoing effort to review all IETF documents
being processed by the IESG. These comments were written
primarily for the benefit of the security
Hi,
We quite often discuss here how to judge rough consensus. In a completely
non-IETF
context, I came upon a reference to an article published in 2007 with the
catchy title
Inferring the Popularity of an Opinion From Its Familiarity: A Repetitive
Voice Can
Sound Like a Chorus. Here's an
On 2011-07-08 19:16, Roger Jørgensen wrote:
Guess I should clearify something, the thing I am considering are to
drop all 2002::/16 addresses hard, of course preferable return a
correct error messages to.
This is an awesomely bad idea. As explained in the approved advisory
document, it makes
Yes, I'm planning to check that in AUTH48 and wordsmith it as necessary.
Regards
Brian Carpenter
On 2011-07-06 14:22, C. M. Heard wrote:
Greetings,
I note that draft-ietf-v6ops-6to4-advisory-02, now approved for
publication and in the RFC Editor's queue, has a minor dependency on
Hi Alexandru,
I don't know which draft you are commenting on, but it isn't
draft-ietf-6man-flow-3697bis, which has no discussion of mobility.
Could you please retransmit with the correct Subject header?
Regards
Brian Carpenter
On 2011-07-02 03:28, Alexandru Petrescu wrote:
For text in
On 2011-06-25 13:38, Noel Chiappa wrote:
From: james woodyatt j...@apple.com
I supported 6to4-advisory and strenuously argued against taking up
6to4-to-historic.
...
I can see how 6to4-to-historic may divert its intended audience from
reading the much more
Keith,
On 2011-06-24 23:47, Keith Moore wrote:
...
1. Working groups often have strong biases and aren't representative of the
whole community. Put another way, a working group often represents only one
side of a tussle, and working groups are often deliberately chartered in such
a way as
On 2011-06-24 12:44, Peter Saint-Andre wrote:
On 6/23/11 4:36 PM, Paul Hoffman wrote:
Greetings again. The subject line is an honest question, not a
gripe.
For those on the ietf@ mailing list, please see
https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ballot/.
In short,
Michel,
On 2011-06-10 15:38, Michel Py wrote:
...
On that one I agree with Keith; where's the rush? Although imperfect,
6to4 was an obvious path and its demise would be the failure of the
IETF, following a long list of things that have been killed prematurely.
Who's talking about its demise?
On 2011-06-11 04:03, Tony Hain wrote:
...
There is no real problem with 6to4, despite the BS being propagated about
failure rates.
That's no BS, unfortunately. Have you studied the careful reports at
https://labs.ripe.net/Members/emileaben/6to4-how-bad-is-it-really
and
John,
On 2011-06-11 05:05, John C Klensin wrote:
...
But, to the extent to which the motivation for moving 6to4 to
Historic is what Tony describes as kill-what-we-don't-like,
Unfortunately, as I know from the enormous amount of technical
feedback I got from living, breathing operators while
Klensin wrote:
--On Saturday, June 11, 2011 05:28 +1200 Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
John,
On 2011-06-11 05:05, John C Klensin wrote:
...
But, to the extent to which the motivation for moving 6to4 to
Historic is what Tony describes as kill-what-we-don't-like
Ralph,
As far as I can tell this seems to describe some sort of a Layer 2 stateful
per-flow QoS mechanism using new Ethertype headers. As such I don't see why
the IETF would care. The point of it escapes me, since we have plenty of reason
to believe that such solutions are impractical and do not
Philip,
On 2011-06-10 03:18, Philip Homburg wrote:
...
I think this is likely to happen anyway. In all discussions it has been come
clear that 6to4 has nothing to offer for ordinary users,
In all fairness, that depends on your definition of ordinary.
Where I differ from Keith is that I don't
Hi Lorenzo,
On 2011-06-10 06:20, Lorenzo Colitti wrote:
On Thu, Jun 9, 2011 at 10:57 AM, Keith Moore
mo...@network-heretics.comwrote:
So the existence of 6to4 is in itself a significant barrier for IPv6
deployment for server operators and content providers.
non sequitur. Existing
On 2011-06-09 04:17, james woodyatt wrote:
On Jun 8, 2011, at 9:04 AM, Noel Chiappa wrote:
From: Martin Rex m...@sap.com
Classification of 6to4 as historic is [in]appropriate use of the IETF
process, because it would be a political .. statement.
Well, we've never done _that_ before, have we?
After a fair amount of thought, I have decided that I support
this document without reservation.
I support the recommendation that RFC 3056/3068 support should be off
by default in CPEs; the reasons for this are clear enough in my companion
draft. Specifically, I support the choice of SHOULD NOT
Ship it. We are way past the point of diminishing returns in
polishing this.
Regards
Brian Carpenter
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
On 2011-04-22 05:49, Joel Jaeggli wrote:
On 4/21/11 10:38 AM, Dave CROCKER wrote:
On 4/20/2011 2:21 PM, Brian E Carpenter wrote:
In the case of the IETF Chair I believe the issue is that it's
highly desirable, from a governance viewpoint, that the IETF Chair
has *personal* responsibility
On 2011-04-21 17:18, Glen Zorn wrote:
On 4/21/2011 12:18 AM, Behcet Sarikaya wrote:
Hi,
It seems like I-D submission for a revised draft (after expiration)
encounters
so many new hurdles:
1. Version number. Submission page complains about the version number even
though it is
On 2011-04-20 21:13, SM wrote:
Hi Bob,
At 14:04 19-04-2011, Bob Hinden wrote:
But that may not always be the case that all IAOC members have a lot
of IETF experience. We need to have a governance model that works
into the future.
...
You may notice that there isn't any intersection with
Olaf,
Thanks for posting this analysis. I'm on travel but will have
a careful look in a few days.
Brian
On 2011-04-15 04:25, Olaf Kolkman wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Certainly the IASA/IAD/IAOC reorganisation produced a noticeable
reduction in the IETF Chair
On 2011-04-14 06:19, Bob Hinden wrote:
Olaf,
On Apr 2, 2011, at 1:28 AM, Olaf Kolkman wrote:
[as editor:]
It seems that the high order bit of this discussion circles
around the question on whether it a requirement for the
IETF Chair to have a voting position in order to
effectively
John,
On 2011-04-15 01:10, John C Klensin wrote:
...
But, remembering that the IASA has only the purpose of making
the extended IETF (including the IAB) work more efficiently, I
see a somewhat different question. The roles and resource
requirements of the IAB and IETF Chairs have expanded
On 2011-04-07 03:27, Russ Housley wrote:
This revision proposes a solution to the issue raised by Brian Carpenter
about documents lingering at Draft Standard. Some people thought it was a
problem. Others thought it did not matter. The proposed solution leaves the
matter in the hands of
On 2011-03-31 08:52, SM wrote:
...
My reading of John's proposal (draft-klensin-iaoc-member-00) is that it
is framed in such a way to avoid some of the issues that can occur with
draft-kolkman-iasa-ex-officio-membership-00. When delegating
responsibility, one should also consider
On 2011-04-01 08:38, SM wrote:
Hi Brian,
At 00:07 31-03-2011, Brian E Carpenter wrote:
And that is exactly the problem with 'non-voting' status in a committee
that mainly operates by consensus. It allows people who really ought
to share accountability to apear to avoid it.
According
On 2011-03-31 00:21, Olaf Kolkman wrote:
Dear Colleagues,
I have just chartered a very short draft that intends to update BCP101. It
can be found at:
http://tools.ietf.org/html/draft-kolkman-iasa-ex-officio-membership
The draft is very short and contains only a few sentences of
On 2011-03-31 01:26, Barry Leiba wrote:
I'm very concerned about the IETF Chair getting decoupled
from the IAOC. The IETF Chair's job is a whole lot more than being
IESG Chair, and some degree of personal responsibility for oversight of
the administrative work seems to me to be appropriate.
On 2011-03-31 01:44, Russ Housley wrote:
Brian:
Dear Colleagues,
I have just chartered a very short draft that intends to update BCP101. It
can be found at:
http://tools.ietf.org/html/draft-kolkman-iasa-ex-officio-membership
The draft is very short and contains only a few sentences of
301 - 400 of 1719 matches
Mail list logo
