[Ietf-not43] -02 requirements draft

[Leslie Daigle]

Rick,

It comes back to the point made in the requirements document and
several times on this list:  the requirements are for a protocol
that might support any eventual servICE.  If there is no requirement
that the protocol be able to support query distribution, it will
be difficult (at best) to retrofit coordination of leaf servers into
some kind of overall service.  

So, I think it is *critical* that there is a requirement for the servER
protocol to be capable of query distribution.

Note, from the Introduction:

>    The requirements captured in this document are for the purpose of
>    designing technical specifications.  The words used in this document
>    for compliance with RFC2119 [8] do not reference or specify policy
>    and speak only to the capabilities in the derived technology.  For
>    instance, this document may say that the service "MUST" support
>    certain features.  An actual service operator is always free to
>    disable it (and then to return an error such as "permission denied".)


I.e., whether or not a given servER participates in some aspect of
a servICE is up to the operator.

Setting up a servICE that is *effective* about query distribution is
possible -- cf Peter Gietz's comments, and I'll cite my experience
with the TISDAG project as well.  In those cases, the query distribution
is actually out of band of the leaf servers, but my experience with the
TISDAG project suggested it would be *much* easier if the protocol
supported referrals and other mechanisms for... query distribution.

All of that said, I understand that you are coming at this from the
standpoint of wanting to get a usable global whois-followon servICE.
But I don't think you're correct in saying that it is a failure in
the protocol requirements document.

Leslie.

[Rick Wesson wrote:]
> Ted,
> 
> 
>> discussion is a requirements discussion.  The requirement provides
>> functionality: "Tell me all the domains administered by Example DNS
>> /Tell me all the domains owned by Joe Example".  There are
>> clear reasons to want this functionality.
> 
> no, I've asked for the requirement to be removed. only you and the draft
> author have said no. There has been almost no discussion on this list on
> or about the points in the requirements draft. I am stating that these
> requirements are not fully baked and are not nearly cooked enough for
> passing them off to the IESG.
> 
> none of the other requirements have conditions that require all members of
> the mesh to participate in a query. this type of query does deserve
> special attention because of the negative impact it could bring to those
> who provide crip resolution service.
> 
> for these reasons I request that 3.2.3 be removed as a requirement,
> otherwise please enumerate the clear reasons you have eluded to for
> retaining this functionality.
> 
> -rick
> 
> 
> 
> 
> 
> 


-- 

-------------------------------------------------------------------
"An essential element of a successful journey
    is recognizing when you have arrived."
       -- ThinkingCat (c.1983 - 2002)

Leslie Daigle
leslie@thinkingcat.com
-------------------------------------------------------------------