todd glassey wrote:
So let me ask the obvious thing... why is the RFP content being voted on?
This is a business decision in regard to services and process. Why is any of
it open to review inside the IETF?
Because the lunatics want to run the asylum? ;-)
Seriously though, it seems to me that
So let me ask the obvious thing... why is the RFP content being voted on?
This is a business decision in regard to services and process. Why is any of
it open to review inside the IETF?
Todd
- Original Message -
From: "John C Klensin" <[EMAIL PROTECTED]>
To: "Ted Hardie" <[EMAIL PROTECTED
--On Wednesday, 26 July, 2006 13:58 -0700 Ted Hardie
<[EMAIL PROTECTED]> wrote:
> At 3:28 PM -0400 7/26/06, John C Klensin wrote:
>> The other is that, to some readers, it appears to impose
>> binding requirements on how the RFC Editor deals with input
>> from the IESG, either directly (as in "i
Just out of curiosity - does anyone anticipate adding RSS feeds?
T.
- Original Message -
From: "Ted Hardie" <[EMAIL PROTECTED]>
To: "John C Klensin" <[EMAIL PROTECTED]>; "Jeffrey Hutzelman"
<[EMAIL PROTECTED]>; "Allison Mankin" <[EMAIL PROTECTED]>; "IETF Administrative
Director" <[EMAIL P
At 3:28 PM -0400 7/26/06, John C Klensin wrote:
>The other is that, to some readers, it appears to impose binding
>requirements on how the RFC Editor deals with input from the
>IESG, either directly (as in "if we recommend that this text be
>inserted, you must insert it or not publish") or indirect
No Allison - contracts are not what happens when people deal in bad faith -
court battles are. Contracts are what happen when two or more parties want
the formal relationship between them defined and their roles and
responsibilities too.
More inline
- Original Message -
From: "Allison Ma
So someone submits something to the IETF for standardization that is
patented or that they intend to patent. But in the process of submitting the
work-product to the IETF for publication it is altered by the editor's both
in form and in functionality. Now, the patent examiner cant track the IETF's
Phillip - All -
the inclusion of critical Use Guidelines are critical to creating real
standards as opposed to general purpose recommendations. The other side of
the coin is in including value - and the Trust wants its IP to be worth as
much as possible. That said it is totally reasonable to requir
In making it easier to follow this obtuse and convoluted solicitation
document, the other thing is that the HISTORY section needs to go - go
elsewhere - and I personally don't ever need to see it again in the RFP
itself.
The RFP is a formal solicitation for participation or services - it is step
o
> > NEW:
> > As required by RFC 2026, submit document to IESG for review of
> > conflicts or confusion with IETF process, end runs around working
> > group activities, and obvious and significant harm to the Internet
> On balance I don't think the 2026 reference is needed - we wil
--On Wednesday, 26 July, 2006 11:40 -0700 Ted Hardie
<[EMAIL PROTECTED]> wrote:
>> Given those actual or imagined chains of authority, it doesn't
>> take very many steps to get to "the IESG can tell ISOC what to
>> write into and 'RFC Editor' RFP and can tell the IAOC how to
>> interpret that co
>Given those actual or imagined chains of authority, it doesn't
>take very many steps to get to "the IESG can tell ISOC what to
>write into and 'RFC Editor' RFP and can tell the IAOC how to
>interpret that contract". That is a problem because some of us
>who believe in independent submissions beli
--On Tuesday, 25 July, 2006 20:09 -0400 Jeffrey Hutzelman
<[EMAIL PROTECTED]> wrote:
>...
>> But at least
>> some of us believe that making the approval process or content
>> of RFCs that do not arise from IETF processes subsidiary to
>> the IESG would not be in the best interests of the Interne
It has been pointed out to me that the second sentence is unintentionally
ambiguous.
The point I was making is that when the spec has the examples included it is
much more likely to result in successful interop than the case where the spec
has no examples.
Although I generated the initial exa
--On Tuesday, 25 July, 2006 16:49 -0700 Ted Hardie
<[EMAIL PROTECTED]> wrote:
> At 7:25 PM -0400 7/25/06, John C Klensin wrote:
>> And the IETF/IASA can issue an RFP for IETF
>> publications and publishing any time it likes, specifying
>> whatever conditions it likes. _That_ is perfectly normal
At 8:56 AM -0400 7/26/06, Leslie Daigle wrote:
>[*] This is perhaps a reasonable time to reiterate that
>the IAB is, in fact, a separate entity from the IETF organization.
>
With respect, I believe that the formulation "separate entity"
is a bit too simple for the relationship of the IAB and the I
I provided these examples in XKMS and the general feedback on doing so was very
positive. We found that implementations were much more likely to interop having
been written from the spec alone than without the examples. It also helped
identify ambiguities in the specification as people reported
I tried to get this in place several years ago by requesting that the IETF
require specific Use Statements which could be used to accurately reproduce
the technologies in the RFC's or Standards and it wasn't too interested in
that at the time.
The problem is that with the many languages of the sub
Ahahahah - You know Russ - its amazing how WRONG you possibly could be with
that big and powerful Stanford AUP under your belt...
- Original Message -
From: "Russ Allbery" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, July 25, 2006 10:33 PM
Subject: Re: Flaw in the NOTEWell System makes NOTEWEL
Hi,
I am currently debugging some ISAKMP problems and thus using RFCs like
2085, 2412, etc. about cryptographic algorithms and data formats.
Such RFCs are sometimes a little bit ambiguous or difficult to read
since details are spread around the paper. When implementing such
algorithms or data
Actually:
. since the existence of the IASA (last year),
the ISOC BoT has been asked to support the RFC Editor
as part of what IASA supports -- IETF *and* IAB (and IRTF).
. as part of the initial proposal of 2007 budget for IASA,
to the ISOC BoT, on
I'm going to comment on Allison's original posting, since the target
is specific text changes to the RFP. (I have read the follow-ups).
Allison Mankin wrote:
Hi, Ray, and all,
I read the SOW earlier to check that it matched with the
draft-mankin-pub-req-10 (output of techspec), but I've now
giv
Ted is correct. The "harm to the Internet" text is wrong -
it isn't mentioned on 2026 and it is excluded from consideration
by 3932 - but we shouldn't mix fixing that bug in the RFP
with fixing the procedural issues.
Brian
Ted Hardie wrote:
At 7:25 PM -0400 7/25/06, John C Klensin wrote:
23 matches
Mail list logo
