From ggm at apnic.net Tue Dec 2 18:51:50 2003 From: ggm at apnic.net (George Michaelson) Date: Tue Dec 2 18:51:57 2003 Subject: [Ietf-not43] Minutes of the IETF58-MN CRISP WG meeting Message-ID: <20031203095150.601f0c75.ggm@apnic.net> Here are the minutes of the CRISP WG meeting from IETF-58 Minneapolis. Thanks to Cathy Murphy for scribing, and April Marine for editing. Please send any changes/issues to the list. I'll forward to the ietf secretariat in a week. cheers -George --------------------------- Cross Registry Information Service Protocol WG (crisp) Wednesday, November 12 at 1300-1500 CHAIRS: April Marine George Michaelson Scribe: Cathy Murphy [These notes are a summary done by April and George based on Cathy's excellent detailed notes. The detailed notes were sent to the list. Comments like this one that are added to summarize or clarify are in square brackets so their origin is clear.] 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 Klenson 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 - 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 ietf-not43@verisignlabs.com) 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 - Andy Newton AN: These are not the issues sent to mailing list; these have come forward since then. List items can be found in mail archives. AM: What's the next step? AN: Send to list and see who comments. AM: Andy has asked for a co-author for the IRIS documents (for XML)? ... no volunteers... [Note from April: Later Marcos Sanz agreed to co-edit] +-----+ o Additional Requirements? - Ginny Listman re: draft-ietf-crisp-internet-resource-number-requirements-00.txt AM: Are you still willing to be point person for this document? GL: Shane Kerr has agreed to be the editor going forward. [Discussion of best way to move these requirements forward given that we already have a draft req doc in RFC Editor queue. Decision is to do a "bis" or update of the original req doc, one that totally replaces the first req doc so as to capture all the requirements in one place.] +-----+ o IRIS lightweight transport - Andy Newton 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. [Presentaiton and discussion of the possibility of adding UDP as one of the IRIS transports.] 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. [as to whether there is enough demand to see if WG would add it as a work item] +-----+ o Update Charter and Milestones 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 [will send revised charter and milestons to the list--some small changes in milestones from previous msg to the list] +-----+ o Using dreg for registrar-registrar - 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. [This was an FYI to the group; some discussion and feedback for Chris.] From April.Marine at nominum.com Tue Dec 2 19:04:15 2003 From: April.Marine at nominum.com (April Marine) Date: Tue Dec 2 19:04:22 2003 Subject: [Ietf-not43] more verbatim minutes Message-ID: <20031202160009.H62639@shell-ng.nominum.com> 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 George Michaelson 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 ietf-not43@verisignlabs.com) 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? 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 | | 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. #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. From andy at hxr.us Fri Dec 12 15:44:11 2003 From: andy at hxr.us (Andrew Newton) Date: Fri Dec 12 15:37:21 2003 Subject: [Ietf-not43] serialization and named queries Message-ID: <3FDA289B.4020306@hxr.us> Happy Holidays, In writing some serialization code yesterday, I had some thoughts on minor changes to improve it. 1) Get rid of . I'm not sure there is a need for it any more, and any server supporting serialization must have a codepath that is separate from the other two children of (not to mention a separate codepath for sending it). Does anybody think we need this? 2) I noticed that serialization actually can't support serialization of direct entity references. This is an oversight. I propose the creation of a child to support both entity references and search continuations. Additionally, this means we could rip out some of the attributes from that do not make sense for sending over the wire. This would also simplify codepaths as both types would be very similar. 3) It occurs to me that the "service-definition" entity class may actually conflict with some desired name for an entity class in the future (after all, this is a service about other services). Perhaps renaming it to "iris" would be better. I think that more directly describes that it contains entities specific to the operation of the iris servers themselves. 4) While I want to do away with the thing, I do see a need for a separate entity class for tucking away all those copyright notices, acceptable use policies, etc. etc. Therefore, the "named-query" entity class should be renamed to "local" to denote that these are things locally defined. Comments? -andy