Subject: RE: lastVerified: optional vs. extension

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 6 Dec 2002 07:52:28 -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.

I don't think syntax is a problem, but based on the discussion so far I
don't think we've met the "Everyone that will want to use it will do so in
the same way" or "Everyone will want to be able to make use of it at some
point" metrics.

> 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.

Both of these loom large based on the discussion so far.

-Scott-

---

From: Hong Liu <[email-masked]>
Date: Fri, 6 Dec 2002 08:02:03 -0800 (PST)

I concur with Scott's observation. I would say that
extension seems to be the way to go for lastVerified.

--- "Hollenbeck, Scott" <[email-masked]>
> the same way" or "Everyone will want to be able to

agree.

> Both of these loom large based on the discussion so

Agree. This is evident from the discussions so far.

> -Scott-

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

---

From: Edward Lewis <[email-masked]>
Date: Fri, 6 Dec 2002 11:08:42 -0500

Let's go with the working assumption that last-verified will be 
defined as an extension.  (I.e., consensus says...)

The plan here is:

1) An individual ID is worked on towards this end.
2) Although the mailing list is a fine place to talk about this, no 
ID on this topic is to be admitted until we get the base protocol to 
Proposed Standard.
3) We won't consider any milestones about this until we *consider* 
admitting the work.

...I say this to keep us focused on getting the current set of 
documents to Proposed Standard, not to delay 'last-verified.'

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Rick Wesson <[email-masked]>
Date: Fri, 6 Dec 2002 12:18:50 -0800 (PST)

> extension seems to be the way to go for lastVerified.

Hong,

My proposal was to have the follwoing XML in the contact-1.0.xsd:

  <complexType name="infDataType">
...
      <element name="lvDate" type="dateTime" minOccurs="0"/>
...
  </complexType>

You have advocated an extention. prposal is as complex as the "fax"
element. Registries can express this critical value that many
organizations are asking for or they may not.

Why do you prefer to add the burdon of an extention whic is much more
vobers, requireing name space negoiation by the server and extion
libraries for the client to address this ICANN and IESG issue?

-rick

---

From: Michael Graff <[email-masked]>
Date: 06 Dec 2002 20:49:49 +0000

I hate to keep bringing up old topics, but I don't see how ROIDs can be
left in the draft as they are now, when something that is trivial to define
(last verified date) is an extension, but ROIDs are required and at least
two implementors have stood up and said they're problems.

--Michael

Edward Lewis <[email-masked]> writes:

> 2) Although the mailing list is a fine place to talk about this, no ID
> on this topic is to be admitted until we get the base protocol to
> Proposed Standard.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 6 Dec 2002 18:16:47 -0500

>two implementors have stood up and said they're problems.

That's not an old topic - it's a current one...

BTW - if there are folks unhappy with the declaration of consensus 
about last-verified, speak up.  I've heard murmurs...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Rick Wesson <[email-masked]>
Date: Fri, 6 Dec 2002 15:37:15 -0800 (PST)

> about last-verified, speak up.  I've heard murmurs...

ahem...

In the atlanta wg I presented the element last-verified-date as optional,
as the "fax" element is optional in a contact elelemnt of a domain
registration.

I have reviewed the mail archives and the notes from the physical meeting
and there has only been two (2) requests for this element to be a
described in a extention once by Hong, and by Klaus There have been other
expressions of support on the list such as

  http://www.cafax.se/ietf-provreg/maillist/2002-11/msg00047.html

The notes of the physical meeting clearly state the issue about the
element being optional...

EL: OK. On the mailing list, the last message on this talked about this
     being
     optional. Not everyone agreed that all registries. So this is the
     question i
     am most interested in. Should it be optional?
RW: From the comments i have received it makes the most sense.
JP: It doesn't seem to make any sense to make it mandatory. There are
     all kinds of
     bad things about iut.
SH: I agree, it seems appropriate. The last comment was more strong
     that it should
     not be in the base, but i agree with RW on this.
RS: Ditto.
EL: We have documents in from of the IESG and I am not sure if we
    want to make a
     change at this stage.
RW: The IESG knows about this.

an optional element is very diferent than an extention and the term
extention was never presented, raised, or recomended durring the physical
meeting.

best,

-rick

---

From: Hong Liu <[email-masked]>
Date: Sat, 7 Dec 2002 05:58:16 -0800 (PST)

Ed, Michael,

Just like Scott, I am not a big fan of ROID either.
Its usage in EPP is vague at best. But that is a
different thread of discussion.

What I would like to say is while the syntax of
lastVerified may look simple, the policy issues around
its usage is not. In fact, even the technical changes
to be made is _not_ as trivial as it seems. At least
three EPP commands will be affected:
create/update/info. In addition, you also need to add
<verID> for the entity who performs the verification.
Depending on the specific policy, this entity may be a
third party that is neither the registry nor a
registrar, and there could be more than one such
entity. 

One can imagine a scenario where the address info is
verified by a Business Bureau or a post office, the
tel and fax numbers are verified by a telephone
carrier, and the email address is verified by an ISP.
And each of these may have a different <verDate>
associated with it. Now, is lastVerified sufficient to
represent all these information? Of course not! That
is why we need an extension mechanism for a registry
to define what information elements are needed in
order to comply for a specific policy framework.

This may look like an extreme case. The point I want
to make is that it is _very_ dangerous to fix
something in the protocol (i.e., assuming a specific
model) without knowing what the policy framework is
for its collection and usage. This is very similar to
the privacy issue we are dealing with. For the latter,
the WG seems to going down the path of extension.

If your guys want to know the complexity of this type
of information gathering and validation, you can ask
the ENUM folks about telephone number validation.

The bottom line: if we all agree on Ed's metric and
apply it to this issue, the only sensible way to deal
with it is to use extension.

--Hong

---

From: Hong Liu <[email-masked]>
Date: Sat, 7 Dec 2002 08:40:29 -0800 (PST)

Rick,

I agree that there were different opinions on the list
regarding whether this should be optional or as an
extension. Applying Ed's metric, this clearly
indicates that this element _does not_ meet the
criteria of being optional. I can see the value of it.
So making it as an extension is the only sensible way
to go. 

Please see my comments in line.

Regards,

--Hong

> as the "fax" element is optional in a contact

The key difference is "last-verified-date" is heavily
policy related, while "fax" is not. As I said in
another email, to make it useful, the policy framework
needs to be established. Just adding this element does
not solve the problem you intended to solve. In
addition, it may not be enough to collect all the
necessary information for your purpose. So let it be
in the extension allows maximum flexibility. If
different registries excercise different policies,
they can support different extensions.

Bottom line: Different policy framework may post
different requirements on information gathering and
verification. Since we don't know how such policy
frameworks may turn out, we cannot fix the protocol
based on the framework _we_ think that will become.

Correct. That indicates that people have different
views on making it optional in the EPP base. Does it
meet the requirements in Ed's metric for being
optional, the answer is clear: no. 

> element being optional...

I am not a lawyer, and I do not intend to interpret
the following literally. In short, arguing against it
being mandatory does not automatically translate into
supporting it being optional. There is a third
alternative: making it an extension.

> extention was never presented, raised, or recomended

What is important here is that IETF works towards
consensus based on discussions on the mailing list,
not on the spot at f2f meetings. That is the key
difference between IETF and other standards bodies
such as ITU and ETSI.

---

From: Hong Liu <[email-masked]>
Date: Sat, 7 Dec 2002 09:11:36 -0800 (PST)

Rick,

Cheers,

--Hong

> organizations are asking for or they may not.
As I explained in another email, even from a technical
perspective, adding this element is not as trivial as
you described above. I would not repeat why it is
different than "fax" here.

If it is in the base protocol, all registries will
have to deal with it, whether they support it or not,
in order to be EPP compliant. The business logic for
registry policy will be driven down to the element
level. We should try to avoid such design if we have
an alternative.

> libraries for the client to address this ICANN and
That is exactly the beauty of extension, and XML
namespace separation. The server makes it explicit in
terms of what namespaces it supports at session
negotiation. XML parsing will fail right away if a
client uses a namespace that the server does not
support. The server business logic is a lot cleaner
than handling it at the element level.

Most importantly, we don't know whether the element by
itself is sufficient for different policies to be set
up. It is premature to incorporate it in the base EPP
spec. What if different registries collect different
data for the same purpose? Then you need to use
extension anyway.

---

From: janusz sienkiewicz <[email-masked]>
Date: Mon, 09 Dec 2002 11:04:16 -0500

I agree with Hong.
From XML schema point of view, adding lvDate element looks like a simple
change (as complex as the fax element). From the implementation point of
view it is not that simple.  Significant changes may be required to EPP
object mapping documents.

Treating the feature as an EPP extension seems to be a reasonable way to
go.

Regards,

Janusz Sienkiewicz

---

From: Rick Wesson <[email-masked]>
Date: Mon, 9 Dec 2002 08:08:31 -0800 (PST)

> object mapping documents.

could you list the "significant changes" that may be required to EPP? as
the statement above is tratitionally called hand-waving, you'll need to
back yous statement up with some examples.

-rick

---

From: janusz sienkiewicz <[email-masked]>
Date: Mon, 09 Dec 2002 11:22:44 -0500

Significant changes in this case mean pieces of text that explain how relevant
epp commands and responses should handle lvDate element.

Regards,

Janusz Sienkiewicz

---

From: Rick Wesson <[email-masked]>
Date: Mon, 9 Dec 2002 08:39:19 -0800 (PST)

Hong,

> As I explained in another email, even from a technical perspective,
> adding this element is not as trivial as you described above. I would
> not repeat why it is different than "fax" here.

it sounds like you are policy adverse and have a preconceived notion on
how Neulevel would handle the policy. Since your organization is lobbing
the USG for .kids.us I am sure you have been involved in some policy
development.

> If it is in the base protocol, all registries will have to deal with
> it, whether they support it or not, in order to be EPP compliant. The
> business logic for registry policy will be driven down to the element
> level. We should try to avoid such design if we have an alternative.

Are you suggesting all registries do not have old, stale and out dated
registrant contact data and that end-users should not have access to the
accuracy of the data and that this should not be in the base protocol?

What appears to be happening is that some registry operators are more
concerned about the inconvenience of "public service" than publishing and
ensuring accurate information within their data sets.

Are you are advocating the publishing of inaccurate information as a BCP
as long as there is no way of knowing if the information is accurate or
not? And that adding a mechanism like last-verified-date would require
that some registry operators acknowledge that there is a problem?

-rick

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 10 Dec 2002 12:45:07 +0100

On Mon, Dec 09, 2002 at 08:39:19AM -0800,
 Rick Wesson <[email-masked]> wrote 

> the USG for .kids.us I am sure you have been involved in some policy

On an IETF mailing list, people are supposed to stand for themselves,
not for their company. Although this is wishful-thinking, in practice,
nobody criticized Scott's proposal on the basis of Verisign policy or
my remarks on the basis of AFNIC's policy. I suggest to continue that
way.
 
> that some registry operators acknowledge that there is a problem?

As shown in your diatribe, this is clearly a registry policy issue,
outside of the scope of the WG.