[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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

Home | Date list | Subject list