Hallam-Baker, Phillip wrote:
For what it is worth my takehome from the Montreal meeting was that there was
genuine desire for change but no recognition of consensus on a particular way
forward.
One of the reasons that there is no recognition of consensus on a way forward
is that we did not
On Tue Sep 19 22:31:40 2006, Dave Crocker wrote:
I would argue that Proposed Standard as the end-of-the-line
in our standardization process is just wrong. I certainly can see
an argument for merging Proposed and Draft - but there are lots
of indications that even the simplified one-step
Brian,
There was consensus to put forward the ISD proposal, which the IESG
kicked
back, with an explanation of its issues, which you can find in the
newtrk archive. That didn't lead to a revised ISD proposal.
So that it's clear, I am not now nor was I then a proponent of ISDs. I
think
I garbled:
To the IESG's credit you did provide at least
something of a menu of options, but it was
... not clear you would advance a draft even if we advanced one of those
options.
Eliot
___
Ietf mailing list
Ietf@ietf.org
My apologies in advance for posting in this thread.
There was, to recall history, no consensus in newtrk for any particular
choice among the various options for simplifying the 3 stage process.
So the IESG never saw or responded to any proposal in that area.
My understanding (as author of
Eliot Lear wrote:
I garbled:
To the IESG's credit you did provide at least
something of a menu of options, but it was
... not clear you would advance a draft even if we advanced one of those
options.
Well, there wasn't likely to be a blank check promise to advance
a draft, was there?
Brian,
But I think there is a message here - badly phrased perhaps - that
running code is needed for such proposals to be thoroughly considered.
Suppose there was a proposal that all RFCs should be sourced as XML
files. We have a lot of running code to measure that proposal against.
Douglas
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 as a whole,
consider this specification a good thing and recommend it, and We,
as disinterested engineers trying to be
At 02:41 20/09/2006, David Conrad wrote:
Yes, IANA is undertaking to convert all our registries over to XML.
We'll be doing this in an incremental fashion of course, starting
with a few of the simpler registries, getting feedback from people,
revising and doing more registries, getting
Julian,
Everything we were originally planning to take care with notes
to the RFC Editor has been dealt with in draft -15... except
this one. Sorry and thanks for pointing this out again.
We will make sure the RFC Editor changes the text to no longer
make reference to Appendix 4 of RFC 2518.
Brian Carpenter wrote:
http://www1.tools.ietf.org/bof/trac/wiki
This is a best-efforts attempt to track BOF requests (not approved BOFs,
very cool. thanks!
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
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
At 20:38 20/09/2006, David Conrad wrote:
The implication of this is that the entire registry would need to be
fetched, right?Given I'm told the registry under discussion is a
bit on the large-ish size, this might be somewhat problematic.Can
you give me an idea of the anticipated scale of the
http://www1.tools.ietf.org/bof/trac/wiki
This is a best-efforts attempt to track BOF requests (not approved BOFs,
which will be in the official agenda). If you're aware of a BOF request
that isn't listed, please contact the relevant Area Director for status.
The IESG has received a request from the Common Control and Measurement
Plane WG to consider the following document:
- 'RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol
Label Switching (GMPLS)-based Recovery '
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt as
The IESG has approved the following document:
- 'Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0
Revision 1 '
draft-nystrom-ct-kip-02.txt as an Informational RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG
A new Request for Comments is now available in online RFC libraries.
RFC 4675
Title: RADIUS Attributes for Virtual LAN
and Priority Support
Author: P. Congdon, M. Sanchez,
B. Aboba
Status: Standards
A new Request for Comments is now available in online RFC libraries.
RFC 4672
Title: RADIUS Dynamic Authorization Client MIB
Author: S. De Cnodder, N. Jonnala,
M. Chiba
Status: Informational
Date: September
A new Request for Comments is now available in online RFC libraries.
RFC 4656
Title: A One-way Active Measurement Protocol
(OWAMP)
Author: S. Shalunov, B. Teitelbaum,
A. Karp, J. Boote,
M.
A new Request for Comments is now available in online RFC libraries.
RFC 4666
Title: Signaling System 7 (SS7) Message
Transfer Part 3 (MTP3) - User
Adaptation Layer (M3UA)
Author: K. Morneault, Ed.,
A new Request for Comments is now available in online RFC libraries.
RFC 4673
Title: RADIUS Dynamic Authorization Server MIB
Author: S. De Cnodder, N. Jonnala,
M. Chiba
Status: Informational
Date: September
A new Request for Comments is now available in online RFC libraries.
FYI0017
RFC 4677
Title: The Tao of IETF -
A Novice's Guide to the Internet
Engineering Task Force
Author: P. Hoffman, S. Harris
A new Request for Comments is now available in online RFC libraries.
RFC 4613
Title: Media Type Registrations for Downloadable
Sounds for Musical Instrument Digital Interface
(MIDI)
Author: P. Frojdh, U.
A new Request for Comments is now available in online RFC libraries.
RFC 4679
Title: DSL Forum Vendor-Specific RADIUS Attributes
Author: V. Mammoliti, G. Zorn,
P. Arberg, R. Rennison
Status: Informational
Date:
24 matches
Mail list logo
