[ca-tf] RIPE 54 task force meeting minutes: DRAFT - ASCII format

[Chris Buckridge <]

Hi all,

Here is the draft of the minutes in ASCII format.

regards
chris

> -------- Original Message --------
> Subject: Re: [ca-tf] RIPE 54 task force meeting minutes: DRAFT
> Date: Sun, 13 May 2007 12:17:29 +0200
> From: Gert Doering gert@localhost
> To: Chris Buckridge chris@localhost
> References: <4641BEA3.6040108@localhost>
>
> Hi,
>
> On Wed, May 09, 2007 at 03:29:23PM +0300, Chris Buckridge wrote:
>> This is a first draft of the minutes from Monday's task force meeting. 
>
> Could we please return to a "technical contents are delivered in
> ASCII"
> model?
>
> I, for one, do not have a .doc reader available in my e-mail
> client, and
> can't see any benefit in having nicely formatted, 5-times as big,
> proprietary formatted minutes - plain text would do perfectly well to
> convey the message: a protocol of what has been said.
>
> Gert Doering
>         -- non-windows user
RIPE Certification Task Force meeting 2
Sokos Hotel Viru, Tallinn, Estonia
7 May 2007

Attendees:
Henk Uijterwaal 
Robert Kisteleki
Axel Pawlik
Andrei Robachevsky
Paul Rendek
Filiz Yilmaz
Gert Doering
Nigel Titley
Ruediger Volk
Daniel Karrenberg
Andrew de la Haye
Chris Buckridge (scribe)


Start: 9:30 am

Andrew de la Haye outlined the agenda for the meeting. 

Henk Uijterwaal went through the CertProto team presentation to be given at the RIPE NCC Services WG meeting on Wednesday, 9 May 2007. 

Daniel Karrenberg noted the need for further clarification of the "up-down protocol" mentioned in the certification model.

Ruediger Volk noted the importance of distinguishing between the registry data and routing registry data, particularly in terms of quality. An assertion of 99% accuracy only makes sense in terms of registration data (not routing registry data). He also noted that the including both the routing registry and registration information in the same database would be an advantage. 

It was generally agreed that it was important for the task force to provide the RIPE 54 audience with a full description of certification, and to be clear about why certification is important, otherwise there is a danger of over-hyping the project, and reducing general support in the community. Paul Rendek also noted that it is important to convey that the project does not end when the first certificates are issued ? this will be the beginning. There is a sense that while certification is very important, there is a danger of killing it if the potential benefits (in terms of both title management and routing) are not highlighted. 

Ruediger noted that the current description of certification does not include any reference to routing applications of certification. He argued that certification is in some ways more useful for routing than for title management, and while it may make sense for the prototype to focus on resource handling, there was no reference to the routing registry and the database interfaces that would be necessary in Henk's presentation. There was consensus agreement on this point, and that this was key information for the audience in assessing the value of certification.

Gert D?ring reiterated the importance of encouraging PI address space holders to certify their resources. He noted the current proposal to create contractual agreement between PI holders and the NCC, and that the result of this will impact on the task force's discussion, but also noted the need for incentives to encourage adoption of certification, as the benefits provided to routing will only be realised if a critical mass of resource holders adopt certification. Paul suggested that for many members of the community, the title issue may be more important than routing. 

Daniel noted that there has apparently not been enough incentive for task force members to experiment with the certification prototype developed by RIPE NCC. Gert suggested that it would be more interesting if he were able to use the prototype to test routing applications of certification. Daniel agreed that it would be useful to provide prototype applications for more than just the certification machinery. 

Henk Uijterwaal noted that the prototype is a preliminary model of the process, based on various assumptions, particularly in relation to policy. The NCC will establish processes to support whatever policies are created by the community, but what these policies will be remains unclear. 

Andrei Robachevsky encouraged thinking of certification not as a tool for routing or title management, but as an improvement on the registration process. Subsequent use for routing or title management can be seen as added value. 

Daniel argued that if the task force does not show how certification can be used for routing or title management, then it is failing to provide key information. Henk noted that most of the work done by the CertProto group in the NCC has been focused on the title management side.

Ruediger noted that it should be possible to create routing registry records that are based on certification records. This could be done in two ways: people who don't want to change their client software can simply trust the certified data in the database, while those who wish to could verify everything for themselves (this would require additional effort and tools). Both methods would be useful, the first to appeal to the "low hanging fruit" and the second as a more solid, long term plan. The ideal would be to map certification data into the RPSL objects ? certain routing services could then only be provided to certified resources (though this can already be done in an imperfect way using RPSS). 

Henk suggested that CertProto group post some of the more detailed use cases which it has prepared to the task force mailing list.

Daniel noted that with the prospect of address trading in coming years, the task force will need to address how certification might help with this, though this is probably beyond the scope of RIPE NCC internal activities.


[Coffee break]


Nigel Titley went through his task force update presentation, and various edits were discussed within the group. Some of discussion points included: 

 - There is a need for a clear, consistent message from the task force. This is important to ensure that certification is not simply perceived as a "pet project", but as an important, globally significant project. 

 - The task force message at this stage should be that important ground work has been done, but that it is clear that this is a complex task which will impact on many areas of RIPE NCC activity. 

 - It is also important to note that there are many elements of certification which will not fall under the task description for this task force, including trust anchor policies, etc.

 - There is a need to highlight those areas where community involvement is required. To this end, it was suggested that a publication schedule of the task force and RIPE NCC CertProto team findings might be useful. It was noted, however, that the material produced thus far by the NCC has not been produced for general consumption, and that in general it is appropriate that publications come from the task force rather than the NCC. Given that many issues concern internal RIPE NCC procedures, however, there will obviously be a need for NCC staff to contribute. 

 - It was agreed that there will be another meeting following RIPE 54, during which there can be a discussion on how to proceed with the next task force report.