Re: [sig-policy] last call: prop-061: Autonomous System Numbers (ASN) fo
< chair hat off >
< sense of humor on >
>> the perception seemed to be that it worked.
> Sure, we ended up getting a documentation prefix, but that doesn't
> mean that the path that led to the end point was the best one...
and here in a nutshell we have the difference between ops and the ietf.
it was not ideal, but it worked and did no damage.
>> that last is not completely clear. it's at the border between
>> ops/rirs and tech/ietf.
> Agree there is room to argue, but there almost always is. :-)
i am married. :-)
> IMO, the question is whether an individual RIR is the best place to
> be making such a reservation or whether there is a more appropriate
> place.
imiho, the question is whether an individual rir is a sufficient and
working approach and does not do damage. i just have to move packets
and can leave perfection to the ietf.
> And I also have to ask, if this type of request is within-scope for
> APNIC's PDP, just what exactly are the scope boundaries? Anything the
> community thinks it should take on is OK? Are there no limits? (Be
> careful what you wish for...)
< chair hat on >
first, as co-author, with anne, of the pdp itself, it is a *process*.
the scope of the applications of the process are a separate issue. i
agree that the scope of the policy sig is a worthwhile discussion.
< chair hat back off >
in this case, i would guess the submitter(s) felt that this was an issue
of allocating a resource outside of existing policy, so it was perceived
as a policy issue.
i suppose an alternative argument could have been that it was a purely
operational issue and the rir registry could have just allocated it. but
i suspect the apnic registry wanted the community input.
i also suspect that folk felt/feel that some sort of community consensus
was desirable, so used the policy sig as the venue for consensus. and,
as far as i can tell, most of this community does not think of the ietf
as a venue for discussion and consensus of this community.
and it is not clear that the ietf needs to be involved in operational
details of resource allocation. many folk still have deep scars from
the years of battle it took to get tlas/nlas/... out of the ipv6
specification.
i believe that the iana reserved ipv4 prefixes (rfc 3330) were done by
the iana, not the ietf. so none of this is really clear.
>> as it did with the v6 documentation prefix. this is perceived as
>> having worked.
> Depends on your definition.
a documentation prefix became usable in documentation. i know this is a
very operational view. but this is an operational community. and i
actually touch routers.
> In that case, just like in this one, there was (to my knowledge) no
> attempt to raise the issue within the IETF first. The IETF works in a
> demand-driven mode. If no one points out the need for something, it
> won't happen on its own.
and this is a bug, a feature, or irrelevant? a documentation prefix was
needed. one was created. it worked.
that the ietf did not perceive the need is not this community's fault.
when this policy was first proposed, if the ietf thought its job was to
meet our needs, and the ietf wanted to be pro active, the ietf could
have said "wow! thanks for catching this missing thing. we'll get this
done by XXX date." it did not; probably too busy fighting with the itu
to worry about operators' needs:-). luckily, this is only a problem for
the ietf, not for the folk who need the allocation.
>>> http://tools.ietf.org/html/draft-huston-as-documentation-reservation-00
>>>
>> so we have the volunteer. folk did look at him with expectation.
>> so what is actually broken here? ietf's tosies being stepped on?
> Of course it is an issue of turf. And if the IETF took on a task that
> an RIR felt was more appropriately theirs, they would object too.
> (Or grumble quietly, or something.)
>
> I'll grant that in this case, the issue of where the work gets done
> is relatively small, since there is general agreement on the
> technical solution. But a precedent is being set. Sometime in the
> future, that precedent will get cited in a case where the stakes may
> well be higher. And then the principle may well matter a whole lot
> more. And the spirit of cooperation in effect between the respective
> communities will come into play.
>
> It would be nice to sort out the scope issue while we have a proposal
> in which there is general (overwhelming?) agreement on the technical
> need and solution. I'd hate to have to also sort out the scope issue
> when the issue itself is complex as well.
well, as an engineer, i judge by results. the apnic process to make
usable doc asns should produce them around the end of october. when do
you think the ietf/rfced/iana processes might produce an operationally
usable result? we do remember the shocking and deeply frustrating lack
of speed with which the ietf handled four byte asns in the first place.
one view might be that, with geoff volunteering to push the ietf path,
we have an ideal cooperative solution, asns we can use in a month and
the ietf, rfc editor, and iana processes grinding away to produce their
style of procedural wrapping in the long term.
on the other hand, if you said that the ietf/rfced/iana would give us
usable doc as numbers this year, my guess would be that folk could be
convinced to take the view that you've saved us some effort.
randy