REGEXT @ IETF 97 ================ Jim Galvin opens the meeting - shows Note Well Alex, Ulrich taking notes - Jim: Small group, suffers from low review volume Gustavo requests a few minutes to talk about "data escrow" Existing Document status ------------------------ Keyrelay --------- IPR - active patent application by Verisign. Understanding is that WG doesn't want to progress without words on licensing terms regarding the IPR Understands from mailing list that interesting in moving forward without licensing terms is low - authors ovbiously want to move forward. Alissa: Have only seen support for moving forward on the list Jim: Support was just from authors Ulrich: Want to move forward Olafur: Can we get a sense of the room? Hum: Room wants to move forward, 1-2 people hum against, will ask on mailing list too, and then take appropriate steps RDAP-Status-Mapping ------------------- Jim: Got Feedback from IANA, waiting on review by IANA Alissa: Will check with Alexey (who is still shepherding AD for the doc) Launchphase + TMCH-functional-spec ---------------------------------- Normative references issue - resolved by seperating launchphase can move forward TMCH-function-spec: Discussion on list between Gustavo and Patrik regarding matching rules Gustavo: Will have a discussion with Patrik to resolve issue, potentially next week Active docs ----------- regext-bundling: Was put on hold in this WG, pending DNSBUNDLED BoF this week Ning: BoF outcome: It is a problem, but the scope is not clear. Why does it need to be solved on the DNS layer? Next steps: make problem statement more clear, maybe create a testbed Opinion: No need to wait for DNSBUNDLED since provisioning independent from what discussed in DNSBUNDLED Richard Merdinger: Should focus on getting the simple case defined Jim Gould: seperate between provisioning and DNS side Alex: Move forward with provisoning side here, DNS side is in DNSBUNDLED Jim Galvin: conclusion: "un-hold" this document here, progress it. reseller extension: Purpose: Enable display of reseller information in RDDS Also, enable "reseller related" features Open question: simple tagging, or more complex object interaction? 4 options to go ahead - from simple name to reusing contact, to dedicated "reseller" object option D - object with different roles of reseller and registrar. - Jim: Similar use case at Verisign - Alex: flexibility adds complexity - Patrick: Why is reseller more important than a registrar (no registrar object) - Alex: Maximum thing he wants to see is "contact role" - Scott: Generic "entity" object that has "roles"? If it's just about text to be displayed, what's the minimum level to get us there - Ulrich: financial, policy, etc. information / specs - noone in the room has same requirements, will take us years. Jim Galvin (as Chair): WG has two roles: a) create extensions that several people require, and standardize those b) just register the extension with IANA - path to go forward in this case would be b) since it does not seem to be applicable to a broad community - Jabber comment: CORE needs this as well, would prefer entity object with multiple roles - Jabber: Antoine: Not dicussing business policy, but best design Linlin: Still want to make the "reseller extension" a standards track document, while the "reseller" document would just be reviewed. Jim gould: We are missing opportunity here, but sounds like the only path forward. Ning: requirement for reseller id is clear, we can still discuss the object. Comment from Antoine: Humming on A-D? Richard Merdinger: There was discussion on adding a fifth option? Alissa: If trying to get sense of the room, recommend show of hands rather than hum (for getting concensus) Option A: No hands Ootpion B: No Hands C: Four hands in the room D: One hand in room + 2 hands in jabber E: Two hands in the room regext-epp-fees --------------- There is interest in moving document forward, looking for a new editor, waiting for a revision WG documents (part2) -------------------- allocation-token: change-poll: verificationcode: nv-mapping: Is an informational doc Nils: verificationcode: parts missing, specifically privacy considerations seems it's an implementation of the Verisign RSEP. Look at privacy guidelines + human rights within hrpc Jim Gould: Please post concerns to list, think that extension has no PI data Nils: verification might create hindrance for people to create domain names "Live meeting Work" ------------------- Can we do some actual work during a meeting? Suggestions to have a U-shape room (Alissa), have one "editing" session and one "reporting" session. Divide up WG in smaller groups for editing session. draft-carney-regext-validate ---------------------------- since berlin: moved from a seperate command into the "check" command Kal Feher: Narrow solution, is there work on other validators? Roger: Key/value mechanism is in there, could be used .. Hum for Adoption: Document is adopted (pending confirmation from list) Scott: please consider adding "Implementation Status" section to document, same for other documents Data Escrow (Gustavo) --------------------- Two "Escrow" drafts exist, but no WG. Feels that the new charter of the group allows moving them into the group. use case is (besides escrow) also transitioning data Currently two expired drafts Jim: Suggestion to post a note on the mailing list describing the drafts, need to doublecheck with AD whether that fits into our charter. Scott: Have three individual items on implementing RDAP: Please talk to me if interested about them: 1) authentication 2) search (with regular expressions) 3) bootstrapping (for entity queries) All three docs are listed as "related" docs.