Re: voting system for future venues?

Dave, > On 8/29/2011 8:01 AM, Henk Uijterwaal wrote: >> If we want more flexibility in order to find better hotel deals, then we have >> to do something like: dates are fixed approximately 1.5 years out, and we do >> not mind having meetings back-to-back with other organizations on the clash >> li

RE: 2119bis

On 2011-08-30 at 07:36:58, Peter Saint-Andre wrote: > for long enough, I finally decided to submit an I-D that is intended > to obsolete RFC 2119. IS THERE ANY CHANCE OF AGREEING THAT SHOUTING IS BAD? (i.e., Burger's first anti-law.) As opposed to mandating that requirements ought to be shou

Re: 2119bis

On 8/30/11, Murray S. Kucherawy wrote: >> Mark Nottingham: >> 1) I agree that the "SHOULD... UNLESS" pattern ought be documented. > I had never thought of this before. I kind of like the idea, especially > since SHOULD > has always meant "MUST unless you really know what you're doing" Such an

Re: 2119bis

Frank, On 8/30/11 12:15 AM, Frank Ellermann wrote: > On 29 August 2011 23:36, Peter Saint-Andre wrote: > >> staring at http://www.rfc-editor.org/errata_search.php?eid=499 for >> long enough, I finally decided to submit an I-D that is intended to >> obsolete RFC 2119. > There are literally thousan

Re: 2119bis

Frank, 2119bis is going to replace RFC 2119, and "Obsoletes: 2119" header is fine here. "Updates:" header means that some changes are made, and these specific changes are clearly indicated; 2119bis imports all the content of 2119 plus adding own changes, and is a significant update of 2119,

Re: 2119bis

30.08.2011 3:08, Mark Nottingham wrote: Thanks for starting this, Peter. A few comments / topics for discussion: 1) I agree that the "SHOULD... UNLESS" pattern ought be documented. I think 2119bis should discuss use of the keywords in conditional clauses, how to interpret something like " MUS

Re: voting system for future venues?

On 30 aug 2011, at 9:22, Henk Uijterwaal wrote: > That is a 4.5 year difference in when the exact date is announced. This > increase the risk that there is a clash with another meeting and people > cannot plan much in advance. Come on, the idea that people need to know the date of a meeting more

Re: Routing at the Edges of the Internet

On 30/Aug/11 04:50, Michel Py wrote: > > The mechanism (ICMP redirects) is technically fine and socially not. > People have become paranoid and now they firewall everything. It is a > behavioral animal. I'm not saying it's a good idea; the market answer to > crossing firewalls is to encapsulate ev

Scheduling years in advance [Re: voting system for future venues?]

On 2011-08-30 22:04, Iljitsch van Beijnum wrote: > On 30 aug 2011, at 9:22, Henk Uijterwaal wrote: > >> That is a 4.5 year difference in when the exact date is announced. This >> increase the risk that there is a clash with another meeting and people >> cannot plan much in advance. > > Come on,

Re: Scheduling years in advance [Re: voting system for future venues?]

> That isn't the point. It's to avoid clashes with IEEE, ITU-T, W3C > and numerous others standards bodies that have overlapping > participants. There were constant problems in the past, until we > went to the current advance scheduling. Understood. But I wonder of we've forgotten the original mo

Re: Scheduling years in advance [Re: voting system for future venues?]

On Tue, Aug 30, 2011 at 8:33 AM, Thomas Narten wrote: > > That isn't the point. It's to avoid clashes with IEEE, ITU-T, W3C > > and numerous others standards bodies that have overlapping > > participants. There were constant problems in the past, until we > > went to the current advance schedulin

Re: 2119bis

Dear Eric; I support adding the SHOULD ... UNLESS formalism (although maybe it should be MUST... UNLESS). It would be useful as there will be times where the UNLESS can be specified and has been given due consideration at the time of writing. That, however, will not always be the case. (More inlin

RE: Routing at the Edges of the Internet

You could start by looking at MANET work, both in the WG of that name and work outside the IETF under that name and as ad hoc networks (the mobile in MANET can be misleading, D for dynamic might be mor to the point) and mesh networks. There are real networks (such as the Freifunk network in Germany

Re: 2119bis

+1, too. This goes along with my strong desire to eliminate passive voice, unless the goal is to have the actor be obfuscated (as an example). On Aug 30, 2011, at 5:29 AM, Mykyta Yevstifeyev wrote: >> 2) I strongly believe that authors should be encouraged to enumerate the >> potential subject

Re: 2119bis

On Aug 30, 2011, at 9:24 AM, Marshall Eubanks wrote: > Dear Eric; > > I support adding the SHOULD ... UNLESS formalism (although maybe it should be > MUST... UNLESS). It would be useful as there will be times where the UNLESS > can be specified and has been given due consideration at the time of

Re: 2119bis

I would offer that working groups that say to do something that may or may not hold in foreseen or unforeseen circumstances is most likely working on a protocol that is way too complex and is begging for interoperability problems. What ever happened to building simple, point-solution protocols

Re: 2119bis

I think you're overgeneralizing. My experience is that judicious use of SHOULD seems to make both protocols and protocol specifications simpler; trying to nail everything down makes them more complex. Keith On Aug 30, 2011, at 9:51 AM, Eric Burger wrote: > I would offer that working groups th

Re: 2119bis

On Aug 30, 2011, at 9:24 AM, Marshall Eubanks wrote: > I support adding the SHOULD ... UNLESS formalism (although maybe it should be > MUST... UNLESS). It would be useful as there will be times where the UNLESS > can be specified and has been given due consideration at the time of writing. > Th

Re: 2119bis

This sentiment mostly makes sense. If an endpoint expects SHOULD/MAY items implemented as MUSTs on the remote end, then one should slap the endpoint developer silly. Read the RFC! If it says SHOULD/MAY, then your implementation MUST be able to handle the feature present *and* absent. Note th

Re: 2119bis

On Aug 30, 2011, at 9:56 AM, Eric Burger wrote: > Every SHOULD/MAY results in at least one "if" statement, to test the > presence or absence of the feature in the remote end. false. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/l

Re: 2119bis

Strictly speaking, you are correct, in that if one interprets SHOULD/MAY as 'not bother', one does not need to check, unless the presence of the remote end doing the feature results in your barfing. However, if one interprets SHOULD/MAY as 'bother', then one most likely needs to check on the ca

Re: 2119bis

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2011 06:54 AM, Keith Moore wrote: > I think you're overgeneralizing. My experience is that judicious use of > SHOULD seems to make both protocols and protocol specifications simpler; > trying to nail everything down makes them more complex.

Re: 2119bis

On 8/30/11, Keith Moore wrote: > On Aug 30, 2011, at 9:24 AM, Marshall Eubanks wrote: > > Personally I think 2119 is just fine and doesn't need to be updated. > > Keith +1 -- hls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinf

Re: 2119bis

On Aug 30, 2011, at 10:13 AM, Eric Burger wrote: > > On Aug 30, 2011, at 9:58 AM, Keith Moore wrote: > >> On Aug 30, 2011, at 9:56 AM, Eric Burger wrote: >> >>> Every SHOULD/MAY results in at least one "if" statement, to test the >>> presence or absence of the feature in the remote end. >> >

Re: 2119bis

On Aug 30, 2011, at 10:14 AM, Marc Petit-Huguenin wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 08/30/2011 06:54 AM, Keith Moore wrote: >> I think you're overgeneralizing. My experience is that judicious use of >> SHOULD seems to make both protocols and protocol specifications

Re: 2119bis

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2011 07:35 AM, Keith Moore wrote: > On Aug 30, 2011, at 10:14 AM, Marc Petit-Huguenin wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 08/30/2011 06:54 AM, Keith Moore wrote: >>> I think you're overgeneralizing. My exper

Re: 2119bis

On Aug 30, 2011, at 10:54 AM, Marc Petit-Huguenin wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 08/30/2011 07:35 AM, Keith Moore wrote: >> On Aug 30, 2011, at 10:14 AM, Marc Petit-Huguenin wrote: >> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> On 08/30/2011 06

Limitations in RFC Errata mechanism

Hello all, I've observed several problems with submission mechanism for RFC Errata. Here they are: First, we have only two types of errata - Technical or Editorial. In presence of , "IESG Statement on IESG Processing of RFC Erra

Re: 2119bis

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2011 07:58 AM, Keith Moore wrote: > On Aug 30, 2011, at 10:54 AM, Marc Petit-Huguenin wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 08/30/2011 07:35 AM, Keith Moore wrote: >>> On Aug 30, 2011, at 10:14 AM, Marc Petit-H

Re: 2119bis

On Aug 30, 2011, at 11:38 AM, Marc Petit-Huguenin wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 08/30/2011 07:58 AM, Keith Moore wrote: >> On Aug 30, 2011, at 10:54 AM, Marc Petit-Huguenin wrote: >> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> On 08/30/2011 0

Re: 2119bis

I think you have hit the root cause on the head. I would also offer that by removing the crutch, or raising the bar to using the crutch, will help alleviate the root cause. On Aug 30, 2011, at 11:44 AM, Keith Moore wrote: > e.g. For the specific case of optional features that must be negotiated

Re: 2119bis

e.g. "SHOULD", "SHOULD NOT", "RECOMMENDED", and "NOT RECOMMENDED" are appropriate when valid exceptions to a general requirement are known to exist or appear to exist, and it is infeasible or impractical to enumerate all of them. However, they should not be interpreted as permitting implem

Re: 2119bis

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2011 08:44 AM, Keith Moore wrote: > > On Aug 30, 2011, at 11:38 AM, Marc Petit-Huguenin wrote: > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> On 08/30/2011 07:58 AM, Keith Moore wrote: >>> On Aug 30, 2011, at 10:54 AM, Marc Petit-

Re: 2119bis

On Tue, 2011-08-30, Keith Moore wrote: > But in general I get the impression that people are attacking > SHOULD because of specific problems rather than general > problems. Since I find SHOULD very useful, to me it makes more > sense to try to outline cases where SHOULD is problematic, and > pr

Re: 2119bis

On Aug 30, 2011, at 12:06 PM, Marc Petit-Huguenin wrote: > The meaning of SHOULD is clear for the authors (it "mean[s] that there may > exist > valid reasons in particular circumstances to ignore a particular item, but the > full implications must be understood and carefully weighed before choosi

Re: 2119bis

On 08/30/2011 06:07 PM, Bill McQuillan wrote: How about recommending SHOULD ... BECAUSE to encourage the author to justify the SHOULD. +1 Although saying something like this should do: "If there's a SHOULD clause in the document, the document MUST provide background and rationale for making

Re: 2119bis

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2011 09:11 AM, Keith Moore wrote: > On Aug 30, 2011, at 12:06 PM, Marc Petit-Huguenin wrote: > >> The meaning of SHOULD is clear for the authors (it "mean[s] that there may >> exist >> valid reasons in particular circumstances to ignore a pa

Re: 2119bis

On Aug 30, 2011, at 12:07 PM, Bill McQuillan wrote: > On Tue, 2011-08-30, Keith Moore wrote: > >> But in general I get the impression that people are attacking >> SHOULD because of specific problems rather than general >> problems. Since I find SHOULD very useful, to me it makes more >> sense to

Re: 2119bis

Can you give an example of where a dangling SHOULD makes sense? Most often I see something like: SHOULD implement security meaning SHOULD implement security, unless you do not feel like it or are in an authoritarian regime that bans security On Aug 30, 2011, at 12:11 PM, Keith

Re: 2119bis

Umm, wait. I'm confused. The boilerplate in existing documents points to 2119, right? and the updated boilerplate would point to this spec, if approved, right? so we're not retroactively changing the meaning of anything, right? What am I missing? Spencer - Original Message - From:

Re: 2119bis

In the perfect written technical specification, if you pulled out all the SHOULDs, the protocol still survives. But if a required functionality breaks down, then it wasn't well written. On 8/30/11, Eric Burger wrote: > Can you give an example of where a dangling SHOULD makes sense? Most often >

Re: 2119bis

On Aug 30, 2011, at 12:46 PM, Eric Burger wrote: > Can you give an example of where a dangling SHOULD makes sense? Most often I > see something like: > SHOULD implement security > meaning > SHOULD implement security, unless you do not feel like it or are in an > authoritarian regime

Re: 2119bis

On Aug 30, 2011, at 1:11 PM, Spencer Dawkins wrote: > Umm, wait. I'm confused. > > The boilerplate in existing documents points to 2119, right? and the updated > boilerplate would point to this spec, if approved, right? so we're not > retroactively changing the meaning of anything, right? >

RE: 2119bis

> -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of HLS > Sent: Tuesday, August 30, 2011 1:00 AM > To: IETF discussion list > Subject: Re: 2119bis > > > I had never thought of this before. I kind of like the idea, especially > > since SHOULD > >

Re: 2119bis

Note the language > "MUST implement, SHOULD use" is a common compromise. ^^^ This is my heartache. Why is it a compromise? Most use of SHOULD I run into in WG's is either this precise one: I don't want to make this a MUST use, because I

RE: 2119bis

> -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Keith > Moore > Sent: Tuesday, August 30, 2011 7:35 AM > To: Marc Petit-Huguenin > Cc: IETF discussion list; Eric Burger > Subject: Re: 2119bis > > To the extent that SHOULD is causing interoper

Re: 2119bis

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2011 09:11 AM, Keith Moore wrote: > On Aug 30, 2011, at 12:06 PM, Marc Petit-Huguenin wrote: > >> The meaning of SHOULD is clear for the authors (it "mean[s] that there may >> exist >> valid reasons in particular circumstances to ignore a pa

RE: 2119bis

It seems to me RFC2119bis might benefit from some consensus text on what proper use of each is, beyond defining their respective meanings. From the discussion, this is obviously true for SHOULD at least. The discussion around use of MAY in RFC2119 is fairly thorough, so maybe SHOULD needs to b

Re: 2119bis

On Aug 30, 2011, at 2:02 PM, Eric Burger wrote: > Note the language >> "MUST implement, SHOULD use" is a common compromise. > ^^^ > > This is my heartache. Why is it a compromise? Most use of SHOULD I run into > in WG's is either this precise

Re: 2119bis

We violently agree. However, the most cited reason I get for watering down security requirements are what I mentioned below. On Aug 30, 2011, at 2:19 PM, Keith Moore wrote: > > On Aug 30, 2011, at 2:02 PM, Eric Burger wrote: > >> Note the language >>> "MUST implement, SHOULD use" is a common

Re: Limitations in RFC Errata mechanism

On 8/30/2011 11:19 AM, Mykyta Yevstifeyev wrote: Hello all, I've observed several problems with submission mechanism for RFC Errata. Here they are: First, we have only two types of errata - Technical or Editorial. In presence of , "IE

Re: 2119bis

Its not correct if its doesn't state it how you interpreted it. A recommendation is not a MUST or a mandate, and using a SHOULD as if its required feature is pretty much guaranteed to cause problems when this MUST expectation is not met. Sounds like we are trying to remove the idea that implement

Re: 2119bis

On 8/29/11 9:44 PM, Eric Burger wrote: Yes, and... I would offer that for most cases, If Y then MUST X or If Z then MUST NOT X *are* what people usually mean when they say SHOULD. In the spirit of Say What You Mean, a bare SHOULD at the very least raise an ID-nit, suggesting to the author to

Re: 2119bis

What is the difference in this case between SHOULD or MAY? On Aug 30, 2011, at 2:49 PM, Adam Roach wrote: > On 8/29/11 9:44 PM, Eric Burger wrote: >> Yes, and... >> >> I would offer that for most cases, If Y then MUST X or If Z then MUST NOT X >> *are* what people usually mean when they say SHO

Re: 2119bis -- Tying our hands?

On 8/30/11 2:23 AM, Thomson, Martin wrote: On 2011-08-30 at 07:36:58, Peter Saint-Andre wrote: for long enough, I finally decided to submit an I-D that is intended to obsolete RFC 2119. IS THERE ANY CHANCE OF AGREEING THAT SHOUTING IS BAD? (i.e., Burger's first anti-law.) As opposed to mand

Re: 2119bis

When I approach a protocol to implement, the first thing I typically do is extract and develop the basic wiring of the protocol, the minimum requirements. Make sure the basic framework is correct 100%, then I look for the SHOULDs and also MAYS which are the easiest to add. I look at the SHOUL

RE: Limitations in RFC Errata mechanism

> -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of > Mykyta Yevstifeyev > Sent: Tuesday, August 30, 2011 8:19 AM > To: IETF Discussion > Subject: Limitations in RFC Errata mechanism > > First, we have only two types of errata - Technical or Edit

Re: 2119bis

In this case, unless the implementation has a good reason, failing to re-subscribe will result in behavior that the user perceives as broken. I don't think that's really "MAY" territory. /a On 8/30/11 1:57 PM, Eric Burger wrote: What is the difference in this case between SHOULD or MAY? On

Re: 2119bis

On Aug 30, 2011, at 2:49 PM, Adam Roach wrote: > Does "SHOULD" get abused by some authors in some documents? Of course it > does. But your crusade to throw out a useful tool just because it has been > misused on occasion is an extreme over-reaction. I like this tool. I use this > tool. If you s

Re: 2119bis

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2011 12:18 PM, Keith Moore wrote: > On Aug 30, 2011, at 2:49 PM, Adam Roach wrote: > >> Does "SHOULD" get abused by some authors in some documents? Of course it >> does. >> But your crusade to throw out a useful tool just because it has been

Re: Hyatt Taipei cancellation policy?

On 8/23/11 9:24 AM, John C Klensin wrote: So I'm opposed to a USD 200 (or any other number) firm limit on hotel rates. At the same time, I continue to wish that the IAOC would be more open with the community about how these decisions are made and, in particular, how the tradeoffs between sponso

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

I have reviewed the discussion from the last call on this document. My conclusion as the sponsoring AD is that we have consensus to move forward. There was clearly a constituency who believed this is a good (albeit small) step forward. A number of other people did not care so much; did not beli

Discuss criteria for documents that advance on the standards track

During the discussion of the two maturity levels change, a question was brought up about DISCUSSes appropriate for documents that advance on the standards track. We discussed this in the IESG and I drafted some suggested guidelines. Feedback on these suggestions would be welcome. The intent is

Re: [Ietf-krb-wg] Gen-ART review of draft-ietf-krb-wg-otp-preauth-18

I was thinking that if it's a proprietary OTP, we can still use it even if the algorithm is secret. If we know we're getting a "clear text" OTP value and we have an (unspecified) method of verifying it against some external infrastructure, that's enough to use otp-preauth. However I don't thin

Re: 2119bis

Thanks for doing this Peter. I only have one input regarding SHOULD. Recently an AD entered an WG during LC, apologized for not being involved more and specifically called out the 4-5 people who had rejected a SHOULD text injection proposal as not understanding RFC2119. He also added that sof

Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw

Reviewing this discussion there are three components. 1) The update of RFC5586 to allow PW to use the GAL. 2) The PW OAM application that is to use the GAL. 3) The label stack structure when teh GAL is used with a PW This draft is only concerned with point 1 above. Points 2 and 3 need to be re

RE: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw

Stewart, I believe that your item #1 is presumably addressed by draft-ietf-pwe3-gal-in-pw (with the changes you've proposed), draft-nadeau-pwe3-vccv-2 is an attempt to address your item #2, and your item #3 is not yet addressed. Is this understanding correct? I also think that one of the items

Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw

Sasha On 30/08/2011 13:22, Alexander Vainshtein wrote: Stewart, I believe that your item #1 is presumably addressed by draft-ietf-pwe3-gal-in-pw (with the changes you’ve proposed), draft-nadeau-pwe3-vccv-2 is an attempt to address your item #2, and your item #3 is not yet addressed. Is th

Re: Discuss criteria for documents that advance on the standards track

There's something inherently wrong with trying to establish criteria for voting DISCUSS. My understanding was always that DISCUSS was supposed to be an indication that, at a minimum, the AD needs to understand the situation better before casting a yea or nay vote. The resolution of a DISCUS

Re: Hyatt Taipei cancellation policy?

Dean, Before you give up completely I would check out: http://wikitravel.org/en/Taipei Taxis are not expensive, the Metro even less so, and there are at least some budget hotels nearby. I expect the local hosts to provide more information soon -- they already have some info on the website. I

Re: Discuss criteria for documents that advance on the standards track

On Aug 30, 2011, at 2:17 PM, Keith Moore wrote: > My understanding was always that DISCUSS was supposed to be an indication > that, at a minimum, the AD needs to understand the situation better before > casting a yea or nay vote. The resolution of a DISCUSS might end up being a > yes vote, a

Re: Discuss criteria for documents that advance on the standards track

On Aug 30, 2011, at 5:51 PM, Fred Baker wrote: > > On Aug 30, 2011, at 2:17 PM, Keith Moore wrote: >> My understanding was always that DISCUSS was supposed to be an indication >> that, at a minimum, the AD needs to understand the situation better before >> casting a yea or nay vote. The resol

Re: 2119bis

> On Aug 30, 2011, at 9:24 AM, Marshall Eubanks wrote: > > I support adding the SHOULD ... UNLESS formalism (although maybe it should > > be MUST... UNLESS). It would be useful as there will be times where the > > UNLESS can be specified and has been given due consideration at the time of > > w

Re: Discuss criteria for documents that advance on the standards track

On 2011-08-31 09:51, Fred Baker wrote: ... > If the AD raised a valid issue, the ball is in the author/wg's court to > address it. They can game this rule by not responding until after 45 days. Not if the draft has been updated and the AD doesn't either cancel the DISCUSS within a reasonable ti

Re: Discuss criteria for documents that advance on the standards track

On 2011-08-31 08:18, Jari Arkko wrote: ... > Here are the suggested guidelines for documents that advance to IS: > > http://www.arkko.com/ietf/iesg/discuss-criteria-advancing.txt > > Comments appreciated. To answer Jari's original request: +1 to these new guidelines. Not worth nit-picking until

Re: 2119bis

On 2011-08-31 10:38, ned+i...@mauve.mrochek.com wrote: >> On Aug 30, 2011, at 9:24 AM, Marshall Eubanks wrote: > >>> I support adding the SHOULD ... UNLESS formalism (although maybe it should >>> be MUST... UNLESS). It would be useful as there will be times where the >>> UNLESS can be specified

Re: 2119bis

Just responding to a small part, here: >   B) RFC2119 states SHOULD is the same as the adjective "RECOMMENDED." > > As far I am concern, a recommendation is not a mandate nor obligation. The problem we have with using what look like English words for these things is that people have expectations

Re: 2119bis

Friendly reminder from BCP 61: Security is a "MUST implement" On 8/30/11 12:46 PM, Eric Burger wrote: Can you give an example of where a dangling SHOULD makes sense? Most often I see something like: SHOULD implement security meaning

Re: 2119bis -- Tying our hands?

On 8/30/11 2:08 PM, Adam Roach wrote: Because the current suggestion -- which turns RFC writing into the game "Taboo" [1], but with incredibly common English words [2] as the forbidden list -- is ridiculous on its face. Don't use requirements language unless you absolutely have to. Otherwise,

RE: 2119bis -- Tying our hands?

My first reaction was that the entire topic is a bike shed. The goal is clear and understandable specifications and 2119 is just a tool we use to make the process of producing and reading specifications more efficient. What I'm getting from this is that there are a significant number of drafts

Re: Limitations in RFC Errata mechanism

30.08.2011 22:09, Murray S. Kucherawy wrote: -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mykyta Yevstifeyev Sent: Tuesday, August 30, 2011 8:19 AM To: IETF Discussion Subject: Limitations in RFC Errata mechanism First, we have only two type

RE: Limitations in RFC Errata mechanism

> -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of > Mykyta Yevstifeyev > Sent: Tuesday, August 30, 2011 9:05 PM > To: ietf@ietf.org > Subject: Re: Limitations in RFC Errata mechanism > > > I think given the current mechanism I would just submit

Re: Discuss criteria for documents that advance on the standards track

--On Tuesday, August 30, 2011 14:51 -0700 Fred Baker wrote: >> What's also not fair game is to "raise the bar" - to expect >> the document at DS to meet more stringent criteria than it >> was required to meet at the time of PS approval. > > Hmmm, the "demonstrated interoperability" requirement

Re: Discuss criteria for documents that advance on the standards track

Keith, thank you for the feedback. Some responses inline: 1. Fix the broken IESG voting system before you try to establish more decision criteria. I do agree with your general thinking here. The way that you describe the different positions is what I personally try to achieve in my IESG revi