Minutes for the
CRISP Working Group Meeting
IETF 64 -- Vancouver, BC, Canada
Tuesday, Nov 8, 2005
minute taker: David Blacka
chair: George Michaelson
(co-chair April Marine could not make the meeting, but did
edit these minutes a bit for format and to summarize a bit more)
o Update on latest drafts
Comments from Andy Newton, Ted Hardie, and George follow:
- DCHK has an IANA registration issue for the xml namespace
- LWZ has numerous issues
- XPC is perfect (actually just can't remember the issues ;).
- common-transport has the same xml-namespace IANA issue.
AFAIK all issues have been addressed.
The four documents have all been last called. We just need to
rev to fix the current issue and then submit to the IESG.
AREG has some discusses against it. (FindNetworks, etc.)
There is a mild XML bug, Alison (Mankin)'s comment about
publishing the domain name under .arpa. We need to go through the
discusses and respond to them.
We just need to go through the issue tracker and go the
We don't need to do another WGLC for the documents.
Bottom line: I will fix those and send to IESG.
o DREG2 Plans
Andy does his presentation on DREG2:
DREG was the first registry type. We learned stuff from
subsequent registry types. There are new players that had new (minor)
requirements. We could probably get this done by the next IETF.
Nothing is rocket science here.
The DREG2 schema is done, and in subversion. What is new:
* result. Looks like a contact with some new
* is clarified. (does not return all possible
variants, only return variants in the registration system).
* for finding out registration rules.
* new status values to be more meaningful to EPP registries.
Clearer status by splitting statuses that were actual compound
* status values for non-domain objects, more values for domain.
* Added "Registration Service Provider". In addition to
registrar. These are third parties in the registration path.
This isn't a new result object.
* Signature life for DNSSEC. Some confusion on this issue, but
think that there should be only one of these per domain.
* Controversy on IDNeMail: whether when accepting email
address/sip address/etc you have to have the nameprep version
Nothing to show the DS record, why?
That is in DNS, but the signature life isn't.
This is the outside check against the registry.
I agree with Fred, this is a good thing
With EPP, you are also able to add the DNSKEY record. You
might also want to be able to show the DNSKEY record, too.
Lameness check, we need three pieces of data: last time we got
a correct answer, status, and last time we checked.
What is the listRegistrationRules thing?
What are the rules for registering an IDN? Something you can
give to the client to allow the client to determine if it can
register a domain. This will be a well-known identifier.
Could be an IANA registry.
Not sure this is necessary. Could be put this under see-also?
See-also are attached to objects that you already know how to
query for. This is a new thing.
This came up specifically in the IDN case.
Do you have a language defined for this? I know of 4
different registries that are using 4 different languages to
describe variant rules. I'm concerned that you are putting a
hook for something that you don't know how to do.
There is no rule writing language. This is just a identifier
that names something that is described in a white paper.
This is a "what is in the registry" protocol, not a business
Again, this is freetext and not usable.
This isn't something that the typical user will do.
When folks want to know this information, I point them to the
FAQ on our website. This isn't the right place to do this.
The variant rules will not be sufficient to determine whether
a variant could be registered.
Let me send a use case to the mailing list.
Other non-gtld registries need to look that the status values
and see if they are sufficient.
o Progress on RREG
Nagahashi-san: rreg presentation. [pls see slides]
Do you have an EPP extension for IRR data?
Mirroring is probably out of scope for CRISP -- databases have
solved this problem. IRIS is just a front-end.
CRISP is an alternative to mirroring. Mirroring guarantees
local access to the data, which is an advantage.
What kind of hierarchy can you describe with the routing data?
Regional, national, local.
We described this in other documents. We created a hierarchy
the started at IANA, but it tied routing registries to address
registries and didn't take off. I think you want to get the
heirarchy fixed before you try to address this in crisp. RPSL
already defines a service model, so why start all over again?
Also, ISPs may want to mantain their own registries.
Recently saw a parallel situation in a different WG. We
reused CRISP in the ECRIT working group, but think it was
important to be done in ECRIT because the semantics were (?)
best understood in that WG. The subject of this proposal
isn't really suited to this group of people. I offer for you
to hold a BOF for something in the routing area, which would
give you a greater chance of success.
Other IRIS registries have been defined in other WGs, so no
requirement to do this here. But first you need to clarify
the issues around how the data moves around.
BOF may be a good idea.
It doesn't look were are in a position to make a decision to
adopt this routing work. We are out of time, so it is looking
like we might be able to wrap up in Dallas.
o WG Next Steps
Fix current drafts and send to IESG. No need for another last
call from the working group. RREG work can be spun off into a
BOF. WG can probably conclude in Dallas.