As Dave Crocker pointed out, this document is, at best, revisionist history.
Dave's original RFC 1603 text (that I carried forward into RFC 2418) bears
little resemblance to the process/considerations described in this ID.
This ID may be describing how we should start to view the meaning of
On Oct 3, 2013, at 6:34 AM, The IESG iesg-secret...@ietf.org wrote:
The IESG has received a request from the Routing Over Low power and Lossy
networks WG (roll) to consider the following document:
- 'Terms used in Ruting for Low power And Lossy Networks'
draft-ietf-roll-terminology-13.txt
, Dave Cridland d...@cridland.net
wrote:
On Thu, Oct 3, 2013 at 12:49 PM, Scott O Bradner s...@sobco.com wrote:
On Oct 3, 2013, at 6:34 AM, The IESG iesg-secret...@ietf.org wrote:
The IESG has received a request from the Routing Over Low power and Lossy
networks WG (roll) to consider
1 April RFCs excepted
Scott
On Oct 2, 2013, at 10:10 AM, Barry Leiba barryle...@computer.org wrote:
because all IETF document are examined by IESG
No they're not. See RFC4844.
Lloyd, it *is* true that all documents in the IETF stream are reviewed
and approved by the IESG. I would take
John covered why I said that Pete's assertion is factually incorrect
that said, I agree that being accurate here (that the IESG is the final decider
and the body that
changed the review from what was described in RFC 2026) may be counter
productive when
the document is reviewed outside of
1/ I believe that change would be factually incorrect
2/ I do not see that being factually correct about what happened says anything
about
the community opinion about any future IESG decision to change processes.
Scott
On Sep 17, 2013, at 6:48 PM, Pete Resnick presn...@qti.qualcomm.com
On Sep 13, 2013, at 2:32 PM, Olaf Kolkman o...@nlnetlabs.nl wrote:
On 13 sep. 2013, at 19:17, S Moonesamy sm+i...@elandsys.com wrote:
The intended status would have to be BCP instead of Informational.
Correct…. fixed on trunk.
In Section 3.1:
A specific action by the IESG
looks good to me except that maybe using the IETF Announce list rather than
IESG minutes as the publication of record
Scott
On Sep 5, 2013, at 1:10 PM, Pete Resnick presn...@qti.qualcomm.com wrote:
Having seen no further comments, Jari has asked me to post -01 with the
changes. Done.
pr
thank you - clarity does help
but such an effort will not remove the need for this document imo
Scott
On Sep 3, 2013, at 9:20 AM, Jari Arkko jari.ar...@piuha.net
wrote:
Olaf, John, Scott,
In fact, going back to the language of RFC2026 for Full (now Internet)
Standard. It confirms that
fwiw - I would love for the IESG to exercise flexibility here
but I have not seen that in many years - so I think we are already there
without a discernible path back
Scott
On Sep 3, 2013, at 4:40 PM, Barry Leiba barryle...@computer.org
wrote:
I mostly agree with this draft, but I have a
On Sep 2, 2013, at 10:23 AM, Jari Arkko jari.ar...@piuha.net wrote:
Olaf, Scott,
Apologies for a late reply on this (I was on vacation after the IETF). But
thank you for writing this draft. My general comment is that the draft makes
what in my mind is an accurate correction to our
correct - except that the IRTF has adopted the same disclosure requirements
Scott
On Nov 6, 2012, at 4:56 PM, Stephan Wenger st...@stewe.org wrote:
On 11.6.2012 16:17 , Scott O Bradner s...@sobco.com wrote:
On Nov 6, 2012, at 10:54 AM, Fred Baker (fred) f...@cisco.com wrote
I have not signed the petition because I did not think it was proper to do so
(as a IAOC member - see Russ's message and RFC 3777)
but, that aside, I do support the petition - I feel that the IAOC has given
Marshal
the full opportunity to start participating again or to resign and he has done
Sam -
The ISOC BoT has generally (with some slip-ups) accepted IETF process
documents as
describing the IETF process - this has been seen as a good idea for the
insurance coverage
there is no requirement in the IETF process that such RFCs be approved by the
ISOC board
nor that they
On Oct 25, 2012, at 11:03 AM, John C Klensin john-i...@jck.com wrote:
(ii) The IESG could use its implied authority to interpret RFC
2026 (an authority it has at least implicitly applied many times
in the past). It could interpret the 2026 variance procedure as
applying to all bodies to
in addition
since there is no admissions control on IDs I would think that the IESG would
want
to reserve the option to remove an ID that contained clear libel or
inappropriate
material (e.g., a pornographic story published as an ID as part of a DoS attack
on the IETF) once the IESG had been
singing this statement is the right thing to do
Scott
(responding to a sorta-last-call)
On Aug 11, 2012, at 2:10 PM, Paul Hoffman wrote:
On Aug 11, 2012, at 5:05 AM, Randy Bush wrote:
The IETF Chair and the IAB Chair intend to sign the Affirmation
of the Modern Global Standards Paradigm,
ah yes - Mac Mail being helpful (again)
:-)
On Aug 11, 2012, at 7:14 PM, Carsten Bormann wrote:
On Aug 12, 2012, at 00:51, Scott O Bradner s...@sobco.com wrote:
singing this statement is the right thing to do
For 0.29 seconds, I imagined you in front of a microphone in a recording
:-)
its a label not a process (in this case)
i.e., according to 2804 the label on the rfc should not be standards track
Scott
On Jul 30, 2012, at 1:33 PM, Randy Bush wrote:
2804 does not say not to talk about such things - or that such documents
should
not be published as RFCs - 2804
2804 does not say not to talk about such things - or that such documents should
not be published as RFCs - 2804 says that the IETF will not do standards work
in this area
Scott
On Jul 30, 2012, at 5:04 AM, Brian E Carpenter wrote:
Under the long-standing IETF policy defined in RFC 2804, I
I did it once - it took 2 or 3 hours *it was quite a while back and I do not
remember)
there were no significant expenses - the depo was in Boston my only
expense was a few hours parking - the depo was done in the office of the
law firm that was providing the IETF with pro-bono legal services
I did not do them any favor - I did the IETF a favor (as the then ISOC VP for
Standards)
Scott
On Jul 22, 2012, at 4:43 PM, John R Levine wrote:
I did it once - it took 2 or 3 hours *it was quite a while back and I do not
remember)
there were no significant expenses - the depo was in
what John said with one caveat - ITU-T consensus to modify an IETF protocol
rather than
bringing requirements to the IETF should not escape the gatekeeper function
Scott
On Mar 1, 2012, at 6:04 PM, John C Klensin wrote:
--On Thursday, March 01, 2012 18:39 + Stewart Bryant
+1
On Feb 14, 2012, at 1:25 PM, Ross Callon wrote:
+1.
Ross
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Owen
DeLong
Sent: Monday, February 13, 2012 2:06 PM
To: ietf@ietf.org
Cc: draft-bdgks-arin-shared-transition-space@tools. org
Subject: Re: Another
fwiw - the last time I looked at this law
1/ the IETF did not qualify as a SDO under the law
2/ the law only protected employees of the SDO, not participants
Scott
On Nov 28, 2011, at 4:13 PM, Richard Shockey wrote:
+1
It would be helpful in the non normative statement to
how about - when the URLs get added to
http://www.ietf.org/meeting/82/remote-participation.html#audio
they are URLs that bypass the spy features of meetecho?
Scott
On Nov 1, 2011, at 6:37 AM, Simon Pietro Romano wrote:
...forgot to include the list in my response. Sorry about that.
Simon
I'm having a hard time understanding just what this document is trying to do
I understand from the title that it is supposed to be telling the reader why a
single OAM
solution is a good idea for MPLS-TP
if that is the case I'm not all that sure what the purpose of sections 4 and 5
are for -
I'm fully supportive of reclassifying any RFCs that pose a risk to the Internet
to historic but fail to see the usefulness of doing so for RFCs that describe
unused but non-harmful technologies - seems like busywork and useless at best.
Scott
On Sep 15, 2011, at 1:45 PM, Mykyta Yevstifeyev
that technologies were actually
unused
Scott
On Sep 15, 2011, at 2:36 PM, Scott O Bradner wrote:
I'm fully supportive of reclassifying any RFCs that pose a risk to the
Internet
to historic but fail to see the usefulness of doing so for RFCs that describe
unused but non-harmful technologies - seems like
On 2011-09-11 08:11, Sam Hartman wrote:
snip
I do not think the following types of comments should be considered as
objections when judging this sort of consensus:
2) This will not do any good
now lets see, this argument seems to be that the fact that a particular process
change
Jari Arkko sed
I also saw a couple of opposing opinions, though some of them were more about
a desire to do something else
than specific objections about this proposal.
for the record in case Jari is confused - I have specific objection to this
proposal
imo - it fixes no known problem -
I've been traveling so have not had a chance to do anything but watch
the discussion on a RFC 2119 update.
a few thoughts
1/ I am far from convinced that there is a need to update RFC 2119
there is a bug in the boilerplate (as has been mentioned)
and some people seem to have a hard
fwiw - the author of 2119 thinks that less is more when it comes to the use of
these terms
see, as Cullen points out, Section 6
but there is a balance - for example, if you define a structure and say that
all fields are required, it is redundant to
use MUST with each example of using the
obvious that I believe these reports are valuable, but I am
willing to accept the proposed
structure, with the hope and expectation that communities that are serious
about producing and
refining protocols will be producing these reports anyhow.
RjS
On Jul 28, 2011, at 8:19 AM, Scott O
this is better than the last version but
1/ I still see no reason to think that this change will cause any
significant change in the percent of Proposed Standards that move up the
(shorter) standards track since the proposal does nothing to change the
underlying reasons that people do not expend
see RFC 3979 section 4 A - a note like Mike asks for is called for
but the other Scott is also right - do not be specific - see section 11 of the
same RFC
Scott
On Jun 22, 2011, at 3:56 PM, Michael StJohns wrote:
At 11:42 AM 6/22/2011, Scott Brim wrote:
On Wed, Jun 22, 2011 at 11:11,
As I have stated before, I do not think that this proposal will achieve
anything useful since it will not change anything related to the
underlying causes of few Proposed Standards advancing on the standards
track. I see it as window dressing and, thus, a diversion from the
technical work the
jck sed:
Perhaps I'm the only member of the community who cares any more.
he is not alone
quite a few of us were quite worried when the IAOC was formed that
it would tend to evolve into a management group that thought
it knew best for the the IETF without getting around to asking.
announcing
I've previously expressed my opinion that proposals to muck with the
number of steps in teh IETF standards process will no do anything
useful (i.e., will not be effective) - JOhn and I have just posted
what, to us, would be a prerequisite for amy process mucking proposal
to succeed
Scott
-
1/ I still do not think this (modified) proposal will have any real
impact on the number of Proposed Standard documents that move
to a (in this proposal, the) higher level since I do not see
how this makes any significant changes to the underlying reasons
that documents have not
Some history
Back when the IETF decided to charge for meetings ($100/meeting sometime
in the early 1990s) Steve Coya said that the IETF would never check
badges to block people from meetings.
That, I think, was to indicate that people who could not afford to pay
could still attend.
But that was
correction to history - it was Phill Gross not Steve Coya
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
The known problem is it takes well over four years to get anything
published.
...
What I *am* hoping is that with two, clearly defined maturity levels, we
can go back to publishing Proposed Standards in about a year
the only way that could happen is if the IESG were to change their ways a
Russ asks
Just to clarify, do you think that it would be better to document one
step or do you think that the community should not spend time on this
topic at all?
I think the community should only change its processes with careful deliberation
taking into account the interplay of the
some more thoughts
first figure out what problem you are trying to solve
is the problem:
1/ that the 3 step standards track described in RFC 226 and its
predecessors does not describe what happens most of the time?
2/ (as Eric says) that it takes too long to get to the first stage
3/ too much
while we are the topic of problems
Russ basically proposes too change the maturity warning label on IETF
standard track RFCs -- remove baby before folding carriage -- this
hardly seems like our biggest problem
The IETF publishes a lot of standards track RFCs each year. Mostly
these are PS (186
Barry coments
Scott, I'm confused about one thing you say:
You seem to be saying that we have to carefully deliberate, consider
many factors, and be serious if we want to *change* the basic rules...
but that it's OK to *ignore* the basic rules and do whatever we want,
with no deliberation,
Phillip politely says
I think this is nonsense.
We have been discussing this for over a decade. Time for debate is up. It is
time to make a decision.
since I see no reason to think that the proposed changes will do
anything at all to address any of the problems that I, and others, have
I think that Phillip and I have agreed to disagree
Scott
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
not the DoD but maybe of interest
Scott
http://www.cio.gov/Documents/IPv6MemoFINAL.pdf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
The ISD proposal
required the IESG spend a lot of time that the individuals simply did
not have.
so the IESG insisted - that was not the opinion of the newtrk chair
(who thought that ISDs would likely reduce the load on ADs
Further, this came at a very, very bad time
and that, apparently,
the reason that the blue sheets were created was as part of maintaining
a full record of the open standards process - the question of room size
was never considered
the basic idea is discussed in section 8 of RFC 2026
Each of the organizations involved in the development and approval of
Bill - sez
Pointing this out for completeness sake, it is not currently
required to sign said sheets to participate in WG sessions.
no one is lording over you but it is expected that all people in
the room will sign
Scott
___
Ietf
Aren't RFC 5377/5378 (and subsequent discussion) such a statement?
sorry - I must have missed the announcement by the trust that
they were responding to these RFCs
Scott
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Aren't RFC 5377/5378 (and subsequent discussion) such a statement?
did I miss the posting that lists each of the proposed chages
with a pointer to the specific request for change (or specific
need for change) in these RFCs?
Scott
___
Ietf mailing list
Some history that may explain some of my and some other reaction to the
recent postings by the Trust
When the Trust was formed a number of us were quite worried that it
would begin to see itself as self directed and not as a function whose
purpose was to act at the direction of and in support of
Isn't this what has essentially happened in this case?
I did not see a statement from the IETF asking for changes
nor did I see a statement from the Trust saying that there
are these issues that need to be fixed for legal or cosmetic
reasons
maybe there were such statements and I missed them
tme wrote:
the comment period is extended to the 23rd of July.
are we under some legal threat that requires this unseemly haste?
Scott
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
I may have missed it but I did not see any response to my posting
from when these changes were first proposed
along the lines of what John just posted - I thought that the Trust was
supposed to be responsive to requests from the IETF not go off on its own
figuring out things to do
I would like
tme said:
6. Provide the rationale for proposed changes in the future, rather than
a summary listing of the changes
this, to me, is exactly the wrong way for the IETF Trust to work. I do
not want a rationale for proposed changes
it seems to me that the Trust should work in one of 3 ways
A more interesting question is if you can submit somebody else's
public domain work to the IETF. I don't know the answer to that.
Legally, yes; it's public domain. Academic honesty and common courtesy
would demand an acknowledgment.
more than that - the standards process requires an
I'm disappointed at how few people have signed up. Even people who've
been active in this debate haven't signed up to the old version.
I signed the old form (on paper) and handed it in a while
back but do not see my name on the list -- did a bit get
dropped somewhere?
Scott
I've reviewed this document as part of the transport area directorate's ongoing
effort to review key IETF documents. These comments were written primarily for
the
transport area directors, but are copied to the document's authors for their
information and to allow them to address any issues
Worse, it is possible to read the current text of 2026 as
requiring, especially in the absence of an ISOC newsletter, that
a version of STD1 be published as an RFC before the clock starts
running on the waiting period. I think that would violate
common sense, especially given the
Do we archive charters and complete millstones for closed WGs?
see http://www.tools.ietf.org/wg/concluded
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ps - very impressive work by the tools group
Scott
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Oh gosh, I hope we're not archiving all those WG millstones...
in the fiction department :-)
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
it seems to be a real bad idea to let people actually remove
any type of IPR statement that might have been relied upon
by a WG in any way and since its hard to figure out if
thats the case, it seems like a real bad idea to let someone
remove a IPR statement at all
having a way for someone
good stuff
---
From [EMAIL PROTECTED] Wed Aug 13 06:54:56 2008
X-Original-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
X-Original-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.359
X-Spam-Level:
an observation:
With today's half day on Friday a good percentage of those people who
chose to stay until noon can still catch a flight home that same day in
most IETF meeting locations (except for people flying across some
ocean).
Moving the end time on Friday until 15:15 would cut that
if indeed RFC 2606 (a.k.a, BCP 32) said all domain names in
RFCs MUST use one of the following bases then a blocking DISCUSS
by an IESG member would be a reasonable thing. RFC 2606 does not
say that and, thus, a blocking DISCUSS is not reasonable
if the IESG had posted a set of rules that
it started w/ folsk scanning the pages of the early bound
copies of IETFF proceedings.
the sheets are no longer included in the proceedings
the process you describe has happend in recent memory at more than
one IETF.
at what scale? 100s of people? 10s?
Scott
and signing the sheet is strictly voluntary to date
well, there are no guards with guns watching but someone who
decides to not sign is not being honest about their participation
Scott
___
IETF mailing list
IETF@ietf.org
Ole guessed
My understanding is that the blue sheet serves mainly as a record of
who was in the room which I think is largely used to plan room
capacities for the next meeting.
the blue sheets are required as part of the basic openness
process in a standards organization - there is a need
that would test something but I'm not sure you could isolate the spam-fear
factor
Scott
---
Date: Thu, 03 Apr 2008 17:44:47 -0700
From: Eric Rescorla [EMAIL PROTECTED]
To: [EMAIL PROTECTED] (Scott O. Bradner)
Cc: ietf@ietf.org, [EMAIL PROTECTED]
Subject: Re: Blue Sheet Change
My suggestion is to rewrite section 4 a bit to call out that this
document does not cover the incoming rights for the independent and
irtf stream and to use the terms ietf-stream and possibly iab-
stream in the definitions.
thats all well good for the independent stream since they have
sorry - it does not make any sense at all to last call this document
it has had no meaningful discussion - we should not be updating our
core process documents this flippantly
Scott
___
Ietf mailing list
Ietf@ietf.org
Russ,
I was specifically not commenting on the contents of this ID
(I will soon) but on the process being followed
I see no justification of issuing an IETF Last Call on a ID that
is designed to modify our core process document where the document
has gotten so little discussion or
substantive review:
I think that Brian has pointed out a number of areas where, if we were
to produce a revised 2026, work needs to be done and I think that some
number (but by no means all) of his suggestions are good, but
1/ I think a delta of this complexity makes the result
Harald sed:
For the implementors, an I-D + the fact of approval is sufficient. For
those who write other documents, it's not - they need the RFC number.
including the folk in other SDOs that want to point to IETF documents
Scott
___
Ietf mailing
Joel sed:
The basic issue for me is that from the tools page I expect to find the tools.
my basic issue is somewhat different in that its not a future issue
why does tools have to show up in just about every IETF URL these days?
nomcom feedback for example - yes its a tool but the key is
brian corrected:
ID submission isn't at the tools server, it's at
https://datatracker.ietf.org/idst/upload.cgi
true but it shows my point as well
why not
www.ietf.org/id/submit
datatracker is a meaningful as tools in this context
Scott
___
Ietf
it is interesting that the free software foundation is espousing
censorship
Scott
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
I seem to have hit a nerve
you are asking the IETF to not publish an IETF doucment - what else
can you call it?
Scott
---
On Mon, Oct 29, 2007 at 09:55:06AM -0400,
Scott O. Bradner [EMAIL PROTECTED] wrote
a message of 9 lines which said:
it is interesting that the free software
we received similar comments during the transport directorate review of
the IPFIX implementation guidelines. The new revision of the document, now
available at:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-implementation-guidelines-07.txt
might address your concerns.
I'm
I reviewed draft-ietf-ipfix-protocol-26.txt as part of the Transport
Area review effort.
I did not find any particular issues in the described technology - a few
nits:
section 3.1 Export Time someday the IETF needs to stop using 32-bit
seconds since 1 jan 1970 for timing - at least within in the
yeh - I read that but am not convinced that the message is clear
enough of what can happen if those rules are not followed
Scott
---
Date: Tue, 25 Sep 2007 23:02:52 +0100
From: Stewart Bryant [EMAIL PROTECTED]
To: Scott O. Bradner [EMAIL PROTECTED]
Cc: ietf@ietf.org, [EMAIL PROTECTED], [EMAIL
I already have links to Agendas, Jabber-rooms, Meeting-materials,
draft tarballs and room location on http://tools.ietf.org/agenda, so
it seems like a good idea to add links to the audio streams, too
(in addition to any mention which is added to the IETF69 Meeting page).
seems to me that
If our consensus process is not independently and openly verifiable, we
might as well close shop!
a hum in a WG meeting is subject to the perceptions of the people
in the room
but its not clear that a fully verifiable process is needed since we
specifically try to do rough consensus not
Simon sez:
According to what definition of 'free standards'?
I agree with the other Scott - please be clear in what you are wanting
to write about
there seem to be as many definitions of free standards as people
writing about them - my definition revolves around how much money
to I have to
But its Informational. My read of RFC 2026 says that
the 4 week case applies to Standards Track only.
rfc 2026 says what must be done in some cases - it does not say what
can not be done in the cases it does not cover - specifically, RFC 2026
in no way would block a 4-week last call for an
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
approach which does not garner IETF consensus. An AD may DISCUSS
92 matches
Mail list logo
