[ppml] Directory Services - Take 2
Ed.Lewis at neustar.biz
Fri Jun 10 14:05:03 EDT 2005
>> As often comes up in policy review, sometimes specific implementation
>> details, in this case media type, shouldn't be written into a policy.
>> I agree that the media types should be limited but I would trust the ARIN
>> staff to determine which ones they can easily support and make that list
>> available publicly. The list is bound to change over time and it
>> shouldn't require a policy change when some fabulous new format becomes
>> available... :-)
I'm for this too, when writing a policy I agree we want "service in"
and "implementation out". (Which is why I also balk at all the
detail in the text about non-responsive contacts.)
The reason I raised IRIS (repeatedly, to the point of beating the
proverbial dead mule) is that I think there's a bit of
chicken-and-egg going on here. Not in the need for clients and
servers, but in the way the IETF works.
The IETF works on volunteered actions from the community. ARIN is
ideally suited, as much as any organization in North America, to
volunteer the knowledgeable resources to push through the
specification for IRIS's address registry. (The doc in question is
ARIN can't "ram" this through the IETF, but the membership should
keep participation in this a priority.
IRIS isn't the only engineering concern, it's one of many. If we
don't use policy to track engineering efforts like this, what do we
use? (That was the question I posed during the open policy bof in
Orlando.) How do we indicate that ARIN spends time and effort on
helping IRIS through the IETF process as well as helps provide the
servers and clients? (Note: "provide" does not mean the staff
implements and maintains the code. It *could* mean that the budget
has money set aside to fund the development.)
Edward Lewis +1-571-434-5468
If you knew what I was thinking, you'd understand what I was saying.
More information about the ARIN-PPML