Re: [gnso-rn-wg] note on technical evidence

[Avri Doria <avri@xxxxxxx>]

Hi,

Well, it certainly is worth finding out whether the questions are  
already answered, and we should be able to do that ourselves by  
checking the RFCs for actual evidence.  But we need to be careful  
that we don't accept blanket cautionary statements from the past that  
had little or no technical investigation as the final answer.  In  
some cases, I believe that these questions, for example the question  
of whether single letter or digit TLD's would cause technical  
problems to the DNS need to be explored further.  And as I think  
about it, it may come down to needing a similar sort of experimental  
test as is currently being done for IDNs to actually know one way or  
another.
The real point I am trying to make is that we should not rely on  
proof by authority or speculation but should make sure that we have  
actual technical evidence.  And I was trying to explore what it was  
we mean when we say that we need technical evaluation; i.e what  
counts as a legitimate and useful result?
As for the amount of time this should take, while developing a new  
protocol may take 1-2 years or more to develop and even longer to  
deploy, asking for a technical analysis of an issue should not take  
nearly that long.
a.

On 9 mar 2007, at 18.20, Gomes, Chuck wrote:

> Avri,
>
> Are you suggesting that the experts in the IETF or IAB be asked  
> whether
> our questions are addressed in existing RFCs or are you suggesting  
> that
> a process be initiated that might result in a new RFC.  If the former,
> that could hopefully happen in relatively short order although it is
> possible that different opinions might come from different  
> experts.  If
> the latter, I am sure that it could not be done in 6-9 months and, in
> fact, think it would take 1-2 years.  I personally prefer the former
> approach unless there is strong evidence to support otherwise.
>
> Chuck Gomes
>
> "This message is intended for the use of the individual or entity to
> which it is addressed, and may contain information that is privileged,
> confidential and exempt from disclosure under applicable law. Any
> unauthorized use, distribution, or disclosure is strictly  
> prohibited. If
> you have received this message in error, please notify sender
> immediately and destroy/delete the original transmission."
>
>
> > -----Original Message-----
> > From: owner-gnso-rn-wg@xxxxxxxxx
> > [mailto:owner-gnso-rn-wg@xxxxxxxxx] On Behalf Of Avri Doria
> > Sent: Friday, March 09, 2007 4:26 PM
> > To: GNSO RN WG
> > Subject: [gnso-rn-wg] note on technical evidence
> >
> > Hi,
> >
> > In several of the categories there was a pending requirement
> > for technical evidence of the protocols capabilities.  I
> > wanted to say a few words about my definitions for technical
> > evidence of a protocol's capabilties.
> >
> > In my experience, there is often a lot of disagreement
> > between technical experts.  One of the reasons I value the
> > IETF processes is that they try to move beyond those
> > disagreements and beyond argument from authority by using
> > extensive open discussion followed by decisions based on
> > rough consensus and running code.  Often, when an analysis is
> > required, these are done by the IAB and designated experts
> > and then vetted in the technical community by open review
> > before they become RFCs.
> >
> > In asking for technical support on various questions of
> > protocol capability, I suggest that we ask the IETF, through
> > its liaison or directly, for the necessary analyses on issues
> > like the safety of single LDH character TLDS.  Once these
> > recommendations have been through the process and become RFCs
> > we will have the basis for designating a decision as
> > 'technical reasons'.  Short of this, I think we remain in the
> > area of speculation and argument from authority.
> >
> > Of course to do this we will have to propose specific
> > questions that need to be answered.
> >
> > BTW, I do not mean to argue that all technical issues can be
> > resolved in this way, obviously some, like those being
> > subjected to experimentation by the President's committee
> > need a different process.  I am recommending that this
> > procedure applies to issues of protocol capability - in those
> > case we need to approach the body who controls the protocol
> > and ask them to answer the questions subject to their own
> > processes.  In the case of DNS that organization is the IETF
> > and I believe that the official response to a technical
> > question is an RFC.
> >
> > One note on this, it is not certain that the IETF process can
> > respond in the 6-9 month time frame that Mike has proposed.
> >
> > thanks
> > a.