in conjunction with APRICOT 2013

Transcript - Policy SIG Session 2 (Informational Presentations: Thursday 11:00 - 12:00)

Disclaimer

While every effort is made to capture a live speaker's words, it is possible at times that the transcript contains some errors or mistranslations. APNIC apologizes for any inconvenience, but accepts no liability for any event or action resulting from the transcripts.

Andy Linton: I am pleased to see we have been able to get the wireless connection done successfully.

Next door, they told us the wireless worked very well. I'm really not surprised at all. That's great.

This is our second session of the policy SIG. Again, we have some informational work to get through this morning. Then this afternoon we will look at the two policy proposals we have in front of us.

It looks as though we have three items on the agenda, but there is a fourth one which everybody is busily typing, so we will get it up shortly. We will have another item on there, further work of discussion and stuff about the PDP, which I'm going to talk about.

I'm watching Adam to see if he's ready to do his bit. Adam is putting the agenda online.

Adam Gosling: I will present if everyone waits for the agenda item.

Andy Linton: This is looking at what to do with the documentation.

Adam Gosling: At the last meeting, I asked for community support to undertake a couple of activities, and this is the list of them.

I want to look at the editorial policy, look at the archives, merge all the resource policies into one

document, and look at maybe changing the document format.

I am going to report on the status of those. I am going to do it out of order, though.

Single policy document -- this is a bit of background and I will try not to make it too boring.

When I started this project, there were three main resource policies. We did some major work on the IPv4 document, primarily to take out duplicated content that was in all three policies -- things like definitions, the objectives and goals of the documents and resource management -- because they were repeated in each document. So I thought, if we take them out and have one overriding environment document, it would make the IPv4 policies and IPv6 policies and ASN policies much smaller documents that were easier to access. At the end of the day, I have gone completely the reverse.

It seemed like a good idea at the time. I did the v4 document and it was published in draft and it is the policy as it stands today. I also did the rest of the work on the slide but never had the opportunity to present it to the community.

It was better, but a couple of things happened. I spoke with APNIC's legal counsel and other people who had an interest in the documentation, and at one

particular point, I was asked to begin the training for the new IRINN staff, the new NIR in India. To do that, I had to run through every policy APNIC had, and I wanted to put them in a Word document, and put them together. It took me ages, I had cut and paste off the website and put them together, just to get a policy manual for APNIC.

It became apparent the first slide in this pack was wrong. We don't have just three policies, we have the transfer policy, the historical resource policy, so this is what we have at the moment, which is not ideal. So this is what I have done.

It is quite a lengthy document. But it has removed most of the repetition. There is some repetition that is inconvenient to take out, but it runs to 30-plus pages, but it looks quite nice. It is ready to go.

I am not quite sure what to do with it now. I have done this document, it is sitting on my hard drive. The adoption of the document as I understand it is not a matter for the policy development process, it can be changed under the document editorial policy, which would require me to publish it as a draft for one month, consider the comments that came back, and then it would become the document. It is such a big change, I am a little hesitant to go that way.

Most of you are busy people and have real work to do, and reading a 36-page document in one month is probably -- there could be significant comments as well.

I am going to propose three months. The document editorial policy doesn't allow a three-month comment period, so what I'm proposing to do is to kind of informally post a link to the list, to the mailing list, not publish it in the draft section of the APNIC website but put it out there and say, if anyone wants to look at it for a couple of months, I'm going to put this up as a draft in two months' time.

I am going to also put it up as a PDF, make available the PDF version, so you can have it on your iPad and also put it up as a Word document, so we can track the changes for it.

I am not going to prepare it as a text document or put it up as HTML until the two months is up. If there are substantial changes to it, I don't want to have to recode it in HTML and renumber it; it is all in a nice Word document and renumbers itself if I change it, so it will be a lot easier for me -- if that's okay with everyone.

The other things I was looking at doing: I asked to start a review of the document editorial policy. Just a little bit of history on this document. It was

originally proposed by Gerard, who had left APNIC by the time I got here, but I'm sure some people in the room know him. It was prop-002, the PDP was prop-001, and there is the link to the official document. It reached consensus at APNIC 16 and was endorsed on 24 December, implemented that day and put out for its own editorial review, under the terms -- it used its own process to do the editorial review.

It is a policy document and it requires a policy proposal in order for it to change.

One of the things I wanted to do with it, starting at the bottom, my initial reason for wanting to review it was it stipulates that the canonical, the official policy document, is a text format document. We will look at the archiving of this a little later. It is like doing ASCII art, when you are four dot points in, and going space, space, space, space, any structural changes to the document are incredibly hard to implement. I am trying to get away from this because it chews up too much time. I will come to that again later.

In looking at doing a review of the documentation editorial policy, there are a couple of other things that have come out of the woodwork.

The policy itself starts off in its introduction and

scope mostly saying that this editorial policy covers the implementation of APNIC policies. But it also describes the numbering of the documents. Because the secretariat wants to keep some documents that are numbered, so that people can version them, and you know you are using the right document, but they are not really policy documents. So one of the things I would like to -- in its review, I think it is clear we need to do some work around the definition of what is covered by the policy itself.

It is something that is a little sensitive, because you have to make the definition very clear. The idea is to allow for some documents to be changed easily, without having to go through the draft editorial process, and bothering you all with this kind of email, "This document has changed because we have put in a full stop", or whatever.

The other part that is problematic about the policy is that the only two reasons you are allowed to enter into the process, into this editorial process, is either to implement a new policy or correct an error. It doesn't accommodate other reasons why you might want to change. I won't go into those because they are many and various. Also the other issues, the secretariat feels that some changes to documents don't actually require

editorial review because they are not complex; there is no semantic issues to be discussed.

We are kind of thinking that some of these numbered documents that are still official and still need to be versioned have a different stream, a different publishing stream, where they are announced to the community that there is a new version of blah, blah, blah, document, but it doesn't have to go through the form of one months or four-week review period, it can be just implemented on the spot. Moving on, a different document format may still be appropriate, but I will come to that later.

The status of this is, can we have a little bit more time to work on it. I want to take more input from legal counsel and more input from Services. As I will touch on later, there are other people who are impacted by any changes in this; it is not just a policy area because there are Services documents, there are EC documents that are all numbered and are impacted by this. I just need to move a little more slowly on that.

The document archive is in the ftp. I went through this in detail at the last meeting so I won't go through it in detail too much now. Most people probably don't know the official documents are kept on the ftp server, and they are kept in multiple versions. There are

actually five copies of each policy. I should correct that -- there are five copies of each numbered document.

It is differences like.txt and not.txt, the archived version and the current version. Those are on the ftp server.

Then there is a HTML version on the website and another text version, so we end up with five. There is also allowance in the editorial policy for Word format or PDF. The reason for the PDF particularly is that sometimes in the fees document we have complex logarithmic calculation, which is hard to do with ASCII art, it looks a lot better in a PDF. There are other layout reasons. There are not many documents that fall into that category but there are a couple.

I was sick of doing all this work, frankly, it takes a lot of time and I thought this is not a good use of member resources. However, if I only have one big policy document, I don't have five copies of each policy, I have five copies of one policy. So I think I need to -- as you can see, the status is "on hold" -- I need to talk more about this as part of this editorial policy review. Because, as I have just mentioned, other stakeholders might be affected.

There is also another issue there, which if you were in the last session, Frank did a presentation on our

ISO 9001 project. I'm not involved in that project directly so I'm not sure how likely it is, but there is an outlying chance there might be a document management system as part of that. That would impact on any decisions I made in the documentation area. So I am on hold on that and will report back next meeting.

Alternate document format. I have touched on this. Again, because there is a single document, it is less work, if I need to make changes to transfer policy or IPv6 policy, I am only adjusting one document, which means less work and less reviewing on the drafts pages.

What I'm proposing for the single merged policy document that I plan to put out for comment for two months and then an official draft for one month, is to publish it in HTML, in text and in PDF. So if I go through that process, then that becomes the resource policy manual for APNIC, it will become the official document, and I will publish it in txt, to stick with the current editorial policy, and it will be the official one.

If the editorial policy changes at a later date, I won't have to touch the txt again, perhaps. I will put it in HTML, like the way most of you probably look at the documents at the moment, I will put a txt version on the ftp and I will put a PDF document, if anyone

needs to train NIR staff.

That is kind of reserving judgment until after the editorial review goes ahead. It kind of looks like this: I don't know how many people are aware of this work. This is work that APNIC manages on behalf of the NRO and whenever, on a quarterly basis the policy people in each region are asked to review this document. The document is published as HTML with an attached PDF version.

What is the document? That is probably the important bit. It is a comparative policy matrix of all the policies from all the regions. So it says, this is 2.1 as an example, it as AFRINIC, APNIC and ARIN and you can see what their policies are in shorthand. If you want to know the difference between the AFRINIC and APNIC initial allocation, you can go to the website and look at the document, and it is updated quarterly. It may not always be the absolute latest implementation of policy but it is usually pretty close.

That is the HTML version. There is a PDF version that does exactly the same thing, it has the same content. I think it looks quite good. This is how it is presented on the page, so it has its own archive on the web page. If you want to go back to June 2011, it is very easy.

Most people probably don't need to understand how these documents have evolved -- not so much these NRO documents but the APNIC documents, I am often asked, "When did IPv4 policy change to implement this, and why?" I have to go back and do a document compare and trace back through the ftp and compare all the documents to see which changed in which version and when it was, then refer back to the proposals index and say, "That changed because of prop-23 back in 2005."

It is work that I love doing but it is probably not always the most effective use of my time. I think maybe I haven't come up with a solution, but maybe some kind of change log or something like that might make it better.

Before I go on to that, some of this -- I have come to this policy role fairly late in the development of policies at APNIC. A few meetings ago, we would have had a dozen proposals, this time we have two, and last time we had three. So the pace of change in these documents is not what it used to be.

My need to do this is probably not as much now as it was when I started the role, but I still think it is work that is well worth doing because, once it is done, if there are very few changes to the policy, that is a good thing and it is in a nice format that everyone

can use.

That is my update on what I talked about last time. I have just a couple of slides.

Interestingly, the policy development process policy, section 4, step 1, "The APNIC secretariat will recommend a preferred proposal format."

At the last meeting, some of you will remember we had a bit of a discussion about the policy development process as a result of prop-103. Part of that discussion was that we need better problem statements in the policy proposals. Some of them are a little bit hazy. It makes it very difficult to understand what people are trying to achieve from the change.

So I am recommending a new proposal format. The changes are minor. I will post it to the mailing list -- again -- for comment.

I have just kind of changed the names. The structure hasn't really changed, I have changed the names. "Author" becomes "proposer". My reason for this is that the Chairs would like more opportunity for themselves and for perhaps the mailing list to develop the problem statement and the solution to that on the mailing list.

I have notes in the proposal template that I haven't included here, because it is a lot of content. I am

making it so that you can submit a proposal with only a problem statement. You don't have to fill in the rest of it. Then the chair can look at it and say, "Okay, we can see this is a problem, it is in scope, we are going to put this to the list," or maybe the Chairs can work with the proposer straight away.

I want to get away from this idea that they are the author of the document and they are the ones required to fill in every part of it. Maybe it is better as a community effort.

Basically, it kind of goes problem statement, what is a simple explanation of your problem, what are you coming up against in the policies? What's it going to look like when you have fixed the problem, basically? This allows perhaps a less formal explanation of what you are trying to achieve.

The proposed policy solution, in the actual template it talks about this section must have a specific change in mind. Sometimes we get proposals that go through the consensus period and get to EC endorsement and land on my desk for implementation and I say, exactly how is this supposed to be written up, what will it look like in the policy document? Sometimes it requires the secretariat to make judgments that we are sometimes perplexed about how we do it.

I think maybe an example of this came up in the transfer, the change to the needs requirement period in the transfer policy from -- I have forgotten the number -- that I reported on yesterday, where the needs requirement period -- in the initial transfer proposal there was no specified time of how long you could demonstrate your need for. The secretariat said, "Well, it's 12 months for normal v4 allocations, we will just take 12 months and do that."

Then another proposal said, it's not specific and we would like it to be 24 months. That is pretty clear, so that goes through the consensus process and everyone is comfortable with it, then we come to implement it and we say, we do pre-approvals, which is an operational secretariat thing, do we change the validity of the pre-approval to 24 months as well?

Some of these things, it would be good if we could get better clarity. If you look at the PDPs in other regions, say ARIN, for instance, their PDP process ends up with very specific text that is just cut and paste from the proposal into the document. We maybe can't do that because of the language issues some of our authors or proposers have, but it is something we should try to be more and more specific about.

The rest is kind of the same, pros and cons and

lists of advantages and disadvantages.

That's all I have to say. Are there any questions or comments?

Andy Linton: Thanks, Adam.

Dean Pemberton: I think the proposed changes to the policy template will definitely assist in that kind of drawing out the problem statement and the collaboration on the problem, on the mailing list. I would fully support those changes. Well done.

Adam Gosling: Thanks very much. As I said, I will put this on the mailing list, it is open for comment and I'm more than happy to take any feedback and try to incorporate that.

Andy Linton: Any other comments?

Emilio Madaio (RIPE NCC): Emilio Madaio from RIPE NCC, Policy Development Office. A question related to the project, to update the implementation guide, there may be something I missed or something that is obvious. I wanted to ask you: you intend to have one single policy manual, so to speak, and you want to keep the past and future global policy in the same manual or as a separate documentation?

Adam Gosling: When you say "global policy", you mean the merged policy, you don't mean IANA policy?

Emilio Madaio (RIPE NCC): For example, the last one we

approved in all the other RIRs for the post-exhaustion allocations.

Adam Gosling: No, I wasn't planning to include the IANA, so the next level up, global policies in that document. Currently APNIC doesn't publish those at all. If you want a copy of them, you go to the IANA site or the ICANN site. Are they on both? We don't keep a local copy, if you know what I mean. I don't know whether anyone has a comment on that, it is something I have wondered about, because I notice other RIRs do keep it because it is part of the policy hierarchy and it has a relevance. If anyone has any opinions on that, I'm happy to listen to it.

Emilio Madaio (RIPE NCC): Every global policy has been discussed in every RIR community, so it should be archived in every RIR.

Adam Gosling: Obviously, our version of the global policy -- the proposal is in a proposal archive and all the action items and everything, but the document itself is not published as a policy.

Emilio Madaio (RIPE NCC): Just to confirm your answer, you have one single documentation for the regional policy, and every other global policy would be separate?

Adam Gosling: Almost. I have one policy manual for the regional policies and nothing for the global policies.

If anyone thinks this is something we should have kept locally -- because while they come from us, they are actually IANA policies. Maybe there has never been a decision to not publish them; I think no one has ever thought this is something we should do. I have thought it but couldn't kind of feel that we really needed to. I don't know.

Emilio Madaio (RIPE NCC): Thanks.

Andy Linton: Anyone else? I have a couple of observations of things I noticed in here.

You say the original document policy was 2003, I think that was the date.

Adam Gosling: Yes, maybe implemented in 2004.

Andy Linton: So that is 10 years we've had of the document having been reviewed, the proposal and also document scope creep, to give us the six or seven documents. Is this something we should build into our future policy, that we should have a periodic review of this stuff and make sure things are in a proper state, rather than let it get to a very -- I'm not saying it is chaotic, but get to the point where you have to do it?

Adam Gosling: Yes. Interestingly, in the document header, where it says the document title and the number and the version and everything, there is a space in there for "Next review is due". But I don't think

I have ever seen one that has been filled out. It could be easily done. How would we decide how often to review it?

Andy Linton: Again, I think that is one for the community to think about. Just because a review period comes up, if everybody is happy as it stands, it doesn't mean it has to be changed, it just means you have the opportunity.

Adam Gosling: Again, you might not want to do it with all the documents -- there are still a lot of them floating around as forms, and as part of that process some of them might be taken out, but they still need to be numbered. Certainly it is something we can do, if we had some kind of clarity on which documents and what time frame.

Andy Linton: Okay, that's great. No other comments or questions?

Adam Gosling: Thank you very much for your time.

Andy Linton: I expect to see this on the list. I'm not going to ask people if this is a good idea. I think it needs to go to the list. Does anybody have any objections to us putting this to the list? No.

I think this is stuff we need to discuss, to make things work for us. Put it out there.

Adam Gosling: Yes, into the community. Thanks very much.

Andy Linton: Thanks, Adam.

Our next question -- it sort of leads into this -- the last thing sort of leads into this, because Adam is suggesting there is something in one of our policy documents that needs to be looked at, and Dean has information about the role of the secretariat in the policy development process. Without the secretariat there wouldn't be much point developing policy, because they make stuff work for us. Dean has a couple of observations on that.

Dean Pemberton: If we look back in time, at one point it was not unusual to have members of the APNIC secretariat propose policies under the APNIC PDP, the documentation prefix for AS numbers and the original IPv4 transfer policy being examples of that.

The present situation, it is not entirely clear if it is still acceptable for members of the APNIC secretariat to bring policy proposals to the wider APNIC membership for discussion under the existing PDP. What I mean by that is that it is not immediately obvious whether Adam or Sanjaya or whoever could become a proposer of a policy under the existing system.

I want to get some clarification around what the existing situation is and then whether that situation is still the way we want it.

What would be the advantages of clarifying this and allowing APNIC secretariat to be proposers? APNIC Hostmasters and secretariat members are in a unique position of dealing with the implementation of the policies on a day-by-day basis. They see where the rubber hits the road. If there are problems with policies or there is problematic activity around things, then it is going to be first noticed by APNIC secretariat members.

Sanjaya's update yesterday had a section about interesting observations that had been seen around the IPv4 transfers, but it is unclear about whether there is any ability to then turn that around into the PDP without getting a non-secretariat member to be the proposer. So that is really where I'm asking for clarification.

Also, enabling them to engage is a positive way to bring these problems and associated solutions to the members; with advantages comes disadvantage, otherwise you are not being balanced.

It could be argued that a level of separation be maintained between the APNIC secretariat and the policy development process. It could be argued, but I believe that the PDP is a robust member-driven process and I don't think there are concerns with proposals being

initiated by APNIC staff because it is not going to be purely the secretariat members that are going to decide on this. I can't imagine we would want to change the PDP so substantially that we wouldn't still have a room like this of the community to discuss any proposal brought up.

All proposals would still require consensus from the APNIC membership before they were implemented. This has parallels in the external world as well. New Zealand public servants, for instance, are perfectly able to propose changes to New Zealand Government policy. They do not, however, play a role in the decision-making process around whether that adoption is made, and we may want to consider whether secretariat members can be proposers of policy but then whether it would still be appropriate to have them considered in terms of consensus. These are all things I want to get back from you guys.

What are the questions I want us to discuss today? This is really where we find out whether this presentation is a lightning talk or a 90-minute tutorial. Is it acceptable for members of the APNIC secretariat to author and/or propose, and going by Adam's clarification on the template, I can take author out. Is it acceptable for members of the APNIC

secretariat to propose policies under the current PDP rules? I don't think that is clear at the moment and I want to get a feeling from the room around whether that's acceptable today.

If yes -- if it is acceptable today but we don't currently do it, would allowing them to do it require a policy change or would it just require us to say, "Yes, no worries, it's not against policy and it's something that as a community we would encourage."

If it's not acceptable then I want to discuss a more appropriate way for APNIC secretariat members to highlight any policy issues. The current way it happens, where someone notices something and has to find a member of the community and convince them that it is a good idea as well, then they become the proposer and all that sort of stuff; I think that has problems with openness and transparency.

I think, if we don't think it's appropriate for APNIC secretariat members to be proposers then I think we may want to think about a more appropriate way for letting them highlight policy issues.

That's all I have. But I really want to take some feedback from the floor on these issues.

Geoff Huston (APNIC): Geoff Houston, APNIC Secretariat.

Dean Pemberton: Welcome!

Geoff Huston (APNIC): Of those three policy proposals you put up, I note I was a co-proposer or the only proposer on all three. At that time, I must admit I, and I think many other folk at the secretariat at the time, felt that it was okay to bring forward issues that we thought were germane and relevant, and not only propose but actively discuss. It was part of the community process of saying, this is an important issue, we think there are policies here that would help, here is our proposal, let's talk.

These days, I feel a lot more constrained, and I must admit, I'm not sure whether that constraint comes from a formal or informal sense, but I notice in other RIRs, the secretariats are generally gagged and I have felt some kind of obligation to sit down and shut up, irrespective of the sanity or otherwise of what is being discussed.

Dean Pemberton: A self-gagging, yes.

Geoff Huston (APNIC): I must admit I would prefer our community to be able to accept inputs from all of us. Certainly in the secretariat, we live this life all of the time, we get exposed to a lot of the issues that sometimes policy guidance would help over and above our frameworks, sometimes the policies are impediments. There is a lot to talk about in transfers; currently

I feel a little bit gagged about being able to say, "I think there are weaknesses in our current policy, I think we should reconsider."

I don't wish to be part formally of your consensus process. I feel that, as part of the secretariat, the outcomes affect the way the secretariat operates, and I think I'll happily sit there and keep my hand down, and I don't wish to be counted as the folk who are in favour or not favour, I'm part of the folk that don't have an opinion in the consensus process. But I do feel I can help all of us in making sure that our policy process works productively and has knowledge and informed-ness about how it is currently operating to guide how it should operate.

Sanjaya (APNIC): Sanjaya, from APNIC Secretariat. My understanding is there has never been a clear restriction of APNIC staff being not involved in the discussion. If anything, it is almost like a self-restriction from the APNIC staff to let more of the community talk among themselves, lately.

I think I like the idea of starting with a problem statement. I think, if we are allowed to raise problem statement, the APNIC Secretariat, that would be really nice. If we do have opinions on the impact of a policy, then we would definitely express them.

Izumi Okutani (JPNIC): I think Sanjaya pretty much covered what I tried to say, so I agree with Sanjaya. And I am not speaking as JPNIC but as an individual. We actually observed the same situation in JPNIC because we do have our own policy forum in Japan and in this case JPNIC has been the secretariat. It is pretty much the same. There is no clear restriction that states that JPNIC Secretariat cannot make policy proposals but we tend to refrain from making proposals. But I think it is worth putting in inputs, like this kind of policy is affecting our practice so what does the community think about it, and raise some issues or share the implication of policy. That might be a useful input from the secretariat.

Dean Pemberton: Awesome. Thank you.

I was going to ask for thoughts from other RIRs, so having John is timely.

John Curran (ARIN): I will point out the practice at ARIN for informational purposes. We have not had staff participate in policy proposals, and our PDP has a sentence prohibiting that.

As much as it can be quite flattering to see developments in ARIN's policy process show up in other regions, I also want to raise a note of caution. We do have a policy experience report that our staff uses to

give feedback to the community, and that's one mechanism of how to highlight policy issues.

But we also have an elected advisory council, which is very proactive in trying to resolve issues with the policies that exist. So in our case, even if the staff isn't exercising self-restraint by occasionally stepping forward, we are giving that presentation to a very active elected community, which may not have a parallel. I'm not saying it is a good call or a bad call, I just recommend you look at the whole system when you try to figure out what to do, independent parts of ARIN's process may be independently broken but collectively quite functional.

Dean Pemberton: Thank you very much.

Emilio Madaio (RIPE NCC): I want to make a couple of examples in the RIPE community. Regularly the RIPE NCC at RIPE meetings, when it is asked in the mailing list, gives input to the community to foreseen issues or a type of behaviour in policy implementation that they want to flag up. So the example I wanted to make, the first one is a proposal we got accepted in 2011, if I recall correctly, and it was the removal of the multihoming requirement for providing the vendor space in IPv6.

Actually, we presented multiple times at the RIPE

meetings this issue, and in fact it was a kind of perceived imbalance in IPv4 and IPv6 policy for provider independent, we did it a couple of times and it didn't take off as a policy proposal. Then independently this issue was raised in the mailing list, there were references to the previous meeting when we highlighted this problem, and it became a policy proposal, then accepted.

The other example I wanted to make is this was more straightforward -- we accepted the last/8 policy at the beginning of 2011, if I recall correctly, and we expressed in the impact analysis our doubts about a sentence that wasn't very clear, so we just explained to the community what we were going to do, how we were going to implement it. We presented it again at the next RIPE meeting, and in order to formalize better policy-wise, that input was caught by the community, a new proposal was submitted, and so it is part of the engagement and the collaboration between the secretariat and the community to maybe -- maybe not to alter a policy proposal but for sure to give what Sanjaya called a problem statement, I would say a call for consideration. It is semantics but it is important to give the perspective of the secretariat to the community.

Dean Pemberton: Thank you. It was something that Adam touched on briefly as well; that sometimes we have proposals that go right the way through, gain consensus, get EC adoption, then come back and the secretariat is left with very much a, "Hmm, how are we going to do that?" It would be better to hear those sorts of concerns during the policy development process.

Maybe it changes the member community thoughts on it, maybe it doesn't, but it would certainly allow us to have a little bit more of a fuller picture about how these things may be implement he, rather than just the intent.

Does anyone have any particular negative feelings about this? The first question, "Is it accept for members of the APNIC Secretariat to author and/or propose policies," does anyone want to come to the mic and say no? Okay.

If no one wants to come to the mic and say no, and we have had some people that have come to the mic and said yes, so not looking to make any decisions today, I just want to get the most out of having the people in the room and my 15 minutes on stage -- or 20 minutes or 30 minutes -- and just kind of go through this.

If we kind of agree with it or think in some situations it could be good, does this actually require

any policy change in order for it to happen?

I have kind of heard there's not anything in the policy today saying it shouldn't happen, so I'm not thinking that it does; that this could just happen.

Anyone have any comments about that? No. Okay.

Because no one kind of stood up and said that this wasn't something that they thought was a good idea, I guess the inference is that this would be an acceptable way for APNIC Secretariat members to highlight policy issues.

Geoff Huston (APNIC): I would feel more comfortable inside the secretariat in saying, "Look, I've got a policy proposal I'm going to put up," and having that preliminary discussion and then going through the process, to at least understand that if I go down that path, I am living up into community's expectations. I don't know if you want a sense of the room, a general thing here, but I would like at least all of us, including the policy managers at APNIC and the secretariat folk, as well as you guys, to say, "This is okay. We have talked about it and we are comfortable."

I don't know how you want to do that, Chairs and Co-chairs, but I would appreciate some kind of positive feedback.

Andy Linton: I was going to let the discussion run, Geoff

and then try to come to that. You have raised a very good point. Sanjaya has something to add to this, then we will come back to it after that.

Sanjaya (APNIC): I support Geoff's idea. My point is number 2. I don't think there is any need for a policy change, but the idea of improving the PDP to include the process of a problem statement, we would simply write on that, we don't need to change the policy.

Andy Linton: Geoff raises a good point, which is trying to get the sense of the room of -- we are not hearing that anybody objects to the idea of this. Obviously, there is some qualification from the staff, saying, yes, but with caution. It may be, listening to Sanjaya, just that you actually raise the problem but not necessarily raise the solution. It may be a mixture of those things. But if there is something that needs fixing, this feeling that the community would like to get good advice from the secretariat on their problems, we would like to hear about that, absolutely. I would be very surprised if we don't do that.

Who would be in favour of proceeding with caution, of course -- sort of where the staff or the secretariat could raise issues with this as perhaps even a formal problem statement, or even more than that? The first thing would be, is it okay for the staff to raise a

formal problem statement? I know Scott has a comment. Do you want to comment on that question? We will come back to the question. Scott, have your say.

Scott Leibrand (Limelight Networks, ARIN AC): We have a different policy development process in the ARIN region with the advisory council, but some of the stuff strikes me as having parallels. The advisory council is made up of elected members of the community so we very much want to be involved in making policy but we also have roles with regards to shepherding policies, which is very much like the Co-chairs.

I have noticed it's not really defined in our policy development process any restrictions on what we can do, but I have noticed that in order to make sure there is not a lot of conflicts there, we have to be careful about separating the proposing of solutions and proposing of policy from the advocating for particular solutions and policies.

If I make a submission of a policy proposal then I'm not the one who is shepherding that through the process and I'm careful to not be advocating for that policy proposal as an AC member. The analogy here is that you have two different sorts of guidelines, one for proposing policy as a secretariat member or whatever; the other is when and how is it appropriate for the

community, for members of the secretariat, even for Co-chairs, to advocate for things?

That is an open question and is maybe even the more important question than the one on the board, which seems to have very strong consensus in favour of "yes".

Andy Linton: Scott, before you go, I have a question for you: because you have the AC, that elected body, is it the case that you get problems raised with you by the staff? Do you have to work out problems for yourselves?

Scott Leibrand (Limelight Networks, ARIN AC): The staff is very good about -- with their policy experience report and the other presentations they do -- of highlighting issues that are real issues for us. Often, an AC member is the one who writes the policy to address that, because we are closest to the staff and closest to the issues, and that's our job as elected members. But I don't see any particular reason that it wouldn't be appropriate for initial submission of a policy proposal to come from a staff member under a slightly different PDP than we have now.

The important thing is that once the staff member makes a clear statement of the problem and possible solutions, they step back and allow the community to work out what the best solution should be and what the community wants. That's where, at least in the ARIN

region, it would be problematic to have too much input from staff on how it should be done.

If I'm working for a company and telling the community how I think the rules should apply to me doing my job, it's a little bit of a conflict of interest there. If I'm just telling the community, there is an issue, this is a couple of ways we might solve it, tell me how you want to solve it and then when they tell me how to solve it, I am implementing that, that is much more the division of roles we are trying to target here.

Izumi Okutani (JPNIC): I agree with Scott's comment. I support the idea of secretariats raising issues for the community to discuss and observations about some policy that they possibly want to consider to change.

But I haven't really decided in my mind about going as far as making a policy proposal. So I would like to have more time to think about it. For the first point, just raising the issue and sharing issues with the community, I really support the APNIC Secretariat being able to do that.

Andy Linton: That leaves us with a relatively complex set of "what ifs" and so on. Let me try to get some questions and break this down into simple things.

First of all, I would like to get a feel of the people in the room, and I think, given this is affecting

staff as well, or secretariat members as well, I would like to see what their view on this is. This is not a formal proposal, this is just gauging what is going on.

Those people who would be in favour of APNIC Secretariat staff proposing policy or policy problems, who would be in favour of that?

Geoff Huston (APNIC): Do you want the secretariat staff to vote?

Andy Linton: I would like to see what they think of this. If people say, "No, that's a really bad idea," and you start doing it, they are the ones in the firing line.

Let's try again. I got a smattering of hands.

Some people obviously don't feel they can get involved in this. How many people think -- can I see who supports that idea? Obviously there are some caveats and some things we need to think about.

Is anybody vehemently against that? Dean already asked that question, but nobody opposes the idea of exploring it? Okay.

Does anybody have a comment?

Randy Whitney (Verizon): I am with Izumi, there are cases that could be perceived as conflict of interest or self-serving, so I think it is okay to have the secretariat propose things, but I would like to see that a neutral party or someone who is not part of policy

development be a co-sponsor.

Andy Linton: Yes.

Dean Pemberton: What I'm hearing in Randy's comment and Izumi's comment as well is that we need time to think about it and work out what this might look like. That is why this is an informational presentation. I didn't try to put anything more formal about this.

I think the community really needs a chance to think about what this is. Maybe we take it out a little bit wider for a little bit longer.

Andy Linton: It may be we need to take small steps.

The other one that comes from me here is this notion of the report John mentioned, the impact statement, or the operational report, I haven't got my head around that. We sort of do that with Adam's implementation report, saying we have implemented the policies, but we don't tend to have a "here is what happened because we did it" report. Maybe that is part of this process. Just my thoughts on that.

Dean Pemberton: Do we have an ability today to get input from the secretariat on what the impacts of implementing a policy would be? I certainly haven't seen that as part of the membership. If there is a policy proposal, does the secretariat have an ability to come and say, "This is the impact"?

Yi Chu (Sprint): There is a distinction between being able to raise a problem statement versus making policy. I am for staff members being able to raise a problem to the community, but I think it is up to the community to decide what to do with it. I second the person in front of me from Verizon. The same sense that raising the problem is okay, but making a proposal, it's better to be done by an independent entity.

Actually, this problem you just raised is a good example that you can follow with that process. You should raise it to the community and discuss it on the mailing list. I think people here heard about it, but there are a lot more members on the mailing list, so their opinions need to be heard.

Dean Pemberton: Absolutely. Thank you very much.

Andy Linton: I will get Adam to comment on Dean's question about a report.

Adam Gosling: The question is: is there a mechanism by which the secretariat advises the community during the PDP process of the likely outcome of a policy?

The chair will from time to time ask for secretariat input during the SIG meeting, but prior to that we also -- I quite often talk informally to the chair, have a discussion and highlight, usually editorial issues, "This is not explained very well, this is

contradictory," rather than actual implementation.

We also prepare just a one-page checklist that we do internally, that says, how much work is this going to be to implement? So that is probably the best way to describe it. I know in other regions they get legal counsel to comment on it and all that sort of stuff as well. That is something we could do.

We talked about this a couple of meetings ago and there was a little bit of resistance to us doing that. We kind of pulled back. So I provide that checklist to the Chairs and say, "We don't believe this is going to break anything. It is not going to send us bankrupt to implement and it will take us six months, not three months," that sort of thing.

Andy Linton: Adam, clearly I'm aware that list comes, because we see them, but given our discussions two or three sessions ago, we don't openly put that up as a slide or whatever on the screen. But at this stage we don't have any formal post-implementation report, other than to say, "It has been implemented."

Adam Gosling: Yes, and that's what happened yesterday. Yesterday we did an implementation report, as I said, to close the loop, to say, "You asked us to implement this or the EC asked us to implement this, this is how we did it." You asked in yesterday's session could I also give

some quantitative or qualitative feedback on the outcome, not just the implementation, but it was a little early.

I gather someone on Jabber provided some very early data to Masato, and in the next meeting I will give a more detailed report on the outcomes. We can make that a regular thing, if you want, that the secretariat does.

Andy Linton: Thanks, Adam.

The sense I'm getting here, and Dean, you're the one looking for the information, but it's been really good for all us to think about this -- the answer here is to perhaps take this to the list, discuss it some more, and then I don't know that we need any formal policy proposal to allow this, but perhaps some discussion about what form this would take, taking things that Scott and Randy said, that someone from the secretariat raises an issue but then finds a co-author, those sorts of mechanisms. I will lead you to fire that to the list to get the debate going.

Dean Pemberton: I will. That's fine. The only question I have in my head at the moment is because this doesn't require a policy change, what does the end of this process look like? Is it just us deciding something, or should we leave where we're going with this until we start the discussion, and I will start it on the list

and then we will go from there.

Andy Linton: I would observe as well, there is a role here, as part of the Chair's responsibility, when we receive proposals, one of the things the Chairs would like to do is to say, is to reject something and say, this isn't on topic for our discussions. With that discretion, if staff start raising a lot of issues, that's one for us to push back on, on your behalf. I don't think we would have to exercise that, but there is a role for us not to reject things but to steer and guide.

Dean Pemberton: Let me take it back out to the mailing list. I will frame something up, maybe with some more questions like this. I might give a bit of a summary about the conversations we have had today, then we can take it to a wider community for a little bit more time to consider what we might want to do here.

Thank you very much for your time today. Thank you.

APPLAUSE.

Andy Linton: We will crack on with the next bit. Dean didn't get his lightning talk out of that, but it was good to have that discussion.

Masato has some things he wants to raise with you, points that need to be clarified in the PDP. We have been thinking about this stuff, Masato has done all

the work.

It is certainly something that between us we have been thinking about, so I will let him get on with it.

Masato Yamanishi: This is the fourth meeting we are working as Chairs and Co-chairs, and during the past three meetings we met some issues which are not well described in the PDP and/or SIG guidelines.

Today, I want to list out the points and want to ask the community's comments about these points.

Currently we have three rules. The first is the PDP document, and since it is an APNIC numbered document, it means it is part of APNIC policy, so to change this one, somebody should propose a policy proposal.

The second one is SIG guidelines. It is a working document, so the problem is -- it is a little bit of a problem, there is no official procedure to change this one. Historically, it can be changed with agreement from the community.

The third one is current practices. This one is not documented.

Right now, I have seven points. The first one is the procedure for accepting policy proposals. It is quite, how can I say, not fundamental, it is an issue within procedure.

The first one is the PDP document says the formal

proposal should be submitted to the SIG mailing list four weeks before the start of the OPM. But also the SIG guideline says the Chair and Co-chair should check the submitted proposal, then present it to the mailing list. So there is a conflict.

Also, SIG guidelines say they wish to have a minimum of four weeks discussion after presenting the proposal to the list. So it is also a conflict. Right now, what we are doing is the chair asks for sending proposals to this mailing list. This mail address is not an actual mailing list, it goes to the APNIC Secretariat. Actually, it goes to Adam.

Then the Chair and Co-chair check the sent proposal and then present it to the list.

Why is it a problem? Proposals should be sent to policy SIG chairs and/or APNIC Secretariat, not to the mailing list directly, otherwise we cannot check it before presenting it, of course.

Also, the Chair needs some days to just check the proposal. In some cases, the Chairs also need to reach the authors, because some proposals do not describe well about what is the problem, and in some cases they also do not define the solutions.

Another point is the deadline should be specified more clearly. Currently, we are just saying, "Please

send the proposal four weeks before the OPM," but this time Andy said, "This day means the day four weeks before is after the deadline," but I said, "It is before the deadline."

It is some kind of English test.

Currently, we are not specifying the time. Also, which time zone is not clear.

Then the second problem is the timing of calling consensus, or it is not consensus in some cases, in the OPM.

The PDP says, "Consensus must be reached first." First means it is considering about the consensus in the AMM, so we don't need to care about "first" in this context, but consensus must be reached at the SIG session.

Right now, the Chair decides just after asking consensus. But the problem is the Chairs may need some internal discussion before deciding consensus in some cases.

In particular, when there are a few objections, but these objections are quite strong, in such cases we should have some internal discussion to gauge the strength of these objections and what is the impact if we think this proposal will reach consensus.

This is the second point.

The third point is consensus at the AMM. Right now, PDP document says consensus must be reached at the member meeting also. So we are doing so as the current practice. However, it is not a real problem, but not so effective.

Historically, different SIGs might propose conflicting policies in the same meeting, so that is one of the reasons why we are asking consensus at the AMM also, but now SIG is only discussing policies.

Also, if members have objections to the proposal, they can participate in the OPM because AMM and OPM are in the same week and the same venue.

The next point is the procedure if substantial objections are raised in the comment period. If substantial objections are raised in the comment period, the PDP document says the SIG will then discuss. But actually, we don't have a current practice for this issue, because there is no such proposal, at least in the last five years, I believe.

Anyway, the decision whether to pursue or not should be done before the next meeting to continue the discussion in the next meeting, of course. But it is very difficult to decide it on the mailing list if there are some objections. Then also we should define who will decide, at least the mailing list itself will not

decide.

That is a text problem.

The next one is the length of comment period after the meeting, which I think is a problem. Right now, PDP says eight weeks, but actually eight weeks plus comment period is longer than the discussion period. So I'm not sure whether we still need such a long period for the last comment period.

The second-last one is the timing of Chair and Co-chairs' election. The PDP document doesn't say anything about the timing of the election, however the SIG guidelines says the Chair elections and Co-chair elections occur in alternate years, but the current practice is a little bit different.

Right now, we are having one of the Co-chair's election in the same year as the Chair's election, and another Co-chair's election occurs in alternate years, so it is slightly different from what the SIG guidelines say.

Either way, it is not an actual problem I think, but these two should be aligned with each other, of course.

The last one is the biggest one. Voting rights for Chairs and Co-chair elections. The current PDP document says not so many things about voting rights, the first section just says anyone may attend the meeting and

participate in discussions and the decision-making.

But this decision-making also includes consensus, several things, so it doesn't mean elections only.

Then the SIG guidelines just says voting will take place by a count or show of hands. That's all. So there is no definition about who is eligible for election voting.

The current practice is everybody in the policy SIG session can participate in the voting and are counted by showing hands, but remote hub participants are not counted in the last election, but counted in the second-last election. So we do not have any clear way for remote hub participants, because APNIC is sending stuff for remote hub, so they can make sure their actual person is attending, not virtual people, but there is no clear answer for remote hub participants.

Also, we have remote participants through the website, and currently we are not counting them.

Who is eligible voters should be defined and documented, because in recent elections we are seeing multiple candidates, so it means Chair and Co-chair elections are becoming more important.

"Anyone may attend" has two aspects. We may need to consider adding more remote participants to eligible voters, but we also need to consider about prevention

of fraud.

These are points which we have some problems in meeting the operational perspectives, so this time I would ask for your comments for this point.

Before making a comment, it is very much appreciated if you clearly mention which point you are talking about.

Andy Linton: Masato, I think we are running pretty tight on time, and I have other pieces which are relevant to this to talk about.

Adam is suggesting to me that at our policy proposals this afternoon, it seems we probably won't consume the whole session, so we will spill into that session. Please go ahead with the comments.

Dean Pemberton: Thank you very much for doing the work to go through the three documents at least and finding all these inconsistencies. That's great. I didn't know we had all those problems. I think a lot of members didn't.

Making things consistent is important because it means that when we have situations that arise, we are not trying to solve them by three conflicting policies. I think it's very important work.

Probably what we need to do is get all of these onto the mailing list, so that we can have a little bit more

time to think about them and discuss them.

What I would really like as well is what the Chairs and Co-chairs' recommendation would be. Looking at these, there are a couple of areas where you could go to the left or to the right, and it would really help me to understand what the Chair and Co-chairs thought would be the most workable solution, given their experience over the last four meetings.

One that I had an immediate thought about was the length of comment period after the meeting, in conjunction with the procedure for substantial objections. If we have never had a substantial objection in the last five years -- and from my experience we never really have a lot of conversation after the meeting if we raise consensus at the meeting.

So the meeting is really where things happen. If there is consensus at the meeting and there wasn't a whole lot of talk on the mailing list beforehand, it does seem strange to have this eight-week period.

Pulling that down is certainly something I would be supportive of.

Andy Linton: I will just comment on the couple of things you have raised, Dean. In the next presentation that I am going to do, there are a few recommendations from us based on stuff. It is interesting you picked up that

one about the eight weeks, and certainly that is one that we picked up on.

I am trying to remember what the other point is.

Dean Pemberton: The substantial objections.

Andy Linton: The substantial objections in that period, that is certainly one of the things we are going to suggest immediately after this.

I know we are saying, here is the problem and here are some possible answers, but it is like two sides of the same coin.

Dean Pemberton: That is important, in the same way that hearing from the secretariat about things, it's important to hear from the people who will be implementing these policies, about what they think the most workable thing will be.

Andy Linton: Normally, one of our strategies for dealing with the meeting is for us to try to remain out of the debate and be the referee and be pulling threads together and so on, but in this case this is stuff that has a real impact on the work we have to do, so it is really important to try to get this right so we can do a good job for the community.

Dean Pemberton: The only other thing I would say is that the consensus at the AMM, yes, I have thought for a few years now how strange it is that we have to raise our

hands twice. It is exactly the same outcome each time. I am seeing nods in the audience and I know we have had this conversation before.

Andy Linton: Again, it is on our list.

Dean Pemberton: I am going to sit down and shut up.

Andy Linton: I am not trying to stop you. We may have a little bit more discussion after we put those things up.

Adam Gosling: For the sake of clarity, I want to point out there are no formal remote hubs for this meeting, with staff and all that. For our policy discussions, the audience will be those watching on webcast and those posting to Jabber.

Masato Yamanishi: As Andy said, he will present the next session, and it will have some solutions for these points.

About the last point, I think we didn't include the solution for eligible voters. I want to ask your comment about eligible voters for the Chair's election.

Personally, I think a good starting point is the current NRO elections. It means each APNIC member has one vote, not based on the size of the allocated address space, and also each person who attended two consecutive meetings, they also have another one vote right.

I think that is a good starting point about this point. Anyway, I will ask for your comments about this

election.

Andy Linton: I would echo Masato's point on this. I am not trying to say we are particularly important or that we deserve a more formal election or anything like that, but we work for the community who are both in the room at the OPM and also the community on the mailing list, the wider community. If you have any view on that, is a simple show of hands in the OPM a sufficient mechanism or should we explore widening the franchise and making it more open to everyone in the community to take part in?

Sunny, do you have a comment related to that?

Sunny Chendi: No, but one of the points --

Andy Linton: Let me first ask a question -- something for you to think about: what is the best way to choose the Chairs? Should it be wider than the meeting; just the people in the room on the day at that particular particular meeting? Does anybody have any thoughts on that? Would that be good?

There must be somebody else who has an opinion, other than Dean.

Dean Pemberton: It does seem to be more important than just a show of hands in the room. That depends very much on the location of the meeting, a lot of times it depends on the proposals being put forward. We have

seen policy SIG sessions which are very large if there is a contentious proposal and we have seen them very small if there is a non-contentious proposal.

My initial thoughts are that it possibly does need to be a little bit more structured than that.

The thing that urges me towards that is the point Masato made about needing to be accountable. Let's imagine that there is an election where there are two positions and there are five people coming up for them. Three people aren't going to get on. Historically, they have been very good about that, but if there was a time when they felt maybe there was something wrong with the counting, perhaps we need to be a little bit more robust about how we do that, given the policy SIG Chair and Co-chairs are a very important position. Thank you.

Andy Linton: Thank you, Dean.

Sunny.

Sunny Chendi: On the current topic, we have a provision in the webcast that we are running, the system we are running, we could have an app in that room to take the votes for the SIG Chair elections.

We also have a provision in the system to pre-register the remote participants. We are not using that currently, we are allowing them as guests and they can log in with whatever names and we do not

authenticate them. There is a provision that we can use that to pre-register the remote participants to participate in the policy SIG and there is a provision in the system for the consensus to raise their hands virtually and we can take account of that.

Andy Linton: Thank you, it is useful to know that.

Mike Jager (Synack): If there is going to be a more formalised voting process, we need to be clear, as you have already mentioned, on who is eligible to vote. Currently, anyone can come into the meeting or anyone can join the mailing list and take part in the discussion.

I am unsure how I would feel if it were to be restricted -- I'm not suggesting that is what you are proposing -- but if it were to be restricted to, say, just APNIC members to elect Chairs.

Andy Linton: The comment about APNIC members, it is quite clear, even with our confused guidelines in the PDP, the people who make decision on consensus in the meetings are the community, it is not APNIC members, which is why one of the questions here is, in the AMM meeting, on the Friday, why is it just the members who are ratifying the decision? It is the community that makes this decision, so I think we have to find a way to say, if it is the community that is making decisions, it is the community

who should decide on who the Chair is.

Again, to be thought about and to be discussed.

Mike Jager (Synack): Basically, I think we agree on that.

Adam Gosling: Again, just for clarity, when we speak of the NRO elections, using that use an example, the NRO election is a community election. There are probably other people who are more versed in the details of that, but it is not just restricted to members. People who are at the meeting or who have participated in one of the last four APNIC meetings, or something like that, so it is not just the members voting, it is the community voting, but it is a little controlled.

Andy Linton: I realize I am now between you and your lunch, and that's not always a good thing.

Let's take a break here. We will pick this up in the session immediately after lunch and take a relatively short period to look at some of the proposed ideas that we think would be useful in terms of change.

Then, again, that is not a formal proposal or anything, again it is for further discussion, and take it to the list and perhaps, if there is sufficient appetite for it at the next meeting we would bring a proposal and go for something a bit more formal on it.

Enjoy lunch and we will see you back here at 2.00 pm.

I have an announcement that you should set your mobile to silent, but that was to be at the start.