Minutes from SLC

[Edward Lewis <lewis@tislabs.com>]

Here are the minutes from the meeting last month.  I need to turn them in,
with Jim Gould's slides real soon, so let me know quickly if there are any
edits you want to see.

===========

Buchanan appointed as the scribe.

Ed Lewis:

Document status:

Definitions dropped.
Requirements in front of the IESG.
Last call:  EPP base; host, domain, and contact info mapping; and EPP over TCP.
Two other documents:  Containers and BEEP.  Will address later.
What will happen over the next couple of months?  Last call was just
concluded.

A few comments on last call items:
Scott Hollenbeck:

* Slight issue with the way XML schema deals with choices.  Right now could
say that you want to use the same things more than once.  Tradeoff between
getting multiple repeated elements or an empty ("none").
* Modification to domain mapping so that could delegate to name server
which is not a host object.
* Last issue:  want representation in more UTF-8-ful registration format.
Eric's suggestion-why do you need both?  We could just take whatever we
get.  Requirement in requirements draft.  Redundancy and extra elements;
get rid of

Jordyn Buchanan:
* The reason we added the non-registered objects as name servers was to
solve the out-of-zone hosts?

Hollenbeck: Yes

Buchanan:  I would prefer another solution to that problem if one is available.

Daniel Manley:  What does the new schema gain us if the first address is
still ASCII?

Hollenbeck: Gets rid of some elements, just have a variable number of
address elements.

Sheer El-Showk: Wasn't there a way to have per-registrar views of out-of
zone objects.  That seems like it might solve the problem.

Wesson:  Also, there's a difference between objects and records in the
document.

---

Lewis:  Will do presentations on implementations now.  First, Jim Gould.

Jim Gould: presentation (will be attached when sent to secretariate)

Rick:  Was registry thick or thin?

Gould:  We've done both.

<unknown>:  Did -04 release.  Toolkit supports Java/C++, been out since
summer.  Have been playing with extensions, but not released.  Have 100
registrars certified on EPP-04; looking at -05 and beyond.

Wesson: Registrars noticed issues with lengths.  Can you discuss:

<unknown>: As lengths changed, been very difficult to keep up.  From an
operational perspective, would be nice to get consistent.  Haven't had to
truncate because have been growing.

Hollenbeck:  Speaking of length, one last call issue was an increase of
postal address from 64 to 255 characters.

Lewis: Now Sheer El-Showk's presentation.

El-Showk:  We did both registry and registrar implementations.  I'm not
talking about the protocol itself.  A few small points.  Contact name field
is only a single field, versus two (first, last) in Whois.  Makes for a
difficult mapping.  Name/organization; name is a required field, whereas
organization is not.  Response codes should be more informative; not sure
extension mechanism would be appropriate.  New statuses may be required.
Business logic for statuses horrendous to implement; a significant part of
the business logic.  XML very expensive for check commands.  Lots of
overhead that is not necessary; because form data is identical, makes it
easier to do cryptanalysis.  Not clear how to implement an error condition
on a single check.

Manley:  Discussion of change in semantics of check command, adding
additional returned data.

El-Showk:  I don't like the idea of making it more complicated, should the
whole check fail if 1 out of 1000 returns an error.

Gould: I would assume that if one fails.

Buchanan:  Scenarios may exist in which one out of many could fail exist.

Gould: Then just fail the whole thing if your server logic can't figure out
what to do.

Wesson: There's no provision anywhere saying Whois has to say
firstname/lastname, so that's not a big deal.

El-Showk:  I also mentioned retry commands.  Relying on commands versus
transaction ID means that it may make it more difficult in the future.  Why
not client/server ID?

Hollenbeck:  Idempotency is a property.  By it's definition, it's the
structure of the command.  Take away or adding properties could hurt it.

El-Showk:  It's in mappings, not base protocol?

Hollenbeck: Yes.

El-Showk:  Wouldn't it be useful in the base protocol?  A unique client
trans ID could allow.

Hollenbeck:  We said the server wouldn't necessarily track; it's not a
requirement.

El-Showk:  In our implementation I did.

Lewis: Now Dan Manley.

Manley: A couple of comments; we used an early version of EPP, so many
comments are now out of date.  From a registrar perspective, transfers
aren't handled very well in batch.  May want to transfer hundreds or
thousands of names.  Easy to assimilate in RRP.  In EPP, it's more
difficult because each object could have different auth_info.  Couldn't
guarantee that the same domains had the same auth_info.  If there was a way
to group, that would be good.  Other issue is contacts, and contact
objects.  They are cool, but even more difficult to transfer; might have to
transfer many contacts.  Transfer a subset of the profile.  Containers
could solve; extend domain transfer command to take all contacts with it.

Hollenbeck:  Here's a scenario-I have a domain object with a specified
registrant, and a tech contact that belongs to an ISP.  Should the domain
transfer take the tech contact with it?

Manley:  True.  Hard to solve.

Wesson:  Might be appropriate to write a document on BCP from
registry/registrar perspective.  Would be really good.

Manley: I'll try to put my notes into a document.

Gould:  When you start selling other things than domains, they have to be
completely decoupled.  Might break other product associations.

Dan: This might move onto container discussions.

Buchanan: Could transfer contacts instantaneously and then act on them,
since the contact has the authorization built in and generally no billing
implications.

El-Showk: But then your domain and contacts could be out of sync.

Buchanan: I'm talking about situations when domain has already been
transferred and domain has been left behind.

Lewis: Should we be trying to send these documents up this month?

Wesson: I would encourage the group to move the documents forward.  Many of
the comments have been issues dealing with tracking the protocol as opposed
to actual implementation issues.

Lewis:  For implementations out there, over time we want to do some
interoperability testing.  That is the real test.

Two documents still being working on.  Two promised:  EPP over mail; EPP
push.  Also some murmur of new issues.  Could start considering because
base has been worked well.  Don't want to.  Will update milestones; only
one left is about to be accomplished.

---

Anyone have comments on containers?

Manley: Containers, at first and second glance, provide a lot of good
functionality.  For registrars, could help with transfers-able to transfer
an entire profile in a single command.  Could be scary on the server side.
Billing?  Objects could be in various states.  Makes it easy to change and
do mass changes.  I had some questions that were not all answered.

Tom McGarry:  We'll volunteer to do push.  Re: containers.  Not implemented
yet.  What are options other than standardize?

Lewis:  Experimental versus standards track.

McGarry:  Customers like the idea.

Wesson:  Not convinced that transfers and containers aren't a big security
issue.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: lewis@tislabs.com

Opinions expressed are property of my evil twin, not my employer.