Ted Lemon wrote:
i took the words "at or below" to mean "in-bailiwick". caches that are
not organized as tree-like data structures still have to be able to find
the closest encloser, which means they do know ancestor/descendent
relationships, even if the data structure itself is otherwise flati
> i took the words "at or below" to mean "in-bailiwick". caches that are
> not organized as tree-like data structures still have to be able to find
> the closest encloser, which means they do know ancestor/descendent
> relationships, even if the data structure itself is otherwise flatishly
> hashli
> Perhaps we can make it explicit that the tree here is conceptual, and
> not an implementation required data structure?
That's not the point. The point is that if the _cache_ is represented as a
tree, then you can talk about names being "under" other names; if it's not,
then that relationship
On Fri, Mar 11, 2016 at 3:52 PM, Ted Lemon wrote:
> > It is certainly not the goal. Can you tell exactly where it is
> > assumed? Section 2 is supposed to be implementation-neutral.
>
> Right here:
>
>When an iterative caching DNS resolver receives a response NXDOMAIN,
>it SHOULD store it
Ted Lemon wrote:
It is certainly not the goal. Can you tell exactly where it is
assumed? Section 2 is supposed to be implementation-neutral.
Right here:
When an iterative caching DNS resolver receives a response NXDOMAIN,
it SHOULD store it in its cache and all names and RRsets at or
DNSOP
I apologize but in wanting to get two sessions to separate the 6761
riff-raff, we angered the scheduling gods, and they gave us back to back
sessions on Friday Morning.
once i get home i'll put together a preliminary agenda
for the chairs,
tim
On 3/12/16 12:05 AM, "IETF Secretariat"
Dear Tim Wicinski,
The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.
dnsop Session 1 (2:00:00)
Friday, Morning Session I 1000-1200
Room Name: Buen Ayre C size: 250
-
In message <20160311214228.ga30...@mycre.ws>, Robert Edmonds writes:
> Hi,
>
> Dick Franks wrote:
> > On 11 March 2016 at 17:47, Robert Edmonds wrote:
> >
> > > Dick Franks wrote:
> > > > There is no need to resort to doctrinal arguments about
> MUST/SHOULD, or
> > > > imagine that the RFC6844 ta
Hi,
Dick Franks wrote:
> On 11 March 2016 at 17:47, Robert Edmonds wrote:
>
> > Dick Franks wrote:
> > > There is no need to resort to doctrinal arguments about MUST/SHOULD, or
> > > imagine that the RFC6844 tail can wag the RFC1035 dog.
> > >
> > > Mark A's objection really points a fundamental
> It is certainly not the goal. Can you tell exactly where it is
> assumed? Section 2 is supposed to be implementation-neutral.
Right here:
When an iterative caching DNS resolver receives a response NXDOMAIN,
it SHOULD store it in its cache and all names and RRsets at or below
that node
On Wed, Mar 02, 2016 at 10:10:09AM +0100,
Shane Kerr wrote
a message of 29 lines which said:
> I can see that implementors such as yourself like won't bother with
> a special-cased version, and that adding code to restrict this
> technique to the root only is likely to be MORE WORK.
I know at
On 11 March 2016 at 17:47, Robert Edmonds wrote:
> Dick Franks wrote:
> > There is no need to resort to doctrinal arguments about MUST/SHOULD, or
> > imagine that the RFC6844 tail can wag the RFC1035 dog.
> >
> > Mark A's objection really points a fundamental contradiction in RFC6844
> > itself.
On Fri, Mar 11, 2016 at 04:26:19AM +,
Ted Lemon wrote
a message of 13 lines which said:
> However, I think that this document still goes too far in terms of
> assuming a particular implementation, in the sense that it appears
> to assume that the cache is a tree.
It is certainly not the g
Dick Franks wrote:
> There is no need to resort to doctrinal arguments about MUST/SHOULD, or
> imagine that the RFC6844 tail can wag the RFC1035 dog.
>
> Mark A's objection really points a fundamental contradiction in RFC6844
> itself.
Hi, Dick:
Are you implying that 6844 violates 1035 in some w
There is no need to resort to doctrinal arguments about MUST/SHOULD, or
imagine that the RFC6844 tail can wag the RFC1035 dog.
Mark A's objection really points a fundamental contradiction in RFC6844
itself.
RFC6844:
5.1.1. Canonical Presentation Format
The canonical presentation format of t
15 matches
Mail list logo
