To:
ietf-provreg@cafax.se
From:
Hong Liu <lhongsms@yahoo.com>
Date:
Sat, 7 Dec 2002 08:40:29 -0800 (PST)
In-Reply-To:
<Pine.LNX.4.33.0212061524530.17511-100000@flash.ar.com>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: lastVerified: optional vs. extension
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 --- Rick Wesson <wessorh@ar.com> wrote: > > > 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... > > 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. > 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. > 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 > > 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. > > The notes of the physical meeting clearly state the > issue about the > 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. > > 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. 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. > > best, > > > -rick > > > __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com