Re: Last calling draft-resnick-on-consensus

[Scott O Bradner]

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 the term 
"rough consensus" , but I do wish that the ID took care to propose it as new 
concept rather than pretend that it has always been what the IETF has done.  
The process in the ID is not what was followed when I was an AD and it not what 
I have described by the meaning of the term "rough consensus" in my newcomers 
tutorials (which I have been giving since at least IETF 57 in 2003). 
 
Thus I do not consider this ID ready for publication and call for it to be 
revised to clearly state that it is proposing a redefinition of the concept and 
term "rough consensus" then re-last called.
 
Scott
 

Re: Last Call: (Terms used in Ruting for Low power And Lossy Networks) to Informational RFC

[Scott O Bradner]

that is what I thought at first which caused me to quickly take a look
since the topic seemed to be a bit out of scope, even for the quite broad 
IETF official scope (though I'm not sure what SDO would be a an appropriate 
venue for standardization in this field)

Scott

On Oct 3, 2013, at 8: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 following document:
> > - 'Terms used in Ruting for Low power And Lossy Networks'
> >   as Informational RFC
> 
> "Ruting" - "Rüting is a municipality in the Nordwestmecklenburg district, in 
> Mecklenburg-Vorpommern, Germany"
> 
> the first sentence in the abstract says "routing" - maybe the title is in 
> need of Vana White?
> 
> 
> I'd assumed that they'd misspelt "rutting", and was quite disappointed in the 
> document as a result.
> 
> Dave.

Re: Last Call: (Terms used in Ruting for Low power And Lossy Networks) to Informational RFC

[Scott O Bradner]

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 municipality in the Nordwestmecklenburg district, in 
Mecklenburg-Vorpommern, Germany"

the first sentence in the abstract says "routing" - maybe the title is in need 
of Vana White?

Scott

Re: [Tools-discuss] independant submissions that update standards track, and datatracker

[Scott O Bradner]

 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 documents" to refer to
> documents in the IETF stream.
> 
> (In fact, documents in the IRTF and Independent streams are also
> "examined" by the IESG, but only for conflict review, according to RFC
> 5742.  The only RFCs that the IESG doesn't look at in any formal way
> are those in the IAB stream.)
> 
> Barry, Applications AD

Re: PS Characterization Clarified

[Scott O Bradner]

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 IETF so changing most of the IESG 
reverences to 
read "IETF" is the right thing to do

the one that should not be changed is the one that Olaf calls out at the end of 
the included message

Scott

On Sep 18, 2013, at 4:59 AM, Olaf Kolkman  wrote:

> 
> On 18 sep. 2013, at 01:54, John C Klensin  wrote:
> 
>> Pete,
>> 
>> I generally agree with your changes and consider them important
>> -- the IESG should be seen in our procedural documents as
>> evaluating and reflecting the consensus of the IETF, not acting
>> independently of it.
>> 
> 
> Agreed….
> 
>> Of the various places in the document in which "IESG" now
>> appears, only one of them should, IMO, even be controversial.
>> It is tied up with what I think is going on in your exchange
>> with Scott:
>> 
>> --On Tuesday, September 17, 2013 18:10 -0500 Pete Resnick
>>  wrote:
>> 
> Section 2:
>>> ...
> "the IESG strengthened its review"
>>> ...
> The IETF as a whole, through directorate reviews, area
> reviews, doctor reviews, *and* IESG reviews, has evolved,
> strengthened, ensured, etc., its reviews.
> 
 I believe that change would be factually incorrect
>>> 
>>> Which part of the above do you think is factually incorrect?
>> 
>> The issue here --about which I mostly agree with Scott but still
>> believe your fix is worth making-- is that the impetus for the
>> increased and more intense review, including imposing a number
>> of requirements that go well beyond those of 2026, did not
>> originate in the community but entirely within the IESG.  It
>> didn't necessarily originate with explicit decisions.  In many
>> cases, it started with an AD taking the position that, unless
>> certain changes were made or things explained to his (or
>> occasionally her) satisfaction, the document would rot in the
>> approval process.  Later IESG moves to enable overrides and
>> clarify conditions for "discuss" positions can be seen as
>> attempts to remedy those abuses but, by then, it was too late
>> for Proposed Standard.  And, fwiw, those changes originated
>> within the IESG and were not really subject to a community
>> consensus process either.
>> 
>> However, because the document will be read externally, I prefer
>> that it be "IETF" in all of the places you identify.  If we have
>> to hold our noses and claim that the community authorized the
>> IESG actions by failing to appeal or to recall the entire IESG,
>> that would be true if unfortunate.  I would not like to see
>> anything in this document that appears to authorize IESG actions
>> or process changes in the future that are not clearly authorized
>> by community consensus regardless of how we interpret what
>> happened in the past.
>> 
> 
> 
> 
> But one of the things that we should try to maintain in making that change is 
> the notion that the IESG does  have a almost key-role in doing technical 
> review. You made the point that that is an important distinction between 'us' 
> and formal SDOs. 
> 
> 
> Therefore I propose that that last occurrence reads:
> 
>> cross-area technical review performed by the IETF, exemplified by technical 
>> review by the full IESG at last stage of specification development.
> 
> 
> I think that this language doesn't set precedence and doesn't prescribe how 
> the review is done, only that the IESG does do review.
> 
> 
> In full context:
> 
>In fact, the IETF review is more extensive than that done in other
>SDOs owing to the cross-area technical review performed by the
>IETF,exemplified by technical review by the full IESG  at last stage of
>specification development. That position is further strengthened
>by the common presence of interoperable running code and
>implementation before publication as a Proposed Standard.
> 
> 
> Does that work?
> 
> --Olaf
> 

Re: PS Characterization Clarified

[Scott O. Bradner]

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, Olaf Kolkman wrote:
>> I just posted the third version of the draft at:
>> http://tools.ietf.org/html/draft-kolkman-proposed-standards-clarified-02
> 
> I would like to change "IESG" to "IETF" in five places:
> 
> Section 1:
> 
> "the IESG has evolved its review processes"
> 
> Section 2:
> 
> "IESG Reveiew of Proposed Standards"
> "the IESG strengthened its review"
> "last chance for the IESG to ensure the quality"
> "cross-area technical review performed by the IESG"
> 
> The IETF as a whole, through directorate reviews, area reviews, doctor 
> reviews, *and* IESG reviews, has evolved, strengthened, ensured, etc., its 
> reviews.
> 
> Saying "the IESG" in these places implies precedent setting that I think 
> would be bad. If the IETF capitulated to the IESG changing the rules on its 
> own in the past, so be it, but I think it would be bad to indicate in a BCP 
> that we think it's OK for the IESG to do so unilaterally.
> 
> pr
> 
> -- 
> Pete Resnick
> Qualcomm Technologies, Inc. - +1 (858)651-4478
> 

Re: PS Characterization Clarified

[Scott O Bradner]

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
>>   specification onto the standards track at the "Proposed Standard"
>>   level."
>> 
>> I suggest "standards" instead of "specific" action if you (and the other 
>> authors) decide that BCP is appropriate.  
>> 
> 
> I have used exactly the same term as RFC2026. I have no idea if 'standards 
> action' is defined somewhere.

I do not think we should move away from the ted used in RFC 2026

Scott

Re: Last Call: (Retirement of the "Internet Official Protocol Standards" Summary Document) to Best Current Practice

[Scott O Bradner]

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 Resnick
> Qualcomm Technologies, Inc. - +1 (858)651-4478
> 

Re: PS Characterization Clarified

[Scott O. Bradner]

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
> that concern off of this bit that Jari said:
> 
>> Secondly, the other obvious action we could take is to go back to the 
>> original
>> mode of operation, i.e., making PS RFCs truly early and somewhat untested
>> specifications. I am personally opposed to that on the following grounds. 
>> First,
>> it would not change the fact that a large part of Internet technology today 
>> runs
>> on PS RFCs, and Olaf's problem with getting these RFCs recognised would
>> continue. Second, while I think we need to keep adjusting the level of review
>> performed by the IESG and in IETF Last Call (we sometimes overdo it), I think
>> broad review is actually useful.
> 
> It's certainly clear to all of us that most PS specs are far more
> mature than what we thought about when we wrote RFC 2026.
> 
> The only concern I have is that once we do this -- declare that PS is
> always more mature than that -- we can't go back.  Do we *really* want
> to say that we will never again approve a PS spec that's partially
> baked?  This is painting us into the room where PS is mature and
> robust.  If we like being in that room, that's fine.  But it removes
> the "IESG can put fuzzy stuff out as PS if it thinks that's the right
> thing to do" option.
> 
> It says that IETF PS specs are "at least as mature as final standards
> from other" SDOs.  Mostly, that's true.  But it doesn't have to be.
> After this, it would have to be, always, for every PS spec.  Are we
> *sure* that's what we want?
> 
> Barry

Re: PS Characterization Clarified

[Scott O Bradner]

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 (significant implementation) is one 
>> necessary but not sufficient criterium.
> 
> Sorry. I was careless when I wrote about the effort. I didn't mean to suggest 
> that we have an effort to classify standards merely based on popularity. What 
> I meat that we have an effort to move a particular set of specifications to 
> Internet Standard, and will use the usual criteria when deciding whether the 
> documents are ready. While that particular set of specifications happens to 
> be popular, that was just an observation, not a (sole) reason of moving them 
> forward.
> 
> Hope this clarifies.
> 
>> I would hope that any concerns about technical maturity or significant 
>> benefit to the Internet community are taken into account when making the 
>> decision. If it is the case that members of the community assess that a 
>> specification lacks interoperability that should be sufficient grounds to 
>> not advance until data proofs otherwise.
> 
> Yes, of course.
> 
> Jari
> 

Re: PS Characterization Clarified

[Scott O Bradner]

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 the 
> documents to the current reality. I'd be happy to take the document forward. 
> In fact, I think we need to make this change even if we made other, more long 
> term changes.
> 
> There is at least one ongoing effort right now that has the potential to 
> reclassify a large set of Proposed Standard RFCs that form the basis of 
> widely used technology. These types of efforts can have a relatively big 
> effect on the standards status of the most commonly used RFCs. Do we want to 
> do more? Can we do more?

seems like a quite bad idea (as Randy points out)

take extra effort and get some interoperability data

> 
> Secondly, the other obvious action we could take is to go back to the 
> original mode of operation, i.e., making PS RFCs truly early and somewhat 
> untested specifications. I am personally opposed to that on the following 
> grounds. First, it would not change the fact that a large part of Internet 
> technology today runs on PS RFCs, and Olaf's problem with getting these RFCs 
> recognised would continue. Second, while I think we need to keep adjusting 
> the level of review performed by the IESG and in IETF Last Call (we sometimes 
> overdo it), I think broad review is actually useful.

imo - not a chance in hell of the IESG going back to the original meaning of PS
it is not in the IESG genetics, nor has it been for quite a while

> 
> But enough about my opinions. What do the rest of you think?
> 
> In terms of specific text, I also wrote a few observations, below. These are 
> purely personal comments.
> 
> First, I think you assumed this but never made it explicit. While the new 
> characterisation recognises the often final role of PS RFCs, it does not take 
> away the possibility of publishing Internet Standard specifications. Can this 
> be clarified?
> 
>> In the two decades after publication of RFC 2026 [RFC202] the IESG
>> has evolved its review processes of Proposed Standard RFCs and thus
>> RFC 2026 section 4.1.1 no longer accurately describes IETF Proposed
>> Standards.
> 
> I'd prefer saying "the IETF review processes Proposed Standard RFCs have 
> evolved". And leave the details to Section 2.
> 
>> 2.  IESG Reveiew of Proposed Standards
> 
> Review
> 
>> In response,
>> the IESG strengthened its review of Proposed Standards, basically
>> operating as if the Proposed Standard was the last chance for the
>> IESG to ensure the quality of the technology and the clarity of the
>> standards document. 
> 
> That is part of it, but I think the situation is more complicated than that. 
> The world changed around us, and suddenly Internet was big business, global, 
> and we got more careful about impacts to it. The process has evolved, 
> including the number of steps in the ladder. Review practices in general have 
> changed quite a lot, we now have a fairly broad review of RFCs.
> 
> Progression has also varied, mostly downwards. But as noted, it also seems 
> very much affected by specific initiatives. 
> 
> Here's what I'd say:
> 
>   Initially it was assumed that most IETF technical specifications
>   would progress through a series of maturity stages starting with
>   a relatively early Proposed Standard, then progressing to Draft Standard 
> then, finally,
>   to Internet Standard (see RFC 2026 section 6).  Over time, for a
>   number of reasons, this progression became less common.  At the same time,
>   the review for Proposed Standard RFCs was strengthened.
>   This strengthening was partially a response by the IESG for the above,
>   and in part a consequence of the growth in the importance of the
>   Internet and broader interest in reviewing new Internet technology.
> 
>   At the time of this writing, the IETF operates
>   as if the Proposed Standard was the last chance for the
>   to ensure the quality of the technology and the clarity of the
>   standards document.  The result is that IETF Proposed Standards
>   approved over the last decade or more have had extensive review.
>   Because of this change in review assumptions, IETF Proposed Standards
>   should be considered to be at least as mature as final standards from
>   other standards development organizations.  In fact, the IETF review
>   is more extensive than is done in other SDOs due to the cross-area
>   technical review performed in the IETF.

wfm

> 
> Jari
> 

Re: IESG Considering a Revision to NOTE WELL

[Scott O Bradner]

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:
>>> 
>>> 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 must file IPR statements for standards, but not for
>>> informational documents. We wound up wandering through the details of
>>> legal statements, in which I felt he was working pretty hard to make
>>> words stand on their heads.
>> 
>> in case anyone wonders
>> 
>> one might have been able to read that into RFC 2026 but that was very
>> carefully fixed
>> in the current documents - disclosures are required for ALL contributions
> 
> ALL IETF contributions.  NOT all contributions to the RFC editor, and not
> all RFCs.  (Which is of a certain relevance given, for example, the VP8
> codec definition RFC)
> 
> And, only if the IPR in question is yours or your employer's.
> 
> Stephan
> 
>> 
>> Scott
> 
> 

Re: IESG Considering a Revision to NOTE WELL

[Scott O Bradner]

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 
> must file IPR statements for standards, but not for informational documents. 
> We wound up wandering through the details of legal statements, in which I 
> felt he was working pretty hard to make words stand on their heads.

in case anyone wonders

one might have been able to read that into RFC 2026 but that was very carefully 
fixed
in the current documents - disclosures are required for ALL contributions

Scott

Re: Recall petition for Mr. Marshall Eubanks

[Scott O Bradner]

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 
neither -
it is time to move

Scott

On Nov 1, 2012, at 10:22 PM, Michael StJohns  wrote:

> At 06:01 PM 11/1/2012, Bob Hinden wrote:
> 
> 
>> While the IAOC has not discussed this formally, I agree with you.  The 
>> situation did change when we were able to talk with Marshall.
> 
> 
> 
> 
> I assume at this point the IAOC would like to pursue the recall option?  If 
> not, please be very clear about it to the list as I haven't actually seen a 
> request from the IAOC for that process to proceed as far as I can tell.
> 
> If you'd rather just wait from him to resign, if in fact he does, then please 
> indicate that.  I believe neither you nor Dave Crocker nor Scott Bradner (the 
> only IOAC members that I think have commented on this issue on list so far) 
> have actually specifically asked for or signed the recall on the list. 
> 
> Mike
> 
> 
> 
> 
> 
>> I too hope he will resign.
>> 
>> Bob
> 
> 

Re: ISOC BOT and Process BCPs

[Scott O Bradner]

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 are accepted as describing IETF process before the RFCs become 
active 

see, for example, Resolution 2006-36 
http://www.internetsociety.org/who-we-are/board-trustees/list-resolutions

Scott

On Oct 26, 2012, at 7:20 AM, Sam Hartman  wrote:

>> "SM" == SM   writes:
> 
> 
> So, I'm puzzled by this.  my claim was that ISOC needed to approve
> process related BCPs.  If you take a look at RFC 2031, it supports that
> claim.  However, I'd kind of expect the other half of this to be in RFC
> 2026.  I certainly recall us sending things like BCP 101 before the ISOC
> BOT. I also think we sent a couple of other documents there because they
> were process documents.
> However this is clearly more complex than I thought it was.
> 
> Scott, or anyone else with more history, can you tell us a story about
> how this works?

Re: Hasty procedural changes (was: Re: [RFC 3777 Update for Vacancies])

[Scott O Bradner]

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, whether they were
> created earlier enough to be enumerated in 2026 or not.  (FWIW,
> I personally believe that interpretation would be correct
> relative to the intentions 16 years ago.)  That procedure could
> then be used to treat the current situation as a resignation
> without creating any unfortunate precedents.

for some additional context about the variance procedure - it originally 
came from RFC 1871

Scott

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

[Scott O Bradner]

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 given notice of such material

Scott

On Sep 3, 2012, at 9:29 PM, Sam Hartman  wrote:

> I strongly urge  the IESG to be significantly more liberal in  the cases
> where an I-D will be removed from the archive.
> 
> I can think of a number of cases where I'd hope that the IESg would be
> cooperative:
> 
> 1) the IETF recieves a DMCA take-down notice or other instrument
> indicating that a third party believes an I-D infringes their copyright.
> Forcing such third parties to take the IETF to court does not seem to
> benefit the community.
> 
> 2) An author realizes that an I-D accidentally contains proprietary
> information, infringes someone else's copyright, failed to go through
> external release processes for the author/editor's organization, etc.
> Obviously factors like how long after the I-D is submitted might need to
> be considered.
> 
> 
> In conclusion, I believe there are a number of cases where the interests
> of the community are better served by being able to ask for removal from
> the archive. Being able to easily repair mistakes  is likely to
> facilitate  more free discussion and more speedy updating of I-Ds.
> Yes, I'm aware  that organizations other than the IETF mirror the i-ds
> and some of these organizations will be less sympathetic to these
> concerns.

Re: Last Call: Modern Global Standards Paradigm

[Scott O Bradner]

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 recording 
> studio, singing "Modern Global Standards Paradigm" to the tune of "All the 
> young dudes".  For 0.29 seconds...
> 
> Grüße, Carsten
> 

Re: Last Call: Modern Global Standards Paradigm

[Scott O Bradner]

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, which can be found
>>> here:
>>> 
>>> http://www.ietf.org/proceedings/84/slides/slides-84-iesg-opsplenary-15.pdf
>> 
>> no brainer.
> 
> Even with a brain, the document is obviously good. Please sign it.
> 
> --Paul Hoffman

Re: I-D Action: draft-balaji-mpls-lawful-intercept-thru-label-dis-00.txt

[Scott O Bradner]

:-)

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 says that the IETF will not do standards 
>> work
>> in this area
> 
> for those of us who are easily confused, could you differentiate between
> working on douments and publishing them as rfcs from doing standards
> work?
> 
> randy

Re: I-D Action: draft-balaji-mpls-lawful-intercept-thru-label-dis-00.txt

[Scott O Bradner]

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 trust
> we will not be discussing this draft, or
> draft-balaji-l2vpn-lawful-intercept-thru-label-dis, in the IETF.
> 
> Regards
>   Brian Carpenter
> 
> On 30/07/2012 09:26, internet-dra...@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> 
>> 
>>  Title   : Label-based Provider-Provisioned Lawful Intercept for 
>> L3 VPNs
>>  Author(s)   : Shankar Raman
>>  Balaji Venkat Venkataswami
>>  Gaurav Raina
>>  Vasan Srini
>>  Bhargav Bhikkaji
>>  Filename: 
>> draft-balaji-mpls-lawful-intercept-thru-label-dis-00.txt
>>  Pages   : 12
>>  Date: 2012-07-30
>> 
>> Abstract:
>>   In models of Single-AS and inter-provider Multi- Protocol Label
>>   Switching (MPLS) based Virtual Private Networks (VPNs) Lawful
>>   Intercept is a key requirement. For example, MPLS-based Layer 3 VPN
>>   models like VPLS and the like do not have any provider provisioned
>>   methods of lawful intercept that are comprehensive, quick and easy to
>>   provision from one single point. More particularly the auto-
>>   provisioning of lawful intercept for all sets of streams travelling
>>   between VPN sites and consequent re-direction of these streams to the
>>   appropriate government network has not been covered without multiple
>>   instances of having to configure the intercept at various points in
>>   the network both in the Single-AS case and the Inter-Provider VPN
>>   case.
>> 
>>   this paper, we propose a technique which uses a set of pre-defined
>>   labels called Lawful Intercept labels and a method for provisioning
>>   lawful intercept amongst the various PE devices using these labels
>>   both in the Single-AS and the inter-provider VPN cases. A single
>>   point of configuration is the key to this idea. The intercepted
>>   traffic is mirrored on a PE or a whole set of PEs or on all the PEs
>>   participating in the VPN. A technique called the Domino-effect
>>   provisioning of these Label-based Provider Provisioned Lawful
>>   Intercept mechanism is also outlined.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-balaji-mpls-lawful-intercept-thru-label-dis
>> 
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-balaji-mpls-lawful-intercept-thru-label-dis-00
>> 
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> ___
>> I-D-Announce mailing list
>> i-d-annou...@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> 

Re: [IAOC] Feedback Requested on Draft Fees Policy

[Scott O Bradner]

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 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 at the time
> 
> If the opposing party didn't pay you for your time in the depo, you did them 
> an unnecessary favor.
> 
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> "I dropped the toothpaste", said Tom, crestfallenly.

Re: [IAOC] Feedback Requested on Draft Fees Policy

[Scott O Bradner]

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 at the time

Scott

On Jul 22, 2012, at 3:58 PM, John R Levine wrote:

>>> For people with unique skills or knowledge, $800/hr is not unusual.
>>> So long as the rate is published ahead of time, you're not going to
>>> get much argument.  ("Yes, we know it's high.  But we've already told
>>> you how to download stuff yourself for free.")
>> 
>> Please  note : out of pocket expenses (if someone has to travel to a
>> hearing, say) would be reimbursed, but
>> IETF volunteers will not be paid from these fees.
> 
> If you know, how often have people been deposed on behalf of the
> IETF, and how long does it typically take?
> 
> My thought is that in a depo or trial, the other side pays both for the 
> expenses and the time of the person being deposed, so it would be good idea 
> to say up front here's what it'll cost if you want a live witness.
> 
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> "I dropped the toothpaste", said Tom, crestfallenly.

Re: Future Handling of Blue Sheets

[Scott O Bradner]

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.org] On Behalf Of IETF
>> Chair
>> Sent: Sunday, April 22, 2012 10:31 AM
>> To: IETF
>> Subject: Future Handling of Blue Sheets
>> 
>> 2.  Scan the blue sheet and include the image in the proceedings for the WG
>> session; and
>> 3.  Discard paper blue sheets after scanning.
> 
> [WEG] Based on some other messages in this thread, there seems to be a lack 
> of clarity as to the full, official purpose of the blue sheets. Are they 
> simply to track generic participation levels for room sizing, or are they 
> also meant as a historical record of attendees to a given WG? It seems that 
> if they are being subpoenaed, and they are archived today, I tend to think 
> that they're meant to officially track attendees. I'd appreciate someone 
> correcting me if I'm wrong.
> 
> If blue sheets are meant to be an official record, then technically we should 
> document handling/scanning/storage procedures for WG chairs and the 
> secretariat such that this scan will be admissible in lieu of a paper copy 
> for any subpoena or other court proceeding. But if we're honest, I'm not sure 
> that they're of much use as an official record either way. Do we have 
> procedures today that would prevent tampering before the paper copy ends up 
> in an archive box? And even then, blue sheets and jabber logs (for remote 
> participants) are still ultimately a best-effort honor system, and therefore 
> there is no guarantee of their validity. I can remotely participate without 
> registering for the meeting, and can sign into Jabber as "Mickey Mouse" just 
> as easily as I can sign the blue sheet that way. I can also sign as "Randy 
> Bush" or sign my own name completely illegibly.
> 
> Could we simply do a headcount for room sizing, and treat the matter of 
> official attendee record for WG meetings as a separate problem? IMO, it's not 
> currently solved by the blue sheets, and I don't see that changing just 
> because we dispense with the paper copies in a box in a warehouse.
> 
> Thanks
> Wes George
> 
> This E-mail and any of its attachments may contain Time Warner Cable 
> proprietary information, which is privileged, confidential, or subject to 
> copyright belonging to Time Warner Cable. This E-mail is intended solely for 
> the use of the individual or entity to which it is addressed. If you are not 
> the intended recipient of this E-mail, you are hereby notified that any 
> dissemination, distribution, copying, or action taken in relation to the 
> contents of and attachments to this E-mail is strictly prohibited and may be 
> unlawful. If you have received this E-mail in error, please notify the sender 
> immediately and permanently delete the original and any copy of this E-mail 
> and any printout.

Re: Proposed IESG Statement on the Conclusion of Experiments

[Scott O Bradner]

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 - updating the old rfc is fine

and I agree with Elliot about the nature of research - it is very common to not
reach a conclusion that something is bad (as in bad for the net) - and that is 
the
only case where I think that an experiment should be flagged as a don't go 
there situation

Scott


On Apr 19, 2012, at 4:31 PM, Adrian Farrel wrote:

> All,
> 
> The IESG has been discussing how to tidy up after Experimental RFCs.
> 
> We have developed the following draft IESG statement. This does not 
> represent a change in process, and continues to value Experimental RFCs
> as an important part of the IETF process. It does, however, seek to 
> encourage documentation of the conclusion of experiments.
> 
> We are aware that there may be other discussion points around 
> Experimental RFCs, and we would like to discuss these, but we also
> believe that there is merit in making small, incremental improvements.
> 
> The IESG would welcome your thoughts on this draft before they approve
> the final text on April 26th.
> 
> Thanks,
> Adrian
> 
> =
> 
> IESG Statement on Conclusion of IETF Experiments
> 
> 
> Experiments are an established and valuable part of the IETF process.
> A number of core Internet protocols were first published as Experimental
> RFCs while the community gathered experience and carefully investigated
> the consequences of deploying new mechanisms within the Internet.
> 
> In the case where an experiment leads on to the development of a  
> Standards Track RFC documenting a protocol, the new RFC obsoletes the 
> old Experimental RFC and there is a clear conclusion to the experiment.
> 
> However, many experiments do not lead to the development of Standards
> Track RFCs. Instead, the work may be abandoned through lack of interest
> or because important lessons have been learned.
> 
> It is currently hard to distinguish between an experiment that is still
> being investigated, and an old experiment that has ceased to be of
> interest to the community. In both cases an Experimental RFC exists in
> the repository and newcomers might easily be misled into thinking that
> it would be helpful to conduct more research into an abandoned
> experiment.
> 
> In view of this, the original proponents of experiments (that is, 
> authors of Experimental RFCs, and Working Groups that requested the
> publication of Experimental RFCs) are strongly encouraged to document
> the termination of experiments that do not result in subsequent
> Standards Track work by publishing an Informational RFC that:
> 
> - very briefly describes the results of the experiment
> 
> - obsoletes the Experimental RFC
> 
> - if appropriate, deprecate any IANA code points allocated for the 
>  experiment
> 
> - may request that the Experimental RFC is moved to Historic status.
> 
> If there is no energy in the community for the producing such an
> Informational RFC, if the authors have moved on to other things, or if
> the Working Group has been closed down, Area Directors should author or
> seek volunteers to author such an Informational RFC.
> 

Re: Last Call: (Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM) to Informational RFC

[Scott O. Bradner]

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:
> 
>> ...
>>> FWIW, this seems entirely appropriate to me.  If we do it this
>>> way, I think it is important to note --for the benefit of
>>> those more historically involved with the ITU and others--
>>> that we routinely block our own documents on normative
>>> references to work that is still in progress and, usually, do
>>> not do related code point allocations until the blocking
>>> referenced documents are ready.  Once the present I-D is
>>> judged to be sufficiently ready, this approach would
>>> therefore be IETF approval and a formal guarantee to the ITU
>>> that a code point will be allocated if an when G.8113.1 is
>>> approved and published, but not assignment of that code point
>>> until the referenced base document is finished.
>>> 
>>> Completely normal procedurally.
>> ...
>> To be clear John our normal requirement would be that the
>> technical community achieved consensus that the base document
>> was ready. I have never seen ITU-T consensus on the contents
>> of G.8113.1 at any meeting that I have observed. What in your
>> view is the criteria for determining that  G.8113.1 has
>> achieved consensus?
> 
> Stewart, 
> 
> I don't think so.  
> 
> Let me suggest that there are two entirely separate issues here
> and that talking about "technical community consensus" obscures
> both of them.
> 
> (1) Whether, given the JWT and other agreements, the ITU has any
> business developing G.8113.x at all, or whether they should be
> simply submitting ideas to the IETF for consideration.  Many of
> us think that, under that agreement, the G.8113 activity is
> inappropriate.  But the ITU has obviously decided otherwise and
> we have no enforcement capability to prevent them from doing so
> (whether we should or should not is pretty much irrelevant at
> this point, at least IMO).  Whether the "technical community"
> has achieved consensus is not relevant either, the only thing
> that matters is whether G.8113.1 is, or will be, fully approved
> by the ITU under ITU procedures.
> 
> (2) Whether it is reasonable or appropriate for the IETF to use
> our responsibility for code point assignments and consequent
> relationship with IANA to try to keep protocols that are not
> consistent with our design judgment and aesthetics --no matter
> how grounded in experience and good engineering-- off the
> Internet.  That is the "Internet gatekeeper" function about
> which, as you know, I've expressed concern in other contexts.  I
> think the answer has got to be "we can, should, and always will
> exercise quality control on stable specifications and normative
> references but, unless we can justify being sure of our own
> infallibility, we cannot and should not try to prevent another
> body from deploying a specification on the Internet by using our
> control of the registration model".   Telling people why we
> think their ideas are sub-optimal is fine, as is identifying any
> risks we see in appropriate and visible places, but telling
> another group what they can't do because the IETF doesn't like
> the idea isn't.
> 
> And I think that distinction is entirely consistent with Russ's
> suggestion.
> 
> best,
>   john
> 
> 
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Another last call for draft-weil

[Scott O Bradner]

+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 last call for draft-weil
>  
> I support draft-weil as revised. There is a vital need for this to move 
> forward and the IETF should stop standing in the way and let ARIN allocate 
> the space already.
>  
> Owen
>  
> On Feb 13, 2012, at 10:09 AM, Chris Grundemann wrote:
> 
> 
> Fellow BDGKS Authors,
>  
> FYI: draft-weil is in another Last Call following an update that was 
> requested by IESG Ads (on their December telechat, some ADs asked us to turn 
> our request into a request for more 1918 space, but with a few caveats to 
> home router manufacturers about not breaking when exposed to a CGN 
> environment.). At this point we don't expect to change any minds. Basically 
> everyone who is against the draft has spoken up. Now it is just a numbers 
> game, we need to demonstrate significant support for the draft.
>  
> If you do support this I-D and the allocation of the /10 for shared CGN use, 
> please consider posting a statement of support.  Something as simple as "I 
> support this draft as updated" or "I think the updated draft is more 
> flexible, and would satisfy additional use cases that don't work with RFC1918 
> space" would be very helpful.
>  
> You can respond to the "Last Call: 
>  (IANA Reserved IPv4 
> Prefix for Shared Address Space) to BCP" thread or post individually to  
> ietf@ietf.org. Also, please feel free to encourage anyone else you know who 
> supports the draft to make a similar post. Every statement we can gather is 
> vital right now. Last call ends on Thursday, so reply's must be made before 
> then. Thank you.
>  
> Cheers,
> ~Chris
>  
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: An Antitrust Policy for the IETF

[Scott O. Bradner]

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 the community to cite 
> what suits were are involved, what was the cause of action and what if any 
> decisions were rendered in these cases.
>  
> US antitrust law, for instance has  specific exemptions for SDO’s.
>  
> http://en.wikisource.org/wiki/Public_Law_108-237/Title_I
>  
> There are some requirements under this act that SDO’s need to file a 
> statement of purpose. I don’t know if we ever did that.
>  
> In general, however this sounds like a sound and valuable move.
>  
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Ted 
> Hardie
> Sent: Monday, November 28, 2011 2:27 PM
> To: IETF Chair
> Cc: IETF; IESG
> Subject: Re: An Antitrust Policy for the IETF
>  
> On Mon, Nov 28, 2011 at 11:10 AM, IETF Chair  wrote:
> Sorry, can you expand on the threat model here?  Are we developing one in 
> order to defend against some specific worry about our not having one?  
> Because it has become best practice in other SDOs?  Because the insurance 
> agent wishes to see something in particular?
> 
> I hesitate to develop something that we have not needed in the past unless it 
> is clear what benefit it gives us.  In particular, if we develop one without 
> some particular characteristic, do we lose the benefits of being where we are 
> now?
>  
> Recent suits against other SDOs is the source of the concern.  The idea is t 
> make it clear which topics are off limits at IETF meetings and on IETF mail 
> lists.  In this way, if such discussions take place, the good name of the 
> IETF can be kept clean.
>  
> Russ
> 
> Hmm,  I would characterize our previous policy as a quite public statement 
> that no one is excluded from IETF discussion and decision making,  along with 
> with reminders that what we are deciding is the technical standard, not the 
> resulting marketplace.  What we can say beyond that without diving into 
> national specifics is obscure to me.  
> 
> I agree with Dave that the first work product of an attorney should be a 
> non-normative explanation to the community of how having such a policy helps 
> and what it must say in order to get that benefit.  
> 
> (I have to say that my personal experience is that prophylactic measures 
> against law suits tend to change the terms of the suits but not their 
> existence.  In this case, suing someone because they did not enforce the 
> policy or the policy did not cover some specific jurisdiction's requirements 
> perfectly, seems like the next step.  Your mileage may vary.)
> 
> regards,
> 
> Ted
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF 82 Audio Streaming

[Scott O. Bradner]

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
> 
> Simon Pietro Romano  ha scritto:
> Hi Randy,
> 
> you can skip such a fat frelling chance, if you want; just choose to either 
> attach to the RTSP stream, or to the landline phone bridge.
> 
> Cheers,
> 
> Simon
> 
> Randy Bush  ha scritto:
> > For general remote participation including meetecho support see:
> 
> meetecho seems to require me to let a java applet have its way with my
> machine.  fat frelling chance.  does the ietf really want to recommend
> such a practice?
> 
> randy
> 
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

[Scott O Bradner]

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 - they seem
to be exploring land outside the reservation - how about just addressing the 
topic in the title?

Scott

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Pre-IETF RFCs to Historic (not really proposing)

[Scott O Bradner]

ps - as Keith points out - a round of this type of effort was undertaken by the 
newtrk
working group a while back (I was the chair and did not see much reason to
do so at the time but there was consensus in the WG to proceed) - I will note
that it took quite a bit of work to ensure 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 busywork and useless at best.
> 
> Scott 
> 
> On Sep 15, 2011, at 1:45 PM, Mykyta Yevstifeyev wrote:
> 
>> Dear all,
>> 
>> I've recently received a message from Ronald Bonica, one of the ADs, 
>> proposing undertaking an effort to reclassify many pre-IETF (pre-1000) RFCs 
>> as Historic.  However, I initially had a concern regarding community 
>> consensus on such effort, and whether it will be accepted so that the IESG 
>> may claim the former.  Since I've already suggested a very similar proposal, 
>> and there was a negative reaction of community, I assumed the same would 
>> happen in the case Ronald pursued the work and forwarded it to the IESG.  So 
>> am I right?
>> 
>> Mykyta
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Pre-IETF RFCs to Historic (not really proposing)

[Scott O Bradner]

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 wrote:

> Dear all,
> 
> I've recently received a message from Ronald Bonica, one of the ADs, 
> proposing undertaking an effort to reclassify many pre-IETF (pre-1000) RFCs 
> as Historic.  However, I initially had a concern regarding community 
> consensus on such effort, and whether it will be accepted so that the IESG 
> may claim the former.  Since I've already suggested a very similar proposal, 
> and there was a negative reaction of community, I assumed the same would 
> happen in the case Ronald pursued the work and forwarded it to the IESG.  So 
> am I right?
> 
> Mykyta
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Conclusion of the last call on draft-housley-two-maturity-levels

[Scott O. Bradner]

> 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 
change is useless should not 
stop the IETF from adopting the change

this argument would be nonsense if applied to a proposal for a technical 
standard - i.e. the 
IETF should adopt a technical standard that is known to be useless -- it is no 
less nonsense when
applied in this case - changes for the sake of publishing new bits should not 
be what the IETF
spends its time on

Scott

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Conclusion of the last call on draft-housley-two-maturity-levels

[Scott O. Bradner]

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 - it only adds additional fuzz to a surface 
understanding of what 
causes few RFCs to be advanced on the standards track - I see no reason to 
think that
this proposal will have any significant effect on that problem (nor any 
insignificant effect)

Scott


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

[Scott O. Bradner]

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 time understanding what 
  (to me) seem like clear descriptions of (for example) MUST & 
  SHOULD - but the issues do not seem serious enough to warrant
  replacing what is, basically, a simple dictionary & usage 
  constraint

2/ it seems like a very Bad Idea to move 2119 to historic- we move
 RFCs to historic when no one uses them or when they are a Bad
 Idea in light of updated technology - I do not think that makes 
 much sense in this case - in addition it makes the status of RFCs
 that have a normative reference to a historic document a bit
 funky - if an update is actually needed there is no reason that
 I can come up with that it could not just be that -- an update

3/ I doubt that I'll ever catch up with Postel as the most referenced
 RFC author so that is not a consideration (for me)

I wrote RFC 2119 (most using text from RFC 1122) because people were
using MUST without saying what they meant, an update, if people think
that one is actually needed, will serve that purpose as well as 2119 has.  

When I posted the original ID it was pointed out that I should also
address when such terms should be used (i.e. try to limit the use to
where it actually made sense protocol-wise) - I tried to do that but
that part may not have been as successful as it might have been - any
update might try to be clearer in this area that RFC 2119 is.

Scott


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Gen-ART Review: Last Call

[Scott O. Bradner]

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 structure

Scott

On Aug 11, 2011, at 8:43 PM, Cullen Jennings wrote:

> 
> Thanks for the detailed review - you caught some good stuff. Most of this 
> makes essence but we should probably talk about usage of 2119 language. 
> 
> On Aug 9, 2011, at 16:05 , Mary Barnes wrote:
>> simple
>> ===
>> 
>> Document: draft-ietf-p2psip-base-17
>> Reviewer:  Mary Barnes 
>> Review Date:  9 August  2011
>> IETF LC End Date: 22 July 2011
>> 
>> Summary: Not Ready.  
>> 
>> Comments:
>> 
>> The document is very a dense (with detailed technical information) and long 
>> (150 page) specification for a Peer-to-peer signaling protocol.  While the 
>> overall technical functionality seems fairly correct and thoroughly 
>> specified, the primary issue is a tremendous lack of normative language in 
>> the main body of the document.  Non-inclusive details of such are included 
>> below.  
> 
> The 2119 MUST/SHOULD/MAY terms are simply abbreviations for some words 
> defined in 2119, and different WGs have different styles about how 
> extensively they should be used. P2PSIP has obviously been on the more 
> sparing side of that spectrum. This isn't to say that there aren't any places 
> where it would be useful to add such language, but rather that our policy has 
> been to add it principally where there is likely ambiguity, rather than 
> everywhere where behavior is defined. I'll work thought these and see where 
> they might help reduce the chance of a an implementers doing the wrong thing 
> but in generally when we define a structure in something like ASN.1 or ABNF, 
> if the structure always has a field X, we just use the language like ASN.1 or 
> ABNF to indicate it always has that. We don't  also say it MUST be there. 
> 







___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-two-maturity-levels

[Scott O Bradner]

it looks so - maybe it would be good to have a pointer in this doc

Scott

On Jul 28, 2011, at 9:19 AM, Robert Sparks wrote:

> Scott -
> 
> Didn't RFC 5657 address your point 2?
> 
> The current proposal no longer requires this report during advancement, but 
> it does not disallow it.
> I hope it's 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. 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 that move up the
>> (shorter) standards track since the proposal does nothing to change the
>> underlying reasons that people do not expend the effort needed to
>> advance documents
>> 
>> 2/ one of the big issues with the PS->DS step is understanding what
>> documentation is needed to show that there are the interoperable
>> implementations and to list the unused features - it would help a lot to
>> provide some guidance (which I did not do in 2026 - as I have been
>> reminded a number of times :-) ) as to just what process is to be
>> followed
>> 
>> could be
>>  a spread sheet showing features & implementations
>>  an assertion by the person proposing the advancement that the
>> requirements have been met
>> or something in between
>> 
>> Scott
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
> 

Scott Bradner

Harvard University Information Technology
Security | Policy, Risk & Compliance
+1 617 495 3864
29 Oxford St., Room 407
Cambridge, MA 02138
www.harvard.edu/huit




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-two-maturity-levels

[Scott O. Bradner]

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 the effort needed to
advance documents

2/ one of the big issues with the PS->DS step is understanding what
documentation is needed to show that there are the interoperable
implementations and to list the unused features - it would help a lot to
provide some guidance (which I did not do in 2026 - as I have been
reminded a number of times :-) ) as to just what process is to be
followed

could be
a spread sheet showing features & implementations
an assertion by the person proposing the advancement that the
requirements have been met
or something in between

Scott
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: External IPR Disclosures vs IPR disclosures in the document.

[Scott O. Bradner]

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, Michael StJohns  wrote:
>>> A quick couple of questions to the list based on a document I saw recently.
>>> 
>>> If a document (an ID in this case) contains encumbered material (in this 
>>> case consists of 90%+ encumbered material), and the document is authored by 
>>> the organization (or members of the organization) that holds the 
>>> encumbrance, should the document contain an IPR disclosure itself or is it 
>>> sufficient to submit a IPR disclosure through the IETF web interface?
>> 
>> IPR statements are never put in RFCs unless on occasion they are
>> informational transplants from outside.  The IPR claims or other
>> aspects might change over time and the right place to track all that
>> is in the IPR disclosures.
> 
> Hmm.. even though this was labeled like a normal run of the mill ID, it 
> really was an informational transfer from the outside - at least at this 
> point in the process.  I.e. - single corporate author, long held IPR as 
> opposed to "here's something brand new and never seen before and while parts 
> of it may derive from work from company A, this use of it is new and people 
> from company B and C are figuring out new ways to work with it."
> 
> I think tracking disclosures via the IPR system is reasonable for most 
> documents, but something like "This document consists primarily of 
> intellectual property claimed to owned by .  Please consult the IETF 
> disclosures section for the current terms and conditions for this IPR." may 
> be useful.It's pretty hard to tell from any given document whether or not 
> consulting the IPR disclosures is useful or somewhat necessary.
> 
> Not a big problem, I guess, but somewhat dissonant to the process.
> 
> Mike
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (Reducing the Standards Track to Two Maturity Levels) to BCP

[Scott O. Bradner]

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 should focus on.

If it were up to me, I would not approve this ID for publication as a
RFC (of any type) 

Scott

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [IAOC] xml2rfc and legal services RFPs

[Scott O. Bradner]

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 RFPs without any chance for the IETF community to 
comment is just the sort of the thing that I, for one, was
worried about.

I have an easy time understanding that the IAOC migt find it
a pain to consult with the community, and as John mentioned,
many times there will be little or no comment, but please
rethink your processes 

you may "not see very much value in doing a community review for this"
but, I do not think that should be your call. Always consult is
a better plan to ensure that the IAOC is not getting out of step
with the part of teh community that does care.

Scott


ps - long before Wilmer-Hale it was Hale and Dorr & I was involved
in the first pick so might have an opinion on future ones

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

prerequisite for change (was Re: draft-housley-two-maturity-levels)

[Scott O. Bradner]

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

-
From: internet-dra...@ietf.org
To: i-d-annou...@ietf.org
Subject: I-D Action:draft-bradner-restore-proposed-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

Title   : Restoring Proposed Standard to Its Intended Use
Author(s)   : J. Klensin, S. Bradner
Filename: draft-bradner-restore-proposed-00.txt
Pages   : 6
Date: 2011-01-29

Restore the very low bar for Proposed Standard described in RFC 2026
(BCP 9)

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-bradner-restore-proposed-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-two-maturity-levels

[Scott O. Bradner]

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 progressed in the past - i.e., I see no
   reason to think that this proposal would change the world much
   (would not help, would not hurt)

2/ I think the proposal must specifically deal with the 2026 IPR licence
   requirement in section 4.1.2

  If patented or otherwise controlled technology
  is required for implementation, the separate implementations must
  also have resulted from separate exercise of the licensing process.

   The requirement can be dealt with by explicitly discarding 
   it or by including it. But not mentioning the requirement does
   not make the issue go away.  This requirement was, in theory, a
   way to keep the IETF/IESG out of the business of evaluating
   the fairness of licensing terms.  I can remember only
   one time it came up (in an appeal) so getting rid of it may
   be fine - but don't make it look like it was just forgotten.
 
3/ I think you also be quite specific as to how to decide that the
   conditions for advancement have been met - one of the big
   implementation issues with 2026 was knowing how to decide
   that a technology was ready to be advanced (did you need
   a spreadsheet listing all features and noting with ones
   had been multiply implemented (as was done at huge effort
   for HTTP 1.1) or is there someting simplier - clear rules 
   would help avoid this type of issue in the future

4/ as part of #3 - the rules should also specifically deal with
   the following pp from 2026

  The requirement for at least two independent and interoperable
  implementations applies to all of the options and features of the
  specification.  In cases in which one or more options or features
  have not been demonstrated in at least two interoperable
  implementations, the specification may advance to the Draft Standard
  level only if those options or features are removed.

   this requirement was included to try to remove cruft from protocols
   as they went forward - maybe this is no longer a desire but,
   like with the license issue, a specific mention of what has
   been decided would mean that people would not think that
   things were not just forgotton.

Scott



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [79all] IETF Badge

[Scott O. Bradner]

correction to history - it was Phill Gross not Steve Coya
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

[79all] IETF Badge

[Scott O. Bradner]

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 a very long time ago, and a few hundred dollars per meeting ago

I find it hard to get too bent out of shape that the IETF has joined the
world that every other conference I have gone to in the last 20 years
has been in, and I find it hard to get too bent out of shape about a
change in this level of meeting implementation detail not being subject
to a discussion on the IETF list (there have been many other, much more 
important, changes in meeting implementation which have not, and properly
so, been discussed by the community - e.g. the many tools.ietf.org support
tools, the additional remote participation abilities etc)

I find it amusing that there is more traffic on this topic on the IETF
discussion list than any issue that anyone in the world would see as an
actual issue.  This seems to be this year's cookie crises.  

To me, that means that this meeting is going rather well.

Scott

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-two-maturity-levels

[Scott O. Bradner]

I think that Phillip and I have agreed to disagree

Scott
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-two-maturity-levels

[Scott O. Bradner]

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
brought up (incuding the 'nothing progresses' problem) I have decided

I see no reason that we should make a change that is very likely to 
not fix any known problem just because we have been talking about 
various ideas for change for a long time - length of debate is not
an indication of usefulness of solution

it would not be the end of the IETF if this gets published but
it will also not be the begining of a better IETF - all of the 
problems will still be there and we would have a meaningless change 
just so we can say we made a change

Scott
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-two-maturity-levels

[Scott O. Bradner]

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, consideration, or seriousness (this is what
> we're doing now).

basically, yes - sometimes it is better to do nothing than to do something that
will actually make no real difference

> As I see it, the reason we need to do *something* here -- and I think
> Russ's proposal is a good start for it -- is exactly that we're
> largely ignoring those basic rules and making up a new system without
> serious consideration.

we have been ignoring some of these rules for a very long time - what makes
now a good time to change them?

Scott


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

what is the problem bis

[Scott O. Bradner]

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 in 2009), some DS (3 in 2009), and some S (6 in 2009).  

SOME of these technologies are just what the community needs and just
when the community needs them.  But too many are 
   1/ too late for the market - implementations based on IDs
  deployed or other technologies adopted
   2/ unneeded by the market - does not meet a need that people
  think they have
   3/ broken - flawed in some way that prevents actual deployment
   4/ too complex - hard and costly to correctly implement
   5/ unmanageable - cannot be run by humans

Seems to me that the issue of how the IETF can be better at producing
just what the community needs just when the community needs it is more
important than maturity warning labels.

Scott
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

what is the problem? (was Re: draft-housley-two-maturity-levels)

[Scott O. Bradner]

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 of the Internet runs on Internet Drafts?
4/ ???

then analyze the problem to see what might be behind it
e.g., for problem #1 
1/ no real incentive to put more work into advancing a document
2/ too much effort required to advance
3/ no actual benefit in advancing 
4/ the current IESG review ensures that the first stage document is
   rigorous enough that additional work on the technology is not needed
5/ requiring running code early in the game ensures that additional work
   on the technology is not needed  (see James's note)
6/ ???

e.g., for problem #2 
1/ see #4 above
2/ see #5 above
3/ working with busy volunteers

e.g., problem #3
1/ see problem #2


if the problem is #1 then what to do about it:
1/ change the process to meet what you think is the normal case (i.e.
   define away that there is a problem)
2/ change the process to one that is not currently followed and provide
   no reason to think that the underlying reasons the current process is
   not followed will magically change to make the new process any more of
   an accurate description.  (to me this is where Russ's ID sits)
3/ address some of the underlying reasons that the current description
   is not followed
4/ live with the current description and worry about things that can
   actually be fixed 

etc.

Scott


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-two-maturity-levels

[Scott O. Bradner]

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 different factors

I do not this particular document does this, nor would some other
document that proposes one or 7 steps

I think it is better to not fiddle, even if the current documents
do not paint an accurate picture, I think we need to be serious
when changing our basic rules.

Scott
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-two-maturity-levels

[Scott O. Bradner]

> 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 lot
and permit less complete documents to be published as PS

Scott
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-two-maturity-levels

[Scott O. Bradner]

> 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 while to get a proposed standard published and
people start to use it (if they did not start at the Internet Draft stage)
soon about anyone that has a need for the technology has implemented it and 
it is being used by customers all over the globe

just what is the reason that someone would take time from working on new 
technology to do the work to advance the proposed standard?  it is unlikely 
that all that many more people will implement or use the technology
so what is the point?

in addition, the IESG acts as if the proposed standard will be the last step
in the publication process (or at least reviews IDs as if this were the case)
so we have all the benefits of the cross area review (this making the proposed 
standards 
about as good as one could without requiring interoperable implementations at 
the
first stage (i.e. bringing back running code))

so I say drop it and live with the fact that rfc 2026 does not paint an accurate
picture of the current one step standard process

Scott

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

US government and IPv6 (was US DoD and IPv6)

[Scott O. Bradner]

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

Re: draft-housley-two-maturity-levels-01

[Scott O. Bradner]

> 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, kept (at least some) members of the IESG from seriously
considering what was being proposed

this was not the IESG's finest hour - lets leave it at that

Scott
(ex) newtrk chair
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Retention of blue sheets

[Scott O. Bradner]

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 mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Retention of blue sheets

[Scott O. Bradner]

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
   Internet Standards shall publicly announce, and shall maintain a
   publicly accessible record of, every activity in which it engages, to
   the extent that the activity represents the prosecution of any part
   of the Internet Standards Process.  For purposes of this section, the
   organizations involved in the development and approval of Internet
   Standards includes the IETF, the IESG, the IAB, all IETF Working
   Groups, and the Internet Society Board of Trustees.

2026 does not specifically mention maintaining a list of who was
at the meetings but that is clarly a part of a full record

in addition, RFC 2418 section 3.1 requires obtaining a list of attendees

   All working group sessions (including those held outside of the IETF
   meetings) shall be reported by making minutes available.  These
   minutes should include the agenda for the session, an account of the
   discussion including any decisions made, and a list of attendees. The
   Working Group Chair is responsible for insuring that session minutes
   are written and distributed, though the actual task may be performed
   by someone designated by the Working Group Chair. The minutes shall
   be submitted in printable ASCII text for publication in the IETF
   Proceedings, and for posting in the IETF Directories and are to be
   sent to: minu...@ietf.org

Scott
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Re: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions(TLP)

[Scott O. Bradner]

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 IETF.

My own reaction to the recent postings from the Trust is that the Trust
is moving in the direction that some of us were worried about -- the
Trust posts a bunch of proposed changes out of the blue.  Out of the
blue because I did not see any posting that explained why they felt that
they needed to make changes or that these specific changes were in
response to particular IETF requests (or legal threats)  - see the
original posting at
http://www.ietf.org/mail-archive/web/ietf/current/msg57276.html

The reaction from the Trust to the comments from the community has not
been reassuring.  It is true that they modified some of their proposed
changes but they do not seem to have understood the more basic issue
that I expressed in my message to the Trust on Tue Jun 23 14:57:12.

What I do not see in this message is pointers to where the
IETF asked that the TRUST to make these changes

it would be fine by me if the Trust were to send a note saying
that we see the following problems - (and maybe, here
are options we see) what whould you like us to do, it
   seems less fine for the Trust to get
   out ahead of the folks it is supposed to be working for
   in changing things (even if it provides a chance
   for the IETF to comment)

The fact that there was no response to that message or to a number of
other messages (in particular, messages from John Klensin) reinforces
the worry about an out of control Trust.

I think the Trust needs to press the reset button and start again.

Start with a posting that says what problems they feel the IETF has
asked them to fix and what other problems the feel need fixing, along
with the specific change they propose to deal with each problem.  We can
then talk about each issue to determine if there is consensus that the
problem needs fixing and if the proposed solution meets the needs.  And,
unless there is a specific legal threat that the Trust can point at this
process should not be rushed.

Scott

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions (TLP)

[Scott O. Bradner]

> 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
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions (TLP)

[Scott O. Bradner]

> 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

Re: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions (TLP)

[Scott O. Bradner]

> 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

what I did see was a bunch of changes without anything
that said specifically what problem each change was
trying to solve (not a "justification" for the change but a reason
that any change is needed at all)

we have been changing the IETF's IPR rules far too often
(and I'm in no small way responsible for many of the changes)
we should get out of that mode and only be making changes
where there is a speific need to do so.

Scott
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions (TLP)

[Scott O. Bradner]

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 depending on
the situation

1st way:
The IETF community provides the IETF Trust with a specific request and
the Trust provides possible changes or new text to meet the specific
request.  The IETF request can come form a WG, in which case it should
be in the form of a BCP (an IETF consensus document) or, with a public
justification, from the IETF Chair (or maybe the IAB Chair).  The Trust
publishes the proposed changes with a 4-week last call and the changes
are adopted if the IETF Chair determines that there is IETF consensus
support for the specific changes.

2nd way:
The IETF Trust determines that there is a specific legal risk that must
be countered.  In this case the IETF Trust posts a description of the
specific risk and the proposed change to counter the risk.  In this case
the Trust publishes the proposed changes with a 4-week last call and
adopts the changes if the IETF Chair determines that there is not IETF
consensus against the specific changes.

3rd way:
The IETF Trust determines that there are changes it would like to make
that are not in response to a specific legal risk.  In this case the
Trust publishes a list of the reasons they feel that the changes are
needed and the proposed changes.  (Note: not a list of changes and the
rationale for the changes - I think the IETF needs to agree that the
problems are ones that need fixing first)  The Trust publishes the
proposed changes with a 4-week last call and the changes are adopted
if the IETF Chair determines that there is IETF consensus
support for each specific change.

In no case does the IETF Trust adopt any changes without a public
statement concerning IETF consensus by the IETF Chair.  i.e., there is
no default adoption of changes by the Trust.

Scott


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions (TLP)

[Scott O. Bradner]

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 clear statement of what the trust thinks its role is

and if it not to be responsive to requests from the IETF I think we
need to have a discussion on the IETF list to understand if any other
role is one that is supported by the IETF community

Scott

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [Trustees] Proposed Revisions to the IETF Trust Legal Provisions (TLP)

[Scott O. Bradner]

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

Re: IETF and open source license compatibility

[Scott O. Bradner]

> > 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 acknowledgment of all 
significant contributers so an acknowledgment is required

Scott
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Time for a sign-up campaign [Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary]

[Scott O. Bradner]

> 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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

TSV Area review of draft-ietf-dime-qos-parameters

[Scott O. Bradner]

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 raised. The authors should
consider this review together with any other last-call comments they receive.

This ID describes some useful technology but I think it can be improved.

My main issue is that the ID does not do a good enough job of making clear what
the units of the parameters are or even what the meaning of some of the 
parameters
are.  Some of the information can be found by looking at the RFCs that are
referenced but it would be cleaner to just include the information in this
document.

I was initially confused by the fact that section 3 contained no information on
what the units of the parameters are but much of this is covered in section 4.
(if it were up to me I'd put the units in section 3 as well - e.g. in section 
3.2
I'd say that "The  parameter (expressed in usec) refers to the
accumulated latency …" )

But not all of the units are explained in section 4 and some terms are left
undefined.

I'll only provide some examples here - I suggest that the authors step through 
the
document and be sure that the units as well as the terms are defined in every
case.

For example, in section 3.1.  The value "large" is not defined or explained, nor
is the term "policed unit".  The document does not say what the units for rate
(bytes per second?, packets per usec?) are or the units for bucket size (bytes?)
- an educated guess can be made but it would be better if no guessing were 
needed.

Another example, in section 3.2.  The units for packet loss rate are not given
(packets per second?  % of packets?)

Also, in section 4.5.  It would be nice to have a few words say what "99.9%-ile"
means and how to calculate it for those who might not know

nit: section 4.8 says "A description of the semantic of the parameter values can
be found in [RFC2212], [RFC2215]. "  Should this say " [RFC2212] and 
[RFC2215]"? 

nit: the first sentence under section 4.13.3 is not a sentence

nit: section 6.1 - 4th pp says "1 to 511: Standards Action" the pp following 
says
"range of 0-511"  - should these be consistent?

Scott

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: RFC 2026 interpretation question

[Scott O. Bradner]

>  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 interpretation of the second
> paragraph of RFC 2026 Section 6.2.4 as requiring a sixty-day
> waiting period between IESG action and RFC publication.   I
> think that interpretation is clearly against the intent of 2026,

as does the editor of 2026

Scott
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Archives for closed WGs

[Scott O. Bradner]

> 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

Re: Archives for closed WGs

[Scott O. Bradner]

ps - very impressive work by the tools group

Scott
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Archives for closed WGs

[Scott O. Bradner]

> 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

Re: Removal of IETF patent disclosures?

[Scott O. Bradner]

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 (properly verified) to mark the statement
as no longer in effect (with a reason as to why) might be OK
except that I find it hard to see why the IETF would want to
make it easier for an IPR holder to mislead a WG on the IPR
holder's intentions ('you can have it' 'oops, I did not mean that')

there could be a real issue if someone who did not have the
authority to do so committed a IPR holder to specific IPR 
terms (like free) but that seems to be a problem for the
IPR holder to deal with internally since I'm far from sure
what the legal precident is for that sort of thing

Scott
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: new text for ID_Checklist sect 3, item 6

[Scott O. Bradner]

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-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, 
BAYES_00=-2.599]
From: "Bert Wijnen \(IETF\)" <[EMAIL PROTECTED]>
To: "IETF Discussion" 
Subject: new text for ID_Checklist sect 3, item 6
Date: Wed, 13 Aug 2008 12:21:41 +0200
Organization: Consultant
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6001.18000
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18000
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: ,

List-Post: 
List-Help: 
List-Subscribe: ,

Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]

The revision 1.8 of the ID-Checklist is at
  
http://www.ietf.org/ID-Checklist.html

Sect 3, item 6 in that revision states:

 6. Addresses used in examples SHOULD use fully qualified
domain names instead of literal IP addresses, and SHOULD
use example fqdn's such as foo.example.com instead of
real-world fqdn's. See [RFC2606] for example domain names
that can be used. 

John Klensin has proposed new text, whcih was amended by
Ted Hardie and the resulting text (if I understood it correctly) is:


   "6.  Addresses used in I-Ds SHOULD use fully qualified 
domain names (FQDNs) instead of literal IP addresses. 
Working Groups or authors seeing exemptions from that 
rule MUST supply the rationale for IP address use with 
inline comments (e.g., "Editor's note:" or "Note in 
Draft:" that can be evaluated by the IESG and the 
community along with the rest of the document.  Example
domains in pseudo-code, actual code segments, sample
data structures and templates, specifically including MIB
definitions and examples that could reasonably be 
expected to be partially or entirely copied into code, 
MUST be drawn from the list reserved for documentary
use in BCP32 (RFC 2606 or its successors).  It is generally 
desirable for domain names used in other I-D discussion 
contexts to be drawn from BCP32 as well, if only as an 
act of politeness toward those who might be using the 
domains for other purposes at the time of publication or 
subsequently.   Working groups or editors who are 
convinced that different names are required MUST be 
prepared to explain and justify their choices and SHOULD 
do so with explicit inline comments such as those 
described above." 

>From the discussion on the list (that I have seen), people seem to
be OK with that text. It is quite a bit longer, but so be it.

Does anyone have objections to the above text as replacement for
the current text?

Bert 
Editor for ID_Checklist

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Proposed Experiment: More Meeting Time on Friday for IETF 73

[Scott O. Bradner]

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 percentage
considerably - so for many people this would mean an extra day in the
hotel (and the expense of that) as well as ensuring a good chunk of
another weekend day away from family.

My prediction is that the attendance at the Friday afternoon sessions
will likely be quite low.

Scott

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis

[Scott O. Bradner]

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 said the same thing 
and asked for community comment and the comunity consensus supported 
the rules then a blocking DISCUSS by an IESG member would be a 
reasonable thing. But no such rules were posted and no such comunity 
consensus was shown. (Actually, I whoud hope that comunity consensus
woud be against the idea of the IESG doing any such thing since 
such things should be left to normal IETF process rather 
that to management from the top.)

Scott

___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Blue sheet harvest

[Scott O. Bradner]

> 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/listinfo/ietf

Re: Blue sheet harvest

[Scott O. Bradner]

< 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
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Blue Sheet Change Proposal

[Scott O. Bradner]

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 Proposal
Content-Type: text/plain; charset=US-ASCII

At Thu,  3 Apr 2008 20:10:12 -0400 (EDT),
Scott O. Bradner wrote:
> 
> 
> 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 to know 
> "who is in the room" (see RFC 2418 section 3.1 for the actual
> requirement)
> 
> the blue sheets become part of the formal record of the standards
> process and can be retrieved if needed (e.g. in a lawsuit) but are not
> generally made available 
> 
> as pointed out by Mark Andrews - email addresses can be useful in 
> determining the actual identity of the person who scrawled their 
> name on the sheet - so it is an advantage to retain them
> 
> I'm trying to understand how the blue sheets contribute in any
> significant way to the spam problem - someone whould have to be 
> surreptitiously copying  them or quickly writing down the email 
> addresses - both could happen but do not seem to be all that 
> likely there are far more efficient ways to grab email addresses
> 
> so, my question is "is this a problem that needs solving"?

The only reason I've heard is that some claim that people don't
write their names on the blue sheets out of concern over spam.

This actually seems like something we could test pretty easily
by counting room entries and blue sheet entries and comparing
the totals...

-Ekr

___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Blue Sheet Change Proposal

[Scott O. Bradner]

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 to know 
"who is in the room" (see RFC 2418 section 3.1 for the actual
requirement)

the blue sheets become part of the formal record of the standards
process and can be retrieved if needed (e.g. in a lawsuit) but are not
generally made available 

as pointed out by Mark Andrews - email addresses can be useful in 
determining the actual identity of the person who scrawled their 
name on the sheet - so it is an advantage to retain them

I'm trying to understand how the blue sheets contribute in any
significant way to the spam problem - someone whould have to be 
surreptitiously copying  them or quickly writing down the email 
addresses - both could happen but do not seem to be all that 
likely there are far more efficient ways to grab email addresses

so, my question is "is this a problem that needs solving"?

Scott
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Scott O. Bradner]

> 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 
their own ruleset but gets tricky for irtf unless they do and
splitting off iert & iab from teh rest of the ietf seems a bit
funky

Scott
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-carpenter-rfc2026-changes (Changes to the ..

[Scott O. Bradner]

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
unreadable - a new version of 2026 would make far more sense 
2/ I do not think we are remotely ready to produce a revised
2026 (no matter how much I would like to) process- and discussion-wise



that said, some notes as if this might move forward

I'm not sure that tweaking STD is enough of a problem to fix - STDs are
mostly ignored and thus do not get in the way

re expired IDs: see, for example
http://tools.ietf.org/id/draft-bradner-pbk-frame-00.txt
 i.e, "expired" IDs are available through tools.ietf.org (a good thing
in my mind) but confuses the suggested text changes

TS vs AS - it would be good to say that a TS can include an AS - but I'm
not sure one needs to do much more than that

I'm not sure much needs to be done in a delta document about requirement
levels other than mention RFC 4897

renaming the standards levels
a bit of history 
the first place I found that lists the standards levels is RFC
1083 (Dec 1988) - that lists "Proposed Protocol", "Draft Standard
Protocol" and "Standard Protocol"
"Proposed Protocol" switched to "Proposed Standard Protocol" in
RFC 1140 (May 1990)
The current usage (dropping "protocol") was established by the
time that RFC 1310 was published (March 1992)

so we have been using basically the same names since 1990 - I'd
want to see a very good reason to change names with that amount of
history behind them - and I do not see it here - I do think that we have
issues with the 3-level process but tweaking the names in this way
would:
1/ confuse
2/ not prevent deployment at the first IESG-approved stage
(since we often get deployment at the Internet Draft stage)

re: interoperability requirements - Brian details some real issues here
and having a quick punt to the IESG to say what it mans may not be a bad
idea but this is something that may deserve a separate document because
the details of interpretation will change from time to time - and its
easier to update a stand alone doc

re: informational RFCs - proposed addition makes sense

re - non WG. sponsored info & exp RFCs - I do not like this process
anyway when it is uses as a way around getting a nasty (in some people's
minds) IESG note on their RFC (which can happen if it goes through the
RFC Editor) - I'd rather this escape route were closed and the IESG note
made more factual and less something that an author would want to avoid
- if the path involves real IESG review then it would be good to note
  that in the RFC (and note the same in wg info & exp RFCs)

re: stale proposed & draft standards - something like what Brian
proposes makes sense

re: appeals kickoff - if it applies to "any decision whatever" then how
about document editor decisions?  (document editors are not appointed by
the IESG) or decisions by the IETF Trust or IAD (also not appointed by
the IESG)






___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-carpenter-rfc2026-changes (Changes to the ..

[Scott O. Bradner]

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 indication of support

John's suggestion of a plenary discussion may be a reasonable path 
but I do not think that using the IETF Last Call process to
ferment discussion is all that good a way to proceed (this is what
I was calling flippent)

Scott

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-carpenter-rfc2026-changes (Changes to the ..

[Scott O. Bradner]

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/listinfo/ietf

Re: Should the RFC Editor publish an RFC in less than 2 months?

[Scott O. Bradner]

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 list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: tools everywhere (was Daily Dose version 2 launched

[Scott O. Bradner]

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 mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

tools everywhere (was Daily Dose version 2 launched

[Scott O. Bradner]

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 that 
its related to the nomcom not that its a tool - some thing for id submission

www.ietf.org/id/submit
www.ietf.org/nomcom/feedback

etc

Scott

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Free? Software Foundation

[Scott O. Bradner]

> 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 constructive
comments pointing out technical issues that might get fixed before
publication.

I have seen requests to not publish or delay publishing RFCs that had
been submitted to a working group but were not chosen - those requesters
were worried about the potential for confusion with the working group
output - if memory serves, the RFC was published in almost all of tehse
cases - but after a delay so the working group version could get
published first in some cases.

Scott


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Free? Software Foundation

[Scott O. Bradner]

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 foundation is espousing
> censorship 

It is absolutely ridiculous to call "censorship" a call to NOT publish
in *our* RFC series a document. "Censorship" would be if IETF
exerciced powers (which it does not have) to prevent ANY publication
of this document anywhere. 

If I do not publish your rants on my blog, for instance, it it not
censorship, you can always publish it elsewehere.

Your misusage of words could be excused only if english were not your
native language. Such an outrageous claim is common on /. or similar
sites but I did not expect it on an IETF mailing list (except by JFC
or similar trolls).





___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Free? Software Foundation

[Scott O. Bradner]

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

Re: [IPFIX] draft-ietf-ipfix-protocol-26.txt

[Scott O. Bradner]

> 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 copying the UDP section here below for your convenience.

this text is good as far as it goes, I'd suggest adding specific 
'you may easily kill the network' language (along the lines of what 
I said in a previous message) - that warning is more implied than 
stated in the current text

then it would be good to add a specific pointer to that section
of the guidelines in the UDP section of the protocol document

thanks

Scott



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: [IPFIX] draft-ietf-ipfix-protocol-26.txt

[Scott O. Bradner]

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 PROTECTED]
Subject: Re: [IPFIX] draft-ietf-ipfix-protocol-26.txt

Scott
> Historically the biggest issue with IPFIX has been that most
> implementers want to run it over UDP with consequences be dammed.  -
> this was weaseled in the IPFIX Requirements document (RFC 3917) by
> requiring (in section 6.3.1) that "For the data transfer, a congestion
> aware protocol must be supported."  This draft meets that requirement by
> making the implementation of SCTP a MUST.  That will not stop many
> implementers from ignoring the requirement for implementation or users
> to enable UDP and thus creating a potentially very high bandwidth
> non-congestion avoiding fire hose that can quite easily wipe out a net
> by misconfiguration or become a DoS engine by purposeful configuration.
>
> I'm not sure if anything can be actually be done about this risk - It
> might help some to say that UDP is a "MUST NOT" but I doubt it - in any
> case it would help somewhat, imho, to expand section 10.3 to be clearer
> about the threats posed by any use of a non-congestion avoiding
> transport protocol or to do that in the Security Considerations section
>   

There is text in section 10.1 which states:

UDP MAY be used although it is not a congestion aware protocol.  
However, the IPFIX traffic between Exporter and Collector MUST run 
in an environment where IPFIX traffic has been provisioned for or is 
contained through some other means. 

This sets out the set of conditions that MUST be fulfilled in order to 
run IPFIX over
UDP safely.

Stewart


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

draft-ietf-ipfix-protocol-26.txt

[Scott O. Bradner]

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 next 31
years

section 6.1.2 - it might be reasonable to add the IEEE 8-byte MAC
address as an address type - this is used in ZigBee and may be in wider
use in the future

section 10.3.3 - a max packet size of 1280 could be used if the
connection is known to be running in an IPv6-only environment

I'm not sure why the packet size discussion is only listed for UDP - it
seems like the same restriction should apply to all protocols -
fragmentation is not your friend

Historically the biggest issue with IPFIX has been that most
implementers want to run it over UDP with consequences be dammed.  -
this was weaseled in the IPFIX Requirements document (RFC 3917) by
requiring (in section 6.3.1) that "For the data transfer, a congestion
aware protocol must be supported."  This draft meets that requirement by
making the implementation of SCTP a MUST.  That will not stop many
implementers from ignoring the requirement for implementation or users
to enable UDP and thus creating a potentially very high bandwidth
non-congestion avoiding fire hose that can quite easily wipe out a net
by misconfiguration or become a DoS engine by purposeful configuration.

I'm not sure if anything can be actually be done about this risk - It
might help some to say that UDP is a "MUST NOT" but I doubt it - in any
case it would help somewhat, imho, to expand section 10.3 to be clearer
about the threats posed by any use of a non-congestion avoiding
transport protocol or to do that in the Security Considerations section

Scott

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IETF Streaming

[Scott O. Bradner]

> 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 there should be a clear link on the meeting web page
(http://www3.ietf.org/meetings/69-IETF.html) for both the audio and
jabber services

(unless the aim is to minimize use)

Scott

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: consensus and anonymity

[Scott O. Bradner]

> 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 majority vote - all we 
need to be able to verify is that "most" people support a path 
- if a proposal gets blocked by a secret whisper in the ear of
the WG chair then things are very broken indeed

if the result of a secret whisper results in the chair brings up
topics for public discussion I'm not all that worried

Scott

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

"free standards" [was Re: Withdrawal of Approval and Second Last ...]

[Scott O. Bradner]

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 pay to get a copy of the standard - as in 'the ITU-T
recomendations (a.k.a, standards) used to cost money to get but are now free'
or 'I can download the IETF RFCs from the web for free.'

if you want to write about "standards that have no known patent
licensing requirements" then say that 

(observation: you can not write about "standards that have no patent
licensing requirements" if you are talking about standards less than 
20 years old because there is no way to know if a standard is in that
set)

Scott

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC

[Scott O. Bradner]

> 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 informational RFC
- note that RFC 2026 does not require any last call for informationals

fwiw - I agree with John - this doc warents a longer last call because
it does impact how part of the IETF process will work and the draft
did not get vetted in a normal working group process

Scott

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: "Discuss" criteria

[Scott O. Bradner]

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 
>   a document where she or he believes this to be the case. While 
>   the Area Director should describe the technical area where
>   consensus is flawed, the focus of the DISCUSS and its resolution 
>   should be on how to forge a cross-IETF consensus.

what actual evidence must an AD present to indicate that the
assertion of non-consensus is anywhere but in the one AD's mind?

Scott



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf