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

["Gomes, Chuck" <cgomes@xxxxxxxxxxxx>]

Thanks Avri. A technical analysis might be a sound recommendation.  I
wonder what would be the best way for that to happen?  How would
something like that be initiated?

The RSTEP was not designed exactly for this purpose, but it is a process
that is in place and the process has specific time limits.  If it is not
possible to use the RSTEP for a somewhat general purpose instead of for
a specific registry service proposed by a registry, then a possible way
for this to happen would be to recommend that registries individually
propose services for releasing single-character names at the
second-level; that could then involve the use of the RSTEP if there was
any concerns about security and stability.  This could work at the
second-level but not directly at the top level unless we recommended
something like this: "If there is an application (or applications) for
single-character top-level domains, the RSTEP process should be used to
evaluate stability and security concerns."  Or we could recommend that
the RSTEP role be expanded to deal with applicable new gTLD issues such
as this, a consideration that I think has been mentioned a few times in
the Dec05 PDP.

I agree that "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."  I would add ". . or that no longer
have technical validity."

Regarding your suggestion of a technical test, it seems to me that we
already have that at the second-level because of the fact that there are
single-character names already registered, so it doesn't appear to be
needed there.  But it could be considered at the top level if there is
evidence of technical concerns there, but I think there should be
reasonable evidence of technical concerns before going down that path.

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: Avri Doria [mailto:avri@xxxxxxx] 
> Sent: Saturday, March 10, 2007 12:23 AM
> To: Gomes, Chuck
> Cc: GNSO RN WG
> Subject: Re: [gnso-rn-wg] note on technical evidence
> 
> 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.
> >>
> >
> 
>