Henning == Henning Schulzrinne [EMAIL PROTECTED] writes:
Henning Putting all comments, including DISCUSS, into a
Henning document-specific issue tracker would be most
Henning helpful. (It would be helpful even beyond publication of
Henning an RFC, as we have found for the SIP
Dave == Dave Crocker [EMAIL PROTECTED] writes:
Dave 2. What are some examples of a demonstrated IETF-wide
Dave consensus against work submitted to the IESG? What
Dave improvements resulted?
I don't think there was an IETF consensus behind RFC 4285. I'm not
particularly sure there
Dave, I think you make a lot of interesting points here. I
particularly like aspects of your categorization.
I tend to disagree with your analysis however. At the current
juncture I think that you and I don't have a lot to gain by engaging
in a long mailing list discussion on this topic. I'd
John == John Leslie [EMAIL PROTECTED] writes:
John Sam Hartman [EMAIL PROTECTED] wrote:
Scott O Bradner [EMAIL PROTECTED] writes:
* The IETF as a whole does not have consensus on the
technical approach or document. There are cases where
individual working groups
Keith == Keith Moore moore@cs.utk.edu writes:
It's high time we gave up any pretense that the
IETF-as-a-whole should come to consensus about the
technical details of RFCs before they're published.
Keith strongly disagree. I have seen way too many working groups
Keith
Hallam-Baker, == Hallam-Baker, Phillip [EMAIL PROTECTED] writes:
Hallam-Baker, If you have a chair who is doing their job properly
Hallam-Baker, and honestly this need not be a problem. The
Hallam-Baker, process pretty much fails if the chair is part of
Hallam-Baker, the
Hallam-Baker, == Hallam-Baker, Phillip [EMAIL PROTECTED] writes:
Hallam-Baker, That is empirically not true. At this point we have
Hallam-Baker, precisely two cryptographic security protocols that
Hallam-Baker, can be regarded as a success: SSL and WEP. And the
Hallam-Baker,
Hallam-Baker, == Hallam-Baker, Phillip [EMAIL PROTECTED] writes:
Hallam-Baker, There is another problem to do with consensus and
Hallam-Baker, the status quo. Say we have a situation where a
Hallam-Baker, clear majority of a working group believes that a
Hallam-Baker, spec is
Scott == Scott O Bradner [EMAIL PROTECTED] writes:
Scott to follow up on Dave's note
* The IETF as a whole does not have consensus on the technical
approach or document. There are cases where individual working
groups or areas have forged rough consensus around a technical
If I'm reading the following mail correctly, it sounds like the nomcom
is requesting feedback from a working group mailing list.
In other words anyone who creates a tools.ietf.org account for that
address can see the short list of candidates.
At that point, shouldn't we just be making the
ken == ken carlberg [EMAIL PROTECTED] writes:
ken Sam, Back on Nov 1'st, you started this thread with the
ken following:
I'm speaking here as an individual. I'd like to build
consensus for my position both within the IESG and within the
community, but I realize that if I
ken == ken carlberg [EMAIL PROTECTED] writes:
I'm speaking here as an individual. I'd like to build
consensus for my position both within the IESG and within the
community, but I realize that if I fail to build that
consensus, I cannot make this objection as a single IESG
Fred == Fred Baker [EMAIL PROTECTED] writes:
Fred The remaining requirements, as I understand them, relate to
Fred more traditional internet applications: the delivery of
Fred email within a stated interval, reliable file transfer at a
Fred stated rate in the presence of
Scott == Scott W Brim [EMAIL PROTECTED] writes:
Scott On 11/09/2006 18:43 PM, Sam Hartman allegedly wrote:
Scott == Scott W Brim [EMAIL PROTECTED] writes:
Scott However, it is important that the IETF not *just* do
Scott protocols. The IETF needs to consider how proposed
Yoshihiro == Yoshihiro Ohba [EMAIL PROTECTED] writes:
Yoshihiro On Wed, Nov 08, 2006 at 02:00:14PM -0800, Bernard Aboba
Yoshihiro wrote:
I believe that the document will have implications for the
RADIUS protocol. For example, during the RADEXT WG meeting at
IETF 67, we
Fred == Fred Baker [EMAIL PROTECTED] writes:
Fred The key thing, though, is actually not this charter, as
Fred important as it is. It is the IETF leadership taking it upon
Fred itself to enable the work to progress in a timely fashion
Fred rather than having an infinite series of
Scott == Scott W Brim [EMAIL PROTECTED] writes:
Scott However, it is important that the IETF not *just* do
Scott protocols. The IETF needs to consider how proposed
Scott architectures fit in with all the other requirements on
Scott the Internet. The IETF doesn't do protocol
As an individual I would prefer not having this level of formality.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
King, == King, Kimberly S [EMAIL PROTECTED] writes:
King, On Nov 5, 2006, at 13:27, Sam Hartman wrote:
And I believe that the tsvwg is the right place to discuss
where RSVP intersects with security.
King, The point is that this work belongs here at the IETF, not
King
Fred == Fred Baker [EMAIL PROTECTED] writes:
Fred I have to say that my discussions with US DoD and DHS/NCS,
Fred and with their counterparts in other countries, doesn't
Fred suggest that the set of technical mechanisms is all
Fred specified. If we're looking only at voice, it is
King, == King, Kimberly S [EMAIL PROTECTED] writes:
King, There are several important requirements that are specific
King, to military and governmental needs that are emerging or
King, were outside the current charter's scope. These
King, requirements, I believe, include items
the registration packet include a pointer to http://community.ietf.org/blog .
Whatever blog technology we use should support our atom standard; it
seems not to do so.
There is an rss2 link but not an atom link.
___
Ietf mailing list
Ietf@ietf.org
James == James M Polk [EMAIL PROTECTED] writes:
James At 12:41 PM 11/2/2006 +0200, Pekka Savola wrote:
On Wed, 1 Nov 2006, Sam Hartman wrote: I don't believe the
new charter of ieprep working group belongs in the IETF. I
understand why we chartered it here, and I believe
ken == ken carlberg [EMAIL PROTECTED] writes:
ken Sam, One of the objectives of the work produced by IEPREP was
ken to lay down the ground work and put together a baseline set
ken of requirements to start with when considering solutions.
ken Our intention was that the baseline
[I could not find the ITU's liaison to the IETF. Scott, if such
exists, I'd appreciate you forwarding this to them.]
Hi.
I'm speaking here as an individual. I'd like to build consensus for
my position both within the IESG and within the community, but I
realize that if I fail to build that
Susan == Susan Thomson (sethomso) [EMAIL PROTECTED] writes:
Susan Hi Vidya Inline ...
-Original Message- From: Narayanan, Vidya
[mailto:[EMAIL PROTECTED] Sent: Tuesday, October 24, 2006
2:15 AM To: iesg@ietf.org; ietf@ietf.org Cc: [EMAIL PROTECTED]
Subject: RE:
We almost used the alternative procedure on the DHCP civil addresses
draft. We almost used the alternative procedure on the unique local
addresses draft.
We used the alternate procedure on both PR actions even though they
are not really drafts.
___
John == John C Klensin [EMAIL PROTECTED] writes:
John Andrew, Let me suggest, and suggest to the Nomcom, that
John these requirements are the opinions of the incumbents of
John what it takes to do the jobs as they see them. That is
John important input, but I question whether it
Jeffrey == Jeffrey Hutzelman [EMAIL PROTECTED] writes:
Jeffrey Finally, note that the alternative balloting procedure is
Jeffrey intended to be applied as a last resort, when it is clear
Jeffrey that the AD holding the discuss and the WG or individual
Jeffrey who submitted the
Hi.
I was unable to find a text mode browser that can work with your
nomination pages to nominate candidates.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Robert == Robert Sayre [EMAIL PROTECTED] writes:
Robert On 10/17/06, Sam Hartman [EMAIL PROTECTED] wrote:
Michael Can an appeal be rejected with merit?
Yes. I think Robert's recent appeal was rejected that way.
Robert I don't feel that way. I did wait a long time
Robert == Robert Sayre [EMAIL PROTECTED] writes:
Robert OK. I want to write a document that makes MTI a
Robert non-requirement for HTTP1.1-based protocols, because I
Robert believe that is the consensus in the HTTP community. How
Robert do I get that done?
You start by writing a
Joel == Joel M Halpern [EMAIL PROTECTED] writes:
Joel After re-read Brian's draft, RFC 3683, RFC 3934, and the
Joel relevant portions of RFC2418 I support the IESG/ADs ability
Joel to make longer than 30-day suspensions and to engage in
Joel alternate methods of mailing list
Douglas == Douglas Otis [EMAIL PROTECTED] writes:
Douglas This still seems like too much. Information offered for
Douglas access can be contained within one or more certificates.
Douglas The information within these certificates should be
Douglas limited to a minimal set of
Hollenbeck, == Hollenbeck, Scott [EMAIL PROTECTED] writes:
-Original Message- From: Sam Hartman
[mailto:[EMAIL PROTECTED] Sent: Friday, October 13, 2006
1:33 PM To: ietf@ietf.org Subject: Re: Last Call: 'Extensible
Provisioning Protocol (EPP)' to DraftStandard
Michael == Michael Thomas [EMAIL PROTECTED] writes:
Michael John C Klensin wrote:
(1) The supporter procedure/requirement should be triggered
only is someone shows symptoms of being a vexatious appellant.
People who are entering their first appeals don't trigger it.
John == John C Klensin [EMAIL PROTECTED] writes:
John And, if deciding which appeals are vexatious and which ones
John are ok is too burdensome --especially relative to hearing a
John few more appeals-- then, IMO, we shouldn't be spending time
John on trying to figure out ways to
Hi. RFC 3967 is not applicable in cases where the appropriate
solution is to advance the normative downreference on the standards
track. In each case where you have a normative down reference, to a
PS, please explain why advancing that document is not the appropriate
solution.
It is my opinion
Frank == Frank Yeh [EMAIL PROTECTED] writes:
Frank Standardized VS vendor-specific attributes is not something that
needs to be
Frank solved today. Solutions can start with vendor-specific and migrate
toward a
Frank standard, if one develops, without changing the protocol. The
Susan == Susan Thomson (sethomso) [EMAIL PROTECTED] writes:
Susan regard. For example, potential deployment scenarios may
Susan include,but are not limited to, providing normal access
Drop the may include. You want to have at least one or two
deployments that you commit to solving to
John == John C Klensin [EMAIL PROTECTED] writes:
John --On Wednesday, 27 September, 2006 23:22 -0400 Sam Hartman
John [EMAIL PROTECTED] wrote:
I support the textual descriptions of the changes Eliot made.
However I'm concerned that as with any effort to revise RFC
2026
I support the textual descriptions of the changes Eliot made. However
I'm concerned that as with any effort to revise RFC 2026, there will
llikely be changes in wording that have unintended consequences. I am
not personally convinced that the value of revising RFC 2026 justifies
the risk of
John == John C Klensin [EMAIL PROTECTED] writes:
John --On Monday, 25 September, 2006 11:07 -0700 Lisa Dusseault
John [EMAIL PROTECTED] wrote:
On Sep 23, 2006, at 2:20 AM, Julian Reschke wrote:
But as a matter of fact, draft-newman-i18n-comparator-14
doesn't define any
Julian == Julian Reschke [EMAIL PROTECTED] writes:
Julian But as a matter of fact, draft-newman-i18n-comparator-14
Julian doesn't define any collations that would actually solve
Julian the Unicode NF issue, so it's not really clear how this
Julian helps CalDAV (except that it now
Jefsey == Jefsey Morfin [EMAIL PROTECTED] writes:
I think the following is a good summary of our quandary.
Jefsey At 11:17 20/09/2006, Dave Cridland wrote:
Well, I think there's a lot of confusion between the statement We,
as engineers trying to maintain our scientific integrity
Hallam-Baker, == Hallam-Baker, Phillip [EMAIL PROTECTED] writes:
From: Harald Alvestrand [mailto:[EMAIL PROTECTED] I don't
disagree. The IETF might first try to design an authentication
feature worth requiring. None of the current options are at
all satisfactory.
Henning == Henning Schulzrinne [EMAIL PROTECTED] writes:
Henning For this particular case, I don't think there is a
Henning scientifically provable right answer, so a reasonable
Henning approach is to pick a number (1 or 2 or 3 steps) that
Henning most active participants
Pekka == Pekka Savola [EMAIL PROTECTED] writes:
Pekka I'd be more than happy to support a move to ban Mr
Pekka Glassey. Is it time for a PR-action ?
I don't understand why RFC 3005 is insufficient.
There may also be a need for action in the ipr working group, but I'm
sure the chairs
John == John C Klensin [EMAIL PROTECTED] writes:
John Actually, that topic opens up one of the fundamental issues
John with our standards process ... one where better definition
John and clear community consensus is, IMO, needed. Measured by
John our documented criteria, 2195
Jefsey == Jefsey Morfin [EMAIL PROTECTED] writes:
Jefsey At 05:52 06/09/2006, Sam Hartman wrote:
I want to be able to give you a URL and have you resolve it.
That only works if we speak the same transport protocol.
I want people to be able to reference HTTP and get
Robert == Robert Sayre [EMAIL PROTECTED] writes:
Robert On 9/5/06, Sam Hartman [EMAIL PROTECTED] wrote:
I want to be able to give you a URL and have you resolve it.
That only works if we speak the same transport protocol.
Robert Disagree. The Internet is pretty compelling, so
Robert == Robert Sayre [EMAIL PROTECTED] writes:
Robert On 9/6/06, Keith Moore moore@cs.utk.edu wrote:
A significant proportion of HTTP traffic takes place over
non TCP protocols today.
yes, but only as a client-to-proxy protocol. you won't find
many web
Robert == Robert Sayre [EMAIL PROTECTED] writes:
Robert It's not obvious to me why we would to change the concrete
Robert definition of interoperability in RFC2026 to an
I don't think anyone is proposing changing the definition: For the
purposes of this section, interoperable means to
Pekka == Pekka Savola [EMAIL PROTECTED] writes:
Pekka On Fri, 1 Sep 2006, Sam Hartman wrote:
Pekka == Pekka Savola [EMAIL PROTECTED] writes:
Pekka I do not agree with the assessment that there is community
Pekka consensus to turn this to BCP right out.
Would you
So, I was reading Brian's draft and I noticed that it talks a lot
about interoperability, but does not actually define interoperability.
As discussed in a recent IESG appeal, it's not clear that we have a
clear statement of our interoperability goals. There's some text in
section 4 of RFC
Robert == Robert Sayre [EMAIL PROTECTED] writes:
Robert On 9/5/06, Sam Hartman [EMAIL PROTECTED] wrote:
There are a lot of complexities--for example while we hope
every IP stack works with every other IP stack, two machines
may not share a common upper-layer protocol
Jefsey == Jefsey Morfin [EMAIL PROTECTED] writes:
Jefsey At 21:56 05/09/2006, Sam Hartman wrote:
To be clear, I think I'm documenting what is a long-standing
consensus in the IETF. And I do consider it a bug that HTTP
does not require TCP. It's typical for protocols
Jari == Jari Arkko [EMAIL PROTECTED] writes:
Jari Dave, I'm generally happy with the Nomcom process (and I
Jari believe its a better alternative than direct voting).
Jari However, I do agree with you that making the candidate list
Jari public would be useful.
Me too.
Pekka == Pekka Savola [EMAIL PROTECTED] writes:
Pekka I do not agree with the assessment that there is community
Pekka consensus to turn this to BCP right out.
Thanks for the input.
That's why we asked:-)
Would you be sufficiently interested in the experiment to write text
if
Mark == Mark Townsley [EMAIL PROTECTED] writes:
Mark Sam Hartman wrote:
I notice that this transport provides no authentication of the
data that is retrieved.
The security considerations needs to discuss the potential
attacks if an attacker modifies this public data
Gray, == Gray, Eric [EMAIL PROTECTED] writes:
Gray, Sam, I thought the Security Area Directorate was limited to
Gray, determining if the description of security risks is
Gray, adequate and that determination of whether security is
Gray, adequate - for adequately described
Andrew == Andrew Newton [EMAIL PROTECTED] writes:
Andrew Sam,
Andrew For the second case, you are referring to BCP 38, correct?
Andrew This was mentioned on the wg list by William Leibzon, and
Andrew should have been incorporated into the draft. Thanks for
Andrew noting
I notice that this transport provides no authentication of the data
that is retrieved.
The security considerations needs to discuss the potential attacks if
an attacker modifies this public data. The security considerations
section also needs to point to best practice for avoiding UDP
Harald == Harald Alvestrand [EMAIL PROTECTED] writes:
Harald I regard a 6-month ritual of: 1) Unsuspending Jefsey from
Harald ietf-languages 2) Waiting until Jefsey discovers his
Harald unsuspension 3) Wading through Jefsey posts until
Harald everyone's sure he's still as
Brian == Brian E Carpenter [EMAIL PROTECTED] writes:
Brian This is a personal draft written following some discussion
Brian in the recent General Area open meeting. Comments welcome.
Brian I am already aware that it needs to be reconciled with
Brian
Pete == Pete Resnick [EMAIL PROTECTED] writes:
Pete On 7/18/06 at 11:13 AM +0200, Brian E Carpenter wrote:
Speaking only for myself, I have always read the words Further
recourse is available... at the beginning of section 6.5.3 of
RFC 2026 to mean that an appeal to the ISOC
I do not support Stewart's comment.
However I will note that our current process requires the rfc-editor
to accept ASCII input along with non-normative PDF or PostScript
input. The SOW should reflect this current practice.
___
Ietf mailing list
I don't think the IESg intended to imply that the IETF does not care
about human rights.
The IETF does have its own process rules intended to insure fairness,
and section 6.5.3 of RFC 2026 provides relief in cases where those
rules are inadequate.
However the IESG at least believes that while
Bob == Bob Braden [EMAIL PROTECTED] writes:
BobWhile the IETF needs to be able to manage its revenue
Bob streams against its expense expectations, it also needs to
Bob respect the needs of supporting organizations to manage their
Bob own affairs. That is, the text above
Bob == Bob Braden [EMAIL PROTECTED] writes:
Bob I must confess that I did not quite understand your concerns
Bob (my fault, I am sure). Some discussions of the IETF
Bob administrative functions have bordered on micro-management, I
Bob believe, but I did not intend to suggest
I'd like to second John's comments here. I'm here to do technical
work. Over the last six months I've had to spend a lot of time on
process issuse. I won't be able to do that for a while.
Frankly, the fact that I feel things are working well enough that I
can go focus on technical work says
Hi. I sent in some comments a while back and they sparked a lively
discussion. However I don't think I made the point I was trying to
make successfully and think because of lack of clarity on my part my
point came out much more controversial than I had hoped.
So, here's try #2.
First, I
secIETF == IETF Secretariat [EMAIL PROTECTED] writes:
secIETF * Only HTTP, SMTP, FTP, and DNS traffic are permitted through an
IPv6
secIETF Native firewall (pings, traceroutes etc. are dropped)
Please make sure that ICMP messages needed for path MTU discovery are
not
Alper == Alper Yegin [EMAIL PROTECTED] writes:
Yes, that individual I-D is productized as a proprietary
protocol by one company (Cisco).
As I understand it, EAP over UDP is one of the items proposed
for standardization in the NEA WG.
Alper You misunderstood it,
Ralph == Ralph Droms [EMAIL PROTECTED] writes:
Ralph What is the current state of the nea WG? I don't see it
Ralph listed at http://ietf.org/html.charters/wg-dir.html
It had a BOF at the last IETF.
It seems highly likely it will either have a proposed WG or BOF again.
(Russ and I have
Bernard == Bernard Aboba [EMAIL PROTECTED] writes:
My question is more why do they need EAP in situations where
they are not running at the link layer than why do they want or
not want PANA.
Bernard The simple answer is that there are situations which IEEE
Bernard 802.1X
Pete == Pete Resnick [EMAIL PROTECTED] writes:
Pete On 5/25/06 at 4:30 PM -0400, Sam Hartman wrote:
Ultimately, the rfc-editor function needs to be accountable to
the IETF community because we're the ones paying for it.
Pete Sam, I'm sorry, but this is completely unadulterated
Narayanan, == Narayanan, Vidya [EMAIL PROTECTED] writes:
Narayanan, I fully agree. As far as I can tell, using EAP in this
Narayanan, manner merely reduces it to a posture transport
Narayanan, protocol. The level of security provided by EAPoUDP
Narayanan, does not seem to be any
Gray, == Gray, Eric [EMAIL PROTECTED] writes:
Gray, For those of us that are just trying to follow this
Gray, discussion, what does the word posture mean in this
Gray, context?
Assertions about your OS state--things like patch levels,
configuration of security settings, etc.
I finished reading the RFC editor document and have one major concern.
Ultimately, the rfc-editor function needs to be accountable to the
IETF community because we're the ones paying for it.
In particular I believe that the IETF should be able to pass a BCP
placing requirements on an
Leslie == Leslie Daigle [EMAIL PROTECTED] writes:
Leslie Sam,
Leslie Some high-level responses, and I'm sure we'll hear other
Leslie input:
Leslie 1/ I think you're overlooking something in IETF pays for
Leslie RFC Editor; RFC Editor has been paid by ISOC for years,
Hi. Speaking as an individual, I'd like to make an explicit call for
members of the IETF community not involved in the PANA working group
to review draft-ietf-pana-framework. Please speak up if you have done
such a review or attempted such a review and been unsuccessful. Let
us know what you
Hello.
I'd like to draw your attention te the following BOF proposal. Please
discuss on [EMAIL PROTECTED] I'd appreciate comments and
indications of interest.
I'd also like to draw your attention to two resources besides the BOF proposal:
Russ == Russ Housley [EMAIL PROTECTED] writes:
Russ I am concerned that the current RFC Editor practice that
Russ limits the number of authors is in conflict with the IETF
Russ IPR policies. The RFC Editor currently limits the author
Russ count to five people. Recent IPR WG
Russ == Russ Housley [EMAIL PROTECTED] writes:
Russ Sam: We need a way to track the people that have copyright
Russ interest. I had always assumed this was the author list.
Russ If we are going to continue to limit the author count to
Russ five people, then there needs to be a
Vijay == Vijay Devarapallli [EMAIL PROTECTED] writes:
Vijay On 5/24/06, Bob Braden [EMAIL PROTECTED] wrote:
* That means if you have unlisted authors who have contributed
* significant chunks of text, you still need to get their
clearance to * do anything
Russ == Russ Housley [EMAIL PROTECTED] writes:
Russ Sam: If the people with copyright interest are the
Russ combination of the authors plus the contributors, then we
Russ need to specify this in a BCP.
The people with copyright interest are whoever the court decides have
copyright
John, does the text I proposed to address Margaret's concern (making
it clear that this will not become a permanent BCP), plus the review
requirements proposed by Harald, plus the work started by Brian to
build community consensus on a new set of mailing list procedures help
address your concerns?
Keith == Keith Moore moore@cs.utk.edu writes:
REQ-8: If application transparency is most important, it is
RECOMMENDED that a NAT have an Endpoint independent filtering
behavior. If a more stringent filtering behavior is most
important, it is RECOMMENDED that a NAT have an
Margaret == Margaret Wasserman [EMAIL PROTECTED] writes:
Margaret This document defines an RFC3933 experiment in which we
Margaret would temporarily give the IESG the authority to create
Margaret new mailing list management procedures and enact them.
Margaret The only hard
cases
what I
Harald think will happen is that the IESG will start off with procedures
Harald designed by Sam Hartman, and the big difference is that the
community
Harald will have seen the initial procedures before deciding to run the
Harald experiment.
Harald The whole IETF
John == John C Klensin [EMAIL PROTECTED] writes:
John (2) If they are successful, efforts like this also generate
John specific proposals for change. But we have had many
John specific proposals for change in the time since the work
John that led to RFC 3774 was concluded. In
Frank == Frank Ellermann [EMAIL PROTECTED] writes:
Frank IMHO Sam's proposal was meant to help Randy and Harald (as
Frank the list-moms of two affected lists), and the IESG with a
Frank certain situation (RfC 3934 not good enough, 3683 too
Frank disruptive) - as it turned out the
Frank == Frank Ellermann [EMAIL PROTECTED] writes:
Frank Henrik Levkowetz wrote:
Please provide more data (off-list) as this seems odd.
Frank Will do (ordinary moderation bounce), but on list I should
Frank fix the bogus URLs I've posted here (I forgot one gmane,
Frank
Hi.
I gave a presentation at genarea today and commented that I strongly
felt like giving up on any participation in process change efforts as
a lost cause.
I want to explain what is frustrating me and to explain what is not frustrating
me.
Several people said that I need to get more review
Ed == Ed Juskevicius [EMAIL PROTECTED] writes:
Ed I wonder if part of the reason is we often resort to a modus
Ed operandi of let a thousand flowers bloom and let the market
Ed decide for contentious issues. While that *might* work for a
Ed technology spec, it clearly is not a
Robert, Scott and Paul, is there any chance you could sit down and try to work
this out?
I read Robert's two messages to the working group list and I do find
them fairly hard to follow. They don't explain why he's angry at a
specific organization or what the supposed process failure is.
If he
Elwyn == Elwyn Davies [EMAIL PROTECTED] writes:
Elwyn I was selected as General Area Review Team reviewer for
Elwyn this specification (for background on Gen-ART, please see
Elwyn http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Hi.
I'm sorry it has taken me so long to get
JFC == JFC (Jefsey) Morfin [EMAIL PROTECTED] writes:
JFC I think we all are in agreement except on an idea Eudardo
JFC Mendez gave me. I will rephrase it as if someting tastes as
JFC a WG, smells like a WG, its charter should be approved like
JFC for a WG. The non-WG list is only
JFC == JFC (Jefsey) Morfin [EMAIL PROTECTED] writes:
JFC At 23:53 22/02/2006, Sam Hartman wrote:
JFC == JFC (Jefsey) Morfin [EMAIL PROTECTED] writes:
JFC I think we all are in agreement except on an idea Eudardo
JFC Mendez gave me. I will rephrase it as if someting tastes
401 - 500 of 746 matches
Mail list logo
