> 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 t
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
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 S
< 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
https://www.ietf.org/mailman/l
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 s
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 percenta
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:
X-Spam-Sta
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 (prope
> 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
> 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 interp
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 raise
> 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
__
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
> 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 inf
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 t
> 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 maj
> 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 t
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
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
> 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'
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 "
> So, each time in a Last Call, someone says "This document should not
>be published", it is censorship? That's quite insulting for the
> victims of real censorship.
I do not recall another case where the IETF got requests to not publish
documents in last call - most of the time there are construc
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 t
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
___
I
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
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
https://www1.ietf.org/mailman/l
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 indicat
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
unreadabl
On Oct 25, 2012, at 11:03 AM, John C Klensin 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 which 2026 applies
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 ar
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
On Nov 6, 2012, at 10:54 AM, Fred Baker (fred) wrote:
>
> Not being a lawyer, I can't comment on the legal details of IPR cases. What I
> am looking at is the understandability of a statement. A lawyer that I was
> speaking with recently told me that the IETF IPR policy is ambiguous; one
> mu
correct - except that the IRTF has adopted the same disclosure requirements
Scott
On Nov 6, 2012, at 4:56 PM, Stephan Wenger wrote:
>
>
> On 11.6.2012 16:17 , "Scott O Bradner" wrote:
>
>>
>> On Nov 6, 2012, at 10:54 AM, Fred Baker (fred) wrote:
&g
> 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
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
> I'd like to hear from the community about pushing forward with this
> proposal or dropping it
I do not think this proposal fixes any known problems
the major reason (imo) that technology is not advanced along the
standards track is because there is no need to do so.
someone labors for a whi
> 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
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 di
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 i
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
bro
I think that Phillip and I have agreed to disagree
Scott
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
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
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 pr
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
-
F
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
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 IETF
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, Mich
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
how.
>
> RjS
>
> On Jul 28, 2011, at 8:19 AM, Scott O. Bradner wrote:
>
>>
>> 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
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 struct
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 t
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 -
> On 2011-09-11 08:11, Sam Hartman wrote:
>
>
>
>> 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
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 wrot
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 tec
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 - th
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
> > 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
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 a
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 d
> 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
> 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
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
In
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 mailin
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 t
+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: A
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
> wrote:
encouraging a report is fine
retracting the code points seems to add more confusion than it is worth unless
the
code space is very tight
and I see no reason to obsolete the experimental rfc or move it to historic
status unless the report is
that some bad thing happens when you try it out - upda
see rfc 2418 - they are to keep a record as who is taking part in a WG's
activities
keeping track of attendees is a basic part of any standards development
organization's process
Scott
On Apr 23, 2012, at 10:04 AM, George, Wes wrote:
>> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.o
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 a
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
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 tru
:-)
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 - 280
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 Pa
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 wrote:
>
>> singing this statement is the right thing to do
>
> For 0.29 seconds, I imagined you in front of a microphone in a r
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 gi
On Sep 2, 2013, at 10:23 AM, Jari Arkko 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 documents, aligning th
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
wrote:
> Olaf, John, Scott,
>
>> In fact, going back to the language of RFC2026 for Full (now Internet)
>> Standard. It confirms that popularity (sign
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
wrote:
> I mostly agree with this draft, but I have a concern. Let's anchor
> t
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 wrote:
> Having seen no further comments, Jari has asked me to post -01 with the
> changes. Done.
>
> pr
>
> --
> Pete Resnic
On Sep 13, 2013, at 2:32 PM, Olaf Kolkman wrote:
>
> On 13 sep. 2013, at 19:17, S Moonesamy 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 is required to move a
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 wrote:
> On 9/17/13 11:27 AM
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 the
1 April RFCs excepted
Scott
On Oct 2, 2013, at 10:10 AM, Barry Leiba 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 "IETF docume
On Oct 3, 2013, at 6:34 AM, The IESG 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'
> as Informational RFC
"Ruting" - "Rüting is a munici
00 AM, Dave Cridland
wrote:
> On Thu, Oct 3, 2013 at 12:49 PM, Scott O Bradner wrote:
>
> On Oct 3, 2013, at 6:34 AM, The IESG wrote:
>
> >
> > The IESG has received a request from the Routing Over Low power and Lossy
> > networks WG (roll) to consider the follo
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 th
97 matches
Mail list logo
