Re: IETF Attendance by continent

[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

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

[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

[Ray Bellis]

> Such a mechanism simply does not work when:
> 
>   
>   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: draft-iab-dns-applications - clarification re: Send-N

[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

Re: whine, whine, whine

[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

[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: whine, whine, whine

[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

[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: [IETF] back by popular demand - a DNS calculator

[Ray Bellis]

On 21 Feb 2013, at 02:46, Carlos M. martinez 
mailto: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.



Ray

Re: Deployment of standards compliant nameservers

[Ray Bellis]

On 21 May 2013, at 02:44, Keith Moore  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: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard

[Ray Bellis]

> I can certainly see where it would be useful. However, I question your 
> comments in Section 9 of your draft: specifically that URI should be viewed 
> as a replacement for SRV. URI (may) make sense for "resource" discovery, but 
> I don't believe that is true for "service" discovery - I think SRV still 
> makes the best sense for that.


IMHO, that depends on the service.

In RAI we have "LoST" and "HELD", both of which are HTTP(s) based services 
contacted through a URI.

A "URI" RR-based solution for discovery of those would, I think, have been 
cleaner than the current U-NAPTR based methods.

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher, Nominet
e: r...@nominet.org.uk, t: +44 1865 332211




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

Re: Requirement to go to meetings

[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: Plagued by PPTX again

[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: Plagued by PPTX again

[Ray Bellis]

On 15 Nov 2011, at 16:26, Bob Hinden wrote:

> +1

The Datatracker does officially support PPTX, so I don't believe it's 
unreasonable to use it.  If you don't like that policy, I'm not sure where you 
would take that up.

It also hadn't occurred to me that people might actually prefer PPT over the 
more open PPTX format.

I've also noticed that you can get problems when exporting to PDF using Office 
for Mac 2008.  It mangles ligatures when you copy&paste the PDF contents into 
something else.

Ray

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

Re: Plagued by PPTX again

[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: Consensus Call (Update): draft-weil-shared-transition-space-request

[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: ITC copped out on UTC again

[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: Evil bit (RFC3514) finally implemented

[Ray Bellis]

On 1 Apr 2012, at 15:36, Martin Sustrik wrote:

Hi all,

During yesterday's takedown of the Internet [1] it has become painstakingly 
obvious that the ability to distinguish malicious packets in a quick and 
efficient manner is one of the most pressing security concerns of today.

Thus, RFC3514 (a.k.a. "evil" bit) [2] support was implemented [3] in the Linux 
kernel today.

It is our hope that other operating systems and network devices will follow the 
suite soon and help us make Internet a safer and more welcoming place for 
everyone!

Hey, they can't do that!  I've got a real use for it...

See 
draft-bellis-behave-natpresent-00

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

Ray