On 04/01/2013 05:15, Dean Willis wrote:
...
Either way, I'd like to see some consensus. Because my head is throbbing and
I want to know if it MUST hurt, SHOULD hurst, or just hurts. But I MUST
proceed in accordance with consensus, because to do otherwise would undermine
the clarity of our
ron,
I have just posted draft-bonica-special-purpose-05. I hope that this
version addressed the issues that we discussed, off-line.
indeed it does. s/prefix/address block/ and s/routable/forwardable/
hits my two issues on the head. thank you.
it might be good if, now that these changes
On Fri, Jan 4, 2013 at 8:03 AM, Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
This Gen-ART reviewer believes that words like must have well defined
meanings
in the English language, so shouting is not needed at every use. There are
standards track documents that don't use RFC 2119 at
On 1/4/2013 12:15 AM, Dean Willis wrote:
...
Are we deliberately evolving our language to use RFC 2119 terms as
the principle verbs of a formal specification language?
...
My view on this has evolved over time. I used to follow the practice of
using 2219 language only for emphasis. Over
It gets worse if you head west to the Tampa bay...
http://www.tampabay.com/news/publicsafety/crime/man-shot-at-st-pete-pizza-joint-had-been-complaining-about-slow-service/1266589
On Jan 4, 2013, at 2:55 AM, Ole Jacobsen o...@cisco.com wrote:
You have been warned.
All,
Some nits that need to be fixed:
ME Maintenance Entity
MEG Maintenance Entity Group
MEP Maintenance End Point
MEP ME End Point or Maintenance Entity End Point
MIP Maintenance End Point
MIP ME Intermediate Point or Maintenance Entity Intermediate Point
3.2.
On Thu, Jan 3, 2013 at 4:59 PM, Tony Hain alh-i...@tndh.net wrote:
Like it or not, governments are fundamentally opposed to the open nature of
'the Internet', and they always will be (even the 'reasonable' ones).
Managing information flow is how they derive and exercise power
Aside from the
I believe that Brian's interpretation is exactly right. At least, it
conforms to the Original Intent of the
applicability terms MUST, MAY, and SHOULD as defined in RFC 1122. And I
sympathize with
Dean Willis whose head hurts; as one-time RFC Editor I was often
confronted with wildly
It's a communication problem. If you want your audience to understand
exactly what you're saying, and implement along very specific lines, you
need to tell them in a way they understand. Personally I prefer a
quieter approach, but I've been told that these days one MUST use MUST
or implementors
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wonderful perennial topic. :)
As I always say when this comes up, when writing drafts I've settled
on using the 2119 keywords only in their uppercase form, and otherwise
using need to, ought to, might (etc.) to avoid all possible
confusion. Sure,
+1.
I think it is important that we have communications tools for
documenting strong minimum protocol requirements and we only have
RFC2119 to make that possible.
Yet, we need to be careful where the lack of RFC2119 upper case
wordings can be used to leverage an argument for relaxation of
On 4 jan 2013, at 01:59, Tony Hain alh-i...@tndh.net wrote:
Like it or not, governments are fundamentally opposed to the open nature of
'the Internet', and they always will be (even the 'reasonable' ones).
Because I do not think generalization is really a reasonable thing to do, and
even
Anecdotal data point number N+1...
As an occasional implementor of IETF specs, I have to say it's much easier to
check my conformance if I can just grep for MUST and SHOULD. It's also
easy for developers to get in the bad habit of ONLY doing those things that are
clearly marked in that way.
Lou's view matches how I write and review documents.
I would add that there is sometimes value in using 2119-style language in
requirements documents (The protocol solution MUST enable transmission of
data...) although, in my opinion, this requires a tweak to the normal2119
boilerplate.
Adrian
The tech report cited in Eric's message is not a critique of the SIDR
algorithm agility
document that is the subject if this last call. The tech report is a
critique of the overall
SIDR repository system and object retrieval paradigm, with an emphasis
on the speed with which
relying parties
Hi Dean
I agree with you which I suggested before an update to the RFC [*], I
actually writing a work in progress ID, you may give me your
suggestion if you like. I recommend you use for your work IF, THEN
rather than MUST. Easier to read.
*
I guess the test is whether a reasonably
careful reader might interpret a sentence incorrectly while writing code;
and if so, would a normative keyword help?
I think the best key word used/help is *IF, THEN, ELSE* the programmer
will never miss that key for running code and specification.
AB
formalization of the description language, and I like the English
prose. But it raises process questions for the IETF as a whole:
Are we deliberately evolving our language to use RFC 2119 terms as the
principle verbs of a formal specification language?
Is it *our language* or our
Ted Hardie wrote:
On Thu, Jan 3, 2013 at 4:59 PM, Tony Hain alh-i...@tndh.net wrote:
Like it or not, governments are fundamentally opposed to the open nature
of
'the Internet', and they always will be (even the 'reasonable' ones).
Managing information flow is how they derive and exercise
I generally take (what I infer to be) Richard's view on the matter. If not
doing something will break interoperability or security, then make it
normative. (I realize that's a gross oversimplification).
But that still doesn't mean you have to have a MUST for every step an
implementation has
At 16:59 03-01-2013, Tony Hain wrote:
other. How long the IETF gets to stay independent of that will depend on how
responsive it is to meeting the needs of governments. If short-sighted
attempts at political maneuvering are exposed in the IETF, it will lose its
independence and finally bring
On Dec 31, 2012, at 10:22 PM, Michael Richardson m...@sandelman.ca wrote:
Dave == Dave Crocker d...@dcrocker.net writes:
Dave Quick, name five reasons to go to Orlando. Here are mine:
Dave Puerto Rican
Dave delicacies, alternative cinema, craft beer, African-American
Dave
+1 to Brian and others saying upper case should be used sparingly, and
only where it really matters. If even then.
The notion (that some have) that MUST means you have to do something
to be compliant and that a must (lower case) is optional is just
nuts.
If the ARP spec were to say, upon receipt
Hi Nathan,
Have you looked at the HTML5 AppCache? It operates in a manner similar to what
you're describing.
http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html
That said, most people seem to agree that AppCache is somewhat problematic;
although some do use it, it's
+1; this is what we're doing in HTTPbis.
On 05/01/2013, at 5:15 AM, Peter Saint-Andre stpe...@stpeter.im wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wonderful perennial topic. :)
As I always say when this comes up, when writing drafts I've settled
on using the 2119 keywords
If the powers that be want to encourage us to come for the entire week,
choosing places like this doesn't help. I don't need a tourist paradise, but I
don't want to eat from the same hotel restaurant six days in a row. And needing
a car is absurd.
/grumble
P.S. I wonder how the Stand Your
Mark,
This location was dictated (if that's the right word) by a desire to
co-locate (back-to-back) with the IEEE.
As for transportation to restaurants etc, I believe shuttle options ar
being explored.
Ole
On Fri, 4 Jan 2013, Mark Nottingham wrote:
If the powers that be want to encourage
On Fri, Jan 4, 2013 at 1:44 PM, Tony Hain alh-i...@tndh.net wrote:
Ted Hardie wrote:
On Thu, Jan 3, 2013 at 4:59 PM, Tony Hain alh-i...@tndh.net wrote:
Like it or not, governments are fundamentally opposed to the open nature
of
'the Internet', and they always will be (even the
From: Steve Crocker st...@shinkuro.com
I honestly don't remember whether the plugs were the clunky four pin
or the then-modern RJ11. I recall studying RJ11 and RJ45 plugs and
sockets at some point and discovering that some plugs and sockets
had six wires instead of only four or two. I
And that consent is based on information availability. Manage the
information, and you manage the consent.
Possibly; the extent to which that management is obvious may, of course,
drive other behavior (cf. самизда́т [Samizdat] and similar efforts).
or, in the states, wikileaks.
+1 to Brian and others saying upper case should be used sparingly, and
only where it really matters. If even then.
That's the entire point: The terms provide additional information as to
what the authors consider the important points of compliance to be.
The notion (that some have) that MUST
Scott Brim wrote:
It's a communication problem. If you want your audience to understand
exactly what you're saying, and implement along very specific lines, you
need to tell them in a way they understand.
+1
Personally I prefer a quieter approach, but I've been told that
these days one
On 01/05/2013 06:17 AM, Ole Jacobsen wrote:
Mark,
This location was dictated (if that's the right word) by a desire
to co-locate (back-to-back) with the IEEE.
So if you don't attend IEEE, quit your whining: at least you won't have
to eat he same hotel food for 2 weeks in a row...
...
So if you don't attend IEEE, quit your whining: at least you won't have
to eat he same hotel food for 2 weeks in a row...
You don't have to eat there. Check out the reviews of this restaurant
across the street:
https://plus.google.com/118141773512616354020/about
On 01/05/2013 11:51 AM, John Levine wrote:
So if you don't attend IEEE, quit your whining: at least you won't
have to eat he same hotel food for 2 weeks in a row...
You don't have to eat there. Check out the reviews of this
restaurant across the street:
The IESG has received a request from the RADIUS EXTensions WG (radext) to
consider the following document:
- 'Remote Authentication Dial In User Service (RADIUS) Protocol
Extensions'
draft-ietf-radext-radius-extensions-07.txt as Proposed Standard
The IESG plans to make a decision in the
The Sunsetting IPv4 (sunset4) working group in the Internet Area of the
IETF is undergoing rechartering. The IESG has not made any determination
yet. The following draft charter was submitted, and is provided for
informational purposes only. Please send your comments to the IESG
mailing list (iesg
37 matches
Mail list logo
