[regext] raw meeting notes...

[Alexander Mayrhofer <[e-mail]>]

Here are my raw notes:


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.