On Thu, 7 Sep 2006, Stewart Bryant wrote:
The nomcom pool is in my view very much at the low water mark So an
extension to Ralph's idea would be for the Secretatiat to send a direct
mail to all those who are eligable to say that they are eligable for this
important task and invite them to volunt
Ralph Droms wrote:
Perhaps we could avoid similar delays in generating the final list of
volunteers in the future:
Secretariat generates a list of eligible volunteers as early as possible
(As far as I know, eligibility data is available well before call for
volunteers is posted)
List is used
Ned Freed wrote:
>> Ned,
>>
>>> Dave, I'm sorry, but it didn't show that at all. The specific problem
>>> that
>>> arose here WAS anticipated and analyzed and the correct thing to do in
>>> this case
>>> WAS determined and documented. See RFC 3797 section 5.1 for specifics.
>>>
>
>
>
Perhaps we could avoid similar delays in generating the final list of
volunteers in the future:
Secretariat generates a list of eligible volunteers as early as possible
(As far as I know, eligibility data is available well before call for
volunteers is posted)
List is used to verify volunte
At 21:55 06/09/2006, Sam Hartman wrote:
>I don't think anyone is proposing changing the definition: For the
>purposes of this section, "interoperable" means to be functionally
>equivalent or interchangeable components of the system or process in i
>which they are used.
>
>
>I think we are discus
On Wednesday, September 06, 2006 02:08:06 PM -0700 "Hallam-Baker, Phillip"
<[EMAIL PROTECTED]> wrote:
One simple fix here would be to publish the list on IETF announce BEFORE
it goes to the secretariat and to ONLY use that list regardless of
whether people are excluded or not.
I like that
The IAOC has received and accepted bids from three parties in response to
the RFC Editor RFP.
Those three are:
1. The Information Sciences Institute, University of Southern California,
Marina del Ray, California, USA, the incumbent
2. Standcore LLC, Trumansburg, New York, USA
3. Wipro Technolog
One simple fix here would be to publish the list on IETF announce BEFORE it
goes to the secretariat and to ONLY use that list regardless of whether people
are excluded or not.
This still leaves the question of what to do if people were left off the list
and need to be added in.
Another safeg
On 9/6/06, Robert Sayre <[EMAIL PROTECTED]> wrote:
So the definition of "supports universal interoperability" is "I know
it when I see it"? Which IETF protocols are universally interoperable?
I think of SMTP and HTTP.
I also asked you two questions. Here is the second:
And why would we put the
> Ned,
> > Dave, I'm sorry, but it didn't show that at all. The specific problem
> > that
> > arose here WAS anticipated and analyzed and the correct thing to do in
> > this case
> > WAS determined and documented. See RFC 3797 section 5.1 for specifics.
> I don't know how many ways I can say this,
On 9/6/06, Sam Hartman <[EMAIL PROTECTED]> wrote:
> "Robert" == Robert Sayre <[EMAIL PROTECTED]> writes:
Robert> How do we test "universal interoperability"? MUSTs need to
Robert> be testable.
Musts do not need to be testable.
So the definition of "supports universal interoperabil
On 9/6/06, Sam Hartman <[EMAIL PROTECTED]> wrote:
I think we are discussing consequences of that definition that are
non-obvious. RFC 2026 requires that two interoperable implementations
exist. However I believe that there is a strong IETF consensus that
our specs need to support universal int
> "Robert" == Robert Sayre <[EMAIL PROTECTED]> writes:
Robert> How do we test "universal interoperability"? MUSTs need to
Robert> be testable.
Musts do not need to be testable. Features and options of protocols
need to be testable.
___
Ie
> "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
On 9/6/06, Sam Hartman <[EMAIL PROTECTED]> wrote:
> "Robert" == Robert Sayre <[EMAIL PROTECTED]> writes:
Robert> I think we're off on a tangent. Requiring TCP wouldn't
Robert> change any of the realities we're discussing,
Agreed.
Robert> so it's not
Robert> a bug in the HTTP
> "Robert" == Robert Sayre <[EMAIL PROTECTED]> writes:
Robert> On 9/6/06, Keith Moore 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 reso
On 9/6/06, Keith Moore wrote:
Of course it's useful to be able to run SMTP, HTTP, etc. over other
transports for special purposes. But a distinction needs to be made
between "SMTP specification" and "how to send Internet email", and
between "HTTP specification" and "how to make web resources a
> On 9/6/06, Keith Moore wrote:
> >
> > HTTP proxies do exist but the only reason that they can work
> > effectively is that the vast majority of web resources are accessible
> > through a common medium - namely the public IPv4 Internet and TCP.
>
> Right. But that is a natural occurrence, not th
On 9/6/06, Keith Moore 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 resources
hosted on cell phones.
This is true, but there are many other non-TCP HTTP deployments, like
som
> Keith is as often the case dead wrong.
Phill, when you criticize me, it only serves to enhance my reputation. :)
> HTTP works fine over non TCP/IP protocols and the ability to do so was pretty
> important in 1991 when IP was not considered the one true protocol.
Yes, HTTP can work fine over o
The Applications Area is soliciting volunteers willing to serve as the
IANA charset reviewer. This position entails reviewing charset registrations
submitted to IANA in accordance with the procedures set out in
RFC 2978. It requires the reviewer to monitor discussion on the
ietf-charsets mailing
Eliot Lear wrote:
I don't know how many ways I can say this, but 5.1 is irrelevant to the
problem I was concerned about, which is having the pool come out at the
same time as the results.
right. and that brings things back to the principles I cited.
d/
--
Dave Crocker
Brandenburg Int
Ned,
> Dave, I'm sorry, but it didn't show that at all. The specific problem
> that
> arose here WAS anticipated and analyzed and the correct thing to do in
> this case
> WAS determined and documented. See RFC 3797 section 5.1 for specifics.
I don't know how many ways I can say this, but 5.1 is ir
Just to clarify here there were two problems:
1) The list was not published on time
2) There was an unqualified person on the list.
Neither flaw by itself was fatal. However the combination meant that there was
no situation where the process was entirely deterministic as intended.
Since the lis
> From: Ned Freed [mailto:[EMAIL PROTECTED]
> > Brian E Carpenter wrote:
> > > This isn't a call for bureaucracy, but for precision. As
> this year's
> > > glitch shows, extreme precision is needed in the rules.
>
>
> > Interesting. What it showed me is that we cannot anticipate every
> >
At 17:35 06/09/2006, Keith Moore wrote:
>If the web were split across several networks with dissimilar
>characteristics, it would be much more difficult to arrange seamless
>access via proxies.
The "if" is the reality. Forgetting about it does simplifies things.
This is like computing the tr
At 15:30 06/09/2006, Sam Hartman wrote:
> Jefsey> - either you consider the Internet as Harald Alvestrand
> Jefsey> considers it in RFC 3935: something the IETF leaders
> Jefsey> influence the building along their values. This vision is
> Jefsey> OK with me as long as this Intern
Ned,
Ned Freed wrote:
Interesting. What it showed me is that we cannot anticipate every
contingency.
Dave, I'm sorry, but it didn't show that at all. The specific problem
that arose here WAS anticipated and analyzed and the correct thing to
do in this case WAS determined and documented. See R
Brian E Carpenter wrote:
> This isn't a call for bureaucracy, but for precision. As this year's glitch
> shows, extreme precision is needed in the rules.
Interesting. What it showed me is that we cannot anticipate every
contingency.
Dave, I'm sorry, but it didn't show that at all. The sp
Accountability through Auditability is the watchphrase... no closed
processes - no one operates in a vacuum - no more secrets. Everyone votes
and everyone plays... that is the way its supposed to be right?
Todd
- Original Message -
From: "Hallam-Baker, Phillip" <[EMAIL PROTECTED]>
To: <[E
Brian E Carpenter wrote:
Hence what it showed me is that we need better statement of principles
and less effort to try to specify every problem and solution that
might ever occur.
I don't think that is inconsistent with the need for precision. It's
ambiguity that leads to problems - for exam
> From: Dave Crocker [mailto:[EMAIL PROTECTED]
>
> Brian E Carpenter wrote:
> > This isn't a call for bureaucracy, but for precision. As
> this year's
> > glitch shows, extreme precision is needed in the rules.
>
>
> Interesting. What it showed me is that we cannot anticipate
> every conti
On 9/6/06, Keith Moore wrote:
HTTP proxies do exist but the only reason that they can work
effectively is that the vast majority of web resources are accessible
through a common medium - namely the public IPv4 Internet and TCP.
Right. But that is a natural occurrence, not the result of
bureau
Dave Crocker wrote:
Brian E Carpenter wrote:
This isn't a call for bureaucracy, but for precision. As this year's
glitch
shows, extreme precision is needed in the rules.
Interesting. What it showed me is that we cannot anticipate every
contingency.
Hence what it showed me is that we
Keith is as often the case dead wrong.
HTTP works fine over non TCP/IP protocols and the ability to do so was pretty
important in 1991 when IP was not considered the one true protocol.
The protocol that IS essential to the working of HTTP is in fact DNS. HTTP and
URIs depend upon there being a
Brian E Carpenter wrote:
This isn't a call for bureaucracy, but for precision. As this year's glitch
shows, extreme precision is needed in the rules.
Interesting. What it showed me is that we cannot anticipate every
contingency.
Hence what it showed me is that we need better statement o
Hi,
On Sep 6, 2006, at 12:22, Edward Lewis wrote:
E.g., if Brad Pitt were under consideration for the Hollywood Area
and he was up against a little known Joe Blow, the Nomcom might
also seek information about Robert Redford and Paul Newman (and
others) to throw everyone off the trail that B
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.
Disagree. The Internet is pretty compelling, so proxies can and do
bridge transport protocols. Applications using the HTTP stack don't
need to know or care about the lower level
On 9/6/06, Sam Hartman <[EMAIL PROTECTED]> wrote:
> "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 pr
> "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 prett
> "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 H
Brian E Carpenter wrote:
> 3464 is already DS according to the RFC Index.
Good, the process works, unlike my memory: I meant 3834,
a few days ago I wrote 3864 instead of 3834 on another
list, so that's the third attempt: 3834.
[interoperability report]
> if {all mandatory and optional features
Brian E Carpenter wrote:
Okay, let's nail this, I like to see 2195 and 3464 as DS,
what exactly can I do ?
3464 is already DS according to the RFC Index.
For 2195, write and publish an interoperability report,
SASL WG is revision it (draft-ietf-sasl-crammd5-07.txt).
And no, this document is
Edward Lewis wrote:
...
I don't think it makes much of a difference in the outcome of the nomcom
if names are published or not. (OTOH it is yet another perennial issue
to blow bits on a mailing list about.) How about we just try it once
and see what happens - all that stuff about running cod
C. M. Heard wrote:
> Having just re-read the charter, I would have to say so. I think we
> would have been better served if the WG had been given the much less
> ambitious task of producing an update of RFC 2026 that describes what
> we actually do.
>
What we actually do is a one step process.
Pasi,
That's correct. But as you presumably know, RFC 3967
offers a way of dealing with that problem. See
http://www1.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry
for results so far.
Brian
[EMAIL PROTECTED] wrote:
Brian,
Your description of the process omitted the most
time-consumi
Assertion:
The IETF still operates as if no other body exists.
Fact:
http://www.ietf.org/liaisonActivities.html
Brian
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
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 interoperability,
>not to have to write a profile of http.
Sam,
there are severa
Brian,
Your description of the process omitted the most
time-consuming part:
for {each normative reference}
if {at lower maturity level AND downref acceptable}
then {write justification why downref is acceptable}
else {repeat process recursively to bring reference to DS}
A whi
From my time on the nomcom I'll register this observation.
Keeping the names secret (or at least obfuscated) makes the process a
popularity contest. Not like a high school class president
popularity contest, but, putting the nomcom into a passive-mode
request for information posture usually o
Okay, let's nail this, I like to see 2195 and 3464 as DS,
what exactly can I do ?
3464 is already DS according to the RFC Index.
For 2195, write and publish an interoperability report, and
if {all mandatory and optional features shown to interoperate}
then {send a request to reclassify R
On Sep 6, 2006, at 5:58, Sam Hartman wrote:
"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
Sam gave me a heads up this comment was coming (on the last day
of the Last Call, as it happens) so I had the chance to think about
it overnight.
We certainly could use clarity in this area. I also have some comments
about the meaning of interoperable implementations in
draft-carpenter-rfc2026-cr
Eliot Lear wrote:
> few if any specifications get to draft or full standard,
> and no review of PS had ever been done along the timelines
> specified in RFC 2026.
Okay, let's nail this, I like to see 2195 and 3464 as DS,
what exactly can I do ?
> Numerous proposals were made within the working g
Sam Hartman wrote:
"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> publi
55 matches
Mail list logo
