I'd like to draw the attention of the community to section 3 of
draft-ietf-syslog-protocol-21.txt. This text contains text and a
clarified model of the various layers in the syslog architecture and
new terminology for the parties.
I believe this is responsive to the ietf last call comments and
Dave Crocker wrote:
>
>
> This goes to the heart of the current paradigm problem with IETF
> decision-making: There is nearly exclusive concern about preventing
> all cases of problems, no matter how occasional or minor, with little
> apparent concern for the affirmative need to *faciliate* progr
>> There is nearly exclusive concern about preventing all cases of
>> problems, no matter how occasional or minor, with little apparent
>> concern for the affirmative need to *faciliate* progress.
>>
>
> True. If IP had been subject to the same level of scrutiny that is
> applied to Identifie
Thomas Narten wrote:
If a respected security expert (one who has reviewed many documents,
contributed significantly to WG efforts, etc.) comes to a WG and says
"there is a problem here", but 5 WG members stand up and say "I
disagree and don't see a problem", do you really expect the security
exp
At 8:50 PM +0700 6/15/07, Robert Elz wrote:
And in this case, this is exactly the point. IANA is the
INTERNET Assigned Numbers Authority, not the IETF Assigned Numbers
Authority - and the code points it assigns and the registries it
maintains are used by the Internet as a whole, not just that p
At 12:10 PM +0300 6/15/07, <[EMAIL PROTECTED]> wrote:
Paul Hoffman wrote:
Why not? As long as the reader of the IANA registry can ascertain
which codepoint owner is at a particular level, how would that affect
interop?
Being able to ascertain what the level is isn't enough; you also
need t
At 8:58 AM +0200 6/15/07, Harald Alvestrand wrote:
>But I believe that in neither that page nor in RFC 3935 did we ever commit the
>fallacy of saying "one man, one vote".
>How the weight one gives to opinions is distributed varies, I believe - both
>from case to case and from person to person - b
> "Robert" == Robert Elz <[EMAIL PROTECTED]> writes:
Robert> Date:Fri, 15 Jun 2007 09:28:29 -0400
Robert> From:Thomas Narten <[EMAIL PROTECTED]>
Robert> Message-ID: <[EMAIL PROTECTED]>
Robert> | Um, this train left the station a LONG time ago. RF
Am I confused? The allocation required an IETF Consensus. A consensus
was determined and the code point allocated. How can it make any
difference if the consensus determination is later reversed? Why should
it make a difference to that allocation if the reversal occurred before
or after the RFC was
Date:Fri, 15 Jun 2007 09:28:29 -0400
From:Thomas Narten <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| Um, this train left the station a LONG time ago. RFC 2434 (and
| existing practice) have given the role of approving assignments to the
| technical/proto
Robert Elz <[EMAIL PROTECTED]> writes:
> Date:Thu, 14 Jun 2007 17:08:13 -0700
> From:Thomas Narten <[EMAIL PROTECTED]>
> Message-ID: <[EMAIL PROTECTED]>
> | (Now would be an excellent time to
> | consider updates/clarifications to the above text.)
> Aside from th
<[EMAIL PROTECTED]> writes:
> Thomas Narten wrote:
> > If the above text were in effect today, would it be sufficient to
> > cover the situation at issue here? (Now would be an excellent time
> > to consider updates/clarifications to the above text.)
> I don't think so. The text allows IESG to o
Date:Thu, 14 Jun 2007 17:08:13 -0700
From:Thomas Narten <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| (Now would be an excellent time to
| consider updates/clarifications to the above text.)
Aside from the minor problem that the paragraph you quoted is way
Total of 90 messages in the last 7 days.
script run at: Fri Jun 15 00:53:02 EDT 2007
Messages | Bytes| Who
+--++--+
10.00% |9 | 11.62% |62650 | [EMAIL PROTECTED]
7.78% |7 | 7.37% |39742 | [EMAIL PROTECTED
On 2007-06-15 10:25, [EMAIL PROTECTED] wrote:
Thomas Narten wrote:
If the above text were in effect today, would it be sufficient to
cover the situation at issue here? (Now would be an excellent time
to consider updates/clarifications to the above text.)
I don't think so. The text allows IESG
Bernard,
I think your proposal is worth thinking about. The current BOF process
is very on/off in its nature. One of the problems that it is causing is that
when work is not far enough, a BOF or WG cannot be established. This
in turns leave the perception that the IETF is completely ignoring the
t
Bernard,
Speaking as a participant in both the IETF and IEEE 802, there are many
things that I like in the CFI / Study Group process of IEEE. Your
proposal goes in the direction of solving one of the problems I perceive
in the IETF processes which is the lack of repeatability and
predictability (
Paul Hoffman wrote:
> Why not? As long as the reader of the IANA registry can ascertain
> which codepoint owner is at a particular level, how would that affect
> interop?
Being able to ascertain what the level is isn't enough; you also
need to know (and more importantly, care) about the differ
Thomas Narten wrote:
> If the above text were in effect today, would it be sufficient to
> cover the situation at issue here? (Now would be an excellent time
> to consider updates/clarifications to the above text.)
I don't think so. The text allows IESG to override the allocation
procedures when
On Tue, Jun 12, 2007 at 09:52:58AM -0700,
Dave Crocker <[EMAIL PROTECTED]> wrote
a message of 37 lines which said:
> There is nearly exclusive concern about preventing all cases of
> problems, no matter how occasional or minor, with little apparent
> concern for the affirmative need to *facilia
20 matches
Mail list logo
