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

[Jari Arkko]

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

But I think you are overemphasizing the role of the vote designations. Again, I 
try to do this already, though maybe not always succeeding. In general, if the 
Area Directors are not doing their job of stopping bad stuff and moving good 
stuff along, they don't need a new voting system, they need to grow a spine.

Elaborating a bit more about this:

We have plenty of cases where a DISCUSS has been left standing, and today that acts as 
your "NO" vote. (Obviously, in many cases this was an error, or lack of effort. 
I'm quilty of this for sure, even right now I have a queue of DISCUSSes and their 
proposed resolutions that I need to go check.) But I think a DISCUSS should stand, if 
there is a serious issue and it is not rectified.

There are corner cases where a single AD has an opinion that is not shared by 
the rest of the community. For those cases we have an override procedure. This 
has been never been invoked, but that's probably because it gets pretty ugly 
way before that -- there are often heated discussions between ADs about 
discusses.

We have the ABSTAIN vote, which some ADs use to vote "NO", often together with 
other ADs who feel the same. There's never been a case where this would have blocked a 
document from proceeding, as we've never collected the necessary 1/3 number of ADs to 
vote ABSTAIN for any single document. My conclusion is that ABSTAIN stands for 
NO-OBJECTION in practical terms. I don't recommend its use...


2. Don't overconstrain the use of DISCUSS.  In particular, don't ever create a 
situation where a reviewer can't cite a problem with a document, regardless of 
whether that problem has previously been enumerated.


I agree, and that's why the guidelines I posted are just that -- guidelines. 
They are not binding rules, they leave room for a judgment call.


3. I take serious issue with the statement in the draft that IESG reviews are 
"reviews of last resort" and the implication that WG reviews are sufficient.  
In numerous situations this has not been the case.


Of course. But I don't see a conflict between a "review of last resort" and having the 
last resort find issues. I wish we'd find less issues, but at least I still view the IESG as the 
final check, that should catch issues if others have not. Its not a "last resort" in the 
sense that it would not be invoked; we do review all documents very carefully. Its a last resort 
only in the sense that there is an expectation that previous stages should have produced a quality 
result without issues.

Jari

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

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

[John C Klensin]

--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 of DS/IS
> is in fact a raising of the bar,and one that has served us
> well. We don't (although IMHO we should) require even an
> implementation to go to PS. 

I know it is controversial, but there is at least one other area
in which we should be raising the bar for DS/IS by dropping the
bar for Proposed.  If we really want to get PS specs out quickly
while the percentage of people who easily write very high
quality technical English in the IETF continues to go down, we
need to stop the behavior of various IESG members simulating
technical editors or translators to "fix" PS text (or insisting
that the author or WG do so, which, IMO, is less bad but still
often a problem).  Doing that will get documents out faster,
perhaps even a lot faster in some cases, but will inevitably
result in PS documents that need significant editorial work
before being approved at DS.  

I think that would actually be a good thing.  I think that
stuffing explicit placeholders to the effect of "this needs to
be rewritten to be completely clear to folks who haven't
participated in the WG" into PS documents would be a fine idea
-- it would get those documents finished and out while making
their preliminary nature very clear.   But it implies a higher
editorial quality standard --a higher bar-- for DS/IS than for
PS.

john



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

RE: Limitations in RFC Errata mechanism

[Murray S. Kucherawy]

> -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 such things
> > under "Editorial".
> 
> This is an option; but doing so makes work of RFC Editor when
> incorporating metadata errata harder.  If we have such thing as Metadata
> erratum type, and if such erratum gets verified, RFC Editor will be
> capable of noticing and acting quickly (I doubt RFC Editor pays much
> attention to Editorial errata when submitted/verified).

I'm sure the RFC Editor appreciates people in the IETF trying to make their 
work easier, but since so far they haven't complained about this in particular, 
I'm not sure it's something that actually needs fixing.

> > I was able to type "Appendix A" just now into that section without
> > difficulty.  The preview page shows "Section Appendix A says:", but
> > that hardly seems a difficulty.
> 
> This limitation makes submitters find the way to put what they want in
> this field whose entity, I think, should be limited to digits and ".".
> This issue is probably of aesthetic importance.

As a submitter, I didn't find typing "Appendix A" into that box and decoding 
the output to be at all inconvenient.  It may not be perfect, but it's not 
terribly broken either.

> > Typically a working group discusses an erratum when it is raised, and
> > then it sits in limbo until a document update occurs.  Isn't the right
> > place for discussion about a particular one the mailing list of that
> > working group or, if it's disbanded, the main IETF list?
> 
> Well, there are AD-sponsored Individual Submissions, which have no
> associated WG, and IAB, IRTF and Independent docs which IETF community
> might have a limited interest in.  If we had the lists where errata
> for:
> [...]

I still don't see this as evidence that we need to have a forum specifically 
for discussing errata.  I would have to subscribe to that list just in case 
there's ever any erratum opened for an RFC that interests me, and deal with the 
(possibly huge) amount of traffic that is not of interest.  It seems to me that 
ietf@ietf.org is just fine for this purpose, and most of us already are on that 
one.

I also haven't seen any demand prior to this for a special forum where errata 
are discussed, separate from the list(s) we already have.

> Discussing errata on IETF Discussion list will increase our traffic and
> will soon bore many people who aren't particularly interested in a
> variety of topics errata are submitted on.

As far as I can tell, that's where this happens now, and I don't see it being 
much of a burden.

I could be wrong, but I don't see much evidence that any of this stuff is 
broken enough to warrant a bunch of form changes, new mailing lists, or other 
new infrastructure.  If it ain't broke, don't fix it.

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

Re: Limitations in RFC Errata mechanism

[Mykyta Yevstifeyev]

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 types of errata - Technical or Editorial.  In presence 
of
, "IESG
Statement on IESG Processing of RFC Errata concerning RFC Metadata", I
think the third type is necessary - Metadata.

I think given the current mechanism I would just submit such things under 
"Editorial".


This is an option; but doing so makes work of RFC Editor when 
incorporating metadata errata harder.  If we have such thing as Metadata 
erratum type, and if such erratum gets verified, RFC Editor will be 
capable of noticing and acting quickly (I doubt RFC Editor pays much 
attention to Editorial errata when submitted/verified).





Second, the "Section" field at
  implies that only
numerical sections will contain something an erratum can be reported
against (overlooking the GLOBAL option).  However, Appendices, Abstract,
Index, Author Info, different Notes exist, that aren't covered here.

I was able to type "Appendix A" just now into that section without difficulty.  The 
preview page shows "Section Appendix A says:", but that hardly seems a difficulty.


This limitation makes submitters find the way to put what they want in 
this field whose entity, I think, should be limited to digits and ".".  
This issue is probably of aesthetic importance.





Third, Original text and Corrected text fields imply that only
before-and-after errata may be submitted.  However, there might be
errata like Erratum # 6
(http://www.rfc-editor.org/errata_search.php?eid=6), with an only Report
text field.  I understand this feature was present in previous versions
of errata mechanism but removed from the current.

I don't understand the problem here.  That report seems pretty clear to me.


There used to be a "Text Report" option for submitting errata.  This 
implied filling in the only field, not "Current Text" and "Corrected 
Text".  Now it is unavailable, and this makes submitters write smth like 
this:


"Scope: GLOBAL"; "Current text: N/A"; "Corrected text: to say>"


and this results in a report saying that

"Throughout the document, when it says N/A, it should say submitter wanted to say>".


If the one-field errata existed, this would be:

"Scope: "; "Report Text: "

and the erratum will look like:

"[For this document] the following erratum was reported: wanted to say>".


(The scope-indicating field when submitting such errata should be made 
optional, BTW.)





Also, several issues not related to submission mechanism.

1) Specific mailing lists devoted to discussion of errata against RFCs
from different areas.  I've proposed this on rfc-interest list; see rationale at
.;

Typically a working group discusses an erratum when it is raised, and then it 
sits in limbo until a document update occurs.  Isn't the right place for 
discussion about a particular one the mailing list of that working group or, if 
it's disbanded, the main IETF list?


Well, there are AD-sponsored Individual Submissions, which have no 
associated WG, and IAB, IRTF and Independent docs which IETF community 
might have a limited interest in.  If we had the lists where errata for:


1. IETF Stream:
a. Apps Area;
b. Int Area;
c. Gen Area;
d. Ops Area;
e. RAI Area;
f. Rtg area;
g. Sec Area;
h. Tsv-Area
i. Legacy (published bu concluded areas);
j. Individual Submissions;
2. IAB Stream;
3. IRTF Stream;
4. Independent Submissions

folks who don't have ability or willing to join corresponding groups' 
lists will be capable of joining these lists.


Discussing errata on IETF Discussion list will increase our traffic and 
will soon bore many people who aren't particularly interested in a 
variety of topics errata are submitted on.





3) Verified technical errata may be incorporated in the references. Eg.
4 technical errata were reported against RFC 793 and verified; so the
reference may be:

Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.  Ammended by RFC Errata Reports 573, 1562, 1564, 1572.

I don't think verified errata have any force or effect until the document is 
actually updated, so this really just becomes clutter in the references.  
Moreover, if I'm implementing some RFC that references another which itself has 
errata, I will want to know about all of them, not the ones that were present 
and verified at the time of publication.


Well, a reasonable argument.  At Appendix A of 
draft-rfc-editor-errata-process-02 
(http://tools.ietf.org/html/draft-rfc-editor-errata-process-02#appendix-A) 
I found a proposal from Brian Carpenter to point to errata list in the 
RFC itself, prob

RE: 2119bis -- Tying our hands?

[Thomson, Martin]

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 
being submitted to the IESG for publication that are not sufficiently precise 
in their use of language.

Deciding to revise 2119 seems - at first blush - an interesting reaction to 
this problem.  But it's become evident that we don't share a common 
understanding of the language, nor are we consistent in its application.

Formalizing usage patterns (c.f. server MUST/client MAY, MUST...UNLESS...) does 
help, if only because you've made it easier to do the right thing in more 
cases.  If the problem is that authors and editors don't have the tools they 
need, then maybe a revision is the right approach.

However, I'd still like to see more RFCs that describe something without 
resorting to using these crude implements.

On 2011-08-31 at 05:08:15, Adam Roach wrote:
> There is no reason to tie authors' hands by restricting them from 
> using perfectly good English words just because they happen to be the 
> same symbols used by RFC 2119. If we're going down this path, let's 
> scrap using MUST/SHOULD/MAY/etc, and formalize our conformance terms 
> with symbols that aren't English words.



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

Re: 2119bis -- Tying our hands?

[Dean Willis]

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, explain things in clear prose, describing what happens in 
normal and error cases, and the logic used in distinguishing them.


If you absolutely require RFC 2119 requirements language to make 
something clear, I suggest the following symbology:



✔: MUST
☂: SHOULD
♥: MAY
✖: MUST NOT
♠: SHOULD NOT
☹: MAY NOT

And the fact that the above is garbled for some large percentage of 
readers explains why we use 7-bit ASCII in drafts, so let's just stop 
that argument now, ok?


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

Re: 2119bis

[Richard Barnes]

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
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 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 particular item, but the
full implications must be understood and carefully weighed before choosing a
different course."), the problem is that some implementers use a different
meaning (I do not have to implement this if it is inconvenient or difficult for
me to implement), vendors another one (SHOULD gave us the right to not implement
it).  I even read somewhere, perhaps on this list, about a vendor that rejected
any bug report against a SHOULD.  Conditional MUST, in my opinion, does not have
this problem.


But conditional MUST has other problems, namely that you have to enumerate the 
exceptions for the MUST, and that's not always practical.

Implementors who think that SHOULD gives them a free pass to avoid implementing 
something that's needed to interoperate are misreading 2119.  But document 
editors should avoid using SHOULD for cases where failure to implement the 
requirement will result in interoperability failure.

I could see maybe posting an erratum or a brief update to 2119, but I think 
that reopening that document in general is a Very bad Idea.  And for existing 
documents that misuse SHOULD, the appropriate thing to do is to update those 
documents or post errata to those documents, rather than try to retroactively 
change the meaning of the keywords in those documents.

Keith

___
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: 2119bis

[Barry Leiba]

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 about what those words mean.
Notwithstanding that, these words, in this context, are technical
terms, not English words.  One can't look them up in a dictionary, nor
use one's own sense, as a speaker of English, to determine what they
mean.  One must only use what RFC 2119 says.

It says this:

   3. SHOULD This word, or the adjective "RECOMMENDED", mean
   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 choosing a different course.

That's not the same as many people's understanding of the English
meaning of the words "should" and "recommended", which are similar in
appearance to the technical terms defined in RFC 2119.

Of course, then we run into interpretations of the definitions of the
terms, and exactly what that sentence in item 3 in RFC 2119 *means*,
but I'm not getting into that here.  This may be where you, I, Peter,
and/or the AD in question differ.

But don't make the mistake of thinking that, in the context of RFC
2119, one can use one's own English sense of what the meanings of
these terms are.

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

Re: 2119bis

[Brian E Carpenter]

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 and has been given due consideration at the time of 
>>> writing. That, however, will not always be the case. (More inline).
> 
>> How would SHOULD...UNLESS or MUST...UNLESS differ from using the current 
>> 2119 definitions and just writing SHOULD...unless or MUST ... unless?
> 
>> Personally I think 2119 is just fine and doesn't need to be updated.
> 
> +1. I'm still not seeing sufficient justification to open this particular can
> of worms at this juncture.

+ another 1.

Brian

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

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

[Brian E Carpenter]

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 we have some experience.

   Brian

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

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

[Brian E Carpenter]

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 time*, or explain why the update is insufficient. This happens, 
probably
as often as authors failing to address an issue within a reasonable time. 
Whichever
party is responsible for the delay should be subject to a timeout, surely.

That said, I disagree with Keith. The current DISCUSS criteria were written
for a very specific reason - to get rid of the type of DISCUSS listed in the
"non-criteria". There was a lot of analysis done of documents that were stuck
in the IESG for months in the 2004/2005 timeframe, and the non-criteria describe
the problem cases - DISCUSSes that were not actionable or simply expressed the
fact that the AD didn't like the WG's informed consensus.

Of course nothing's perfect and I'm sure the criteria could be improved. But
not having them was much worse.

* for example, is "IESG Evaluation::AD Followup (for 32 days)" a reasonable
  delay for a Discussing AD to review an updated draft [hint, hint]?

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

Re: 2119bis

[ned+ietf]

> 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. That, however, will not always be the case. (More inline).

> How would SHOULD...UNLESS or MUST...UNLESS differ from using the current 2119 
> definitions and just writing SHOULD...unless or MUST ... unless?

> Personally I think 2119 is just fine and doesn't need to be updated.

+1. I'm still not seeing sufficient justification to open this particular can
of worms at this juncture.

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

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

[Keith Moore]

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 resolution of a DISCUSS might end up being 
>> a yes vote, a no objection vote, a request for clarification of the 
>> document.  It should also be possible for an AD to say "now that I've 
>> understood better, I can't support this going forward"   (for which ABSTAIN 
>> is not an appropriate label).
>> 
>> It should never be wrong for an AD to vote DISCUSS, though it's reasonable 
>> to limit the amount of time during which a DISCUSS can stand for a 
>> particular document.
>> 
>> It should also never be wrong for an AD to vote NO if the AD has initially 
>> voted DISCUSS, made a sincere effort to understand the issues, believes that 
>> he does so, and can state 2026 or other documented criteria for why the 
>> document is not suitable for approval.
> 
> I agree in part. My problem is that even some ADs tell me that ADs sometimes 
> behave as if they haven't done their job if they haven't produced a 
> "discuss". A few months ago, I got a "discuss" on a document that in essence 
> said "what should I be writing a 'discuss' about?". I have no problem with 
> valid concerns, and many of the concerns raised are valid. It should be 
> possible for a working group to produce a quality document and have the IESG 
> simply approve it, however. I'm not sure it is.

The first time I reviewed a document as an AD, I realized I was working very 
hard to find something wrong.  And I did - I found a bona fide (and 
uncontroversial) technical flaw - actually an incorrect value for a constant.  
But after that I got over needing to find things that were wrong.   I found 
plenty of issues without trying to do anything more than read and understand 
the documents - and had quite enough work to do just reading and understanding 
them and writing up those issues without making more work for myself.  
(Especially when other ADs would often demand that I not only identify the 
issues but also specify the fixes - something I always regarded as out-of-scope 
for an AD and even potentially "tampering" with WG output.)

So I don't disagree that ADs sometime believe that they need to vote Discuss or 
they're not doing their jobs.  Though I have a hard time believing that the 
drafts coming out of WGs these days are so good that ADs have to work hard to 
find things that are wrong with many of them.   If they're trying to find a 
reason to Discuss every document, well I guess that is a problem.   But 
overall, it seems like there are far more incentives to avoid finding reasons 
to object to a document, than there are to find them.

>> Discuss votes should time out and be replaced by Abstain (if not explicitly 
>> changed by the AD) after say 45 days.  
> 
> There I disagree. 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.

I don't think I stated that rule very well.   If the author/wg fail to address 
the issue within 45 days, the AD should of course be able to change the vote to 
No.  The point is that the Discuss should inherently be a temporary state, a 
time during which the AD doesn't vote No (yet) but lets the author/WG know that 
he has issues with a document.  And the idea is to encourage those parties 
enough time to understand each other and work out their differences before 
bringing the issue to a firm vote.  But I don't think that the WG should be 
able to game the rule to force the AD's objection to go away, nor should the AD 
be able to singlehandedly block a document.

> Personally, I would rather see the document returned to the author/wg if 
> review results in a request for major changes. In my working group, we 
> recently had one draft completely rewritten in the response to "discuss"es, 
> and I pulled it back for the WG to decide whether it still had consensus 
> around the resulting draft. I would say the same about a "discuss" that is 
> not adequately responded to in 45 days; the IESG should clean it off their 
> plate.

IMO, any time a document is significantly revised, IESG should consider it a 
separate item, requiring a new Last Call, writeup, ballot, etc.

>> 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 of DS/IS is in fact a 
> raising of the bar,and one that has served us well. We don't (although IMHO 
> we should) require even an implementation to go to PS.

I should have been more specific.  By "raising the bar" I was thinking about 
things like design decisions, and document quality.   If feature FOO was judged 
to be

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

[Fred Baker]

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 no objection vote, a request for clarification of the document.  
> It should also be possible for an AD to say "now that I've understood better, 
> I can't support this going forward"   (for which ABSTAIN is not an 
> appropriate label).
> 
> It should never be wrong for an AD to vote DISCUSS, though it's reasonable to 
> limit the amount of time during which a DISCUSS can stand for a particular 
> document.
> 
> It should also never be wrong for an AD to vote NO if the AD has initially 
> voted DISCUSS, made a sincere effort to understand the issues, believes that 
> he does so, and can state 2026 or other documented criteria for why the 
> document is not suitable for approval.

I agree in part. My problem is that even some ADs tell me that ADs sometimes 
behave as if they haven't done their job if they haven't produced a "discuss". 
A few months ago, I got a "discuss" on a document that in essence said "what 
should I be writing a 'discuss' about?". I have no problem with valid concerns, 
and many of the concerns raised are valid. It should be possible for a working 
group to produce a quality document and have the IESG simply approve it, 
however. I'm not sure it is.

> Discuss votes should time out and be replaced by Abstain (if not explicitly 
> changed by the AD) after say 45 days.  

There I disagree. 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.

Personally, I would rather see the document returned to the author/wg if review 
results in a request for major changes. In my working group, we recently had 
one draft completely rewritten in the response to "discuss"es, and I pulled it 
back for the WG to decide whether it still had consensus around the resulting 
draft. I would say the same about a "discuss" that is not adequately responded 
to in 45 days; the IESG should clean it off their plate.

> 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 of DS/IS is in fact a 
raising of the bar,and one that has served us well. We don't (although IMHO we 
should) require even an implementation to go to PS. 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Hyatt Taipei cancellation policy?

[Ole Jacobsen]

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 agree about the Hyatt hotel price.

Ole


Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: o...@cisco.com  URL: http://www.cisco.com/ipj
Skype: organdemo


On Tue, 30 Aug 2011, Dean Willis wrote:

> 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
> > sponsorship (and hence lower costs to the IETF for meeting
> > infrastructure and arrangements) and meetings costs to attendees
> > are made... open enough that the community could give
> > substantive guidance on the subject, guidance that I assume the
> > IAOC would follow if it were coherent and plausible.
> >
> 
> Quite right. There's more than just the hotel rates.
> 
> My budget is about $2500 US per IETF meeting. That has to cover airfare, the
> IETF meeting fee, the hotel, meals, service charges, ground transport, mobile
> phone roaming, incidentals, etc.
> 
> $300 a night counting taxes and surcharge is just ABSOLUTELY OUT OF THE
> FREAKING QUESTION. Having the "backup" hotel a 10 minute taxi ride away is out
> of the question -- I can't afford taxis. If I can't walk, I can't go.
> 
> So guess what? I told the wife last night that I wasn't planning to go to the
> Taiwan meeting. I wanted to go, but I just don't see how it can happen. Maybe
> I'll win the lottery between now and then...
> 
> I'm disappointed. I'm hurt. I'm angry. And the trend has just been getting
> worse and worse with every venue. I want the IAOC's heads on a platter
> (preferably an inexpensive, disposable platter, like maybe the lid off an old
> pizza box) for signing us up to this venue. And I want a travel budget no
> larger than mine for the people we send to future meetings.
> 
> If we can't find a reasonably inexpensive place to have a meeting, DON'T HAVE
> THE MEETING!
> 
> 
> --
> Dean Willis
> ___
> 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: Discuss criteria for documents that advance on the standards track

[Keith Moore]

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 DISCUSS might end up being a yes vote, a 
no objection vote, a request for clarification of the document.  It should also 
be possible for an AD to say "now that I've understood better, I can't support 
this going forward"   (for which ABSTAIN is not an appropriate label).

It should never be wrong for an AD to vote DISCUSS, though it's reasonable to 
limit the amount of time during which a DISCUSS can stand for a particular 
document.

It should also never be wrong for an AD to vote NO if the AD has initially 
voted DISCUSS, made a sincere effort to understand the issues, believes that he 
does so, and can state 2026 or other documented criteria for why the document 
is not suitable for approval.

So my recommendations are: 

1. Fix the broken IESG voting system before you try to establish more decision 
criteria.  I'm serious.  The system you have now is just too broken, and has 
been broken for a long time.  It places too much pressure on ADs to cave in 
when a WG produces flawed output that isn't easily fixed.  It is weighed too 
heavily in favor of approving a document - such that one AD can vote YES, 
another vote DISCUSS, no other ADs read the document and all vote NO OBJECTION, 
and the AD that votes DISCUSS will be expected to change that vote to ABSTAIN 
because nobody else felt like reading it.   And the idea that an AD should 
ever, ever, be compelled to change his vote to an ABSTAIN is completely 
unacceptable.  And the "votes" of ADs who haven't read the document should not 
count AT ALL.

Here is a stab at better voting criteria:

- The possible votes are: Yes, No, No Objection, Discuss, Abstain, Recuse
- Yes means "I've read it, I believe it meets applicable criteria (2026 or 
whatever else is applicable), that there's community-wide consensus to support 
the document, and that all issues raised by reviewers (including directorate, 
last call comments, etc.) have been adequately addressed."
- No means "I've read it, but one or more of the above criteria have failed to 
have been met."  The criteria must be documented.
- No Objection means "I've read it, and I think there are issues with it, but I 
don't think those issues are sufficient to block the document".   The criteria 
should be documented, but the AD isn't compelled to do so.
- Discuss means "I have read the document and see at least one potential issue 
which needs to be discussed."  Discuss should always be raised before voting 
No.  However, Discuss votes should time out and be replaced by Abstain (if not 
explicitly changed by the AD) after say 45 days.  (however, nothing should ever 
stop an AD from changing his vote to No.)  Note that the ADs, WG chairs, 
authors, etc. should attempt to resolve the issue offline (not during the 
telechat or other IESG meeting) but the discussion should be archived.
- Abstain means "I did not read this", and/or "I don't consider myself 
competent to review this"
- Recuse means "I have a conflict of interest with stating a position on this 
document"

All Discuss votes must be changed (whether explicitly by the AD or by automatic 
timeout) before a ballot is finished.
If there are two or more No votes, all ADs without a conflict of interest are 
expected to read the document, and the vote is taken again.
In order to approve a document or standards action, there must be twice as many 
Yes + No Objection votes as No votes.

2. Don't overconstrain the use of DISCUSS.  In particular, don't ever create a 
situation where a reviewer can't cite a problem with a document, regardless of 
whether that problem has previously been enumerated.It's fine to have 
guidelines for the benefit of new ADs but they should be nonbinding.  You need 
to have other ways of dealing with the occasional stubborn AD who votes DISCUSS 
or whatever without a defensible reason.

This applies to all IESG voting actions, not just moving from PS->DS/IS.

3. I take serious issue with the statement in the draft that IESG reviews are 
"reviews of last resort" and the implication that WG reviews are sufficient.  
In numerous situations this has not been the case.  I'm all for having IESG 
place greater reliance on directorates (especially if this is formalized to 
some degree), so as to lessen IESG's workload to to get individual ADs out of 
the hot seat.   But for IESG to presume by default that the WG has done due 
diligence is for IESG to shirk its responsibility.

4. When evaluating PS->DS/IS actions, IESG should avoid repeating the PS 
review.  Instead it should look at what has changed between PS and DS/IS, and 
what has been learned as a result of implementation and deployment experience.  
 The changes have to be minimal and "safe".  

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

[Stewart Bryant]

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 this understanding correct?



Yes


I also think that one of the items in the discussion was the 
restriction on ECMP in MPLS to skip reserved labels. I am not sure if 
it has been properly addressed anywhere, so should not it constitute 
item #4?


Yes-ish, here I am concerned about the practical ability to do that 
given the extent of deployed LSRs that do not do that.


My point here was to note the scope of this draft (which is is IESG review).

Other drafts need to make their own case for what they want to do and 
how they propose to do it.


Stewart



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

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

[Alexander Vainshtein]

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 in the discussion was the restriction on 
ECMP in MPLS to skip reserved labels. I am not sure if it has been properly 
addressed anywhere, so should not it constitute item #4?

Regards,
 Sasha

From: Stewart Bryant [mailto:stbry...@cisco.com]
Sent: Tuesday, August 30, 2011 3:05 PM
To: Luca Martini; IETF Discussion
Cc: John E Drake; m...@ietf.org; Alexander Vainshtein; ietf@ietf.org; Vladimir 
Kleiner; Idan Kaspit; Mishael Wexler; pwe3; Oren Gal; John Shirron; Rotem 
Cohen; pwe3-cha...@tools.ietf.org; i...@ietf.org
Subject: 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 resolved in any PWE3 draft that describes
the use of the GAL.

To that end the text in draft-ietf-pwe3-mpls-tp-gal-in-pw-01



 -  Section 
4.2.
 (GAL Applicability and Usage) in 
[RFC5586], the

  original text:



  In MPLS-TP, the GAL MUST be used with packets on a G-ACh on

  LSPs, Concatenated Segments of LSPs, and with Sections, and

  MUST NOT be used with PWs. It MUST always be at the bottom of

  the label stack (i.e., S bit set to 1). However, in other MPLS

  environments, this document places no restrictions on where

  the GAL may appear within the label stack or its use with PWs.



  is replaced by:



  In MPLS-TP, the GAL MUST be used with packets on a G-ACh on

  LSPs, Concatenated Segments of LSPs, and with Sections, and

  MAY be used with PWs. It MUST always be at the bottom of the

  label stack (i.e., S bit set to 1). However, in other MPLS

  environments, this document places no restrictions on where

  the GAL may appear within the label stack.
=

should be replaced by

=

 -  Section 
4.2.
 (GAL Applicability and Usage) in 
[RFC5586], the

  original text:



  In MPLS-TP, the GAL MUST be used with packets on a G-ACh on

  LSPs, Concatenated Segments of LSPs, and with Sections, and

  MUST NOT be used with PWs. It MUST always be at the bottom of

  the label stack (i.e., S bit set to 1). However, in other MPLS

  environments, this document places no restrictions on where

  the GAL may appear within the label stack or its use with PWs.



  is replaced by:



  In MPLS-TP, the GAL MUST be used with packets on a G-ACh on

  LSPs, Concatenated Segments of LSPs, and with Sections, and

  MAY be used with PWs. The presence of a GAL indicates that

  an ACH immediately follows the MPLS label stack.
==

- Stewart


This e-mail message is intended for the recipient only and contains information 
which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have 
received this transmission in error, please inform us by e-mail, phone or fax, 
and then delete the original and all copies thereof.

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

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

[Stewart Bryant]

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 resolved in any PWE3 draft that describes
the use of the GAL.

To that end the text in draft-ietf-pwe3-mpls-tp-gal-in-pw-01


 -Section 4.2  
. (GAL 
Applicability and Usage) in [RFC5586  ], the
  original text:

  In MPLS-TP, the GAL MUST be used with packets on a G-ACh on
  LSPs, Concatenated Segments of LSPs, and with Sections, and
  MUST NOT be used with PWs. It MUST always be at the bottom of
  the label stack (i.e., S bit set to 1). However, in other MPLS
  environments, this document places no restrictions on where
  the GAL may appear within the label stack or its use with PWs.

  is replaced by:

  In MPLS-TP, the GAL MUST be used with packets on a G-ACh on
  LSPs, Concatenated Segments of LSPs, and with Sections, and
  MAY be used with PWs. It MUST always be at the bottom of the
  label stack (i.e., S bit set to 1). However, in other MPLS
  environments, this document places no restrictions on where
  the GAL may appear within the label stack.

=

should be replaced by

=

 -Section 4.2  
. (GAL 
Applicability and Usage) in [RFC5586  ], the
  original text:

  In MPLS-TP, the GAL MUST be used with packets on a G-ACh on
  LSPs, Concatenated Segments of LSPs, and with Sections, and
  MUST NOT be used with PWs. It MUST always be at the bottom of
  the label stack (i.e., S bit set to 1). However, in other MPLS
  environments, this document places no restrictions on where
  the GAL may appear within the label stack or its use with PWs.

  is replaced by:

  In MPLS-TP, the GAL MUST be used with packets on a G-ACh on
  LSPs, Concatenated Segments of LSPs, and with Sections, and
  MAY be used with PWs. The presence of a GAL indicates that
  an ACH immediately follows the MPLS label stack.

==

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

Re: 2119bis

[Hector Santos]

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 software which does not implement a SHOULD 
is broken already.  In fact, his interpretation is ironically very 
close to what you have for SHOULD in this I-D.  So I wonder if this 
I-D SHOULD text is the same AD view and a result of what happen in the 
WG.  This is not a disrespect of AD, but I vocalized my exception to 
the AD description when:


   A) There was no RFC2119 material text or copy that even came close
  to AD interpretation, and

   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 text is very vague and the original RFC2119 is simpler to 
understand and IMO, closer to practical realities faced for 
implementators.


Of course, none of this is cut and dry and I understand the intent of 
the text is to encourage implementators to update their software, 
especially for enhanced protocol and/or new integrated ideas where one 
protocol requires the help of another protocol, a situation where 
ideally one would like something to be written as a MUST but for 
legacy reasons a fallback is available, thus written as a SHOULD.  The 
dilemma begin that unless it is more described with some level of 
obligation, people don't upgrade as fast or as wide as one would like.


My concerns are when a protocol SHOULD is read as an obligation, then 
two things can and has happen:


   - Any software that is not currently supportive of a SHOULD or 
even aware
 of it, is instantly classified as broken software. This was one 
of the
 concerns  in the WG when the AD issued the same description as 
you have

 here.  When the feature was not already support and especially not
 required, or worst viewed as a temporary short term solution, a 
SHOULD

 defined as an Obligation is not going to go smoothly by all
 responsible implementators.

   - A feature that was a highly controversial decision and was added as
 a SHOULD with a rough consensus with lack compromise, an obligation
 interpretation will cause implementators to not follow it nor 
support
 something else that requires an additional SHOULD. It could even 
be a
 cost reason, an expensive design change that is require to 
accommodate

 a SHOULD not believed to be worth the effort.

I think rephrasing is necessary.  I think what is important, no matter 
which way the text wants it convey SHOULD as an important obligated 
feature to support, no protocol error can occur due to lack of support 
on either end or disabled by operators.


So if anything, I believe removing the final sentence would be more 
correct because its no longer a recommendation but an obligation. 
This is not a suggestion, but to highlight it it can probably be said 
in two sentences to convey the point:


 A SHOULD is a MUST with a fallback. Implementators are not
 considered NON-COMPLIANT if a SHOULD is not implemented as long
 as the fallback is already possible.

Thanks

Peter Saint-Andre wrote:

After 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. I hope that I've been able to update and clarify the
text in a way that is respectful of the original. Feedback is welcome.

http://www.ietf.org/id/draft-saintandre-2119bis-01.txt

Peter



--
Sincerely

Hector Santos
http://www.santronics.com

I addition, even if it was added by a piece of software, it does not
mean the operator MUST enabled it or that the software prevent him 
from turning it off.  I venture most implementations will not provide 
an MUST turn off switch but will provide a SHOULD turn off switch.


I also stated more importantly that even if it was a mandate for a 
server, since it must be ready for clients that do not support it and 
there is no operational repercussions for its lack of usage, thus by 
this consideration, there is no mandate or obligation by either side 
to support it.  In my view, if one end expects a feature, then its a 
MUST.  But if its able to fall back, then its a SHOULD.




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

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

[Henry B. Hotz]

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 think this actually requires a complete registry.  A single 
undefined/external entry for the existing PSKC registry would be sufficient, 
wouldn't it?

On Aug 29, 2011, at 7:03 AM, Sam Hartman wrote:

> What information required by the PSC registry do we not need?
> The only thing I see is the XML information, but it looks like that
> could be blank.

--
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
henry.b.h...@jpl.nasa.gov, or hbh...@oxy.edu



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

Discuss criteria for documents that advance on the standards track

[Jari Arkko]

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 to publish an 
IESG statement to complement the already existing general-purpose DISCUSS 
criteria IESG statement 
(http://www.ietf.org/iesg/statement/discuss-criteria.html).

Here are the suggested guidelines for documents that advance to IS:

http://www.arkko.com/ietf/iesg/discuss-criteria-advancing.txt

Comments appreciated. Please send comments either on this list or to the IESG 
(i...@ietf.org) in time before our next telechat (Thursday, September 8, 2011).

Jari

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

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

[Jari Arkko]

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 believe 
there was either harm or benefit. 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. I will be recommending that the IESG approve 
the draft.

There were a number of smaller details raised in the discussion. But I did not 
see an overwhelming consensus on any specific issue to make changes. But I will 
ask Russ to take a look at the issue raised by Scott, whether he wants to add 
an informative reference to RFC 5657.

Another issue that I wanted to highlight is the question of what kinds of discusses are 
desirable/acceptable for documents that move from PS to IS. It is outside the scope of 
Russ' document, but generated nevertheless some interest. The IESG has discussed this 
matter and drafted some suggested guidelines. Look for a different thread on this list, 
under "Discuss criteria for documents that advance on the standards track". 
Feedback on the guidelines would be appreciated.

Jari

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

Re: Hyatt Taipei cancellation policy?

[Dean Willis]

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
sponsorship (and hence lower costs to the IETF for meeting
infrastructure and arrangements) and meetings costs to attendees
are made... open enough that the community could give
substantive guidance on the subject, guidance that I assume the
IAOC would follow if it were coherent and plausible.



Quite right. There's more than just the hotel rates.

My budget is about $2500 US per IETF meeting. That has to cover airfare, 
the IETF meeting fee, the hotel, meals, service charges, ground 
transport, mobile phone roaming, incidentals, etc.


$300 a night counting taxes and surcharge is just ABSOLUTELY OUT OF THE 
FREAKING QUESTION. Having the "backup" hotel a 10 minute taxi ride away 
is out of the question -- I can't afford taxis. If I can't walk, I can't go.


So guess what? I told the wife last night that I wasn't planning to go 
to the Taiwan meeting. I wanted to go, but I just don't see how it can 
happen. Maybe I'll win the lottery between now and then...


I'm disappointed. I'm hurt. I'm angry. And the trend has just been 
getting worse and worse with every venue. I want the IAOC's heads on a 
platter (preferably an inexpensive, disposable platter, like maybe the 
lid off an old pizza box) for signing us up to this venue. And I want a 
travel budget no larger than mine for the people we send to future meetings.


If we can't find a reasonably inexpensive place to have a meeting, DON'T 
HAVE THE MEETING!



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

Re: 2119bis

[Marc Petit-Huguenin]

-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 misused
>> on occasion is an extreme over-reaction. I like this tool. I use this tool. 
>> If
>> you see people misusing it, slap them.
>>
>> But don't ban the tool.
> 
> +1
> 

I am wondering if having an Implementers Directorate, tasked to do reviews from
an implementation point of view, could not help discovering when a SHOULD can
create interoperability problems.  I would certainly volunteer in such group.


- -- 
Marc Petit-Huguenin
Personal email: m...@petit-huguenin.org
Professional email: petit...@acm.org
Blog: http://blog.marc.petit-huguenin.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk5dQT4ACgkQ9RoMZyVa61eU3gCglqmaf07bpE1RJU9oN3YotGgS
T+oAoKeRCXuB2Ea+Bzy+nw+A7er0kURv
=bHul
-END PGP SIGNATURE-
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

[Keith Moore]

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 see people misusing it, slap them.
> 
> But don't ban the tool.

+1

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

Re: 2119bis

[Adam Roach]

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 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 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 turn the statement into the if Y then MUST X or if Z then MUST NOT X 
form.  Being pedantic and pedagogic:
SHOULD send a 1 UNLESS you receive a 0
really means
UNLESS you receive a 0, one MUST send a 1.

My vision of the UNLESS clause is not necessarily a protocol state, but an 
environment state.  These are things that I can see fit the SHOULD/UNLESS form:
SHOULD send a 1 UNLESS you are in a walled garden
SHOULD flip bit 27 UNLESS you have a disk
SHOULD NOT explode UNLESS you are a bomb
are all reasonable SHOULD-level statements.

I would offer that ANY construction of SHOULD without an UNLESS is a MAY.


Eric. Put down the axe and step away from the whetstone. Here, I'll give you 
some text from RFC 3265 to mull.


   deactivated: The subscription has been terminated, but the subscriber
  SHOULD retry immediately with a new subscription.  One primary use
  of such a status code is to allow migration of subscriptions
  between nodes.


Let's examine this use of "SHOULD." If the subscriber doesn't re-subscribe, is 
it an interop issue? No.

Is it in the interest of the implementation to re-subscribe? Yes. At least, 
under most circumstances. Otherwise, they won't get the state change 
notifications they want.

Are there cases in which it makes sense for the subscriber _not_ to 
re-subscribe? Yes, I'm sure there are. It's conceivable that the client happens 
to be shutting down but hasn't gotten around to terminating this particular 
subscription yet. But any such exceptions are highly implementation-dependent. 
Listing them would be useless noise to the reader, and senseless text creation 
for the author.

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 see people 
misusing it, slap them.

But don't ban the tool.

/a


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

RE: Limitations in RFC Errata mechanism

[Murray S. Kucherawy]

> -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 Editorial.  In 
> presence of
> , "IESG
> Statement on IESG Processing of RFC Errata concerning RFC Metadata", I
> think the third type is necessary - Metadata.

I think given the current mechanism I would just submit such things under 
"Editorial".

> Second, the "Section" field at
>  implies that only
> numerical sections will contain something an erratum can be reported
> against (overlooking the GLOBAL option).  However, Appendices, Abstract,
> Index, Author Info, different Notes exist, that aren't covered here.

I was able to type "Appendix A" just now into that section without difficulty.  
The preview page shows "Section Appendix A says:", but that hardly seems a 
difficulty.

> Third, Original text and Corrected text fields imply that only
> before-and-after errata may be submitted.  However, there might be
> errata like Erratum # 6
> (http://www.rfc-editor.org/errata_search.php?eid=6), with an only Report
> text field.  I understand this feature was present in previous versions
> of errata mechanism but removed from the current.

I don't understand the problem here.  That report seems pretty clear to me.

> Also, several issues not related to submission mechanism.
> 
> 1) Specific mailing lists devoted to discussion of errata against RFCs
> from different areas.  I've proposed this on rfc-interest list; see rationale 
> at
>  August/002672.html>.;

Typically a working group discusses an erratum when it is raised, and then it 
sits in limbo until a document update occurs.  Isn't the right place for 
discussion about a particular one the mailing list of that working group or, if 
it's disbanded, the main IETF list?

> 3) Verified technical errata may be incorporated in the references. Eg.
> 4 technical errata were reported against RFC 793 and verified; so the
> reference may be:
> 
> Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
> September 1981.  Ammended by RFC Errata Reports 573, 1562, 1564, 1572.

I don't think verified errata have any force or effect until the document is 
actually updated, so this really just becomes clutter in the references.  
Moreover, if I'm implementing some RFC that references another which itself has 
errata, I will want to know about all of them, not the ones that were present 
and verified at the time of publication.

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

Re: 2119bis

[hector]

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 SHOULD by order of importance and also complexity. 
 How much "CANDY" is it?  It is a security feature?  What are the 
other implementation requirements, tools, APIs, etc.  Generally I want 
to get security out the way.  Its like SMTP AUTH - its not required 
but anyone cleaning up and rewriting an SMTP spec today, might include 
the AUTH extension as a SHOULD. And implementators are keen to the 
importance of it.  But nothing won't break down if you don't, less 
functionality but the basic structure is still there.


Its the same approach used for all the protocols we support. Start 
with the basics and then add on  as necessary.


Eric Burger wrote:

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 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 turn the statement into the if Y then MUST X or if Z then MUST NOT X 
form.  Being pedantic and pedagogic:
SHOULD send a 1 UNLESS you receive a 0
really means
UNLESS you receive a 0, one MUST send a 1.

My vision of the UNLESS clause is not necessarily a protocol state, but an 
environment state.  These are things that I can see fit the SHOULD/UNLESS form:
SHOULD send a 1 UNLESS you are in a walled garden
SHOULD flip bit 27 UNLESS you have a disk
SHOULD NOT explode UNLESS you are a bomb
are all reasonable SHOULD-level statements.

I would offer that ANY construction of SHOULD without an UNLESS is a MAY.


Eric. Put down the axe and step away from the whetstone. Here, I'll give you 
some text from RFC 3265 to mull.


  deactivated: The subscription has been terminated, but the subscriber
 SHOULD retry immediately with a new subscription.  One primary use
 of such a status code is to allow migration of subscriptions
 between nodes.


Let's examine this use of "SHOULD." If the subscriber doesn't re-subscribe, is 
it an interop issue? No.

Is it in the interest of the implementation to re-subscribe? Yes. At least, 
under most circumstances. Otherwise, they won't get the state change 
notifications they want.

Are there cases in which it makes sense for the subscriber _not_ to 
re-subscribe? Yes, I'm sure there are. It's conceivable that the client happens 
to be shutting down but hasn't gotten around to terminating this particular 
subscription yet. But any such exceptions are highly implementation-dependent. 
Listing them would be useless noise to the reader, and senseless text creation 
for the author.

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 see people 
misusing it, slap them.

But don't ban the tool.

/a





___
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: 2119bis -- Tying our hands?

[Adam Roach]

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 mandating that requirements ought to be shouted.  Lowercase 
"must" can be as effective as uppercase as long as it is consistently applied.



You paint that as tongue-in-cheek, but Peter's draft does go down the 
rat-hole of picking out a color scheme for this particular bike shed, 
when doing so is really unwarranted. In addition to the SHOULD & co 
brouhaha, I have serious heartburn over this passage:


   When it is not appropriate to use the conformance terms, authors can
   use a variety of alternative words and phrases, such as: "need to" or
   "mandatory" instead of "MUST"; "ought to" or "strongly encouraged"
   instead of "SHOULD"; and "might" or "discretionary" instead of "MAY".
   To prevent confusion, authors ought to use these alternative words
   and phrases instead of the lowercase versions of the conformance
   terms, and to use the conformance terms only in their uppercase
   versions.



There is no reason to tie authors' hands by restricting them from using 
perfectly good English words just because they happen to be the same 
symbols used by RFC 2119. If we're going down this path, let's scrap 
using MUST/SHOULD/MAY/etc, and formalize our conformance terms with 
symbols that aren't English words.


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.


/a

[1] http://en.wikipedia.org/wiki/Taboo_%28game%29
[2] According to Project Gutenberg, "must" and "may" are among the 100 
words most frequently used in written literature. See 
http://en.wiktionary.org/wiki/Wiktionary:Frequency_lists#Project_Gutenberg
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

[Eric Burger]

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 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 turn the statement into the if Y then MUST X or if Z then 
>> MUST NOT X form.  Being pedantic and pedagogic:
>>  SHOULD send a 1 UNLESS you receive a 0
>> really means
>>  UNLESS you receive a 0, one MUST send a 1.
>> 
>> My vision of the UNLESS clause is not necessarily a protocol state, but an 
>> environment state.  These are things that I can see fit the SHOULD/UNLESS 
>> form:
>>  SHOULD send a 1 UNLESS you are in a walled garden
>>  SHOULD flip bit 27 UNLESS you have a disk
>>  SHOULD NOT explode UNLESS you are a bomb
>> are all reasonable SHOULD-level statements.
>> 
>> I would offer that ANY construction of SHOULD without an UNLESS is a MAY.
> 
> 
> Eric. Put down the axe and step away from the whetstone. Here, I'll give you 
> some text from RFC 3265 to mull.
> 
> 
>   deactivated: The subscription has been terminated, but the subscriber
>  SHOULD retry immediately with a new subscription.  One primary use
>  of such a status code is to allow migration of subscriptions
>  between nodes.
> 
> 
> Let's examine this use of "SHOULD." If the subscriber doesn't re-subscribe, 
> is it an interop issue? No.
> 
> Is it in the interest of the implementation to re-subscribe? Yes. At least, 
> under most circumstances. Otherwise, they won't get the state change 
> notifications they want.
> 
> Are there cases in which it makes sense for the subscriber _not_ to 
> re-subscribe? Yes, I'm sure there are. It's conceivable that the client 
> happens to be shutting down but hasn't gotten around to terminating this 
> particular subscription yet. But any such exceptions are highly 
> implementation-dependent. Listing them would be useless noise to the reader, 
> and senseless text creation for the author.
> 
> 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 see people misusing it, slap them.
> 
> But don't ban the tool.
> 
> /a



smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

[Adam Roach]

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 turn the statement into the if Y then MUST X or if Z then MUST NOT X 
form.  Being pedantic and pedagogic:
SHOULD send a 1 UNLESS you receive a 0
really means
UNLESS you receive a 0, one MUST send a 1.

My vision of the UNLESS clause is not necessarily a protocol state, but an 
environment state.  These are things that I can see fit the SHOULD/UNLESS form:
SHOULD send a 1 UNLESS you are in a walled garden
SHOULD flip bit 27 UNLESS you have a disk
SHOULD NOT explode UNLESS you are a bomb
are all reasonable SHOULD-level statements.

I would offer that ANY construction of SHOULD without an UNLESS is a MAY.



Eric. Put down the axe and step away from the whetstone. Here, I'll give 
you some text from RFC 3265 to mull.



   deactivated: The subscription has been terminated, but the subscriber
  SHOULD retry immediately with a new subscription.  One primary use
  of such a status code is to allow migration of subscriptions
  between nodes.


Let's examine this use of "SHOULD." If the subscriber doesn't 
re-subscribe, is it an interop issue? No.


Is it in the interest of the implementation to re-subscribe? Yes. At 
least, under most circumstances. Otherwise, they won't get the state 
change notifications they want.


Are there cases in which it makes sense for the subscriber _not_ to 
re-subscribe? Yes, I'm sure there are. It's conceivable that the client 
happens to be shutting down but hasn't gotten around to terminating this 
particular subscription yet. But any such exceptions are highly 
implementation-dependent. Listing them would be useless noise to the 
reader, and senseless text creation for the author.


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 see people misusing it, slap them.


But don't ban the tool.

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

Re: 2119bis

[hector]

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 implementators really don't have "valid" reasons to
ignore it.

IMV, the problem here is that we can't generalized how protocol
recommendations are implemented across the board equally and its not
correct to be begin using this as a mandate for forcing deployment of
what may be deemed unnecessary, controversial and automatically begin
classifying existing minimum requirements implementators as
non-compliant.


Murray S. Kucherawy wrote:

-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
has always meant "MUST unless you really know what you're doing"

Such an odd reading.  Does it mean you MUST because you could not
handle it otherwise?


I'm sorry if you think it's odd, but it's correct.  Read RFC2119 again:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean 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 choosing a different course.
___
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: Limitations in RFC Errata mechanism

[Wesley Eddy]

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
, "IESG
Statement on IESG Processing of RFC Errata concerning RFC Metadata", I
think the third type is necessary - Metadata.




I agree with this part of the proposal, at least.


--
Wes Eddy
MTI Systems
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

[Eric Burger]

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 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 will have deployments 
>> *THAT ARE NOT FOR THE INTERNET* but I want to market them as if they were.
>> Example: instant messaging systems for enterprises where tapping is a legal 
>> requirement, not something to be avoided.
>> Example: instant messaging systems deployed where governments want to do 
>> warrantless, undetectable tapping
>> 
>> I would offer neither of these examples are Internet examples, and we should 
>> get some iron underpants on and say so.
> 
> Mumble.  I fundamentally don't buy the argument that things that are used on 
> both local networks and the Internet should not be subject to 
> Internet-strength security.   
> 
> And even where recording is a legal requirement, that's NOT an argument for 
> sending traffic in cleartext or with weak encryption.  That might be an 
> argument for some kind of backdoor - e.g. a trusted proxy or key escrow or 
> whatever, but it's not an argument for making the traffic available for those 
> without a legal need to see it.
> 
>> SHOULD should neither be a crutch for making a proprietary protocol look 
>> like an Internet protocol nor for making two proprietary protocols look like 
>> a single, Internet protocol.
> 
> agree.
> 
> Keith
> 



smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

[Keith Moore]

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 one:
>   I don't want to make this a MUST use, because I will have deployments 
> *THAT ARE NOT FOR THE INTERNET* but I want to market them as if they were.
> Example: instant messaging systems for enterprises where tapping is a legal 
> requirement, not something to be avoided.
> Example: instant messaging systems deployed where governments want to do 
> warrantless, undetectable tapping
> 
> I would offer neither of these examples are Internet examples, and we should 
> get some iron underpants on and say so.

Mumble.  I fundamentally don't buy the argument that things that are used on 
both local networks and the Internet should not be subject to Internet-strength 
security.   

And even where recording is a legal requirement, that's NOT an argument for 
sending traffic in cleartext or with weak encryption.  That might be an 
argument for some kind of backdoor - e.g. a trusted proxy or key escrow or 
whatever, but it's not an argument for making the traffic available for those 
without a legal need to see it.

> SHOULD should neither be a crutch for making a proprietary protocol look like 
> an Internet protocol nor for making two proprietary protocols look like a 
> single, Internet protocol.

agree.

Keith

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

RE: 2119bis

[Murray S. Kucherawy]

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 be similarly 
expanded.  And I suspect some distillation of this discussion might provide 
some ideal text.

-MSK

From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Eric 
Burger
Sent: Tuesday, August 30, 2011 11:03 AM
To: IETF discussion list
Subject: 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 will have deployments *THAT 
ARE NOT FOR THE INTERNET* but I want to market them as if they were.
Example: instant messaging systems for enterprises where tapping is a legal 
requirement, not something to be avoided.
Example: instant messaging systems deployed where governments want to do 
warrantless, undetectable tapping

I would offer neither of these examples are Internet examples, and we should 
get some iron underpants on and say so.

Internet protocols need Internet protections.

SHOULD should neither be a crutch for making a proprietary protocol look like 
an Internet protocol nor for making two proprietary protocols look like a 
single, Internet protocol.

On Aug 30, 2011, at 1:50 PM, Keith Moore wrote:


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 that bans security

That wording doesn't make any sense.  Security implementation should almost 
always be a MUST, regardless of what any particular government might say.  We 
shouldn't relax the security requirements of our protocols because of 
brain-damaged governments (and I include my own country's government in that 
list).

In cases like this it's sometimes important to distinguish between 
implementation and use.  "MUST implement, SHOULD use" is a common compromise.

Note also that MUST doesn't mean "you have to do this".   It means "if you 
don't do this, you don't comply with the specification".

I don't think the example above is a typical use of SHOULD, though it might be 
too common.

Keith


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

Re: 2119bis

[Marc Petit-Huguenin]

-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 particular item, but 
>> the
>> full implications must be understood and carefully weighed before choosing a
>> different course."), the problem is that some implementers use a different
>> meaning (I do not have to implement this if it is inconvenient or difficult 
>> for
>> me to implement), vendors another one (SHOULD gave us the right to not 
>> implement
>> it).  I even read somewhere, perhaps on this list, about a vendor that 
>> rejected
>> any bug report against a SHOULD.  Conditional MUST, in my opinion, does not 
>> have
>> this problem.
> 
> But conditional MUST has other problems, namely that you have to enumerate the
> exceptions for the MUST, and that's not always practical.
> 

No, you just have to list the known cases.  Here's an example of a SHOULD that
creates a lot of problems.  This is from RFC 1889 (RFC 3550 has a slightly
better statement, but the damage was done by the time it was published):

"Functions 1-3 [i.e. RTCP feedback, RTCP CNAME and RTCP rate limit] are
mandatory when RTP is used in the IP multicast environment, and are recommended
for all environments."

If I remember correctly the reason was that it is not always possible for the
receiver to send back the RR packets, for example on satellite links.

But VoIP implementations more or less all decided to not implement RTCP using
this statement (feedback is very important even on unicast RTP for congestion
control).

A conditional MUST could have been written this way:

"Functions 1-3 are mandatory for all environments that permit a channel back to
the sender."

- -- 
Marc Petit-Huguenin
Personal email: m...@petit-huguenin.org
Professional email: petit...@acm.org
Blog: http://blog.marc.petit-huguenin.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk5dKFgACgkQ9RoMZyVa61d7ZACgn3U/lqN14YWy3TPGArqtN7AO
yrwAmwcccGVHNOm0AsbeUIdj/0MxFG1p
=91cE
-END PGP SIGNATURE-
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: 2119bis

[Murray S. Kucherawy]

> -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 interoperability problems, it may
> be that some authors are misusing SHOULD.  But it's not an inherent
> problem with SHOULD.
> 
> [...]
> 
> I'm an implementor also, and I've found SHOULD to be very helpful.

+1 to both points.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

[Eric Burger]

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 will have deployments 
*THAT ARE NOT FOR THE INTERNET* but I want to market them as if they were.
Example: instant messaging systems for enterprises where tapping is a legal 
requirement, not something to be avoided.
Example: instant messaging systems deployed where governments want to do 
warrantless, undetectable tapping

I would offer neither of these examples are Internet examples, and we should 
get some iron underpants on and say so.

Internet protocols need Internet protections.

SHOULD should neither be a crutch for making a proprietary protocol look like 
an Internet protocol nor for making two proprietary protocols look like a 
single, Internet protocol.

On Aug 30, 2011, at 1:50 PM, Keith Moore wrote:

> 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 that bans security
> 
> That wording doesn't make any sense.  Security implementation should almost 
> always be a MUST, regardless of what any particular government might say.  We 
> shouldn't relax the security requirements of our protocols because of 
> brain-damaged governments (and I include my own country's government in that 
> list).
> 
> In cases like this it's sometimes important to distinguish between 
> implementation and use.  "MUST implement, SHOULD use" is a common compromise.
> 
> Note also that MUST doesn't mean "you have to do this".   It means "if you 
> don't do this, you don't comply with the specification".
> 
> I don't think the example above is a typical use of SHOULD, though it might 
> be too common.
> 
> Keith
> 



smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: 2119bis

[Murray S. Kucherawy]

> -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
> > has always meant "MUST unless you really know what you're doing"
> 
> Such an odd reading.  Does it mean you MUST because you could not
> handle it otherwise?

I'm sorry if you think it's odd, but it's correct.  Read RFC2119 again:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean 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 choosing a different course.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

[Keith Moore]

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?
>  
> What am I missing?

If 2119 were to be updated, that's how it should work.   If we're going to 
retroactively clarify the meanings of the keywords, that should probably be 
done on a per-document basis.  (here's what we really meant when we said SHOULD 
in RFC ...)

I think it's very premature to assume that 2119 will be updated.

Keith

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

Re: 2119bis

[Keith Moore]

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 that bans security

That wording doesn't make any sense.  Security implementation should almost 
always be a MUST, regardless of what any particular government might say.  We 
shouldn't relax the security requirements of our protocols because of 
brain-damaged governments (and I include my own country's government in that 
list).   

In cases like this it's sometimes important to distinguish between 
implementation and use.  "MUST implement, SHOULD use" is a common compromise.

Note also that MUST doesn't mean "you have to do this".   It means "if you 
don't do this, you don't comply with the specification".

I don't think the example above is a typical use of SHOULD, though it might be 
too common.

Keith

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

Re: 2119bis

[HLS]

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
> 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 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 particular item,
>>> but the
>>> full implications must be understood and carefully weighed before
>>> choosing a
>>> different course."), the problem is that some implementers use a
>>> different
>>> meaning (I do not have to implement this if it is inconvenient or
>>> difficult for
>>> me to implement), vendors another one (SHOULD gave us the right to not
>>> implement
>>> it).  I even read somewhere, perhaps on this list, about a vendor that
>>> rejected
>>> any bug report against a SHOULD.  Conditional MUST, in my opinion, does
>>> not have
>>> this problem.
>>
>> But conditional MUST has other problems, namely that you have to enumerate
>> the exceptions for the MUST, and that's not always practical.
>>
>> Implementors who think that SHOULD gives them a free pass to avoid
>> implementing something that's needed to interoperate are misreading 2119.
>> But document editors should avoid using SHOULD for cases where failure to
>> implement the requirement will result in interoperability failure.
>>
>> I could see maybe posting an erratum or a brief update to 2119, but I
>> think that reopening that document in general is a Very bad Idea.  And for
>> existing documents that misuse SHOULD, the appropriate thing to do is to
>> update those documents or post errata to those documents, rather than try
>> to retroactively change the meaning of the keywords in those documents.
>>
>> Keith
>>
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>
>


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

Re: 2119bis

[Spencer Dawkins]

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: Keith Moore 
  To: Marc Petit-Huguenin 
  Cc: IETF discussion list ; Eric Burger 
  Sent: Tuesday, August 30, 2011 11:11 AM
  Subject: Re: 2119bis


  I could see maybe posting an erratum or a brief update to 2119, but I think 
that reopening that document in general is a Very bad Idea.  And for existing 
documents that misuse SHOULD, the appropriate thing to do is to update those 
documents or post errata to those documents, rather than try to retroactively 
change the meaning of the keywords in those documents.


  Keith




--


  ___
  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: 2119bis

[Eric Burger]

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 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 particular item, but 
>> the
>> full implications must be understood and carefully weighed before choosing a
>> different course."), the problem is that some implementers use a different
>> meaning (I do not have to implement this if it is inconvenient or difficult 
>> for
>> me to implement), vendors another one (SHOULD gave us the right to not 
>> implement
>> it).  I even read somewhere, perhaps on this list, about a vendor that 
>> rejected
>> any bug report against a SHOULD.  Conditional MUST, in my opinion, does not 
>> have
>> this problem.
> 
> But conditional MUST has other problems, namely that you have to enumerate 
> the exceptions for the MUST, and that's not always practical.
> 
> Implementors who think that SHOULD gives them a free pass to avoid 
> implementing something that's needed to interoperate are misreading 2119.  
> But document editors should avoid using SHOULD for cases where failure to 
> implement the requirement will result in interoperability failure.
> 
> I could see maybe posting an erratum or a brief update to 2119, but I think 
> that reopening that document in general is a Very bad Idea.  And for existing 
> documents that misuse SHOULD, the appropriate thing to do is to update those 
> documents or post errata to those documents, rather than try to retroactively 
> change the meaning of the keywords in those documents.
> 
> Keith
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf



smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

[Keith Moore]

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 try to outline cases where SHOULD is problematic, and
>> provide advice for those cases, than to try to get rid of it or change what 
>> it means.
> 
>> e.g. For the specific case of optional features that must be
>> negotiated, I don't think that SHOULD is the problem.  Rather I
>> think that optional features are too common.  That's not to say
>> that optional features and feature negotiation are never
>> useful, particularly when extending a protocol that is already
>> well-established in the field.  But if making features optional
>> is seen by WGs as a way to avoid making hard decisions about
>> what is required to interoperate, that really is a problem.  It
>> just doesn't have anything to do with SHOULD.
> 
> How about recommending SHOULD ... BECAUSE to encourage the author
> to justify the SHOULD. I suspect that this would reduce the
> number of SHOULDs, that would be better as MAYs, due to the
> author's personal preference.

I think 1122 and 1123 did this very well.  State the general requirement 
briefly in terms of MUST or SHOULD or whatever, then follow that by an 
explanation written in normal language.

What I see far too often these days is an attempt to write both complicated 
requirements and the explanations in terms of 2119 conditional keywords.   This 
makes the requirements difficult for an implementor to understand and perhaps 
more ambiguous than was intended.

> My impression is that the 2119 limitation on MUST and SHOULD for
> only necessary protocol features is sometimes forgotten.

This is actually one case where I think 2119 misstated things.   The problem is 
that it's not just protocol features (as viewed on the wire) that matter in 
practice.  SHOULD and its friends are really useful for cases where you can't 
precisely nail down what should happen on every particular platform on which 
the protocol might be implemented, but it's quite reasonable to state the 
intent.

Keith

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

Re: 2119bis

[Marc Petit-Huguenin]

-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 particular item, but 
>> the
>> full implications must be understood and carefully weighed before choosing a
>> different course."), the problem is that some implementers use a different
>> meaning (I do not have to implement this if it is inconvenient or difficult 
>> for
>> me to implement), vendors another one (SHOULD gave us the right to not 
>> implement
>> it).  I even read somewhere, perhaps on this list, about a vendor that 
>> rejected
>> any bug report against a SHOULD.  Conditional MUST, in my opinion, does not 
>> have
>> this problem.
> 
> But conditional MUST has other problems, namely that you have to enumerate the
> exceptions for the MUST, and that's not always practical.
> 
> Implementors who think that SHOULD gives them a free pass to avoid 
> implementing
> something that's needed to interoperate are misreading 2119.  But document
> editors should avoid using SHOULD for cases where failure to implement the
> requirement will result in interoperability failure.
> 
> I could see maybe posting an erratum or a brief update to 2119, but I think 
> that
> reopening that document in general is a Very bad Idea.  And for existing
> documents that misuse SHOULD, the appropriate thing to do is to update those
> documents or post errata to those documents, rather than try to retroactively
> change the meaning of the keywords in those documents.

I like your definition a previous email, so perhaps an alternative solution to
updating 2119 is for authors who really care about this subject is to integrate
it in the Terminology section, something like this:

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   "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 implementors to fail to implement the general requirement
   when such failure would result in interoperability failure.


- -- 
Marc Petit-Huguenin
Personal email: m...@petit-huguenin.org
Professional email: petit...@acm.org
Blog: http://blog.marc.petit-huguenin.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk5dDYkACgkQ9RoMZyVa61fA6gCfYTawSM53Uy7okAgidhSyQZzH
8JUAn3AwH0wz96A9K2EfyALIsVkjAFJP
=L35E
-END PGP SIGNATURE-
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

[Martin Sustrik]

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 the behaviour optional.


For an implementor it's often pretty hard to decide whether to implement 
functionality marked as SHOULD given that he has zero context and no 
idea whether the reason he has for not implementing the feature is at 
all in line with RFC authors' intentions.


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

Re: 2119bis

[Keith Moore]

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 choosing a
> different course."), the problem is that some implementers use a different
> meaning (I do not have to implement this if it is inconvenient or difficult 
> for
> me to implement), vendors another one (SHOULD gave us the right to not 
> implement
> it).  I even read somewhere, perhaps on this list, about a vendor that 
> rejected
> any bug report against a SHOULD.  Conditional MUST, in my opinion, does not 
> have
> this problem.

But conditional MUST has other problems, namely that you have to enumerate the 
exceptions for the MUST, and that's not always practical.

Implementors who think that SHOULD gives them a free pass to avoid implementing 
something that's needed to interoperate are misreading 2119.  But document 
editors should avoid using SHOULD for cases where failure to implement the 
requirement will result in interoperability failure.

I could see maybe posting an erratum or a brief update to 2119, but I think 
that reopening that document in general is a Very bad Idea.  And for existing 
documents that misuse SHOULD, the appropriate thing to do is to update those 
documents or post errata to those documents, rather than try to retroactively 
change the meaning of the keywords in those documents.

Keith

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

Re: 2119bis

[Bill McQuillan]

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
> provide advice for those cases, than to try to get rid of it or change what 
> it means.

> e.g. For the specific case of optional features that must be
> negotiated, I don't think that SHOULD is the problem.  Rather I
> think that optional features are too common.  That's not to say
> that optional features and feature negotiation are never
> useful, particularly when extending a protocol that is already
> well-established in the field.  But if making features optional
> is seen by WGs as a way to avoid making hard decisions about
> what is required to interoperate, that really is a problem.  It
> just doesn't have anything to do with SHOULD.

How about recommending SHOULD ... BECAUSE to encourage the author
to justify the SHOULD. I suspect that this would reduce the
number of SHOULDs, that would be better as MAYs, due to the
author's personal preference.

My impression is that the 2119 limitation on MUST and SHOULD for
only necessary protocol features is sometimes forgotten.

-- 
Bill McQuillan 

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

Re: 2119bis

[Marc Petit-Huguenin]

-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-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: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.
>> 
>> But using SHOULD does not make the implementation less complex, it
>> simply decreases the complexity for the *author* and increases the
>> probability that two independent implementations will have
>> interoperability problems.
> 
> To the extent that SHOULD is causing interoperability problems, it
> may be that some authors are misusing SHOULD.  But it's not an
> inherent problem with SHOULD.
> 
>> As an implementer, I would ban all SHOULD/SHOULD
>> NOT/RECOMMENDED/NOT RECOMMENDED.
> 
> I'm an implementor also, and I've found SHOULD to be very helpful.
 
 Yes, it is very helpful in convincing one's PHB that one does not have
 to implement something, or in convincing another company to reactivate
 a feature during interop tests because one did not bother to implement
 it.
>>> 
>>> 
>>> Rather than vaguely attacking SHOULD, maybe it would be more illuminating
>>> to cite specific examples?
>> 
>> It is difficult because of a mix of NDAs, employment confidentiality
>> agreements and desire to not single out individuals.  I'll send you an
>> example in a private email.
> 
> I look forward to seeing it.
> 
> 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 provide advice for those cases, than to try to get rid of it
> or change what it means.

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 choosing a
different course."), the problem is that some implementers use a different
meaning (I do not have to implement this if it is inconvenient or difficult for
me to implement), vendors another one (SHOULD gave us the right to not implement
it).  I even read somewhere, perhaps on this list, about a vendor that rejected
any bug report against a SHOULD.  Conditional MUST, in my opinion, does not have
this problem.

> 
> e.g. For the specific case of optional features that must be negotiated, I
> don't think that SHOULD is the problem.  Rather I think that optional
> features are too common.  That's not to say that optional features and
> feature negotiation are never useful, particularly when extending a protocol
> that is already well-established in the field.  But if making features
> optional is seen by WGs as a way to avoid making hard decisions about what is
> required to interoperate, that really is a problem.  It just doesn't have
> anything to do with SHOULD.

- -- 
Marc Petit-Huguenin
Personal email: m...@petit-huguenin.org
Professional email: petit...@acm.org
Blog: http://blog.marc.petit-huguenin.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk5dCosACgkQ9RoMZyVa61e8iwCfZccbWf20L0VaDtBFH6ekmhm5
l30AoJmTDscY/dAGwjfU3toAnydGZHft
=pbTY
-END PGP SIGNATURE-
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

[Keith Moore]

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 implementors to fail to 
implement the general requirement when such failure would result in 
interoperability failure. 


On Aug 30, 2011, at 11:46 AM, Eric Burger wrote:

> 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, I 
>> don't think that SHOULD is the problem.  Rather I think that optional 
>> features are too common.  That's not to say that optional features and 
>> feature negotiation are never useful, particularly when extending a protocol 
>> that is already well-established in the field.  But if making features 
>> optional is seen by WGs as a way to avoid making hard decisions about what 
>> is required to interoperate, that really is a problem.  It just doesn't have 
>> anything to do with SHOULD.
> 
> ___
> 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: 2119bis

[Eric Burger]

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, I 
> don't think that SHOULD is the problem.  Rather I think that optional 
> features are too common.  That's not to say that optional features and 
> feature negotiation are never useful, particularly when extending a protocol 
> that is already well-established in the field.  But if making features 
> optional is seen by WGs as a way to avoid making hard decisions about what is 
> required to interoperate, that really is a problem.  It just doesn't have 
> anything to do with SHOULD.



smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

[Keith Moore]

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 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 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.
> 
> But using SHOULD does not make the implementation less complex, it simply
> decreases the complexity for the *author* and increases the probability 
> that two
> independent implementations will have interoperability problems.
 
 To the extent that SHOULD is causing interoperability problems, it may be 
 that some authors are misusing SHOULD.  But it's not an inherent problem 
 with SHOULD.
 
> As an implementer, I would ban all SHOULD/SHOULD NOT/RECOMMENDED/NOT 
> RECOMMENDED.
 
 I'm an implementor also, and I've found SHOULD to be very helpful.  
>>> 
>>> Yes, it is very helpful in convincing one's PHB that one does not have to
>>> implement something, or in convincing another company to reactivate a 
>>> feature
>>> during interop tests because one did not bother to implement it.
>> 
>> 
>> Rather than vaguely attacking SHOULD, maybe it would be more illuminating to 
>> cite specific examples?
> 
> It is difficult because of a mix of NDAs, employment confidentiality 
> agreements
> and desire to not single out individuals.  I'll send you an example in a 
> private
> email.

I look forward to seeing it.

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 provide advice for those cases, than to try to get rid of it 
or change what it means.

e.g. For the specific case of optional features that must be negotiated, I 
don't think that SHOULD is the problem.  Rather I think that optional features 
are too common.  That's not to say that optional features and feature 
negotiation are never useful, particularly when extending a protocol that is 
already well-established in the field.  But if making features optional is seen 
by WGs as a way to avoid making hard decisions about what is required to 
interoperate, that really is a problem.  It just doesn't have anything to do 
with SHOULD.

Keith

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

Re: 2119bis

[Marc Petit-Huguenin]

-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-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 simpler;
> trying to nail everything down makes them more complex.

 But using SHOULD does not make the implementation less complex, it simply
 decreases the complexity for the *author* and increases the probability 
 that two
 independent implementations will have interoperability problems.
>>>
>>> To the extent that SHOULD is causing interoperability problems, it may be 
>>> that some authors are misusing SHOULD.  But it's not an inherent problem 
>>> with SHOULD.
>>>
 As an implementer, I would ban all SHOULD/SHOULD NOT/RECOMMENDED/NOT 
 RECOMMENDED.
>>>
>>> I'm an implementor also, and I've found SHOULD to be very helpful.  
>>
>> Yes, it is very helpful in convincing one's PHB that one does not have to
>> implement something, or in convincing another company to reactivate a feature
>> during interop tests because one did not bother to implement it.
> 
> 
> Rather than vaguely attacking SHOULD, maybe it would be more illuminating to 
> cite specific examples?

It is difficult because of a mix of NDAs, employment confidentiality agreements
and desire to not single out individuals.  I'll send you an example in a private
email.

- -- 
Marc Petit-Huguenin
Personal email: m...@petit-huguenin.org
Professional email: petit...@acm.org
Blog: http://blog.marc.petit-huguenin.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk5dBA0ACgkQ9RoMZyVa61cu4gCfTBpCbDMdZry14MxAA32zhFe8
oMwAn3dTiHuqO90Kb9SmC0etND8YT9px
=Nht0
-END PGP SIGNATURE-
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Limitations in RFC Errata mechanism

[Mykyta Yevstifeyev]

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 Errata concerning RFC Metadata", I 
think the third type is necessary - Metadata.


Second, the "Section" field at 
 implies that only 
numerical sections will contain something an erratum can be reported 
against (overlooking the GLOBAL option).  However, Appendices, Abstract, 
Index, Author Info, different Notes exist, that aren't covered here.


Third, Original text and Corrected text fields imply that only 
before-and-after errata may be submitted.  However, there might be 
errata like Erratum # 6 
(http://www.rfc-editor.org/errata_search.php?eid=6), with an only Report 
text field.  I understand this feature was present in previous versions 
of errata mechanism but removed from the current.


So, taking this into consideration, some specific proposals:

1) Additional Metedata erratum type.  The fields which will be required 
to be filled in are: (a) metadata type: document source, RFC number, 
subseries*, obsoletes header*, updates header*, obsoleted-by header*, 
updated-by header*, category, (b) current value, and (c) correct value.  
Values marked under * in (a) may be available in the case when such 
metainfo is present in the RFC.


2) Replace the "Section" field with the drop-down list containing the 
following options: Section, Appendix, Abstract, Table of Contents, Note, 
Author information, Index.  In the case of the first two an additional 
field for number is available; in the case with Note - type of Note (RFC 
Editor, IESG etc.).


3) Allow user to choose whether they will enter old_text-new_text 
erratum or single_text erratum.


Also, several issues not related to submission mechanism.

1) Specific mailing lists devoted to discussion of errata against RFCs 
from different areas.  I've proposed this on rfc-interest list; see 
rationale at 
.;


2) Users might want to submit comments which could be displayable at 
erratum's page, similar to the mechanim employed by some IETF WGs in 
issue trackers.  This also includes ability to add myself to cc list.


3) Verified technical errata may be incorporated in the references.  Eg. 
4 technical errata were reported against RFC 793 and verified; so the 
reference may be:



Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.  
Ammended by RFC Errata Reports 573, 1562, 1564, 1572.


So, further discussion is welcome...

Mykyta Yevstifeyev

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

Re: 2119bis

[Keith Moore]

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: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.
>>> 
>>> But using SHOULD does not make the implementation less complex, it simply
>>> decreases the complexity for the *author* and increases the probability 
>>> that two
>>> independent implementations will have interoperability problems.
>> 
>> To the extent that SHOULD is causing interoperability problems, it may be 
>> that some authors are misusing SHOULD.  But it's not an inherent problem 
>> with SHOULD.
>> 
>>> As an implementer, I would ban all SHOULD/SHOULD NOT/RECOMMENDED/NOT 
>>> RECOMMENDED.
>> 
>> I'm an implementor also, and I've found SHOULD to be very helpful.  
> 
> Yes, it is very helpful in convincing one's PHB that one does not have to
> implement something, or in convincing another company to reactivate a feature
> during interop tests because one did not bother to implement it.


Rather than vaguely attacking SHOULD, maybe it would be more illuminating to 
cite specific examples?

Keith

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

Re: 2119bis

[Marc Petit-Huguenin]

-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 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.
>>
>> But using SHOULD does not make the implementation less complex, it simply
>> decreases the complexity for the *author* and increases the probability that 
>> two
>> independent implementations will have interoperability problems.
> 
> To the extent that SHOULD is causing interoperability problems, it may be 
> that some authors are misusing SHOULD.  But it's not an inherent problem with 
> SHOULD.
> 
>> As an implementer, I would ban all SHOULD/SHOULD NOT/RECOMMENDED/NOT 
>> RECOMMENDED.
> 
> I'm an implementor also, and I've found SHOULD to be very helpful.  

Yes, it is very helpful in convincing one's PHB that one does not have to
implement something, or in convincing another company to reactivate a feature
during interop tests because one did not bother to implement it.

- -- 
Marc Petit-Huguenin
Personal email: m...@petit-huguenin.org
Professional email: petit...@acm.org
Blog: http://blog.marc.petit-huguenin.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk5c+YgACgkQ9RoMZyVa61fVhACeKsjqPX1ckD572A+wpb2AKQA/
3qUAoJz3M9ORMxmCGksApSlxu5sEQbdk
=r9Bf
-END PGP SIGNATURE-
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

[Keith Moore]

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 simpler;
>> trying to nail everything down makes them more complex.
> 
> But using SHOULD does not make the implementation less complex, it simply
> decreases the complexity for the *author* and increases the probability that 
> two
> independent implementations will have interoperability problems.

To the extent that SHOULD is causing interoperability problems, it may be that 
some authors are misusing SHOULD.  But it's not an inherent problem with SHOULD.

> As an implementer, I would ban all SHOULD/SHOULD NOT/RECOMMENDED/NOT 
> RECOMMENDED.

I'm an implementor also, and I've found SHOULD to be very helpful.  

Keith

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

Re: 2119bis

[Keith Moore]

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

> 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 
> capabilities of the far end or handle the varying data elements or protocol 
> states that will or will not happen.

SHOULD/MAY is used for many other cases than whether to implement a protocol 
feature that changes how the protocol works as viewed by its peer.

Keith

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

Re: 2119bis

[HLS]

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

Re: 2119bis

[Marc Petit-Huguenin]

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

But using SHOULD does not make the implementation less complex, it simply
decreases the complexity for the *author* and increases the probability that two
independent implementations will have interoperability problems.

As an implementer, I would ban all SHOULD/SHOULD NOT/RECOMMENDED/NOT 
RECOMMENDED.

> 
> Keith
> 
> On Aug 30, 2011, at 9:51 AM, Eric Burger wrote:
> 
>> 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
>> that followed the hour-glass and end-to-end principles, and then building
>> your complex protocols out of them?
>> 
>> On Aug 29, 2011, at 11:11 PM, Keith Moore wrote:
>> 
>>> On Aug 29, 2011, at 10:44 PM, Eric Burger wrote:
>>> 
 I would offer that ANY construction of SHOULD without an UNLESS is a
 MAY.
>>> 
>>> The essential beauty of SHOULD is that it gets specification writers and
>>> working groups out of the all-too-common rathole of trying to anticipate
>>> and nail down every exceptional case.
>>> 

- -- 
Marc Petit-Huguenin
Personal email: m...@petit-huguenin.org
Professional email: petit...@acm.org
Blog: http://blog.marc.petit-huguenin.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk5c8DMACgkQ9RoMZyVa61dv/ACfRCGdkyioOtkcLOR5P5AT7EGE
y/gAn2LtqRUztE/HJEpTAMuY2eoVrRjp
=VFmG
-END PGP SIGNATURE-
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

[Eric Burger]

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 capabilities 
of the far end or handle the varying data elements or protocol states that will 
or will not happen.

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



smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

[Keith Moore]

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

Re: 2119bis

[Eric Burger]

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 that every SHOULD/MAY in a specification introduces cyclomatic complexity. 
 Every SHOULD/MAY results in at least one "if" statement, to test the presence 
or absence of the feature in the remote end.  Protocols will be much simpler to 
implement. Moreover, given the results in the software engineering literature 
that indicate latent defects appear super-linearly with cyclomatic complexity, 
protocols without (or a minimum) of SHOULD/MAY features will have fewer defects 
in the field.

Remember, we are working on Internet protocols, where a one-in-a-million corner 
case happens many times per day.

On Aug 30, 2011, at 4:00 AM, HLS wrote:

> 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 odd reading.  Does it mean you MUST because you could not
> handle it otherwise?
> 
> It takes two to tango.  One side reasons can be different than the
> other. If a software breaks down because it read SHOULD as a MUST and
> expected the other end will also view is a MUST, then it didn't know
> what it was doing.  Things break down. Implementors on either side
> can't depend on it and need to function in lieu of it. There is always
> the possibility one decided "Na, not needed, not worth the cost.
> Its not required." etc, and no one should die because of that
> decision.
> 
> I think it MUST be noted that a Minimum Implementation for a protocol
> is all anyone can expect. If a SHOULD item is among the listed minimum
> requirements, it MUST be removed from the list or changed to a MUST.
> 
> Maybe the term Minimum Implementation (is part of, is not part of) can
> be incorporated into each of the key word text.
> 
> -- 
> hls
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf



smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

[Keith Moore]

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. 
> That, however, will not always be the case. (More inline).

How would SHOULD...UNLESS or MUST...UNLESS differ from using the current 2119 
definitions and just writing SHOULD...unless or MUST ... unless?

Personally I think 2119 is just fine and doesn't need to be updated.

Keith

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

Re: 2119bis

[Keith Moore]

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 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 
> that followed the hour-glass and end-to-end principles, and then building 
> your complex protocols out of them?
> 
> On Aug 29, 2011, at 11:11 PM, Keith Moore wrote:
> 
>> On Aug 29, 2011, at 10:44 PM, Eric Burger wrote:
>> 
>>> I would offer that ANY construction of SHOULD without an UNLESS is a MAY.
>> 
>> The essential beauty of SHOULD is that it gets specification writers and 
>> working groups out of the all-too-common rathole of trying to anticipate and 
>> nail down every exceptional case.
>> 
>> Keith
>> 
>> ___
>> 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: 2119bis

[Eric Burger]

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 that followed 
the hour-glass and end-to-end principles, and then building your complex 
protocols out of them?

On Aug 29, 2011, at 11:11 PM, Keith Moore wrote:

> On Aug 29, 2011, at 10:44 PM, Eric Burger wrote:
> 
>> I would offer that ANY construction of SHOULD without an UNLESS is a MAY.
> 
> The essential beauty of SHOULD is that it gets specification writers and 
> working groups out of the all-too-common rathole of trying to anticipate and 
> nail down every exceptional case.
> 
> Keith
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf



smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

[Eric Burger]

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 writing. 
> That, however, will not always be the case. (More inline).
[snip]
> But how about 
> 
> SHOULD do FOO UNLESS you have given serious consideration as to the 
> consequences of not doing FOO.
> 
> Isn't that really the original intention of SHOULD ?  Do we gain anything if 
> that is added every time it is used?

Looking at this from a protocol perspective, SHOULD now equals MAY.  There is 
no objective way of deciding when to do FOO or not.

[snip]

smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

[Eric Burger]

+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 subjects of conformance terms, and to use them in every instance.
>> 
>> For example, a requirement like this:
>> 
>> """The Foo header MUST contain the "bar" directive"""
>> 
>> is ambiguous; it doesn't specify who has to do what. Rather,
>> 
>> """Senders MUST include the "bar" directive when producing the Foo header; 
>> recipients that receive a Foo header without a "bar" directive MUST ..."""
>> 
>> is unambiguous (assuming that the spec defines the terms "sender" and 
>> "recipient").
> 
> +1.



smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Routing at the Edges of the Internet

[Dearlove, Christopher (UK)]

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) that do some
of what you are talking about, and use protocols based on IETF
work. (Freifunk uses OLSR - RFC 3626 - and intends, as I
understand, to use OLSRv2, once we manage to finish it.)

Note: I'm an author of OLSRv2, but have no connection to
Freifunk.

There are more issues, some of which you touch on, such as
with regard to addressing issues (the MANET WG is about
routing). The AUTOCONF WG was intended to address these but
that has not been a great success. Nor am I claiming MANET
has produced all the answers to all the routing-related
problems. Part of what's missing is rationale and explanatory
material explaining how you can do more than might be obvious
with what does exist. (There are RFCs 2501 and 5889, but
there is more material known to people working in these areas
than those capture.)

-- 
Christopher Dearlove
Technology Leader, Communications Group
Communications and Networks Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Adam Novak
Sent: 26 August 2011 02:58
To: ietf@ietf.org
Subject: Routing at the Edges of the Internet


*** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
  Keep this in mind if you answer this message.
 

I trust that some of you have seen this article from a while back:



An informative except:

"When I open my laptop, I see over ten different wifi access points.
Say I wanted to send data to my friend in the flat next to mine. It is
idiotic that nowadays, I would use the bottleneck subscriber line to
my upstream ISP and my crippled upload speed and push it all the way
across their infrastructure to my neighbors ISP and back to the Wifi
router in reach of mine. The Internet is not meant to be used that
way. Instead, all these wifi networks should be configured to talk to
each other."

I also trust that you are aware of what happened to the Internet in
Egypt (and elsewhere) this spring, where Internet connectivity was
disrupted by shutting down major ISP networks.

I would like to bring the attention of the IETF to what I see as a
fundamental problem with the current architecture of the Internet:

The Internet is not a network.

As part of the development of the Internet, fault-tolerant routing
protocols have been developed that allow a connecdestined fortion to
be maintained, even if the link that was carrying goes down, by
routing packets around the problem. Similarly, packets can be
load-balanced over multiple links for increased bandwidth. However,
the benefits of these technologies are not available to end users. If
I have a smartphone with both a 3G and a Wi-Fi connection, downloads
cannot currently be load-balanced across them. The two interfaces are
on two different networks, which are almost certainly part of two
different autonomous systems. Packets must be addressed to one of the
two interfaces, not the device, and packets addressed to one interface
have no way to be routed to the other. Similar problems arise when a
laptop has both a wired and a wireless connection. Wired networks also
suffer from related difficulties: If I have Verizon and my friend has
Comcast, and we string an Ethernet cable between our houses, packets
for me will still all come down my connection, and packets for my
friend will still all come down theirs.

The Internet, as it currently appears to end-users, has a logical tree
topology: computers connect to your home router, which connects to
your ISP, which connects to the rest of the Internet. Cell phones
connect to the tower, which connects through a backhaul link to the
rest of the Internet. Almost all of the devices involved have multiple
physical interfaces and full IP routing implementations, but only the
default route is ever used. This results in a brittle Internet: the
failure of one ISP router can disconnect a large number of end-users
from the Internet, as well as interrupting communication between those
users, even when those users are, physically, only a few feet from
each other.

My question is this: what IETF work would be needed to add more
routing to the edges of the Internet? If each home or mobile device
was essentially it's own autonomo

Re: 2119bis

[Marshall Eubanks]

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 inline).

On Mon, Aug 29, 2011 at 10: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 turn the statement into the if Y then MUST X or if Z then
> MUST NOT X form.  Being pedantic and pedagogic:
>SHOULD send a 1 UNLESS you receive a 0
> really means
>UNLESS you receive a 0, one MUST send a 1.
>
> My vision of the UNLESS clause is not necessarily a protocol state, but an
> environment state.  These are things that I can see fit the SHOULD/UNLESS
> form:
>SHOULD send a 1 UNLESS you are in a walled garden
>SHOULD flip bit 27 UNLESS you have a disk
>SHOULD NOT explode UNLESS you are a bomb
> are all reasonable SHOULD-level statements.
>

But how about

SHOULD do FOO UNLESS you have given serious consideration as to the
consequences of not doing FOO.

Isn't that really the original intention of SHOULD ?  Do we gain anything if
that is added every time it is used?


> I would offer that ANY construction of SHOULD without an UNLESS is a MAY.


How about this as a counterexample.

In London, you MAY use the tube for transport. Given the weather, you SHOULD
carry an umbrella.

This SHOULD and  MAY convey different things, in a way that I would argue is
useful, and enumerating a list of UNLESSes is not going to be exhaustive.


> Unless of course one considers us the Protocol Nanny's(tm) - if do not do a
> SHOULD, we will send you to bed without your treacle!


Now, now, now. This is the IETF. We use cookies for motivation.

Regards
Marshall


> I.e., there IS NO DISTINCTION BETWEEN A BARE SHOULD AND A MAY.
>
> On Aug 29, 2011, at 9:47 PM, ned+i...@mauve.mrochek.com wrote:
>
> >> Hi -
> >
> >>> From: "Eric Burger" 
> >>> To: "Narten Thomas" ; "Saint-Andre Peter" <
> stpe...@stpeter.im>
> >>> Cc: "IETF discussion list" 
> >>> Sent: Monday, August 29, 2011 3:08 PM
> >>> Subject: Re: 2119bis
> >>>
> >>> I would assume in the text of the document.  This paragraph is simply
> an enumeration of Burger's Axiom:
> >>> For every SHOULD, there must be an UNLESS, otherwise the SHOULD is a
> MAY.
> >
> >> I disagree.
> >
> > I concur with your disagreement. SHOULD should *not* be used when the
> > list of exceptions is known and practically enumerable.
> >
> >> If the "UNLESS" cases can be fully enumerated, then
> >> "SHOULD x UNLESS y" is equivalent to "WHEN NOT y MUST X."
> >> (Both beg the question of whether we would need to spell out that
> >> "WHEN y MUST NOT X" is not necessarily an appropriate inference.)
> >
> >> RFC 2119 SHOULD is appropriate when the "UNLESS" cases are
> >> known (or suspected) to exist, but it is not practical to exhaustively
> >> identify them all.
> >
> >> Let's not gild this lily.
> >
> > +1
> >
> >   Ned
> > ___
> > 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: Scheduling years in advance [Re: voting system for future venues?]

[Marshall Eubanks]

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 scheduling.
>
> Understood.
>
> But I wonder of we've forgotten the original motivation for this rule
> and it has become an unchangable slogan (e.g., "four legs good, two
> legs bad")
>
> If, in fact, a date we've chosen turns out to be problematic in terms
> of getting a good site, the IAOC should consider (emphasis on
> *consider*) whether an alternate date would be better. Of course, such
> a change in date should not be done lightly. And it should not be done
> with out checking with the specific organizations we try to avoid
> clashes with, etc. But to say the dates are fixed and immovable no
> matter what seems unhelpful.
>
> At the plenary, I recall it being said that for one of the upcoming
> asian meetings, the exact dates were problematical, and alternate
> dates would have had better options/rates. When I suggested privately
> to the IAOC that they should *consider* changing the date, I got (what
> to me) felt like one big knee jerk "we can't change the dates,
> period."
>
>
As we move the meeting scheduling window from 1.5 years out to 3 years, I
think that that is
one of the things we should consider when necessary. Of course, hopefully
that same move will make it less necessary.

Regards
Marshall





> Thomas
> ___
> 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: Scheduling years in advance [Re: voting system for future venues?]

[Thomas Narten]

> 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 motivation for this rule
and it has become an unchangable slogan (e.g., "four legs good, two
legs bad")

If, in fact, a date we've chosen turns out to be problematic in terms
of getting a good site, the IAOC should consider (emphasis on
*consider*) whether an alternate date would be better. Of course, such
a change in date should not be done lightly. And it should not be done
with out checking with the specific organizations we try to avoid
clashes with, etc. But to say the dates are fixed and immovable no
matter what seems unhelpful.

At the plenary, I recall it being said that for one of the upcoming
asian meetings, the exact dates were problematical, and alternate
dates would have had better options/rates. When I suggested privately
to the IAOC that they should *consider* changing the date, I got (what
to me) felt like one big knee jerk "we can't change the dates,
period."

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

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

[Brian E Carpenter]

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, the idea that people need to know the date of a meeting more than 
> 1.5 years out or they won't be able to plan their attendance is ridiculous. I 
> don't even know which country I'll be living in 1.5 years from now.

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.

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

Re: Routing at the Edges of the Internet

[Alessandro Vesely]

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 everything into HTTPS, which is
> probably worse. But then again, we have to deal with market pressure
> against technically sound solutions, and the market almost always wins.

That brings us back to the problem that "free routing" is apparently
insecure.  OTOH, there are large expectations from RIRs and network
providers, about security and policy routing, especially on port 25.
On closer inspection, though, those chaps don't seem to be eager to
play net-cops.

Should we go for secure routing, now that we have secure DNS?

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

Re: voting system for future venues?

[Iljitsch van Beijnum]

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 than 1.5 
years out or they won't be able to plan their attendance is ridiculous. I don't 
even know which country I'll be living in 1.5 years from now.

You also only look at the situation where the dates are completely open until 
after the venue negotiations are complete. I don't think we need to go that 
far, we could start by selecting two weeks long in advance and then choosing 
between those as the negotiations happen. This could be especially useful for a 
meeting in a region where more contraints than usual are expected.

> The question is what we, as a community, want: dates known early or
> flexibility to select the best venue at a late stage.

I can only speak for myself, but $300/night is a big problem for me. I have no 
problem staying in non-official hotels, but obviously that only works when 
those are available and have more reasonable prices.

Then again, I don't need to go to _every_ IETF meeting (I think I'm at 12 
meetings in 9 years now) so I'm ok having a mix of cheaper and more expensive 
meetings.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: 2119bis

[Mykyta Yevstifeyev]

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 " MUST be set to  if  
is ", or " SHOULD be  if  and SHOULD be  if " etc.  
Defining the " ... IF"/" ... UNLESS" constructions for 
all of them?





2) I strongly believe that authors should be encouraged to enumerate the 
potential subjects of conformance terms, and to use them in every instance.

For example, a requirement like this:

"""The Foo header MUST contain the "bar" directive"""

is ambiguous; it doesn't specify who has to do what. Rather,

"""Senders MUST include the "bar" directive when producing the Foo header; recipients that receive a Foo 
header without a "bar" directive MUST ..."""

is unambiguous (assuming that the spec defines the terms "sender" and 
"recipient").


+1.




3) It may be worth further cautioning against over-use of MAY; this is the 
most-abused term, IME. Perhaps encouraging people to make requirements testable 
on the wire would help.


My personal observation is that MAY is often used in sense of "can", 
i.e. to designate possibility rather than optionality.  So 2119bis 
should be clear that MAY is used for describing discretionary 
actions/behavior, and those authors who wish to denote "possible action" 
should use "can", which shouldn't be included in the repertoire as being 
irrelevant to conformance.





4) WRT to the status of the document -- if people really feel that we don't 
need to revise 2119, I'd define this as a superset of 2119 and NOT obsolete it; 
i.e., have documents opt into it. However, I'd hope that we can get consensus 
that it's time to build on what 2119 offers.


See my previous message.

Mykyta Yevstifeyev



Cheers,



On 30/08/2011, at 7:36 AM, Peter Saint-Andre wrote:


After 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. I hope that I've been able to update and clarify the
text in a way that is respectful of the original. Feedback is welcome.

http://www.ietf.org/id/draft-saintandre-2119bis-01.txt

Peter

--
Peter Saint-Andre
https://stpeter.im/


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

--
Mark Nottingham   http://www.mnot.net/



___
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: 2119bis

[Mykyta Yevstifeyev]

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, so "Updates: 2119" is inappropriate (sorry for pun).


I would rather object to making RFC 2119 Historic; I remember RFC 2026 
discusses such case (probably Section 6.3, which is also applicable to 
BCPs).  So, the following change is necessary:


Abstract and Introduction (similar text).  OLD: "If approved, this 
document obsoletes RFC 2119 and changes its status to Historic."; NEW: 
"This document obsoletes RFC 2119."


Mykyta Yevstifeyev

30.08.2011 1:15, 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 thousands of documents (not only RFCs, also W3C
standards, etc.) with normative references to RFC 2119 (sic!) instead
of BCP 14, and I see no compelling reason to render these references
as "historic".

For starters simply confirm the erratum, I don't see why that caused
you headaches.

IMO it is not necessary (but allowed) to import any BCP 14 terms not
actually used in a document, i.e., I disagree with section 4 in your
draft.

How about trying an "updates 2119" and status BCP, where BCP 14 then
consists of 2119 and 2119bis, and old RFC 2119 references are still
okay "as is".

Readers with difficulties to figure out what RFC 2119 meant might
find the confirmed erratum and the "updated by 2119bis" with better
answers.  Authors could use RFC 2119, 2119bis, or even BCP 14 in
the references of new documents, where "BCP 14" would be new, IIRC
RFC 2119 did not permit this -- fearing precisely what is happening
now, somebody trying to update critical terms.  I think that your
new definitions match precisely what RFC 2119 wanted, but I'm also
almost sure that some old "2119 clients" will disagree.

-Frank
___
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: 2119bis

[Eliot Lear]

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 thousands of documents (not only RFCs, also W3C
> standards, etc.) with normative references to RFC 2119 (sic!) instead
> of BCP 14, and I see no compelling reason to render these references
> as "historic".

On the basis of this logic we wouldn't be able to supercede any of our
key RFCs.

> [...]

> How about trying an "updates 2119" and status BCP, where BCP 14 then
> consists of 2119 and 2119bis, and old RFC 2119 references are still
> okay "as is".

What ends up happening, then, is that we need Internet lawyers to
traipse through references.  I challenge you or anyone else here to list
all the process RFCs that update RFC 2026.  Let's not repeat that fiasco
with 2119.


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

Re: 2119bis

[HLS]

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 odd reading.  Does it mean you MUST because you could not
handle it otherwise?

It takes two to tango.  One side reasons can be different than the
other. If a software breaks down because it read SHOULD as a MUST and
expected the other end will also view is a MUST, then it didn't know
what it was doing.  Things break down. Implementors on either side
can't depend on it and need to function in lieu of it. There is always
the possibility one decided "Na, not needed, not worth the cost.
Its not required." etc, and no one should die because of that
decision.

I think it MUST be noted that a Minimum Implementation for a protocol
is all anyone can expect. If a SHOULD item is among the listed minimum
requirements, it MUST be removed from the list or changed to a MUST.

Maybe the term Minimum Implementation (is part of, is not part of) can
be incorporated into each of the key word text.

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

RE: 2119bis

[Thomson, Martin]

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 shouted.  
Lowercase "must" can be as effective as uppercase as long as it is consistently 
applied.


On a more serious note, many documents lean too heavily on conformance terms.

A gentle reminder that conformance terms ought to be sparingly used might not 
go astray here.  It's just like the F-bomb, it's a F-ing big deal if used 
infrequently enough.  People are more likely to pay attention when it's rare.

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

Re: voting system for future venues?

[Henk Uijterwaal]

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

> As we have been told for many years and experienced directly, hotel schedules
> become crowded 2-3 years ahead of time.  That means we must fix our dates
> farther ahead than we have been doing.  1.5 years essentially guarantees our
> having very limited choice.

Yes, I agree.  My point was the change that was proposed.  Currently the
algorithm is something like:

 T-6 years:Announce date of meeting
 T-3 years:Start finding a hotel
 T-2 years:Select hotel
 T-1.5 years:  Announce venue to community.

Obvious advantage of this model is that all other organizations know when we
will meet and clashes are minimal.  Also, people who asked for early
announcements of meeting dates, get what they want.

If we change to a model where we are more flexible in order to find the best
hotel deal, this becomes something like:

 T-6 years   Announce that we have meeting in say March/July/November
 T-3 years   Start finding a hotel for that month.
 T-2 years   Select hotel and set exact meeting dates.
 T-1.5 years Announce to community.

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.

The question is what we, as a community, want: dates known early or
flexibility to select the best venue at a late stage.

Henk

-- 
--
Henk Uijterwaal   Email: henk(at)uijterwaal.nl
  http://www.uijterwaal.nl
  Phone: +31.6.55861746
--

There appears to have been a collective retreat from reality that day.
 (John Glanfield, on an engineering project)
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf