Hi all,

I just uploaded the attached draft minutes from our IETF 100 meeting to the 
datatracker.
If you happen to see any errors in them, please let us know within the coming 
week, so we can make them final.
Thank you very much Alexander for taking the minutes!

Jim and Antoin

Registration Protocols Extensions (REGEXT)
IETF 100, Singapore, Meeting minutes

Co-chairs: Jim Galvin, Antoin Verschuren

Mailinglist: [email protected]

================
 
Existing Documents
------------------
 
Launch Phase is in publication requested - all good so far.
 
Fee Extension (Roger Carney)
---------------------------
 
Couple of open questions from implementation - next version (09) is
ready to be published (adds just one item to the schema).  Two
questions:
 
1) "cd:avail" flag if only a partial set is returned - currently
returning 0 (unless full set is given).  Jim Gould argues for the
opposite (should be 1 even in case of partial responses) - will bring
it to the list.

2) classification on the command vs. object level - should be at the
object level (proposal to move it up to the object level) - Roger
agrees, if someone disagrees Roger will post the two last remaining
items to the list, then roll -09 and then ask for WGLC
 

Validate
-------
 
-02 was posted in August. Only a handful of comments, and currently
 looking for implementors.

Jim Gould: Option to use it for existing contacts, rather than
supplying "new" contacts?

Roger: Mainly intended for domain creates
 

Registry Mapping (Roger Carney)
---------------
 
http://www.verisign.com/assets/epp-sdk/verisign_epp-extension_registry_v01.html
 
Will talk more about it later in the Working Session

 
Milestone Review
----------------
 
Back in Chicago, got pushback on new documents from AD - should clean
up document queue, 3-5 documents are going to go to IESG before end of
year or latest Q1 2018. Discussion goal is to identify whether
documents are ready from the WG perspective.
 
3-5 people required during WGLC to indicate concensus - can be hard to
reach "non-authors" because of group size.

 
- Change Poll: Chairs think it is ready, Jacques said they intended to implement

Jim: Implementation from Neustar and Verisign. Think it is ready for
WGLC - Jim will make a request on the list. Nobody objects against
that plan.
 

- Allocation Token: same.

 
- dnsoperator-to-rrr: Needs more review, is not there yet for WGLC.

Jim Gould: Did a recent review, and has a concern about lack of
addressing of the trust relationship between dns operator and other
parties.

Jim Galvin (as individual): appreciates the 2 implementation efforts
(CIRA and CZ.NIC), however it's difficult for gTLDs to support this
for policy reasons. (Is defined out of scope in document).

Roger: As Registrar, changing data outside of the registry/registrar
loop is problematic for registrars.  Communication "along the chain"
needs to be figured out. Currently no intention to implement this.
 
Jim (as Chair) notes the Milestone for this document is coming up soon
- heads up to document authors.

 
- bundling-registration: Defines just one way / use-case of bundling,
but does not cover all options.  Suggestion from the Chairs is to make
it informational, and move it forward that way.

Jiankang Yao: We have significant implementation / operation
experience in that under .cn.

Scott: If we go to informational, then add an Implementation Status
section with the experiences?

Ning: If there are other bundling mechanisms / use cases, please feed
back to us and we can add them

Edmund Chang: Wouldn't that be worthwhile as a standard if it would be
subject to IDN bundling only?

Jim: No way to enable/disable individual registrations in a bundle,
and DNSSEC would need to be dealt with


- org/org-ext: Antoin: Documents need a thorough review, but also
implementation analysis / experience report. Suggests the authors push
for review or more implementation.

Ning: reseller draft is implemented, org drafts are not implemented
yet, research ongoing on whether implementation feasible.

Jim Galvin: Implementations in other contexts?

Ning: Registrars and .cn

Roger: Never found a reason to implement this

Jody: Have no reason to implement this - considers that information
that is of no concern to the registry. ICANN option to include it is
considered an overkill.

Jim Galvin: Falls into same category as the dnsoperator-to-rrr and
bundling - whether that's a standards track document or informational
candidate.

Scott: Since when is implementation required for standards track?

Jim Galvin: Wide applicability is, not necessarily implementation,
right.

Andrew Newton: Don't like the concept "i'm not going to do that" ->
"we won't standardize it".

Andrew Sullivan: If this WG is not the work to produce one canonical
document for a problem, then please point us to where that work is
performed.

Jim: That's what the IANA extension is for - doesn't mean everything
has to be standards track

Ning: not sure we should always spend the energy on that adoption

yes/no discussion or standards track / informational


 
RDAP jcr (Andrew Newton)
---------
 
Problem: RDAP defines JSON just in prose - no formalism -> difficult
testing.  Uses JSON content Rules (JCR
draft-newton-json-content-rules)
 
(Mario Loffredo, .it) - Following another approach than JSON
Scheme... Thinks that JCR is better because fits better to the way
RFCs are written. Thinks JCR might be less useful for other REST
services, lacks ways to describe relationships between query and
responses. Plus, only few implementations for JCR vs JSON Schema.
 
Scott: Where would the base JCR document go? This WG is not the right
place for the base JCR doc - but where is it?

Jim Galvin: Dispatch?

(??): Similar to CBOR.

(??): Really useful, easy to use, i like it.
 
Adam Roach (as AD): JCR base to be taken on in this WG?

Andrew: No, didn't say that.

Adam: Good- we just need to make sure underlying technology is pushed
forward before we have apps on top of it here

 
RDAP sorting-paging & partial response & reverse search  (Mario Loffredo)
--------------------------------
 
sorting-paging & partial-response: takes practices from REST services
to RDAP. New parameters "count", "sortby", "limit/offset", and new
properties "paging_count", "paging_links". Alternative to offset
"cursor" - logical pointer to the next page.
 
Discussing advantages/disadvantages of offset / cursor based variants.
 
Field sets - two options: List of fields vs. named sets of
fields. Flexibility vs. comfort.

Reverse search: Registries already provide users with reverse searches
(eg. domains based on nameservers).

Q: Should reverse search be based on other entities as well? Should it
be extended to the other types of searches?
 
Andy: Search - before we do anything like this, we need to get the
OAuth stuff done.  Plus, this is very foundational work, and should be
standards track work.

Scott: Please get your plate clean - RDAP is moving into operational
status, and we'll encounter more similar things which we need to work
on.
 
Discussion about registrars requiring lists - comment: We don't want
lists in EPP.

 
Interim Meeting feedback
--------------------
 
First two interim meetings were very productive, last one was zero
participation (4 or 5 people on the call).

 
AOB
---
 
Andrew: a) BCP about operating servers - sometimes hard to contact the
operators b) Draft about http vs. https, sometimes people cannot
operate https
 
Stephane: Extend 5731 RFC to allow registration via DNAMEs

Kim: The only use case was the one presented - not work on this?

Jim Galvin: Push that to the mailing list?
 
Jim: Discussion about broadening the charter to adopt other
"registration-related" documents, once the document "plate" is clean.
Before london, several documents should be off our WG, and we can
adopt more documents.
 
Alex: Search is underspecified, would appreciate working together with
others to get that fixed

Scott: Was similarly confused when writing the section to capture the
opinion of the working group (WEIRDS)
- --
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392






Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext

Reply via email to