There's no need to change the current language. RFCs have been referring
to cron jobs since 1997.
Actually since 1991, see below
jaap
% cd ~/library/rfc-editor/in-notes
% grep -w cron *
rfc1244.txt:- Checks all commands in the /etc/rc files and cron
Barry Leiba wrote:
A real live LIST organism (stream) is adding an extra line (two bytes,
CRLF) after the header and before the body probably all its life
It's an outlier, off in the weeds. This is not a common situation all
around the Internet. And in any case, the MLM document isn't the
On May 15, 2011, at 9:42 PM, Barry Leiba wrote:
The author can be a human using an MUA (Mail User Agent) or
an automated mail robot with an MTA.
I don't see that automated mail robot with an MTA is right at all.
But I see what you're getting at, and I'd support a change such as
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Hector Santos
Sent: Sunday, May 15, 2011 10:42 PM
To: IETF General Discussion Mailing List
Subject: Re: [ietf-dkim] MLM and C14N
But as a MLM vendor/developer, noting the existence of some
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of J.D.
Falk
Sent: Monday, May 16, 2011 5:35 AM
To: IETF list; DKIM List
Subject: Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt
(DKIM And Mailing Lists) to BCP
I don't see
On May 11, 2011, at 5:25 PM, Joe Touch wrote:
Hi, all,
Although this is a minor point, it's also easy to address:
On 5/4/2011 4:56 PM, Doug Barton wrote:
...
Meanwhile, the discussion about whether or not to call this
whitelisting is pointless. The term is already well-established.
On 5/16/2011 5:27 PM, Joel Jaeggli wrote:
For the terms in this doc, alternatives that do not require explanation
(and aren't potentially racially charged) include permit list and deny
list.
the blacklist originates with charles the 2nd. it has no racial connotations
in that context.
see
On May 16, 2011, at 2:37 PM, Dave CROCKER wrote:
On 5/16/2011 5:27 PM, Joel Jaeggli wrote:
For the terms in this doc, alternatives that do not require explanation
(and aren't potentially racially charged) include permit list and deny
list.
the blacklist originates with charles the
On 2011-05-11, at 20:25, Joe Touch wrote:
FWIW, the Los Angeles County banned the terms in 2003 when used for various
purposes - including technology, preferring primary and secondary, in
specific. The terms don't even appear in the ATA spec after version 1.
I believe that story may be
On 5/16/2011 6:08 PM, Joel Jaeggli wrote:
On May 16, 2011, at 2:37 PM, Dave CROCKER wrote:
1. Changing times often call for changed vocabulary.
which is fine, the rational stated is false to fact.
But you do not seem to be refuting the point /I/ am making, which that the fact
that the
Hi Dave,
I take no position on whether it's in good taste to use the word whitelist in
this particular instance or in general, but
On 2011-05-16, at 18:21, Dave CROCKER wrote:
1. It is not previously standardized and I believe it is not documented in an
RFC.
the term appears to have some
On 5/16/2011 6:28 PM, Joe Abley wrote:
Hi Dave,
I take no position on whether it's in good taste to use the word whitelist in
this particular instance or in general, but
On 2011-05-16, at 18:21, Dave CROCKER wrote:
1. It is not previously standardized and I believe it is not documented in
On 2011-05-16, at 18:33, Dave CROCKER wrote:
2. It is typically a split-DNS private/public mechanism.
No.
No doubt you can point to IETF documentation or other related, formal
documentation of this?
No, and I'm not sure why that's relevant. There's no shortage of examples of
addresses
On May 16, 2011, at 3:21 PM, Dave CROCKER wrote:
1. It is not previously standardized and I believe it is not documented in an
RFC.
2. It is typically a split-DNS private/public mechanism.
The draft is quite clear about exploring this topic in order to pursue common
behaviors.
On 5/16/2011 6:44 PM, Joel Jaeggli wrote:
By my observation, what is being done, satisfactorily meets the dictionary
definition of a whitelist. the term was uncontroversial in the dicussion
The working group is what statistical research methodology calls a biased
sample...
Will we be
At 15:44 16-05-2011, Joel Jaeggli wrote:
Will we be revising dkim rfc 4871 to explictly define whitelist as
dns name based whitelist thereby replacing the existing two usages
of the term (which involve explicitly allowing delivery on the basis
of orign), or was the term appraise in 2009 but
On 5/16/2011 8:34 PM, SM wrote:
Maybe this could be called DNS Seal Team 6.
Well, apparently that would be /actual/ trademark infringement, with Disney.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
On May 17, 2011, at 12:49 AM, Dave CROCKER wrote:
On 5/16/2011 6:44 PM, Joel Jaeggli wrote:
By my observation, what is being done, satisfactorily meets the dictionary
definition of a whitelist. the term was uncontroversial in the dicussion
The working group is what statistical research
The IESG has approved the following document:
- 'Guidelines for the use of the OAM acronym in the IETF'
(draft-ietf-opsawg-mpls-tp-oam-def-10.txt) as a BCP
This document is the product of the Operations and Management Area
Working Group.
The IESG contact persons are Adrian Farrel and Dan
The IESG has approved the following document:
- 'Computing TCP's Retransmission Timer'
(draft-paxson-tcpm-rfc2988bis-02.txt) as a Proposed Standard
This document is the product of the TCP Maintenance and Minor Extensions
Working Group.
The IESG contact person is Wesley Eddy.
A URL of this
The IESG has approved the following document:
- 'RPKI Objects issued by IANA'
(draft-ietf-sidr-iana-objects-03.txt) as a Proposed Standard
This document is the product of the Secure Inter-Domain Routing Working
Group.
The IESG contact persons are Stewart Bryant and Adrian Farrel.
A URL of
The IESG has approved the following document:
- 'Signed Object Template for the Resource Public Key Infrastructure'
(draft-ietf-sidr-signed-object-04.txt) as a Proposed Standard
This document is the product of the Secure Inter-Domain Routing Working
Group.
The IESG contact persons are Stewart
The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Mechanism for performing LSP-Ping over MPLS tunnels'
draft-ietf-mpls-lsp-ping-enhanced-dsmap-09.txt as a Proposed Standard
The IESG plans to make a decision in the next few
The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol
Label Switching (MPLS) - Extensions to LSP Ping'
draft-ietf-mpls-p2mp-lsp-ping-16.txt as a Proposed
The IESG has approved the following document:
- 'A Profile for Route Origin Authorizations (ROAs)'
(draft-ietf-sidr-roa-format-12.txt) as a Proposed Standard
This document is the product of the Secure Inter-Domain Routing Working
Group.
The IESG contact persons are Stewart Bryant and Adrian
The IESG has received a request from the Layer 3 Virtual Private Networks
WG (l3vpn) to consider the following document:
- 'Internal BGP as Provider/Customer Edge Protocol for BGP/MPLS IP
Virtual Private Networks (VPNs)'
draft-ietf-l3vpn-ibgp-07.txt as a Proposed Standard
The IESG plans to
26 matches
Mail list logo
