Subject: [Ietf-not43] more verbatim minutes

From: April.Marine at nominum.com (April Marine)
Date: Tue Dec 2 19:04:22 2003

And here are Cathy's more verbatim minutes for those who love detail.
These are for the group's info--the shorter version will go to the
secretariat (with any corrections from the group) for the proceedings. I
took out some comments where she noted she wasn't sure if she caught every
detail, so pls attribute any errors to me, not our scribe! It's amazing
she got as much detail as she did! :)

thanks Cathy!
A.

----------------

Cross Registry Information Service Protocol WG (crisp)

Wednesday, November 12 at 1300-1500
CHAIRS: April Marine <[email-masked]>
        George Michaelson <[email-masked]>

Name Abbreviations:
AM  April Marine
AN  Andy Newton
CA  Chris Ambler
CM  Cathy Murphy
EL  Ed Lewis
FN  Frederico Neves
GGM George Michaelson
GL  Ginny Listman
JK  John Klensin
LD  Leslie Daigle
MK  Mark Kosters
MS  Michael S... (Could not find him after the meeting to get
his name)
RS  Richard Shockey
TH  Ted Hardie
WM  Bill Manning

+-----+

 o Welcome and Agenda Bashing - 10 min, chairs

AM:
- Welcome new co-chair, George Michaelson
- Ted Hardie (now sheparding AD) was wearing too many hats
- Scribe is Cathy Murphy
- Anyone to do jabber log? Ted volunteers.
- Mail list (currently at [email-masked]) will be
  moving to IETF servers
- No agenda changes

Since last meeting, group came to consensus on IRIS as way forward.
Reqts draft in RFC editor queue; some recent comments, but done and
not re-opening.

+-----+

 o Outstanding IRIS Issues  - 35 min, Andy Newton and WG discussion

AN: These are not the issues sent to mailing list; these have come
forward since then. List items can be found in mail archives.

| Slide: Areg document
| Slide: Resolution Methods
| * Dreg; based on Eric Hall's original docs; probably good enough
| * Areg; probably needs to be re-visited
| Slide: Misc. Changes
| Slide: Host in DREG
| * Should probably make consistent for developers
| Slide: Status in Domain
| Slide: Draft mechanics

AN: Any other open issues?

#1
GGM: Please clarify: is areg resolution a discovery phase activity?
Put the dreg method as a suggestion for the areg?
AN: Correct, but don't think it properly maps.
GGM: Plus not reverse domain not required, so not required.

#2
TH: Is it okay to have URI scheme iris, with the understanding that
BEEP is the obligitory transport and other methods have specific
names?
AN: Requirements require that transport be identified because
anticipated multiple types. Agree this is for the corner cases.
TH: Concerned that we are adding an element for a corner case.
Will re-read and possibly comment.

#3
CA: Unclear on sorted issues on stats?
AN: Currently it's a sequence because domain can have multiple
status. That is how xml schemas are defined, so don't have to do
sorting anymore.

AM: What's the next step?
AN: Send to list and see who comments.

+-----+

 o Additional Requirements?           - 15 min,  Ginny Listman
                                      -  7 min, WG discussion
 re: draft-ietf-crisp-internet-resource-number-requirements-00.txt

| Slide: Before Writing the Document
| Slide: General differences
| Slide: Base Functions (1)
| Slide: Base Functions (2) Relay Bags

#1
TH: Just to clarify: "implement" is being used where it really
intends to mean "deploy". You don't see the use of it, but don't
object to it being in the protocol?
GL: Correct

| Slide: Base Functions (3) Privacy Labels
| Slide: Lookups/Searches
| Slide: Information Set
| Slide: Specific Functions (Serialization)
| Slide: Specific Functions (DNS delegation)
| Slide: Distribution of Registry Types
| Slide: Privacy
| Slide: Feature Requirements (Schema Language)
| Slide: Feature Requiremenets (DB Schema)
| Slide: Comments from the List

#2
AN: Do you think description of searches in the document are what you need overall?
GL: Yes. With the exception of the noted IPv4 differences.

#3
AN: Regarding a couple of the requirements:
- Query of access permission: the protocol spec must say this,
but don't have to deploy this.
- Relay bag
- Privacy label: This is something the IESG asked us to add. If you
want to leave it, you will need to discuss it with them.
MK: This issue has come up in the ARIN meetings; thinks it is
premature to take it out. If the facility is there, some members
might want to take advantage of it.

#4
AN: Lookups and searches; good comments and within the spirit of
the protocol

(#3 continued)
WM: Regarding the privacy label, this smacks of a binary thing.
Came up in geopriv context.  If going to put privacy in, needs to be
more robust because if leaving in, not sufficient as is.
AN: As participant of geopriv, please contribute text. Concerns in
geopriv are similar to those here.
GL: If needed, will leave in.
AN: Wasn't insufficient when IESG had us put it in. Don't want to
become mired in issues raised in geopriv. Send text.
EL: Relates what happened in provreg too. Operational concern by
IESG policy has to be done at sender side per client need.
TH: Not trying to set this up as a policy requirement; supposed to
be an engine to allow implementers to apply policy. This is not the
forum for policy questions.

#5
AM: Are you still willing to be point person for this document?
GL: Shane Kerr has agreed to be the editor going forward.

+-----+

AM: How do we move this forward? Personally, don't want to hold up
the existing document.
AN: Point of procedure: what's the implication of issuing a biz
version while the existing reqt doc is in the editor's queue?
<discussion of the process points>
LD: I agree with Andy that doing as a biz but that does not allow
a re-opening of old (settled) issues is the best way to proceed.
AM: Another path is to do as a separate document.
LD: Yes, that's another possible path, but that could lead to
confusion among future developers about which reqts are necessary,
which is the current or current document.
AM: Lets survey the room...Okay, it appears the consensus of the
room is to take the path of a biz version.

AM: Andy has asked for a co-author for the IRIS documents (for XML)?
... no volunteers...
Okay, will take it to the list.

+-----+

 o IRIS lightweight transport         - 15 min, Andy Newton
                                      -  7 min, WG discussion

AN: Recently, some discussion about transports on the list.
It was brought up before a while back, but is was probably premature
to discuss at that time. Now seems like a good time to discuss this.

| Slide: BEEP
| <not advocating getting rid of beep, but only add another transport>
| Slide: The Open Door
| Slide: IRIS Transport Design
| Slide: A Survey of Possible Transports

#1
TH: (Re: XML, GZIP) How would you make those congestion aware?
AN: Would say using UDP, say don't flood network, etc.

| Slide: Fast and simple UDP
| Slide: ...
| Slide: A sample IRIR-LWZ request
| Slide: IRIS-LWX & IRIS-LWB
| Slide: Simple TCP-based Transports
| Problem with using TLS is that it doesn't offer any advantages
| that BEEP doesn't already provide.
| Slide: HTTP-based
| - Not as simple as it sounds.
| - SOAP, has issues with session semantics (severs at tcp layer and
| reloads up above)
| -- Same issue: nothing these offer that BEEP doesn't
| Slide: The Case for UDP
| - If access is anonymous and
| - If size of response is small (512 to 1500 bytes)
| -- UDP also works better with anycast
| e.g., fast domain name check, scaled down dreg query

#2
EL: Lightweight transport or lightweight CRISP?
AN: What I'm describing is how to do IRIS over UDP.
EL: But is that scaling down the queries or ...
AN: The intent is not to get everything run over UDP; the intent is
to get some running over UDP.

<some discussion...>
#3
TH: Using Whois behavior to predict how CRISP will work is
misleading. Once they have session state client, it doesn't mean
that they won't get used to it. That doesn't mean that there isn't
a place for it, but this would not meet all of the crisp reqts?
AN: Correct.
TH: Then why not complete the BEEP work first, then address this
issue later?
AN: Because this is the use case that will bring everyone on board.
If IRIS is only really necessary for %5 of the queries, then there
is 95% that considers this unnecessary.
TH: 95% of foo doesn't mean anything to bar.
CA: We have a real world requirement for this now: we are currently
doing it over port 43.
LD: It's not that BEEP will be too complex, it's more to get
something to complement BEEP, that will actually help get it
[CRISP] done.
TH: Why?
LD: Because some are intimidated by all the BEEP reqts, thus causing
CRISP to fail. This allows early adoption by a larger number.
TH: Okay, that's a valid point, but if going to design as
interlocking pieces (light-weight then failover to heavy-weight)
versus two separate, independent transports. If interlocking, need to
do together. How does a client know if response is going to be
cut-off? Needs explanation. Clarity is critical.
AN: Draft does talk about how to know which to use.
JK: Registrars want a very heavy transport that delivers everything.
What you are proposing is a middle of the road that doesn't meet the
protocol requirements. Have a strong protocol to meet the demands of
what folks need that won't work over UDP.
MS: But a light-weight transport to answer the bulk of the queries
has to be done.
AN: Anyone else see a need for it?
MK: UDP version always comes up. Did in rwhois. Sometimes gets
implemented, sometimes not. There are always concerns with UDP.

GGM: Ted, were you speaking as a contributor or an the AD?
Could you live with a delayed decision about this?
TH: Was speaking as a contributor, not an AD. As an AD, there is
only one document out to the wider community. I'm concerned about
making the change to the charter and the transport at the same time.
GGM: Feel strongly that if it going to proceed, should be done here.
TH: Agree. What is going to get people to move? Will IRIS-light get
people to move? But if what is defined is so similar to whois-like,
then worry that will discourage moving.
AN: Agree with that concern, that if we proceed to UDP, won't ever
get to BEEP. But all the other drivers (int'lzation, etc) still will
require BEEP.
RS: Is any one clamoring for this?
AC: Yes, registrars are.
AM: Would like to take it to the list.

+-----+

 o Update Charter and Milestones      - 20 min, chairs

AM: Let's talk charter: only suggested change is to the following
lines:

    << April -- I think you'll need to put something here.
       I can't find where I noted the exact text to change.
       Sorry! >>

[will send text to list separately--AM]

Is there agreement on the change to the charter language that
allows number resources to be included?

...Sense of the room was YES...

Revised Milestones proposed:

WM: Are the authors in question okay with the dates?
CM: Regarding the IP address registration document, thinking of
doing a new one. Our internal date is prelim by March, final by May.
Or will work with Andy on revising his areg document.
AM: So is March for preliminary working group draft okay?
CMM: Yes.

+-----+

 o Using dreg for registrar-registrar - 6 mins, Chris Ambler
   communication

CA: Several of aspects of IRIS are to limit queuing due to mining.
This works to the detriment of registrars. What we need is a very
light-weight registar-to-registrar query mechanism.  So, looking to
implement in a number of ways. One idea was to just add a flag
in port 43 so that would send back XML . Do we want to proceed with
full blown CRISP? Probably, but am approaching now just to do as a
light-weight implementation.

TH: Are you using EPP?
CA: Yes.
TH: So you don't look at EPP for this?
CA: We want something that is read-only. See this a first step to
migrating off of port 43.
AN: Is it possible to not do the switch on port 43? SoAP Is a
separate issue. Is it a detriment to proceed with switch?
CA: Switch is to aid implementation to get all registrars on the
band-wagon. Switch allows decision to answer. If we can validate
that IP comes from another registrar, then will answer;
otherwise will not.
AN: Which type of registrars, thick or thin?
CA: Thin. Need to be able to poll the data over from another
registrar.
AN: Won't you have to eventually do a separate registry for the
thick registrars too?
CA: Only thin that is driving this, but will eventually have to do
for both.

+-----+

 o Wrap-up & Other Biz                -  5 mins

No other business.