On 12/02/2012 01:41 PM, Melinda Shore wrote:
On 12/2/12 9:37 AM, Keith Moore wrote:
Perhaps roughly the first 2(?) days of an IETF meeting could be largely
devoted to presentation sessions, and the remainder of the time to
discussion sessions.
I think you'd end up with 2 days of presentation
On 12/02/2012 02:21 PM, Melinda Shore wrote:
On 12/2/12 10:18 AM, Keith Moore wrote:
On 12/02/2012 01:41 PM, Melinda Shore wrote:
I think you'd end up with 2 days of presentation sessions and the
remainder of the meeting given over to presentation sessions.
In which case the ADs should fire
On 12/02/2012 03:57 PM, joel jaeggli wrote:
On 12/2/12 11:15 AM, Keith Moore wrote:
On 12/02/2012 01:46 PM, joel jaeggli wrote:
We have non-native english speakers and remote participants both
working at a disadvantage to follow the discussion in the room. We
should make it harder for them
On 12/02/2012 10:49 PM, Joel jaeggli wrote:
On 12/2/12 19:02 , Keith Moore wrote:\
I saw very little productive discussion happening in Atlanta in the vast
majority of working group meetings which I attended. True, there were
times when people queued up at the microphones. (though that's
On 11/29/2012 10:36 AM, Dave Crocker wrote:
F2f meetings are explicitly managed, with significant control of the
room. Mailing list exchanges are typically not managed at all.
Given the difference, it's not surprising that one proves more
productive than the other.
Please don't confuse
On 11/29/2012 06:06 PM, Pete Resnick wrote:
On 11/29/12 3:45 PM, Lee Howard wrote:
I can't take notes while I'm standing up, facilitating discussion.
Interesting. I am forced to (only somewhat facetiously) ask: Why are
*you* standing up, facilitating discussion, if you are the editor?
On 11/27/2012 01:00 PM, Barry Leiba wrote:
This brings up a question that I have as an AD: A number of times
since I started in this position in March, documents have come to the
IESG that prompted me (or another AD) to look into the document
history for... to find that there's basically no
On Sep 28, 2011, at 2:12 PM, Cameron Byrne wrote:
In the end (as well as IPv6-only near term in mobile), IP version
agnostic apps will prove to be more reliable and therefore will get
more market share.
Not clear. There's a tradeoff between the additional reliability of being
On Sep 26, 2011, at 10:07 AM, George, Wes wrote:
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Keith
Moore
Sent: Friday, September 23, 2011 10:04 PM
To: Cameron Byrne
Cc: IETF Discussion
Subject: Re: Last Call: draft-weil-shared-transition-space-request-03.txt
On Sep 26, 2011, at 12:47 PM, Iljitsch van Beijnum wrote:
On 26 Sep 2011, at 18:41 , Keith Moore wrote:
The problem isn't in the difficulty of finding these changes and fixing
them, for currently maintained code. The problem is in the zillions of
systems in the field that have
On Sep 26, 2011, at 2:15 PM, George, Wes wrote:
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Keith
Moore
Sent: Friday, September 23, 2011 10:04 PM
The problem is in the zillions of systems in the field that have assumptions
about 240/4 wired into them, most
On Sep 26, 2011, at 6:21 PM, Christian Huitema wrote:
We see here a proposal to create site local IPv4 addresses for Internet
providers. The IETF previously expanded significant efforts to deprecate IPv6
site local addresses. Why exactly do we believe that IPv4 site local
addresses would
On Sep 25, 2011, at 9:42 AM, John C Klensin wrote:
Remembering that an ISP who wants to avoid the use of public
IPv4 addresses on its backbone/infrastructure has the option of
simply converting that infrastructure to IPv6, tunneling
public-address IPv4 packets (both its own and those of its
On Sep 25, 2011, at 2:34 PM, John C Klensin wrote:
--On Sunday, September 25, 2011 13:25 -0400 Keith Moore
mo...@network-heretics.com wrote:
Remembering that an ISP who wants to avoid the use of public
IPv4 addresses on its backbone/infrastructure has the option
of simply converting
I already made one Last Call comment, but I neglected to state unambiguously
whether I supported the proposal.
I do support this proposal.
I think that this question needs to be viewed as a choice between two risks:
1) the risks associated with this proposal
2) the risks associated with
On Sep 23, 2011, at 9:53 PM, Cameron Byrne wrote:
So if there is going to be breakage, and folks are willing to fix it over
time because the good outweighs the bad (I personally do not believe this),
then why not dedicate 240/4 for this purpose?
The 240/4 work has been shot down multiple
On Sep 19, 2011, at 12:27 PM, Peter Saint-Andre wrote:
On 9/19/11 10:14 AM, Alejandro Acosta wrote:
+1
I also support the idea of every RFC havving the associated wiki.
I think that if some people support the idea, they can easily create a
wiki somewhere (e.g., specsannotated.com) and get
On Sep 17, 2011, at 3:38 PM, Marshall Eubanks wrote:
Instead of having a wiki, why not have a wikipedia article for each RFC ?
Whatever problems we would have with change control,
wikipedia is already dealing with.
wikipedia has different goals. they're really trying to be an encyclopedia;
On Sep 17, 2011, at 4:28 PM, Joel jaeggli wrote:
we have abundant evidence of there being color added in the context
of ietf mailing lists. problem is, there's a lot more than color
added there.
a wiki is a different medium than email. because people can alter
and even delete
On Sep 17, 2011, at 5:37 PM, Yaron Sheffer wrote:
Like Keith, I believe we can benefit a lot from users being able to freely
annotate RFCs with implementation notes, corrections and even opinions (this
protocol option sucks!).
But I also tend to agree with Joel that the wiki format is
My impression is that the IETF quite regularly does new things that break
current, actively used, maintained, and even standards-track protocols. Maybe
we should worry about those before worry about breaking older protocols.
Keith
On Sep 16, 2011, at 9:30 AM, Ronald Bonica wrote:
Scott,
I hit send too quickly after answering the first question, neglecting to answer
the latter two.
2. In general, IETF has a difficult time maintaining a cadre of people with
expertise in any particular area. There's very little representation by
applications developers; there's also
On Sep 16, 2011, at 10:52 AM, Cyrus Daboo wrote:
Again I would like to bring up the idea of every RFC having an associated
wiki page(s). The goal here is to provide a way for implementors to add
comments, annotations, clarifications, corrections etc to augment the RFCs.
Whilst such
On Sep 16, 2011, at 1:06 PM, Paul Hoffman wrote:
On Sep 16, 2011, at 9:39 AM, Keith Moore wrote:
On Sep 16, 2011, at 10:52 AM, Cyrus Daboo wrote:
Again I would like to bring up the idea of every RFC having an associated
wiki page(s). The goal here is to provide a way for implementors
On Sep 16, 2011, at 3:07 PM, hector wrote:
I don't see these ass Wikis but basically blog style flat display of user
comments, which I often do find useful, especially for the user (this way)
upon user (not always) follow ups.
A Wiki is more where you can change the main content and
On Sep 16, 2011, at 3:26 PM, Andrew Feren wrote:
On Fri 16 Sep 2011 03:22:08 PM EDT, Keith Moore wrote:
On Sep 16, 2011, at 3:07 PM, hector wrote:
I don't see these ass Wikis but basically blog style flat display of
user comments, which I often do find useful, especially for the user
My recollection is that this has already been done to a large degree.
Also, focusing on this specific set of RFCs would be a lot of work, for very
little actual value to the community.
On the other hand, I'd be very much in favor of IETF periodically reviewing ALL
standards-track RFCs for
On Sep 15, 2011, at 3:17 PM, Frank Ellermann wrote:
On 15 September 2011 20:39, Scott O Bradner wrote:
as Keith points out - a round of this type of effort was
undertaken by the newtrk working group a while back
About five years back, IIRC, and with some limiting parameters.
I think this
On Sep 15, 2011, at 6:44 PM, Spencer Dawkins wrote:
I was in the rough on that one in 2005, but since we're looking at another
bulk recategorization effort, I might make this suggestion again - perhaps we
could define a new level, which might be called something like Not
Maintained, with
On Sep 13, 2011, at 11:25 AM, Joe Touch wrote:
On Sep 12, 2011, at 8:09 PM, Keith Moore mo...@network-heretics.com wrote:
...
SRV indicates the port number (useful if not the default) and weight, etc.
right. but given that you can include the same things in a TXT record, if
you have
On Sep 11, 2011, at 6:23 PM, Joe Touch wrote:
On Sep 11, 2011, at 2:09 PM, Keith Moore wrote:
On Sep 11, 2011, at 4:46 PM, Joe Touch wrote:
We've been discussing this in the Transport area lately.
DNS SRVs are defined in RFC 2782 as I have described. Additional info is
passed in TXT
On Sep 12, 2011, at 7:32 AM, Sam Hartman wrote:
Keith == Keith Moore mo...@network-heretics.com writes:
Keith 2) This will not do any good
Keith IMO, that is a valid objection. Stability in our process is
Keith desirable; therefore change merely for the sake of change
On Sep 12, 2011, at 10:57 AM, Joe Touch wrote:
On 9/11/2011 11:32 PM, Keith Moore wrote:
On Sep 11, 2011, at 6:23 PM, Joe Touch wrote:
On Sep 11, 2011, at 2:09 PM, Keith Moore wrote:
On Sep 11, 2011, at 4:46 PM, Joe Touch wrote:
We've been discussing this in the Transport area lately
I think at this point we're just talking past each other, but I simply disagree
with your assertion that RFC 2782 should be taken as a prohibition on using SRV
RRs in any way other than defined in RFC 2782.
My bigger concern is why you insist on wanting to play in the SRV sandbox and
On Sep 12, 2011, at 2:31 PM, Joe Touch wrote:
The issue is that if this document wants to go outside the spec, *it* needs
to update RFC2782 - and survive the discussion that will incur.
Well, in a pedantic sense I'm sure that's true. But it doesn't need to update
RFC2782 as it pertains to
On Sep 12, 2011, at 3:50 PM, Joe Touch wrote:
On 9/12/2011 11:41 AM, Keith Moore wrote:
I think at this point we're just talking past each other, but I
simply disagree with your assertion that RFC 2782 should be taken as
a prohibition on using SRV RRs in any way other than defined in RFC
On Sep 12, 2011, at 3:50 PM, Joe Touch wrote:
On 9/12/2011 11:46 AM, Keith Moore wrote:
On Sep 12, 2011, at 2:31 PM, Joe Touch wrote:
The issue is that if this document wants to go outside the spec, *it*
needs to update RFC2782 - and survive the discussion that will incur.
Well
On Sep 12, 2011, at 4:23 PM, Nico Williams wrote:
On Mon, Sep 12, 2011 at 3:15 PM, Keith Moore mo...@network-heretics.com
wrote:
On Sep 12, 2011, at 3:50 PM, Joe Touch wrote:
I think RFC 2782 inappropriately specified SRV RRs by defining both the
label syntax and the RDATA syntax
On Sep 12, 2011, at 4:22 PM, Joe Touch wrote:
On 9/12/2011 1:15 PM, Keith Moore wrote:
On Sep 12, 2011, at 3:50 PM, Joe Touch wrote:
On 9/12/2011 11:41 AM, Keith Moore wrote:
I think at this point we're just talking past each other, but I
simply disagree with your assertion that RFC 2782
On Sep 12, 2011, at 4:57 PM, Joe Touch wrote:
Most RRs tie some set of data to a domain name which is historically
a host name, though in recent years it's become a somewhat more
nebulous concept (e.g. a collection of services, or in the case of
MX records a collection of recipient
On Sep 12, 2011, at 6:23 PM, Joe Touch wrote:
Again I'm confused.
You claim there's a clear need to revise SRV syntax, but not the registry
that basically defines that syntax?
I don't claim that there's a clear need to revise the syntax of the RDATA. I
claim that the syntax defined in
On Sep 12, 2011, at 7:06 PM, Joe Touch wrote:
Given that I think service location is almost inherently
application-specific anyway, that solution is also fine with me. I don't
know what value is added by SRV, other than confusion.
SRV indicates the port number (useful if not the default)
I've always thought that insistence on the use of RFC 2782 labels with SRV
records unreasonably overconstrained the use of SRV records; and thus, limited
their applicability.
Part of the problem, I suspect, is that at the time that 2782 was being drafted
there may have been some belief that
On Sep 11, 2011, at 4:46 PM, Joe Touch wrote:
We've been discussing this in the Transport area lately.
DNS SRVs are defined in RFC 2782 as I have described. Additional info is
passed in TXT records for current DNS SRVs.
I.e. what I have proposed is what is both current spec and current
On Sep 10, 2011, at 10:44 AM, Russ Housley wrote:
That said, at the plenary at IETF 81, Harald suggested that we have waited so
long that incremental improvements may not be the right approach, rather it
was time for 2026bis. I agree that it is needed, but I am not sure the IETF
community
On Sep 10, 2011, at 11:47 AM, Dave CROCKER wrote:
In the current case, it's been particularly impressive to see criticisms
against the proposal because it does not solve problems it is not trying to
solve and because other problems are deemed higher priority.
Nevermind whether the
On Sep 10, 2011, at 4:11 PM, Sam Hartman wrote:
I do not think the following types of comments should be considered as
objections when judging this sort of consensus:
1) You are not solving the most important problem
I don't think that was anybody's objection. Rather, the objection were
On Sep 7, 2011, at 10:17 AM, Ned Freed wrote:
Face it, we've effectively had a one-step process pretty much ever since 2026
was approved. For the most part, the documents that have advanced have been
those that were buggy enough to need to be fixed, but not so buggy that they
had to recycle
On Sep 6, 2011, at 12:11 PM, Andrew Sullivan wrote:
On Tue, Sep 06, 2011 at 11:38:14AM -0400, Ross Callon wrote:
I haven't heard anyone currently on the IESG say that the two step process
would require higher more rigorous document reviews.
That particular refusal to recognize part
On Sep 6, 2011, at 2:26 PM, Ned Freed wrote:
I find it impossible to believe that this will not result in even more
hard-line positions on the part of some IESG members when something
with which they disagree is a candidate for PS. I see no way in which
the draft solves this problem, which
On Sep 6, 2011, at 6:01 PM, Brian E Carpenter wrote:
On 2011-09-07 09:35, Ted Hardie wrote:
...
My personal opinion for some time has been that we ought to recognize that
the previous PS moved into WG draft years ago and that anything named an
RFC should be recognized as something that
On Sep 6, 2011, at 5:35 PM, Ted Hardie wrote:
The document doesn't actually say out loud there that the requirements for
Proposed Standard have been considerably increased by IESG practice over the
years, nor does it charge subsequent IESGs to return to a faithful reading of
the actual
On Sep 6, 2011, at 7:33 PM, Ted Hardie wrote:
but it means we are changing out a standard that doesn't accurately reflect
what we do now for one that doesn't accurately reflect what we will do.
Yup. And IMO we're better off with the old incorrect statement than a new
one. At least with
On Sep 6, 2011, at 7:48 PM, Fred Baker wrote:
I wonder if we would be better off discarding the concept of layers of
standards, call PS Standards track, and instead specify a way to report
interoperability tests.
+1. Perhaps along with periodically updated applicability statements.
Honestly, the thing that is the most broken about this draft is the idea that
there's something wrong with our process because few drafts make it to full
standard, so the solution is to short-circuit the process. The transition from
Draft to Full Standard is the least of the problems with our
On Sep 2, 2011, at 5:29 PM, Ross Callon wrote:
Two things that I don't seem to have picked up on: (i) Any consensus that a 3
step process is better than a 2 step process; (ii) Any hint of moving towards
an agreement on other things that we might do to improve the process.
(iii) Any
On Sep 2, 2011, at 5:36 PM, ned+i...@mauve.mrochek.com wrote:
In looking through this discussion, I see:
- People saying that moving from 3 steps to 2 steps is a small step in the
right direction, lets do it. Many people who have said this (including I)
have
been silent for a while quite
think two levels are enough.
Jari
On 03.09.2011 00:34, Keith Moore wrote:
(iii) Any consensus that a 2 step process is better than a 3 step process.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
On Sep 2, 2011, at 7:07 PM, Ned Freed wrote:
As far as our process is concerned, the question is, do we have rough
consensus to accept it? I think it's dubious that we have such consensus,
and
apparently so do others.
Simply put, I've watched the responses to this fairly closely, and I
On Sep 1, 2011, at 2:58 AM, Hector wrote:
6. Guidance in the use of these Imperatives
Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which
On Aug 31, 2011, at 2:31 AM, John C Klensin wrote:
--On Tuesday, August 30, 2011 14:51 -0700 Fred Baker
f...@cisco.com 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
On Aug 31, 2011, at 2:36 AM, Jari Arkko wrote:
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
On Aug 31, 2011, at 4:34 AM, Jari Arkko wrote:
Eric, John,
Would having professional editors make a difference here?
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
On Aug 31, 2011, at 8:30 AM, Hector wrote:
In my view, SHOULD are user protocol options to set.
In my view, SHOULD should rarely be used for optional protocol features,
because optional protocol features should themselves be rare. And the primary
purpose of SHOULD is not to permit optional
On Aug 31, 2011, at 9:12 AM, Hector wrote:
Keith Moore wrote:
On Aug 31, 2011, at 8:30 AM, Hector wrote:
In my view, SHOULD are user protocol options to set.
In my view, SHOULD should rarely be used for optional protocol features,
because optional protocol features should themselves
On Aug 31, 2011, at 10:03 AM, Murray S. Kucherawy wrote:
On the other hand, given the current SHOULD definition in RFC2119, I'm at a
loss to understand how one could reasonably come to other than the second
interpretation you give here. It's fairly explicit to me.
The simplest explanation
On Aug 31, 2011, at 9:57 AM, hector wrote:
SHOULD is IMO most often useful not when specifying how a protocol acts on
the wire, but when specifying how a protocol needs to be implemented on a
particular platform, where the precise semantics, API details, etc.
naturally differ from one
On Aug 31, 2011, at 10:42 AM, John C Klensin wrote:
We ought to, IMO, be permitting
publication of PS documents at the second level as long as there
are no _obvious_ ambiguities that cannot be figured out (the
same way) by people of good will acting in good faith and with
help from WG lists
thanks Spencer for pointing this part out.
On Aug 31, 2011, at 11:23 AM, Spencer Dawkins wrote:
IESG reviews should be considered as a review of last resort. Most
documents reviewed by the IESG are produced and reviewed in the
context of IETF working groups. In those cases, the IESG
On Aug 31, 2011, at 11:36 AM, John C Klensin wrote:
We ought to, IMO, be permitting
publication of PS documents at the second level as long as
there are no _obvious_ ambiguities that cannot be figured out
(the same way) by people of good will acting in good faith
and with help from WG lists
or maybe just file an erratum. I think it's fairly obvious that any document
that actually uses NOT RECOMMENDED should define what it means, if it expects
those words to have any meaning other than the ordinary English meaning of
those words (with or without capitalization).
I've seen
On Aug 31, 2011, at 11:55 AM, Hector wrote:
Keith Moore wrote:
On Aug 31, 2011, at 9:57 AM, hector wrote:
Yeah, but its also very very useful to offering what parts of a protocol
are on and off and let operators decide what they want. Don't we already do
this?
yes, it is done to some
On Aug 31, 2011, at 12:19 PM, John C Klensin wrote:
we either ought to be identifying real problems and fixing them
or just staying with what we have until we have the knowledge
and will needed to make real changes.
That would certainly be my preference.
Keith
On Aug 31, 2011, at 3:07 PM, Hector wrote:
Murray S. Kucherawy wrote:
The only difference between SHOULD and MAY is that the implementor /
deployer needs a good excuse to not implement / employ a SHOULD.
That's not the same as IGNORE.
But that's a big difference. I think some people are
On Aug 31, 2011, at 3:44 PM, Hector wrote:
I'm having a hard time understanding why you continue to work on the basis
that people fail to read essentially implying stupidity in the process.
I work on the basis of fail to read because I've seen countless examples of
it. And stupidity is not
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
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,
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
On Aug 29, 2011, at 10:40 AM, Iljitsch van Beijnum wrote:
Obviously the date needs to be fixed at some point, but does it really have
to be six years in advance? ( http://www.ietf.org/meeting/upcoming.html )
I've been wondering the same thing. Would it be reasonable to specify
ballpark
On Aug 27, 2011, at 7:30 PM, Hector Santos wrote:
Keith Moore wrote:
On Aug 27, 2011, at 10:31 AM, John Levine wrote:
TLS for session privacy is nice, but I find negligible value in a
little lock icon in my browser that means only that one of the several
dozen cert issuers configured into my
On Aug 29, 2011, at 9:12 PM, Randy Presuhn wrote:
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.
+1.
___
Ietf mailing list
Ietf@ietf.org
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
On Aug 28, 2011, at 2:35 AM, Glen Zorn wrote:
I'm familiar with the refrigerator full of caffeinated sugar water, even
the occasional tray of treats or keg of beer, but cookies (often 2 or 3
varieties)/brownies (ditto), fresh fruit, crudites dip, twice a day?
Wow, I've really been working
On Aug 27, 2011, at 10:31 AM, John Levine wrote:
TLS for session privacy is nice, but I find negligible value in a
little lock icon in my browser that means only that one of the several
dozen cert issuers configured into my browser, most of whom I've never
heard of, and many of whom aren't
On Aug 26, 2011, at 12:03 PM, Scott Brim wrote:
On Fri, Aug 26, 2011 at 11:04, Worley, Dale R (Dale) dwor...@avaya.com
wrote:
There must be at least a few hundred million mobile phones with data
capability, and a similar number of homes and small businesses with
WiFi systems. So we can
On Aug 26, 2011, at 3:22 PM, Adam Novak wrote:
On Fri, Aug 26, 2011 at 1:12 PM, Ned Freed ned.fr...@mrochek.com wrote:
It ensures that what you're getting is the same as what the IETF has
on file,
No, it really doesn't do that. There can be, and usually are, a lot of steps
involves besides
On Aug 25, 2011, at 2:13 AM, Henk Uijterwaal wrote:
On 24/08/2011 23:12, Keith Moore wrote:
Maybe there needs to be some sort of voting system for future venues.
First of all, remember that the community asked for venue selections
2 to 3 years in advance. I don't think that many people can
101 - 200 of 1815 matches
Mail list logo
