[Crisp] minutes of CRISP mtg in vancouver

[April Marine <[e-mail]>]

Thanks to David Blacka for these minutes. I have tweaked them a bit, but 
not much. This is what I have uploaded via the tool to the Secretariat, 
but I can replace that version with any that contain corrections that you 
send. :)

thanks!
April

=====

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

      draft-ietf-crisp-iris-dchk-03.txt
      draft-ietf-crisp-iris-lwz-04.txt
      draft-ietf-crisp-iris-xpc-02.txt
      draft-ietf-crisp-iris-common-transport-02.txt

Comments from Andy Newton, Ted Hardie, and George follow:

Andy Newton:
 	- 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.

 	  draft-ietf-crisp-iris-areg-12.txt

Ted Hardie:
 	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.

GGM:
 	We just need to go through the issue tracker and go the
 	mailing list.

Ted:
 	We don't need to do another WGLC for the documents.

Andy:
 	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:

      * <organization> result.  Looks like a contact with some new
        fields.

      * <findDomainsByIDN> is clarified. (does not return all possible
        variants, only return variants in the registration system).

      * <listRegistrationRules> for finding out registration rules.

      * new status values to be more meaningful to EPP registries.
        Clearer status by splitting statuses that were actual compound
        states.

      * 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
        or not.

Frederico Neves:
 	Nothing to show the DS record, why?

Andy:
 	That is in DNS, but the signature life isn't.

Frederico:
 	This is the outside check against the registry.

Mark Kosters:
 	I agree with Fred, this is a good thing

Ed Lewis:
 	With EPP, you are also able to add the DNSKEY record.  You
 	might also want to be able to show the DNSKEY record, too.

Frederico:
 	Lameness check, we need three pieces of data: last time we got
 	a correct answer, status, and last time we checked.

Marcos Sanz:
 	What is the listRegistrationRules thing?

Andy:
 	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.

Marcos:
 	Not sure this is necessary.  Could be put this under see-also?

Andy:
 	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.

John Klensin:
 	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.

Andy:
 	There is no rule writing language.  This is just a identifier
 	that names something that is described in a white paper.

Ed:
 	This is a "what is in the registry" protocol, not a business
 	rules protocol.

Marcos:
 	Again, this is freetext and not usable.

Andy:
 	This isn't something that the typical user will do.

Marcos:
 	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.

John K:
 	The variant rules will not be sufficient to determine whether
 	a variant could be registered.

Andy:
 	Let me send a use case to the mailing list.

Fred:
 	Other non-gtld registries need to look that the status values
 	and see if they are sufficient.

  o Progress on RREG
    Kengo Nagahashi
      draft-kengo-crisp-iris-rreg-02.txt

Nagahashi-san:  rreg presentation. [pls see slides]

Scott Hollenbeck:
 	Do you have an EPP extension for IRR data?

Nagahashi-san:
 	No.

Robert Martin-Legene:
 	Mirroring is probably out of scope for CRISP -- databases have
 	solved this problem.  IRIS is just a front-end.

N:
 	CRISP is an alternative to mirroring.  Mirroring guarantees
 	local access to the data, which is an advantage.

Andrei:
 	What kind of hierarchy can you describe with the routing data?

N:
         Regional, national, local.

Larry Blunk:
 	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.

Ted:
 	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.
Andy:
 	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.

N:
 	BOF may be a good idea.

GGM:
 	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.


_______________________________________________
Crisp mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/crisp