Once again, the starting point was a simple oval.
Author: otmar
Today I gave a talk at the ISPA office concerning DNSSEC. See here for the official announcement.
Attendance was good, we had interesting questions and a lively discussion.
You can download my slides in pdf format.
Categories
All the king’s horses …
… and all the king’s men, couldn’t get Clemens’ bread together again.
Categories
Nokia 6120 Classic and A1 Broadband
When I got my company cell-phone two years ago, I opted for a Nokia 6120. The reasoning was simple: Nokia was supposed to have a decent user-interface, the phone could act as a 3G modem for my laptop and run various simple applications like Avantgo.
Well, …
The razor business is said to have premiered the following business model: Sell the razor really cheap, but charge a lot for the blades.
Seeing the same in IT isn’t unusual, the prime examples are Inkjet printers where the printer is ridiculously cheap, but a new ink cartridge costs almost the same as the printer.
Cisco memory is another example.
I just noticed the same with HP’s new entry-level 1U server, the HP 120G5. We bought one for evaluation purposes for slightly above 500 €. Seems like a decent hardware: 1GB RAM, a Xeon processor and a single SATA harddisk. No frills, no chrome spoilers, just a straight forward server.
But: no on-board remote management. That would be extra. You need to buy the HP DL120 G5 Lights-Out 100c kit. We just plugged one of these into a DL 180, where we really need it. It’s a very tiny card. Just a PCI-E slot, a RJ45 jack and a single chip:
The price: ~ 200 €.
Sheesh.
Categories
Buying shoes for kids
The feet of kids are delicate things and as a caring parent you’re supposed to make sure that the spawn’s footwear fits his ever-growing feet. Ok, spring is coming and thus the time is near where we can stop using his #24 winter boots and give him “normal” shoes again. So off to the store we are and what do we find?
At the end of February, the shop is already geared towards summer shoes. i.e.: open shoes and sandals. Great. That’s about 2 to 3 months in the future.
That stocking policy might make sense for shoes for adults, but for kids? The size of their feet is highly variable. You buy when you need the shoes as you want to size them correctly.
So dear shoe industry: what’s fine in the woman’s section of the store does not make sense in the kids section. There, “just in time” shopping is much more appropriate. Please stock accordingly.
I’ve written about this already a few times in various IETF / RIPE lists, but it seems to be relevant to the current draft as well, so here is a repeat:
According to the usecases draft, SSPs report the public identities of their customers to the registry so that the registry can store the mapping to destination groups. All fine and dandy for TN based public identities, but what about sip:user@domain?
These URIs come in (at least) two flavors:
a) the domain is the provider’s domain (e.g. “verizon.com”)
b) the domain is owned by the customer (e.g. “shockey.us”)
The first one makes it easy for the SSP to authoritatively tell the registry that it provides service for whatever URI it is going to provision. So from the point of drinks, this is easy.
[I still very much doubt that solely offering such PIs to customer is dangerous to the SSPs as they might be forced to offer PI portability, which would really mess up a lot of assumptions.]
So what about b)? Portability is a given, and ISPs are used to deal with customer-owned domains for email and web. Good. So what’s the authorization mechanism? For email and the web it’s simple: the entity which controls the domain must set the respective MX and CNAME/A records so that the rest of the world know who provides email/web services for this domain. If the control over the domain changes, so does instantly change the control over email and the website.
Now, if a SSP can provision any URI regardless of the domain ownership status / domain content, this opens up a pandora’s box of interesting errors. We now duplicate who operates SIP service for a domain in two databases which can and will run out of sync with each other.
I consider it thus a lot more in line with the rest of the Internet protocols to store the mapping domain -> destination group in the DNS and not some other registry.
Richard wants feedback, so here it comes.
This document is a _lot_ better than -01. Much more consistent.
Overall impressions:
-
This is a telco design. Basic bell-head thinking with only some marginal sprinkling of Internet ideas. This is a document which describes how one might carry over the telco provisioning, interconnection and call routing approaches to the VoIP world.
All fine and good, but to be provocative: why is this an IETF WG document and not an ITU-T, OASIS or 3GPP paper? The role model, the actors and a most use-cases are almost straight from the PSTN playbook.
- This is way too ambitious on one hand. Defining all this in a single protocol and implementing the registry which actually does all these things is a herculean task.
Layering, folks. Layering.
Divide the problem into discrete, clearly separated sub-problems (see the speermint LUF/LRF split for a good one) and the complexity can be brought under control.
- This is way too conservative on the other hand. There is little dynamic routing. There is no integration of enterprise VoIP routing with carrier routing. There no possibility of ad-hoc peering.
Okay, some specifics:
Categories
Windows XP: Doh.
Letzte Woche:
Verarschen kann ich mich selber.