[Crisp] Minutes of the CRISP WG (fwd)

Kim Davies took these excellent minutes. Before we submit for the 
proceedings, I thought I'd give those of you who were actually at the mtg, 
since I missed it, to comment/correct. Of course, you only have the 
briefest of windows to comment because we rarely do things early.

thanks to Kim!
A.

----------------
Minutes of the CRISP working group
62nd IETF, Minneapolis USA
March 2005

Chair:
George Michaelson

Scribe:
Kim Davies

Status Update
=============

George Michaelson reported that the group had met three of the four milestones. 
The only outstanding job was to finish the AREG specification which has been 
held over to May 2005.

Four RFCs have been published, and four working group documents are in 
progress:

   * draft-ietf-crisp-iris-areg-09
   * draft-ietf-crisp-iris-areg-urires-00
   * draft-ietf-crisp-iris-dchk-02
   * draft-ietf-crisp-iris-lwz-01

AREG
====

Fred Neves reported on the differences in the latest revision -10 of the AREG 
draft. Included in the changes, <findOrganisztions> was made similar to 
<findContacts>; Organisational Search Group to provide the same services 
throughout the document; change of <findNetworkBySpecificity> to 
<findNetworkByHandle> mentioned in Washington but not included in -10; and for 
<contact> result added address, city, region, postalCode and country elements.

It is also proposed to drop the URI resolution draft, instead adding a URI 
resolution section to the AREG draft. Top-down resolution is still recommended, 
but the top is left undefined.

New text for Section 7 will propose including a direct resolution against 
"areg-iris.arpa", as there needs to be a fixed anchor as opposed to domain 
names.

Leslie Daigle suggested some alternate wording on how the IANA request be 
drafted relating to the areg-iris.arpa registration. Cathy Murphy said that 
ARIN had some minor rewordings that will be supplied, but that they are not 
substantive.

George Michaelson noted that based on discussion, the document should make the 
May deadline, and the URI resolution draft will be left to die.

XML Pipelining with Chunks (XPC)
================================

Andrew Newton reported on his new draft (draft-newton-crisp-iris-xpc-00.txt) 
which provides a new TCP transport for IRIS. Currently defined in RFC is IRIS 
bindings to BEEP. BEEP was considered useful at the time because it met all the 
requirements, especially for security. However implementation experience shows 
it is difficult to implement, especially as BEEP is designed to do many extra 
things (run over different transports, with multiple channels etc.). It is 
difficult to write a BEEP library just for use with IRIS, and there is not a 
rich set of libraries available for BEEP.

There were two options available - either reuse someting (like with BEEP) or 
create something new. To reuse something, need to find a protocol that suits - 
but that may require features in that protocol that are not commonly 
implemented. If something new is created it needs to be easy to build.

The first reuse question is "Why not use HTTP?". BCP 56 discusses using HTTP as 
a substrate, and expresses dire warnings for using it for anything other than 
web browser. This could be ignored, but may be a political battle not worth 
fighting.

HTTP also doesn't support SASL - there is a draft, but hard pressed to find an 
implementation that supports it. Doesn't really support chunking, which has 
been defined for HTTP for years, but not many libraries support it.

This lead to the idea of building something, can be done by a competent 
programmer in a day or two. The protocol makes room for SASL, the same security 
layer that BEEP uses, so can be used for different security mechanisms. By 
design the protocol supports chunking.

It has something called 'basic auth' built in, using plain text passwords. 
There is explicit room for SASL, and the draft does define using SSL and TLS in 
a tunneling mode.

It is important to note that SASL is being retrofitted. SASL Plain has 
something called SASL nameprep, that takes something that needs 30 minutes to 
implement now, and makes it take 2 days. Whilst the nameprep thing isn't 
actually needed, in the SASL co-chair's words it is a "SHOULD", so if you only 
have ASCII user names, you dont have to do it. So basic auth may come out.

On the need for chunking. Why is it important? Essentially when you do octet 
counting with HTTP or BEEP, you get a whole xml packet, you have to look at 
content length up front, then you can tell your parser you have all the data. 
Then to send it back you have to buffer all the data as you need to tell how 
long it is. There are ways around the first part, but not the second. On an 
IRIS server, they are not files off the file system where the size is easy to 
find, this is data generated dynamically so it is hard to do.

Pipelining cuts up the XML up and sends it in manageable chunks. This results 
in a smaller footprint and latency as the server is able to divide processing 
into smaller subsets.

XPC is very complimentary to the LWZ draft, which is IRIS over UDP. It uses the 
same XML scheme for versioning etc. All the values in the headers overlap with 
LWZ, if they have the same meaning it is the same value. Wire format very much 
like LWZ.

Brian Tremmel: Have skimmed the draft, how easy would it be to take any XML 
message request/response protocol and put it on XPC? Is it CRISP specific?
Andy: Nothing is IRIS and CRISP specific, so it could be used forother 
messages. The only problem may be the XML trasport scheme's method of 
versioning: it is not specific to IRIS but it is defined in an IRIS document. 
The intent was not to design something generic, it was just for this problem, 
but turns out to be generic.

Robert Martin-Legene: Could you give an example of what kind of request you 
would send in chunks?
Andy: One of the things you would see, is an initial request that says "give me 
a domain name". The response is here is a domain name and 2 associated 
nameservers, over the UDP channel. The nameservers may not be in the IRIS 
response, so 2 more requests may come for those, with 1 nameserver in a chunk, 
and 1 in another. There are several scenarios with my iris clients, that when 
you do referral chasing, you get back a set of 1 or 2 objects, if it isn't in 
the referral section, it can break those up into a manageable chunk and process 
them.

IRIS Routing Registry
=====================

Kengo Nagahashi informed the group on investigative work towards implementing a 
routing registry over IRIS (draft-kengo-crisp-iris-rreg-00.txt).

Currently query transactions with an IRR is conducted using the WHOIS protocol, 
which lacks a referral capability - therefore the IRR data is hosted centrally.

The reason for the interest is in development of Near Real Time Mirroring 
(NRTM), a mirroring architecture to replicate IRR databases in near time (e.g. 
30 minutes). However this requires a referral query mechanism for IRR, and 
hence a need for RREG. For example, in IRR a routing registry may wish to defer 
the query to another.

The initial document is based on the AREG document, and it is hoped to discuss 
on the mailing list. Would like it to become a working group item.

Cengiz Alaettinoglu: Does CRISP provide a full real-time mirroring of data?
George Michaelson: Out of scope, the protocol supports referral and chaining, 
but as to whether mirrors are done, it is not part of the protocol.

Andrew Newton: There is a serialisation spec in IRIS to support things like 
mirroring, escrow, etc.

??: The charter would need to be extended to support real-time mirroring in the 
wg charter. People use this data to configure routers, for that you need every 
record.

Cathy Murphy: This brings up another point, what is the resolution method? We 
just got through figuring out top-down resolution for AREG. There is a natural 
structure for areg and dreg - what is the resolution method for routing 
information?
Kengo: In the draft this is an open issue, what is needed.. this is almost a 
similar discussion with AREG. Currently in the initial draft, it needs a top 
down starting resolution point.

George Michaelson: Two people have expressed views who can't be here. Joao 
Damas of ISC (RPSL) and Andrei Robachevsky who runs the RIPE Routing Registry. 
They have made two different observations I should communicate. Joao's concerns 
were tht the current draft only included information models from AREG, a better 
approach would be how to represent routing objects in xml syntax. Starting with 
allocation object set is a disadvantage. He is also concerned that the use of 
routing registries is really very different to domain or resource management 
lookup in address registries. Although it is a registry implemented over WHOIS, 
he felt it is not a given that it should exist in CRISP as well. He didn't say 
it should not be in crisp, but he said it is not 100% clear as the behaviour 
set is different.

Andrei's concern is that this is a tool set for automatic generation of router 
configs, that toolset uses RPSL to generate an intermediate format, so was 
concerned there needed to be conformance with that process. Would the tool use 
XML (may be attractive), the tool (irrtoolset and rpconfig) moved to ISC for 
maintainance. There is also the question of global coverage, that current 
registry practices separate management of address and number resources, that 
people need to assert routes that cover objects that are outside of their 
control. The work done in routing support includes interesting authorisation 
behaviours on the input side. It is not a CRISP problem, but is a real one. The 
rights over the data lie in different spaces, so other dimensions exist to the 
problem.

Cengiz: CRISP can encode the routing data, but needs to be extended to include 
full mirroring and authorisation that is part of the RPSL process. Probably 
needs specific queries for this type of data. You can't just use AREG to 
implement it, you need so much more. if you guys took this on, I think it would 
be a good thing, but there is work that needs charter extension.

George: Is this a well formed idea, extending out charter? I have no personal 
view.
Scott Hollenbeck: Me and Ted have a strong preference for groups finishing 
their charter before taking new work. If you want to add a missing something 
though, it can be done. But that is a question for you all to decide.

George: We need to take this to the list to discuss. If this work continues, 
the document will need substantial revision. Would like to invite you to take 
on additional authors from the routing and whois community to help. I am sure 
someone here can assist. I think we are shepherding this informally until we 
know more.

Cathy Murphy: Are you going to be reaching out to the operator forums? I know 
it was presented at APRICOT. what about NANOG and RIPE meetings?
Kengo Nagahashi: One target is the RIPE community, APRICOT etc. to involve rir 
community and routing community. The routing community is the most important 
for us.

Andrew Newton: Is there a need for RPSL in XML? Is there resistance from people 
who may not be in this room? If people are saying it shouldn't be done it helps 
answer the question. Maybe we should work out if RPSL can be represented as 
XML, then fit it into IRIS if it fits.
George Michaelson: It is a valid question - RPSL has fans and enemies. I 
wouldn't want to say there is opposition, but there are definitive 
considerations. I am not an XML fanatic. The whole idea of chunking shows 
issues, but there is such a huge amount of code that can take XML, it is hard 
to see how router vendors would not want to receive tokenised data in this 
format. People will probably exploit this if it was done.
Larry Blunk: I am not sure. I went through the draft, sort of confused, lots of 
things missing, route objects but not origin AS etc. It looked like the AREG 
doc with minor mods.
Andrew Newton: The compelling reason for XML is there are lots of XML parsers, 
and there are loads of tools. so if you simply took RPSL wrapped in XML it 
would be useless. so you need to go through the spec and work out how to XML 
it.

Future
======

DCHK and LWZ will be moved to working group last call.

_______________________________________________
Crisp mailing list
Crisp@ietf.org
https://www1.ietf.org/mailman/listinfo/crisp