--On Monday, August 26, 2013 10:49 -0400 John R Levine
wrote:
> Sorry if that last one came across as dismissive.
>
>> Until such time, I'd personally prefer to see some explicit
>> notion that the odd history of the SPF TXT record should not
>> be seen as a precedent and best practice, rather
Hi Doug,
At 15:42 26-08-2013, Douglas Otis wrote:
When the SPF document refers to "Sender Policy Framework (SPF)
records" or "SPF records" this conflicts with DNS's record
definition. It is wrong to refer to these as "records". RFC1034
defines resource records as TTL and RDATA that is selecte
Douglas Otis wrote:
>
>On Aug 26, 2013, at 4:29 PM, Scott Kitterman
>wrote:
>
>> On Monday, August 26, 2013 16:28:03 Douglas Otis wrote:
>>> On Aug 26, 2013, at 3:48 PM, Scott Kitterman
>wrote:
On Monday, August 26, 2013 15:42:41 Douglas Otis wrote:
> Please also note that the PTR RR
On Aug 26, 2013, at 4:29 PM, Scott Kitterman wrote:
> On Monday, August 26, 2013 16:28:03 Douglas Otis wrote:
>> On Aug 26, 2013, at 3:48 PM, Scott Kitterman wrote:
>>> On Monday, August 26, 2013 15:42:41 Douglas Otis wrote:
Please also note that the PTR RR is not constrained in the curren
On Monday, August 26, 2013 16:28:03 Douglas Otis wrote:
> On Aug 26, 2013, at 3:48 PM, Scott Kitterman wrote:
> > On Monday, August 26, 2013 15:42:41 Douglas Otis wrote:
> >> Please also note that the PTR RR is not constrained in the current
> >> specification and can create erratic results. It w
On Aug 26, 2013, at 3:48 PM, Scott Kitterman wrote:
> On Monday, August 26, 2013 15:42:41 Douglas Otis wrote:
>> Please also note that the PTR RR is not constrained in the current
>> specification and can create erratic results. It would be far safer to
>> Perm error when overflowing on the num
On Monday, August 26, 2013 15:42:41 Douglas Otis wrote:
> Please also note that the PTR RR is not constrained in the current
> specification and can create erratic results. It would be far safer to
> Perm error when overflowing on the number of PTR records. There is no
> upper limit as some repre
On Aug 24, 2013, at 3:16 AM, S Moonesamy wrote:
> Hi Doug,
> At 13:07 23-08-2013, Douglas Otis wrote:
>> The SPFbis document improperly conflates DNS terminology with identical
>> terms invented by this document. Examples are terms used to describe
>> mechanisms having the same identifier diff
--- Forwarded Message
To: Michael Richardson
From: Mark Andrews
References: <20130819222037.ga55...@mx1.yitter.info>
<20130822184610.2640.qm...@joyce.lan>
<20130822212337.b37a838cb...@drugs.dv.isc.org> <5559.1377478...@sandelman.ca>
Subject: Re: [dnsext] Deprecating SPF
In-reply-to: You
Now I get it!!
A Spanglish translation would be "It depends how the rides in the
carnival goes for you" ("Depende como te va en la feria")
/as
On 8/26/13 1:54 PM, Dave Aronson wrote:
>> As my mother used to say "What you lose on the roundabouts
>> > you gain on the sw
> From: "Randy Presuhn"
>
> I had to google it as well. The word "roundabout" (in the
> sense of "traffic circle") led me to mistakenly think it
> had something to do with navigating British streets, but
> this seems to be where the idiom comes from:
> http://www.oldpoetry.com/Patrick_R_Chalmer
>
> > As my mother used to say "What you lose on the roundabouts
> > you gain on the swings"
>
> I had to go Google that. To save others the trouble: it seems to
> refer to rides at a carnival, and mean "whatever losses you suffer in
> one place, you usually make up elsewhere", implying that it
Hi -
> From: "Dave Aronson"
> To: "IETF Discussion Mailing List" ; "Janet P Gunn"
>
> Sent: Monday, August 26, 2013 9:54 AM
> Subject: Re: Charging remote participants
...
> I had to go Google that. To save others the trouble: it seems to
> refer to rides at a carnival, and mean "whatever los
On Mon, Aug 26, 2013 at 11:57 AM, Janet P Gunn wrote:
>> From: Abdussalam Baryun
>> Date: 08/25/2013 08:40 AM
>>
>> ...
>> The reward/motivation from IETF to participants is to
>> acknowledge in writting their efforts, which I think still the IETF
>> management still does not motivate/encourage.
On Mon, 26 Aug 2013, Janet P Gunn wrote:
I have never felt "ignored" as a remote participant. Sometimes
misunderstood because there is little opportunity to expand and explain
when you are remote. But never ignored.
I have no idea what you mean by "hides information". Are you suggesting
th
> From: Abdussalam Baryun
> Date: 08/25/2013 08:40 AM
>
> ...
> The reward/motivation from IETF to participants is to
> acknowledge in writting their efforts, which I think still the IETF
> management still does not motivate/encourage.
I COMPLETELY disagree with this. The reward/motivation f
--
Casey Farrell
shem_...@operamail.com
- Original message -
From: Casey Farrell
To: w...@sfchronicle.com
Subject: Fred MacMurray's
Date: Mon, 26 Aug 2013 08:21:21 -0700
--
Casey Farrell, designer/author
1824 Rancho
Nicasio, CA
shem_...@operamail.com
RE: Fred MacMurray's
Michael,
Thanks for asking. We have consulted with Canadian tax experts on this matter.
The federal Goods and Services Tax (GST) does not apply to Admissions to
"foreign conventions", which is what the IETF meeting is as Canadians make up
fewer
than 25% of the attendees. Maybe you can work on t
On 08/26/2013 04:55 PM, Jelte Jansen wrote:
>>
>> I'd have thought that the debate here and elsewhere already documented
>> that. Since it's not specific to SPF, perhaps we could do a draft on
>> "overloaded TXT considered harmful" to get it into the RFC record.
>>
>
> That draft may not be a bad
On 08/26/2013 04:49 PM, John R Levine wrote:
> Sorry if that last one came across as dismissive.
>
>> Until such time, I'd personally prefer to see some explicit notion that
>> the odd history of the SPF TXT record should not be seen as a precedent
>> and best practice, rather than hope that this
Sorry if that last one came across as dismissive.
Until such time, I'd personally prefer to see some explicit notion that
the odd history of the SPF TXT record should not be seen as a precedent
and best practice, rather than hope that this is implicit.
I'd have thought that the debate here and
On Sat, Aug 24, 2013 at 08:39:36AM -0400, Phillip Hallam-Baker wrote:
> On Fri, Aug 23, 2013 at 3:46 PM, manning bill wrote:
>
> >
> > the question is not that "nobody" checks type 99, the question is
> > "is the rate of adoption
> > of type 99 -changing- in relation to type 16?
>
Thanks
-- DJ
-Original Message-
From: recentattendees-boun...@ietf.org
[mailto:recentattendees-boun...@ietf.org] On Behalf Of Ray Pelletier
Sent: Friday, August 23, 2013 2:19 PM
To: recentattend...@ietf.org
Subject: [Recentattendees] Huawei is the Host for IETF 88 in Vancouver
The IAOC
On 08/26/2013 04:08 PM, John R Levine wrote:
>
> Could you point to anyone, anywhere, who has ever said that the odd
> history of the SPF TXT record means that it is perfectly fine to do
> something similar in the future?
>
Three of the four points on the list that triggered my first message in
prevented, not solved. I would like to prevent someone from having to
submit a draft specifying that in the case of TXT, the (name, class,
type)-tuple should be extended with the first X octets from the RDATA
fields, somewhere in the future, because client-side demuxing is getting
too buggy and it
Mishra, Sanjay wrote:
> 1. Registration A. Early-Bird Registration - USD 650.00 Pay by Friday,
Since the last Vancouver IETF, the province of BC has "rescinded" it's
harmonization of provincial and federal sales taxes. (I think the decision is
totally moronic, but, I don't live there). This
On 08/23/2013 04:34 PM, John Levine wrote:
>>
>> I don't know of any (at least ones that are used in the global dns
>> namespace), and I would like to still not know of any in 2033.
>>
>
> Since we agree that the issue you're worried about has not arisen even
> once in the past decade, could you c
> I experienced rude respondings in IETF list
That would be when you tried to get April 1 RFCs discontinued.
> in one WG list
That would be MANET, when you lobbied for an acknowledgement on a draft you
didn't write or contribute significantly to.
Have you considered that being polite and reas
28 matches
Mail list logo
