Subject: RE: "ok" status on domains (and other objects)

From: Edward Lewis <[email-masked]>
Date: Mon, 2 Dec 2002 10:17:57 -0500

As a chair, I should back up what Scott says.

The document set is currently close to reaching Proposed Standard 
state.  ("Close, but no cigar" can apply at any time.)  Once the 
documents reach this stage, they are still by no means "done."  Our 
Area Director, Patrik, asked that we stick around as a WG until the 
documents reach the Draft Standard state.

What often gets lost is what it means to "become an RFC", as well as 
what Proposed and Draft mean (I even reverse them myself).  Recall 
that an RFC is "Request For Comments" and not "A Standard."  An RFC 
is just a reviewed, perpetually archived document, as opposed to an 
ID.

A description on the Standard levels is in RFC 2026, but I won't bore 
folks with the trite "go read it."  I'll make a stab at abstracting 
the difference between PS and DS here.  To go from PS to DS, 
implementations appear, implementation issues are fed back to the 
documents, and an interoperability report is needed.  So, it is 
recognized that places in which a PS is unclear will pop up and be 
fixed on the way to DS.

But what happens when a change is more severe than an implementation 
adjustment.  This can force a document set to be published at PS 
again.  Good or bad?  Depends on whether you are more concerned about 
getting it right or getting it done.

One last point I want to make about changes.  Sometimes an issue will 
be settled in a WG and then come up again once new folks come along 
with a fresh perspective and find issues.  This might uncover a 
show-stopper that needs to be revisited and maybe even cause 
documents to be published again at the PS level.  Sometimes, however, 
the new approach might be better, but the existing approach is still 
sufficient.  In this case, it pays to stick with the old.  Recall 
that "sufficient" means that it meets the requirements.  The hard 
part here for the WG is to get the proponents of the new approach to 
realize "yeah, you're right, but..." without causing serious rifts.

So - if something is an implementation detail or clarification, no 
sweat.  If something is an improvement but the existing way is still 
good enough, let it lie.  If something is a show stopper, then we 
need to at least understand the impact.  At that point, we'll consult 
with our friendly AD (who is also an implementer here) and see how we 
want to progress.

To those thinking that we are done at "becoming an RFC" - be aware of 
what that means!

At 21:15 -0500 11/26/02, Hollenbeck, Scott wrote:
>We need to understand something: the protocol documents have almost
>completed IESG review.  I don't have a lot of liberty in making changes to
>documents that have completed both WG and IETF-wide last calls (other than
>dealing with editorial issues) unless _serious_ issues are discovered.  In
>my mind, _serious_ means that a large number of WG participants agree that
>something needs to be changed _now_ and the chairs declare that we have
>consensus on the need for such a change.
>
>The answer to your first question is "yes".  I will _try_ to deal with
>wordsmithing the text to more fully explain that the default "ok" status is
>set and unset as a result of other explicit status-setting operations.  I'm
>not open to the idea of changing status behavior unless we enter into the
>_serious_ issue state as described above.
>
>-Scott-

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

---

From: Michael Graff <[email-masked]>
Date: 02 Dec 2002 18:25:57 +0000

> documents reach the Draft Standard state.

I understand the distinction here, but my concern is that putting something
that is, IMHO, very poorly thought out both in terms of implementation in
this protocol and how it will ever, indeed IF ever, be used in operation
is a serious mistake.

Once it gains RFC level, regardless of how firm the mud is, people tend to
point at it and say "but the RFC says..." and worse, "but the implementations
all do..."  The latter isn't bad, for "it's as good, but different" but is
IMHO a serious mistake to have for things that can be added later, once
they are more thought out.

Needless to say, most of the above is directed at the ROID stuff.

--Michael

---

From: Edward Lewis <[email-masked]>
Date: Mon, 2 Dec 2002 14:30:22 -0500

>they are more thought out.

The problem is that the IETF has traditionally done a poor job of 
setting expectations.  Perhaps provreg should take it upon ourselves 
to add a note to the introduction to our documents to reinforce what 
is said in 2026.  I don't know, I'm just saying.  The reason I think 
that this may be applicable here is that a lot of the folks reading 
and implementing to the documents haven't been properly warned of the 
limitations of what an RFC is and what the standards level mean.

>Needless to say, most of the above is directed at the ROID stuff.

I ain't saying you are wrong.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Joe Abley <[email-masked]>
Date: Mon, 2 Dec 2002 16:04:52 -0500

> limitations of what an RFC is and what the standards level mean.

I don't think we can assume that TLD managers are going to read the RFC 
before they start referring to it in the "Required Compliance" sections 
of their RFPs.

In the eyes of RFP-writers, I think "RFC 8192" rolls off the tongue 
nicely and has the feeling of standardisation about it. On the other 
hand, "RFC 8192 with Michael's proposed changes to deal with the ROID 
issue, not the original idea but the one he posted after Scott 
commented on his first proposal; oh, and we want to be able to delete 
an authinfo attribute from a domain, which RFC 8192 does not allow" 
sounds decidedly non-standard and awkward.

If we wind up with twenty registries all supporting different 
variations on whatever description of EPP is first published in the RFC 
series, then we're not tremendously advanced on where we are today. 
Registrars will still need custom code to talk to different registries, 
and registries will still face expensive migration exercises whenever 
they decide they need to move from one set of registry software to 
another.

I think the spec needs to be well-done before it is published as an 
RFC. At the moment it seems medium-rare.

Joe