Subject: [Ietf-not43] draft minutes

From: [email-masked] (Ted Hardie)
Date: Wed, 24 Jul 2002 09:40:27 -0700

Hi,
	Below are draft minutes for the working group meeting in
Yokohama; many thanks to Ed Lewis for taking these and sending them
over so quickly.  I slowed the process a good bit, and my apologies
for that delay.  If you have revisions or additions, please send 
them to me or the list by Tuesday, July 30th.
			thanks,
				Ted Hardie

Minutes (draft) of CRISP WG meeting, July 17, 2002 in Yokohama
Chair: Ted Hardie
Minutes prepared by: Edward Lewis
Minutes edited by: Ted Hardie

Agenda:
     Review of the IESG-approved charter
     Review of the updated requirements draft
     Review of the ICANN whois Task Force draft document
     "Advertisement" for a draft on Authentication Mechanisms
         draft-rescorla-auth-mech-00.txt
     Review of two candidate proposals
         LDAP-based
         IRIS

Action Items:

1)   Andy Newton will resubmit his drafts as draft-ietf-crisp items
     so that they are tracked as working group drafts.  These will
     be updated to clarify the points raised during the working group
     meeting and on the list.  The requirements draft will be re-released
     first and the candidate proposals after.
   
2)   Leslie Daigle will send a pointer to the list on the TISDAG work.

3)   Ted Hardie will send a pointer to the Rescorla draft to the mailing
     list and start discussion of authentication mechanisms required by
     CRISP.

Meeting Review:

Charter discussion (WG chair Ted Hardie)
     (see the WG charter page for content)
     Scope has been reduced since the BoF held at Minneapolis
     Now limited to domain registries with extensibility to others a plus

     Question: "Why?"
     RIR's and IRR's are removed to allow for a narrower scope, hence
     higher probability of the WG accomplishing its goals

     Question: "Why do deliverables and milestones omit extensibility?"
     Extensibility is a facet of the proposed & to-be-worked solutions,
     degree of extensibility will be one metric used to judge goodness.

Review of requirements draft (Andy Newton)
     -01 reflect the new charter scope (not yet true for proposal docs)
     new registry types: Incident Coordination and Network Edge Resources(?)
     DNS users considered
     Functional reqts split into extensible base and specific domain items
     DNS Label Referencing (3.2.10) needs input from WG

     Question: "Why does doc exclude registrants?"
     They are just not explicitly mentioned, one reference is the DNS user.

Review of ICANN (DNSO) whois Task Force draft (Ted Hardie)
     http://www.dnso.org/ and http://www.dnso.org/dnso/notes/whoisTF/
     Questions 9-11 as input to process, requirements

     Comment: This document is open for a 4-week period for comments, as part
     of DNSO.  (See web page for details.) - Scott Hollenbeck

     Comment: European privacy laws will have an impact on CRISP (as written)
     - two folks, one whose name I missed and Jaap Akkerhius

     Comment: Requirements document should be altered to deal with privacy
     concerns. - Leslie Daigle

     Comment: TISDAG documents are helpful for understanding the problem to
     be solved here, and come from a European setting. - Also Leslie, and
     she has been asked to provide a list of relevant RFC's on TISDAG.

     Comment: Conclusions in the document did not exactly follow from the
     question presented (for question 10), from Andy

Advertisement for Auth Mech draft

     An individual submission from Eric Rescorla, "A Survey of Authentication
     Mechanisms" is recommended reading.

     http://search.ietf.org/internet-drafts/draft-rescorla-auth-mech-00.txt

     Not discussed further as there was no advanced notice given to the WG.

Candidate Proposals
     LDAP-based and IRIS
     Both doc( set)s are out of sync with new scope of charter and requirements.
     LDAP is a single, large draft
     IRIS is a set of smaller drafts (XML via HTTP)
     No further discussion as we need more background on requirements

Return to the Requriements Draft for discussion

     Question: How does authentication work in the requirements?
         Two separate issues
             Anonymous vs. identified access
             Data mining policy (3.1.1)
         Authentication query (3.1.8) - suggestion to drop section

     Question: Is this a read-write or read-only protocol?
         Read-only
         No desire to store requests on server (too complicated)
         Declare features in which a client would write (store) data on server
         as out of scope

         *** WG consensus needed on above point ***

     Question: Concerning search functions in 3.2.4 and 3.2.9, "reasonable
     subset" wording - Yoshiro Yoneya, JPNIC
         Discussion also covered ACE encoding & lookup issue, do not want to
         solve that problem in this group.
         Text about this topic solicited

     Question: Also on "reasonable" from NaoMASA Maruyama  (JPNIC)
         Resonable subset wording conflicts with data mining text (on the
         surface).
         Suggested rewording for 3.2.4 - "MUST support lookups on exact
         names and reasonable subset names, MAY/SHOULD provide limits to
         answers to alleviate performance, privacy, and/or data mining
         concerns.

     Question: Is there a requirement for hierarchical search?
         Base spec does not cover this.
         3.2.10 is closest to this topic.

     Question: Is there a requirement to allow for determination of the
         registry delegating a domain name?
         Needed feature, so folks asking for, say, ac.jp, know who to
         contact about domain name.  (DNS may have multi-label deep zones.)

Action items for Andy
     New requirements draft (with the updates discussed in meeting and a
     switch to draft-ietf-crisp-... name) is due about a week after the
     minuted are submitted.  Revised candidates assumed to appear sometime
     later.

---

From: [email-masked] (Rick Wesson)
Date: Wed, 24 Jul 2002 10:09:00 -0700 (PDT)

>      higher probability of the WG accomplishing its goals

two points.. one of procedure, why are decisions being made at the meeting
and not on the list? If the RIRs and the IRRs want out of CRISP then the
name registries and registrars may want out too. To play fair the topic
needs to be discussed and consensus determined on the list.

secondly, without the RIRs and the IRRs the protocol does not improve ones
ability to navigate the heiracy of names and number delegations and as
such I believe CRISP should either solve the problem of all registries or
not exist.

I would like to understand how these decisions got made and why we all
were not consulted in the matter.

thanks,

-rick

---

From: [email-masked] (Leslie Daigle)
Date: Wed, 24 Jul 2002 13:30:22 -0400

Rick,

This is so not news... 

First, it wasn't decided at the meeting in Yokohama -- as
a result of the LAST meeting (i.e., Minneapolis), it was
_proposed_ to the list (see, e.g., Ted's note to this list
on April 25):

> Subject: 
>         [Ietf-not43] Proposed charter
>    Date: 
>         Thu, 25 Apr 2002 15:24:59 -0700
>    From: 
>         Ted Hardie <[email-masked]>
>     To: 
>         [email-masked]
> 
> 
> 
> 
> Howdy,
>         Based on the discussions we've had since the last IETF, I
> believe that the scope of the CRISP work has been narrowed to a focus
> on DNS-related registries, registrars, and registrants.  Though I
> believe that there is value from a user perspective for a more general
> approach, I believe that deployment of such services is unlikely among
> other infrastructure registries using similar administrative directory
> services.  Given that, I have put together the following straw
> charter, which is narrower in focus than those discussed at previous
> BoF sessions.  Comments to the list are welcome.
>                                 regards,
>                                         Ted Hardie

Leslie.

Rick Wesson wrote:
> _______________________________________________
> Ietf-not43 mailing list
> [email-masked]
> http://lists.verisignlabs.com/mailman/listinfo/ietf-not43

-- 

-------------------------------------------------------------------
"An essential element of a successful journey
    is recognizing when you have arrived."
   -- ThinkingCat

Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: [email-masked] (Ted Hardie)
Date: Wed, 24 Jul 2002 10:38:34 -0700

> needs to be discussed and consensus determined on the list.

This actually points to a clarification required in the minutes,
as this wasn't a decision reached in the meeting, it was a decision
by the IESG reviewed in the meeting.  The initial agenda for
the IETF listed the meeting as a BoF and the transition to working
group occured fairly close to the actual meeting.  I reviewed
the current charter and compared it to the charter proposed at
the last BoF as an aid to those who might be attending the meeting
anticipating a continuation of the previous BoF.

The charter reviewed was the same as the one posted to the list
and to the ietf-announce and new work mailing lists.  

> such I believe CRISP should either solve the problem of all registries or

While I certainly sympathize with that view, the IESG felt that a more
restricted initial charter was appropriate.  They did feel that
extensibility or applicability to other domains could be design
criteria, but that the work items of the group should be focused on
the domain name space.  The first draft of that more restricted charter
was first posted to the list back in late April (see message id
[email-masked] in the archive at
https://lists.verisignlabs.com/pipermail/ietf-not43/2002-April.txt,
and the discussion on it which followed into the May archives).

> were not consulted in the matter.

I appreciate your concern for process, but I believe this discussion
did occur according to the appropriate procceses.  After the BoF,
the IESG felt a more narrowly scoped effort was appropriate; a draft
charter on that basis was posted and discussed on the working group
mailing list, and a revision of that charter based on those discussions
was posted for review on ietf-announce and new-work.  

If you continue to have concerns on the process, I would be happy to
discuss it with you as, I am sure, would the ADs.

			regards,
				Ted Hardie

---

From: [email-masked] (Rick Wesson)
Date: Wed, 24 Jul 2002 10:51:53 -0700 (PDT)

> discuss it with you as, I am sure, would the ADs.

yes, I do and I would like to discuss it with the ADs; The parties to this
wg have not been consulted and may not want to participate w/o the IRR and
RIR registries.

If this wg's work is re-scoped to just include name registries and
registrars I have a big probelem and I'd like to discuss it with the IESG

-rick (with his CTO of the ICANN Registrars hat on)

---

From: [email-masked] (Ted Hardie)
Date: Wed, 24 Jul 2002 13:27:43 -0700

> wg have not been consulted and may not want to participate w/o the IRR and

Patrik is the relevant AD; if you'd like me to be  involved,
please feel free to cc: me on your messages.  

> -rick (with his CTO of the ICANN Registrars hat on)

As a process point, I remind you that IETF participants speak (or
at least, are heard) as individuals.  
			regards,
				Ted Hardie

---

From: [email-masked] (Eric A. Hall)
Date: Thu, 25 Jul 2002 12:39:33 -0500

[sorry for the late response]

on 7/24/2002 12:09 PM Rick Wesson wrote:
>
> On Wed, 24 Jul 2002, Ted Hardie wrote: two points.. one of procedure,
> why are decisions being made at the meeting and not on the list?

The decision to limit scope to domain names was made before the WG charter
was submitted. As I understand it, this was a requirement passed down from
the IESG.

This doesn't mean that we have to ignore those parties. Towards this
point, as part of restructuring my proposal, I am going to provide
expiremental-track IDs for IPv4, IPv6, ASN and user schemas and protocols.

> secondly, without the RIRs and the IRRs the protocol does not improve
> ones ability to navigate the heiracy of names and number delegations
> and as such I believe CRISP should either solve the problem of all
> registries or not exist.

Personally, I think it is useful to limit our responsibility (and thus,
our culpability) to a single target area. If we get the core and the first
layer (domain names) right, adding more profiles should be simple. Yes, we
have to keep those other uses in mind in order to avoid designing
something that doesn't work with those other profiles (see the extra IDs
comment above), but this in fact no more of a risk than trying to define
six different standards. We could get four of them wrong in either
scenario. Focusing the standards-track effort on the core and domain names
specifications makes some sense.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/