Orbit

good mornin' thomas,

...

my memory of the discussion at the meeting was o there is precedent for apnic doing this

What precendent, other than the IPv6 prefix?

that's it.

the perception seemed to be that it worked.

This sort of global reservation is best made by IANA (at the request of someone). We have lots of examples/precedent for that. The IETF is the logical place for the request to come from.

that last is not completely clear. it's at the border between ops/rirs and tech/ietf.

...

o for it to have global/formal effect, there probably should be an rfc directing the iana

If APNIC makes the reservation, IANA can only record what APNIC has done after the fact.

as it did with the v6 documentation prefix. this is perceived as having worked.

...

o but an apnic allocation would do in the long meantime

I disagree about the "long" part. The IETF can do this quickly too.

( i will keep my mouth shut. i will keep my mouth shut. ... :)

Also, it wouldn't be a "meantime". Once APNIC makes the reservation, it cannot be revoked, since the vendor might have already put bit into documentation.

is there a problem with this? is it a bug or a feature?

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?

randy

hi thomas,

< 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