I don't see a problem with people not assigning customers /56s so long as they go in the correct direction and give /48s and not /60s or /64s.
Many ISPs will end up handing their customers /64, /62 or other less-than-ideal prefixes. As soon as a customer needs to subnet their /64, the real fun starts. There is nothing we can do about it, other than trying to educated people and hope for the best.
If we educate a sufficient percentage of ISPs and solve the perception problems of the RIR policies that are driving some ISPs to be overly conservative (see proposal 121 in the ARIN region for an example of what I think represents a reasonable solution), then, the other ISPs will eventually find themselves at a competitive disadvantage as their customers start to ask "Why can't I have a /48 like my friend Bob got from provider Z?" This is a good thing, but, it means we need to do what we can to educate as many ISPs as possible as quickly as possible during this critical phase of deployment.
I honestly think I never explained (as in, after I understood the matter, myself) netmasks other than as a bit vector. Unless you mean "write 255.255.255.0 in there cause that's what right for you".
Then you are young and never had to deal with systems that didn't know about bit-vector syntax. I have had to explain the translation between bit-vector syntax (/n) and bit-field syntax (255.255.255.240) to many people. It's easy when n is a multiple of 8. After that, it can be quite hard for some mathematically challenged individuals unfamiliar with binary and BCD to wrap their heads around.
I wish ;) Either the person can grasp that a dotted netmask can be transformed into a bit vector or I tell them "use 255.255.255.0 everywhere, it will work for everything you will ever need." 80/20 and all that.
Ah... OK... Sorry, I'm the guy that had to deal with all of your users when they found themselves on one of my /27s and tried to use 255.255.255.0 there. :p So... Don't worry, I ended up picking up the educational task where you left off. (OK, maybe not the exact same set of users, but, honest, you're not the only one who took this approach and it did lead to interesting breakages by users so educated in a number of places I have worked.)
Removing bitmath from operations where possible is a good thing that reduces outages caused by human factors. It's just good human factors engineering. We can't do so in IPv4, there aren't enough bits to do it. We seek to do so in IPv6 with ARIN draft policy 2010-8 and proposal 121.
If by bitmath you mean ending netmasks not on full bytes only, I could not agree more. This will reduce a lot of useless overhead. I really wish the RIRs would get unique a name space for their respective drafts. If even my person object needs a -RIPE suffix, I don't see why drafts etc don't.
Well, in IPv6, I think ending them on nibbles is fine. Specifically, see ARIN Policy Proposal 121 (as mentioned above).
Should we all sing kumbayah now?
Only if you bring a tambourine.
LoL Sorry, I don't own a tambourine. Owen