Re: Deployment of standards compliant nameservers

2013-05-21 Thread Ray Bellis

On 21 May 2013, at 02:44, Keith Moore mo...@network-heretics.com wrote:

 p.s. I wonder if the problem you describe might at least partially be caused 
 by DNS proxies and interception proxies, including but not limited to those 
 incorporated in consumer-grade routers.

Those are already addressed in RFC 5625.

kind regards,

Ray




Re: [IETF] back by popular demand - a DNS calculator

2013-03-20 Thread Ray Bellis

On 21 Feb 2013, at 02:46, Carlos M. martinez 
carlosm3...@gmail.commailto:carlosm3...@gmail.com wrote:

Wasn't the 'evil bit' able to hold the value 2 ?

Use all evil bits for IP addresses and we'll soon have no need for IPv6.

Geoff Huston and I wrote a draft to use the evil bit to indicate the presence 
of IPv4 NATs.  It could be used as a tie-breaker for Happy Eyeballs.  It's 
expired, though.

http://tools.ietf.org/html/draft-bellis-behave-natpresent-00

Ray



Re: ITC copped out on UTC again

2012-01-23 Thread Ray Bellis
Just curious, but I've often used the formulation:

day = (now - now % 86400)

where now is the output of gmtime() of equivalent to calculate the number 
of days since the epoch.

How is this affected (or not) by the presence of leap seconds, and/or any 
proposal to remove them.

Ray

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


Re: Consensus Call (Update): draft-weil-shared-transition-space-request

2011-12-08 Thread Ray Bellis

On 5 Dec 2011, at 18:08, Noel Chiappa wrote:

 I hear you. However, after thinking about it for a while, I still think we
 ought to include a chunk of 240/ space _as well as_ some 'general use' space
 (be it a /10 of that, or whatever).

+1

Ray

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


Re: Plagued by PPTX again

2011-11-15 Thread Ray Bellis

On 15 Nov 2011, at 20:46, Barry Leiba wrote:

 By suipport it, you mean accept it and convert it to something
 else, a meaning of support with which I'm unfamiliar.  I'd say
 tolerate.

Well, support may have been a little strong - specifically the meeting 
materials page says:

You can only upload a presentation file in txt, pdf, doc, or ppt/pptx. System 
will not accept presentation files in any other format.


 What's worse is that if you post PPT/X, it gets converted
 not to PDF, but to HTML, which I find awkward for slides (it's harder
 to download a presentation as a whole in a convenient form).  That's
 why I do the PDF conversion up front.

Yes, that _is_ a good reason to convert to PDF up front, ligature problems 
notwithstanding.

Ray

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


Re: Plagued by PPTX again

2011-11-14 Thread Ray Bellis

On 15 Nov 2011, at 10:24, Brian E Carpenter wrote:

 Please can everybody who doesn't upload PDF to the meeting materials page
 at least take care to upload PPT instead of PPTX?

Noted - we'll ask for PDF next time.

Please do note that the final proceedings will be in PDF format, though.

Ray

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


Re: Requirement to go to meetings

2011-10-28 Thread Ray Bellis

On 27 Oct 2011, at 12:03, Richard Kulawiec wrote:

 I support this concept, although I would go much further and
 eliminate ALL face-to-face meetings.

I absolutely wouldn't.

 Travel (for meetings) is expensive, time-consuming, energy-inefficient,
 and increasingly difficult.

Your assertions above are all true, but that does not mean that people should 
be denied the opportunity to meet.

Being mostly social animals, I believe it's essential that we *do* get to 
actually meet our IETF colleagues.

Do not underestimate how important it is to actually establish a rapport with 
other people, and that can really only be achieved face-to-face.  This is 
simple psychology.  You simply can't get to know people and work with them 
effectively if all they are is faceless email accounts or a voice on a crowded 
conf call.

I've met loads of people at my four years of IETF, and many of those I now 
consider friends.  I know what their competences are, and I know which ones I 
trust and distrust.  You just don't get that from remote participation.

Ray

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


Re: whine, whine, whine

2011-06-22 Thread Ray Bellis

On 21 Jun 2011, at 14:44, Klaas Wierenga wrote:

 otoh, not having to go through US immigrations saves you about as much
 time as you would have saved with a direct flight, not to mention the
 terrorist until proven innocent treatment. ;-)

Thus far I've been lucky with the TSA and found them courteous and reasonably 
efficient.

The longest queue by far I've ever had for immigration was at Vancouver for 
IETF70, where the shape of the queueing system coincidentally resembled the 
Hilbert space-filling curves we were playing with at the time.
 
I am slightly concerned about the relatively short time for my connection at 
YUL, though - I've only got 1h05 between scheduled landing from LHR and the hop 
out to YQB.

Ray



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


Re: My Internet experience in the West at times is comparable to female foeticide

2011-06-22 Thread Ray Bellis

On 22 Jun 2011, at 09:59, Krishna Birth wrote:

Some not all internet forums/mailing list organisers need some
educating and need to educate others for example by having some
by-laws and rules so that I am treated without these problems.

Oh, but they do!

The most common rule being that postings are *ON TOPIC*

Ray

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


Re: whine, whine, whine

2011-06-21 Thread Ray Bellis

On 21 Jun 2011, at 14:02, Simon Perreault wrote:

 Not going to argue about San Diego vs Québec, but just going to point
 out that multiple carriers do serve Québec. Among them are Air Canada,
 United, Continental, Delta, and US Airways.

The only European operator into YBQ appears to be Air Transat (whoever the heck 
they are) and they only fly from Marseille and Paris.

I'm flying BA to Montreal and taking the short city hopper flight to YBQ from 
there.

Ray


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


Re: whine, whine, whine

2011-06-21 Thread Ray Bellis

On 21 Jun 2011, at 14:37, Tim Chown wrote:

For a single operator trip from the UK to Quebec City, there's Air Canada out 
of Heathrow.   You can go via Montreal or other cities.

I seem to recall that it was actually somewhat cheaper to fly BA.  Although I 
didn't check economy class...

Ray

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


Re: draft-iab-dns-applications - clarification re: Send-N

2010-10-22 Thread Ray Bellis

On 21 Oct 2010, at 23:42, John Levine wrote:
 
 I dunno about you, but it seems utterly unreasonable to demand that we
 change the way we've been placing calls for the better part of a
 century merely to avoid a few DNS lookups.  I thought computers were
 supposed to make life easier for people, not the other way around.

Indeed, and it's not just DNS lookups - per my original message it's also a 
potentially significant saving in the number of SIP transactions.  Those are 
_much_ more resource intensive than a DNS lookup.

Ray

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


draft-iab-dns-applications - clarification re: Send-N

2010-10-20 Thread Ray Bellis
Gentlemen,

Re: §4.2 of your IAB Draft draft-iab-dns-applications-00:

(http://www.ietf.org/internet-drafts/draft-iab-dns-applications-00.txt)

Send-N is not only intended for open number plans, it's intended for use in 
_any_ plan with variable length telephone numbers.  It came out of the proposed 
specifications for the UK local number portability database, where E.164 
numbers vary from 8 to 12 digits in length.

A typical application for Send-N might be where an analogue phone is attached 
to a CP-managed SIP ATA - this will be a common setup in Next Generation 
Networks.

It is a solution to the problem of gatewaying between the 100s of millions of 
dumb handsets that use overlapped dialling[*] and the SIP world where 
overlapped dialling is not currently feasible.  As an analogue phone has no 
dial button the ATA must listen for DTMF digits, and somehow figure out for 
itself when the user has finished dialling before initiating the SIP call over 
the ATA's SIP trunk.

A common (but unreliable) method is to use inter-digit timeouts, but the end 
user experience is poor - it might take the ATA a few seconds to start the SIP 
session after the last digit is dialled.  Assuming that the ATA doesn't do ENUM 
dips itself, the existing alternative would be for the ATA to establish a brand 
new SIP session after each digit is dialled, receiving a 484 Address 
Incomplete error from the CP switch until the number is complete.

With Send-N metadata available, the definition of the SIP 484 Address 
Incomplete could be extended to return the Send-N data so that an ATA can 
benefit from this information and omit unnecessary SIP session establishments.

Regarding this sentence:

Maintaining that synchronization, however, requires that the
 DNS have semi-real time updates that may conflict with scale
 and caching mechanisms.

As Jon pointed out during the ENUM session at Maastricht there is indeed a need 
to synchronise the metadata with the underlying data.  However number plans are 
not generally prone to sudden unexpected changes.  In any event with Send-N the 
only identified synchronisation issue is when a Send-N record indicates that 
_more_ digits are required than is actually the case.  Since it is very rare 
(if not unheard of) for number blocks to get smaller I don't consider this a 
significant risk.

The assertion therefore appears to be unjustified.

And finally, regarding:

It is unclear why this data is better maintained by the DNS
 than in an unrelated application protocol.

If a device is performing an ENUM dip hoping to find a contactable SIP URI, it 
is simply most efficient for the ENUM response to directly include the Send-N 
metadata when needed rather than have separate queries using a different 
network protocol.  Also, the hierarchical and distributed nature of the DNS 
protocol makes it an _ideal_ structural fit for this meta data.

I believe the onus should be on your draft to explicitly identify valid 
technical reasons why the DNS protocol should _not_ be used, rather than make 
vague hand-waving assertions which appear to have little or no justification.

kind regards,

Ray

[*] the draft misdescribes overlapped dialling - it's the practise of sending 
digits to the network as they're received rather than en bloc at the end of 
dialling.  It's what analogue phones do, and is completely separate from open 
number plans.

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


Re: draft-iab-dns-applications - clarification re: Send-N

2010-10-20 Thread Ray Bellis
 Such a mechanism simply does not work when:
 
   draft-iab-dns-applications-00
   In these
   plans, a telephone switch ordinarily cannot anticipate when a dialed
   number is complete, as only the terminating customer premise
   equipment (typically a private branch exchange) knows how long a
   telephone number needs to be.
 
 where even telephone switches (thus, telephone operators) do not have
 any knowledge on how many numbers should be dialed.

It is for this reason that Send-N specifies the _minimum_ number of required 
digits, not the exact number.

Ray



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


Re: IETF Attendance by continent

2010-08-09 Thread Ray Bellis

On 9 Aug 2010, at 16:12, Andrew Sullivan wrote:

Since we're providing anecdotal data, I'll mention that for me the big
central room in Maastrict turned out to provide far greater
cross-fertilization than I got in Anaheim.

+1

I actually thought the Anaheim venue was really poor for this, and liked having 
that large _seated_ communal area full of IETFers at the MECC.

Ray

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