Subject: RE: action items from our meeting in atlanta

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 5 Dec 2002 08:49:07 -0500

> (1) handling of external host
> (2) handling of last-verified
> 
> I would like to see a closure on each one.

Janusz's proposal [1] has had some support with no negative push-back so
far.  Does it work for everyone?

The overwhelming feeling of the room in Atlanta was that the lastVerified
element could be added as an optional contact element.  If you disagree,
maybe we need a chair measurement of rough consensus.

-Scott-

[1]
http://www.cafax.se/ietf-provreg/maillist/2002-11/msg00065.html

---

From: Hong Liu <[email-masked]>
Date: Thu, 5 Dec 2002 11:49:54 -0800 (PST)

Scott,

Please see my comments below. Cheers,

--Hong

--- "Hollenbeck, Scott" <[email-masked]>
> far.  Does it work for everyone?
On a high level, Janusz's proposal seems fine with me.
I would like to see the actual texts in the spec and
check for consistency when they become available.

> maybe we need a chair measurement of rough
Not being in Atlanta in person, I am not in the
position to judge the feeling in the room. By reading
the draft meeting minutes, I did not get a sense of
the feeling for making lastVerified optional as
overwhelming. What I saw was that people did not want
it to be mandatory. But that does not automatically
translate into making it optional. There is a third
alternative: making it as an extension.

If I understand correctly, IETF WG decisions are made
via the mailing list. I would like the co-chairs to
poll on the list on this issue: optional vs.
extension. I will leave it to our co-chairs to
formulate the question to the list. So far, at least
two people on the list are for extension, _and_ gave
good reasons for why, -:) [1]. I am for it to be an
extension. I will reiterate my reasoning once the
co-chairs poll the list.

[1] http://www.cafax.se/ietf-provreg/maillist/2002-11/msg00064.html

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

---

From: Rick Wesson <[email-masked]>
Date: Thu, 5 Dec 2002 12:09:34 -0800 (PST)

Hong Liu,

don't hold back --  post your thoughts on how to handle this issue. There
was allot of support in the room and in the halls so please be specific in
your alternate proposal.

hand-waving and promises of your reasoning at a later date don't count.

-rick

On Thu, 5 Dec 2002, Hong Liu wrote:

> two people on the list are for extension, _and_ gave good reasons for
> why, -:) [1]. I am for it to be an extension. I will reiterate my
> reasoning once the co-chairs poll the list.

---

From: Hong Liu <[email-masked]>
Date: Thu, 5 Dec 2002 13:22:40 -0800 (PST)

Rick,

I think the same standards apply to both camps. I
already stated my position and my reasoning in a
previous posting [1]. I will further elaborate if need
be. The burden of proof lies on both sides. I want to
see the reasoning from you why this element _must_ be
in the base EPP instead of as an extension. And I want
to hear from you why the effectiveness of this element
can be assessed without an established policy
framework.

Just to be clear: I am not against the utility of this
element. This is a nice feature to have IF armed with
the right policy framework. However, as others have
pointed out, this is a nice-to-have, but _not_ a
must-have, feature [2]. Most importantly, AFAIK, there
is no established policy framework that ensures the
accuracy of the data. Without it, it will be
garbage-in and garbage-out. Just adding a new element
does not really solve the problem you try to solve.
Both points indicate that this element needs further
study before it is incorporated in EPP, and thus
should be treated as an extension rather than as a
element in the base protocol.

Let's have a constructive discussion on the list. Just
getting frustrated by different opinions and
countering with accusations does not help. Please,
despite of our differences, let's have a good dialogue
on this issue. I stand to be corrected and convinced.

Regards,

--Hong

[1]
http://www.cafax.se/ietf-provreg/maillist/2002-11/msg00064.html

[2]
http://www.cafax.se/ietf-provreg/maillist/2002-11/msg00052.html

---

From: Edward Lewis <[email-masked]>
Date: Thu, 5 Dec 2002 18:57:10 -0500

Here's my metric:

Make it optional if
1) Everyone that will want to use it will do so in the same way and 
can agree on the syntax.
2) Everyone will want to be able to make use of it at some point - 
even if not regularly.
3) It's worth making a change to the core documents for this.

Make it an extension if
1) Not everyone agrees on what is should look like or how it should be used.
2) Not everyone will want the ability to make use of it.
Note that there is no #3 (would have been - it can be an extension 
after the core specs are at PS).  I won't say this because I refuse 
to consider extensions to a protocol that hasn't hit PS yet.

Everyone means 'all users of EPP clients, all users of EPP servers.' 
Implementer's opinions don't count here - except to argue over my 
choice of metrics.  Implementer's can report what they hear users 
saying.

The question isn't the goodness nor evilness of last-verified.  It's 
whether it is vital to the protocol.

PS - I refuse to poll the list.  That's voting and I won't stand for it.
PPS - I don't have a preference, I'm a chair.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Hong Liu <[email-masked]>
Date: Thu, 5 Dec 2002 20:06:35 -0800 (PST)

Ed,

Questions for clarification regarding whose opinion
counts:
- when you said users of EPP clients, do you mean
registrars/resellers?
- when you said users of EPP servers, do you mean
registries?
- when you said implementors, do you mean third party
EPP software vendors?
- how about other people who do not fall into one of
the above three categories, but are also concerned
about this topic, such as regulartory agencies? The
verification can be done via a third party other than
the registry and its registrars.

Also, questions for clarification on the metric:
- are technical issues such as simplicity, continuity,
and legacy data migrations key considerations?
- is lack of established policy framework for the use
of this element a key consideration?

Thanks!

--Hong

---

From: Edward Lewis <[email-masked]>
Date: Thu, 5 Dec 2002 23:24:47 -0500

>- when you said users of EPP clients, do you mean

yup

>- when you said users of EPP servers, do you mean

yup

>- when you said implementors, do you mean third party

uh, yeah, but that includes you (and Scott, Joe, Michael, Rick, 
et.al. - I don't mean to omit anyone, but you get the idea).

>the registry and its registrars.

no - they may influence the users, but let's keep this in 
perspective.  We are talking about whether to put last-verified as an 
optional element of the base protocol or in an extension.

>and legacy data migrations key considerations?

I can't imagine that these are important here.  (Remember that we are 
just talking about last-verified date.)

>of this element a key consideration?

I think so.  I'd hate to see two servers interpret the date different 
given just one way of expressing it.  If there are two semantics 
involved, two different ways of communicating should be present.

Think about client C and server S1 and server S2.  S1 and S2 disagree 
on last-verified date's meaning and usage.  Is there a need to keep 
the syntax the same?  It may be nice because it makes the parsing 
code the same.  But if you require them to be the same (optional 
elements in the base), you are forcing a decision to be made.  If you 
leave them to extensions, then as new interpretations of the 
last-date are made, syntax can be decided later.

(Also C can verify that it is using the right date semantics by 
looking at the XML - if you debug down to that level.)

---

From: Rick Wesson <[email-masked]>
Date: Thu, 5 Dec 2002 23:53:25 -0800 (PST)

> the syntax the same?

the semantics of last-verified-date is the same as those for other date
elements that are published in other formats (whois/crisp) in the XML the
last-verified-date uses the same "type" as created-date.

I don't see a problem with a server interpeting this data.

-rick

---

From: Klaus Malorny <[email-masked]>
Date: Fri, 06 Dec 2002 10:31:52 +0100

Hong Liu wrote:
 > [...]

I second Hong's objections. Up to now no registry I know supports this feature. 
So nobody can claim that this belongs to the base functionality of a registry. 
In this context I would like to remind you on a discussion I had with Scott in 
June 2001. There I suggested to add a field to the responses that reports the 
cost of a transaction, e.g. the registration fee for the creation of a domain. 
Scott rejected it as follows:

     I'd certainly prefer to keep registry-specific billing details out of the
     protocol.  If they have to be in there anywhere a registry could do whatever
     it wants in the <unspec> elements.  If you have a proposal in mind, though,
     please post it to the list to present a more complete picture and to gather
     other opinions.

The same argument applies to the lastVerified topic. It is registry specific, it 
is not required for the registration process in any way and therefore violates 
the KISS principle. As we discussed, a date alone has no value as registries may 
apply differnet policies *IF* they support this field. And maybe they have 
different verification methods for different kinds of entities, which they need 
to report, too. So this element might be insufficient on the other hand.

We already have a lot of registry-specific and inflexible stuff in EPP, mostly, 
but not limited to, the handling of name servers. EPP is clearly designed after 
Network Solution's registry model (before they were forced to open the registry 
to others), which is far from being generic or prototypical for the existing 
ccTLDs around the world.

Once a famous protocol designer (unfortunately, I don't know who it was) said, 
that in the aim to optimize a protocol, one should not ask what should be added 
to it, but what can be removed. In this sense, I suggest not to add this element.

regards,

Klaus

___________________________________________________________________________
      |       |
      | knipp |                   Knipp  Medien und Kommunikation GmbH
       -------                           Technologiepark
                                         Martin-Schmeißer-Weg 9
      Dipl. Inf. Klaus Malorny           44227 Dortmund
      [email-masked]             Tel. +49 231 9703 0