From: "James Galvin" <galvin@elistx.com>
To: "Registration Protocols Extensions WG" <regext@ietf.org>
Date: Fri, 15 May 2020 12:25:39 -0400
Message-ID: <6669F1B7-897D-4DA8-B14F-D84E0B6D4C09@elistx.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="=_MailMate_74B7A362-5265-4E8E-8C71-D95DE4728DE6_="
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/aAkIx8fntAuEdN6Q4M382dEylGU>
Subject: [regext] minutes from IETF107 Virtual Interim Meeting
Precedence: list


--=_MailMate_74B7A362-5265-4E8E-8C71-D95DE4728DE6_=
Content-Type: text/plain; format=flowed

Sorry for not sending this sooner.  We mistakenly believed that 
submitting them to the proceedings would alert the working group.

Attached please find the minutes as taken by Zaid AlBanna.  He provided 
these right after the meeting.  Thanks so much for doing this Zaid!

They have been submitted to the proceedings.  However, please do review 
the summary and let us know if there are any corrections or updates.  We 
will take those on board and update the proceedings as needed.

Thanks to Zaid and thanks to all for your review!

Antoin and Jim

--=_MailMate_74B7A362-5265-4E8E-8C71-D95DE4728DE6_=
Content-Disposition: attachment; filename=regext-107-minutes.txt
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

The Registration Protocols Extensions (regext) Working Group
Virtual IETF107 meeting on 2020-04-27 from 17:00 to 19:00 UTC

Webex Link:
https://ietf.webex.com/ietf/j.php?MTID=3Dm324df1905fea9a26595469217a900a8=
3
 =

Co-chairs: James Galvin, Antoin Verschuren
Mailing list: regext@ietf.org
 =

*****************************************
 =

Monday, April 27th, 17:00-19:00 UTC, Webex
 =

 =

1. Welcome and Introductions (10 minutes)
 =

   i.   Jabber scribe
   ii.  Notes scribe
   iii. NOTE WELL
   iv.  Document management
   v.   Special attention document shepherds
 =

 Notes:
 =

            - Please use full name in webex chat. (Reverse etherpad)
            - Jabber scribe was forgone
            - Will address doc management later
            - RFC 8748 Extensible Provisioning Protocol (EPP) published c=
ongrats
            - Two documents : =

                        - Data Escrow Specs
                                    - Working on logistics
                        - Domain Name Registration Data (DNRD)
            - Domain Bundling
                        - Had two BOFs
                        - Submitted to IESG
                        - IESG working with authors to publish this as an=
 individual submission =

                        - It has expired, it is not a part of this workin=
g group
            - Milestones review:
                        - Three documents are falling behind. Need author=
s to step up and decide what to do. =

                        - Four other documents in flight. Keep in mind as=
 work gets reprioritized.
                        - One other document referenced by Gustavo
            - Questions/Comments:
                        - None

2.   Existing work, newly adopted drafts since last IETF106. (40 minutes)=

 =

  i.  Registry Maintenance Notifications for EPP (Sattler/Carney/Kolker?,=
 20 minutes)
  https://datatracker.ietf.org/doc/draft-ietf-regext-epp-registry-mainten=
ance/

Notes:
            - Roger Carney presenting.
            - History =

                        - How to standardize maintenance notifications. D=
ifferent emails, different registries, etc. =

                        - First draft oct 2017, adoption request in 2018.=
 =

            - Working Team: =

                        - Tobias Sattler, Roger Carney, Jody Kolker
            - New feedback from Patrick will be presented to move forward=
 with the process. =

            - Qs/Comments:
                        - Alex Mayrhofer: Are there consensus to move the=
 document forward ?
                        - Ans: Not much discussion for the past year or s=
o. Just looking to finalize.  =

                        - Is the source of the silence because everyone i=
s happy or no one has not read it ?
                        - Agreed so will be pushing forward. =

            - Next steps:
                        - address open question
                        - If any change will create a new version. =

 =

  ii. EPP Unhandled Namespaces (James Gould/Martin Casanova?, 20 minutes)=

  https://datatracker.ietf.org/doc/draft-ietf-regext-unhandled-namespaces=
/

Notes:
            - James F. Gould presenting =E2=80=A6
            - Overview:
                        - Purpose: Server should not return objects and e=
xtensions to clients not in login services . Defining operational practic=
e, use RFC 5730. Plus provide reformatted reason for processor to monitor=
 the existence unhandled namespaces.
                        - General EPP Responses.
                                    - Server may use unhand. Namespaces a=
pproach for general EPP responses
                                    - Should be applicable to only comman=
d-response extensions
                                    - Example includes RGP information in=
 RFC 3915
                        - Poll message EPP responses.
                                    - Server MUST use unhandled  name spa=
ce approach for poll message
                                    - MAY be applicable to both object le=
vel and command response. Extensions
                                    - Example includes namespace informat=
ion to be processed later by client. =

            - Implementation Experience:
                        - Discussion .
            - Posted message (https://mailarchive.ietf.org/arch/msg/regex=
t/kjTGIfkm5ednf2l0rSe-FltYLzQ/) to the list applies to BCP/EPP =

                        - Q1: Is signaling needed in EPP for the implemen=
tation of BCPs?
                        - Q2 : Does signaling mechanism existing today me=
et the need. =

                        - Q3 : Type of URI (object or extension ). EXT is=
 most important to support
                        - Q4:  Groups under EPP name space, create BCP su=
b space under name space. =

                        - 01 Version was posted last week. Included regis=
tration for EPP extensions , Added signaling section when BCP is supporte=
d by client or server. =

                        - Unhandled namespace approach, service URI needs=
 more discussion. Need to maintain compliance with RFC 5730. Enable poll =
queue messages to be consumed independent of client login services. =

            - Qs/Comments:
                        - Document is best current practice, questioning =
whether is should be a standard or not ? If no feedback received what the=
 next steps should be?
                                    - Both drafts have been updated. A ve=
rsion was created to answer the questions. =

                        - Patrick: suggest to make response more explicit=
 by not using the human readable reason element, BCP for EPP not to be ha=
rd coded, and not sure if these drafts are the best solutions. =

                                    - Agree with the intention of the usa=
ge. Not sold on inclusion of BCP in URI, but open to suggestions. Hope fo=
r a final URI as the document matures. =

                        - Barry: Doc status issue. RFC 2026 section 3. Ev=
en through doc do not create protocol, they can be a standard. Suggest to=
 read that RFC 2026 and see if it applies to this work. =

                        - Ulrich: There has been a disagreement to this d=
raft. Do not think this is made for standards track. =

                        - Barry: BCP and standards are treated equally. =

                        - Jody: Whether signaled in URI or not, BCP needs=
 to be in the logging at minimum. It is more operations friendly. =

                                    - Should it be in both greeting and l=
ogin? Maybe both, maybe greeting is more important. Needs further conside=
ration. =

                        - Alex: What is server to do when multiple unhand=
led namespace elements? =

                                    - This is addressed in the draft
                        - Scott: Can we consider experiment status?
                        - Ulrich: Client and server need to know unhandle=
d namespaces when negotiating.


  iii.EPP Secure Authorization Information for Transfer (James Gould, 20 =
minutes)
  https://datatracker.ietf.org/doc/draft-ietf-regext-secure-authinfo-tran=
sfer/

Notes:
            - Problem:
                        - Review security of authinfo. To support secure =
storage - short lived. =

                        - Draft does not scope policy
            - More details of the problem provided. =


            - Support of secure authinfo for other than transfer
            - Empty authinfo stored as null
            - Reference use of SHA-256
            - Support indication of set or unset authinfo in the info res=
ponse of registrar. =

 =

            - Changes:
                        - Request for new transition consideration sectio=
n
                                    - starting with base case. A classic =
authorization informational model is defined. =

                                    - three phases - feature compatible, =
storage, and enforcement were presented. =

 =

            - Conclusion
                        - no new extensions or protocols required =

                        - Authinfo can exist only during transfer process=

                        - Authinfo can have client managed TTL
                        - Authinfo is not stored by the registrar and sto=
red as a hash by the registry
            - Qs/Comments:
                        - Hash algorithm suggest salted version of SHA-25=
6
                        - Many aspects in the draft are not related to EP=
P
                        - Why authinfo needs to be stored as =E2=80=98nul=
l=E2=80=99, not every registry uses same type of database.
                        - EPP is a provisioning protocol and its mechanis=
m is important. With respect to NULL value does not require the use of a =
particular database. Use whatever is null in the database used.
                        - Document mixes protocols with operations instru=
ctions. Suggest the operational aspects to be minimized or move to a diff=
erent document. =

                        - Feedback on transition section is welcomed. =



3.   Existing work, almost done (10 minutes)
 =

  i.  RDAP Partial Response (Mario Loffredo, 5 minutes)
  https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-partial-respons=
e/

Notes:
            - Mario Loffredo.
            - Reviewed changes based on feedback received . Still process=
ing some remaining feedback
            - No questions:
 =

 =

  ii. Query Parameters for Result Sorting and Paging (Mario Loffredo, 5 m=
inutes)
  https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-sorting-and-pag=
ing/
 =

Notes:
            - Mario Loffredo.
            - Reviewed changes based on feedback received. =

            - No questions
            - Getting more feedback after last call. =



4.   Other work (40 minutes)
 =

  i.  7482bis and 7483bis (Scott Hollenbeck, 20 minutes)
  https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rfc7482bis/
  https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rfc7483bis/

Notes: 7482bis
            - Scott Hollenback =E2=80=A6
            - Status of drafts designed to capture corrections and clarif=
ications needed to advance to protocol track.
            - Change#1:
                        - What is an internationalized domain name ?
            - Change#2:
                        - Registrars are entities =

            - DNR =3D Domain name registries or registrar
            - Bootstrap registry which is incomplete to support (see RFC =
8521) =

            - Section 3.1.1, 3.1.2, 3.1.3 =

            - Suggested =E2=80=98JSON objects=E2=80=99 value to JSON obje=
cts properties
            - Strike text in section 3.2.1 and 3.2.2
            - Section 4.1 - a character string representing domain label =
suffix
            Qs/Comments
            - Alex: Slide 9: is YYYY a representation of an IP address ? =

                        - Scott will review the discussion related this s=
lide. =


Notes: 7483bis
            - Similar approach
            - Description of a handle , handle is a string
            - Definition of identifier =3D string
            - Unicode characters were morphed. This has been corrected
            - IPv4 was described as v6. Change completed. =

            - Definition of a country. =

            Qs/Comments:
                        - This WG has to decide evolving this standard. T=
hese are standards track document. Are there any other things to add ?
                        - Scott: Qualified =E2=80=98technical changes=E2=80=
=99. The discussion is still on RDAP level 0. =

                        - What are the next steps for these documents ?
                                    - Intention is to update the docs bas=
ed on comments received. =

 =

 =

  ii. Simple Registration Reporting (Joseph Yee, James Galvin, 20 minutes=
)
https://datatracker.ietf.org/doc/draft-yee-regext-simple-registration-rep=
orting/

Notes:
            - Joseph Yee:
                        - Registries produce different reports. Need to s=
tandardize the reports. Examples shared. =

                        - In order to standardize these reports, the colu=
mns headings need to be registered with IANA
                        - Define what fields in the reported, shard field=
 samples.
                        - The reports need to be registers as well. Share=
d reports names. =

                        - Reports baseline requirements: CSV, first line =
in columns, what to do with odd columns
                        - More discussions needed to address fields types=
, like date, =

                        - Report storage structure (hierarchical versus f=
lat)
                        - Discussion on separator types (comma, versus ot=
her symbols)
 =

            -Qs/comments:
                        - Suggested a certain type of characters to use. =

AOB
            Thanks everyone. Chairs apologized for not turning on recordi=
ng until the meeting was half through

--=_MailMate_74B7A362-5265-4E8E-8C71-D95DE4728DE6_=--