> On Jan 28, 2017, at 5:20 PM, Casey Deccio wrote:
>
> My recommendation is that 1) this sentence is rewritten as follows:
>
>> The term "verification" is used
>> interchangeably with "validation", in the sense of the third
>> definition
Thanks for the efforts that went into the new revision of the DNS Terminology
draft. Just a few comments on the new "Validation" section:
> The first two definitions above consider the only validity of...
Should be "only the" instead of "the only" (that typo was inherited from the
text I contr
On Thu, Aug 4, 2016 at 1:16 PM, Paul Hoffman wrote:
> Greetings again. There are six terms that are commonly used when we talk
> about DNSSEC:
> - validation and validate
> - authentication and authenticate
> - verification and verify
> Are they defined in any RFCs that we can use for the term
Hi,
Some thoughts below, strictly on the NSEC/NSEC3 algorithm. They're quite
rough, but hopefully they're useful.
Cheers,
Casey
On Tue, Jul 7, 2015 at 5:20 AM, wrote:
> Please check this algorithm.
Several times, the phrase "query as usual" is used. However, something
might need to be said
On Tue, Jul 14, 2015 at 1:15 PM, Tim Wicinski wrote:
>
> On 7/14/15 12:26 PM, Tony Finch wrote:
>
>> Paul Hoffman wrote:
>>
>>>
>>> This is still contentious, and I think it really should be deferred to
>>> the
>>> -bis document for longer discussion and hopefully consensus.
>>>
>>
>> As far as
On Tue, Jul 14, 2015 at 12:00 PM, Paul Hoffman
wrote:
> On 13 Jul 2015, at 14:20, Casey Deccio wrote:
>
> 1. (stylistic) There are a number of definitions that quote terminology
>> and
>> then parenthetically state "quoted from". It seems more intuitive,
>
More comments below.
Cheers,
Casey
1. The definitions of iterative mode and recursive mode still seem a bit
awkward. Also, the bit about answering from cache doesn't seem to be a
part of recursive mode, but of general response to queries. And the
discussion of the distinction between recursive
Hi all,
I have a few comments on the latest draft-ietf-dnsop-dns-terminology
(-03). There will be more; I'm part way through a review.
Thanks,
Casey
1. (stylistic) There are a number of definitions that quote terminology and
then parenthetically state "quoted from". It seems more intuitive,
pr
On Mon, May 4, 2015 at 10:32 AM, Casey Deccio wrote:
>within document itself and not necessarily beyond.
>
typo: there should be a "the" after "within".
Casey
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
I am still a bit uncomfortable with the -01 definition of glue,
specifically the reference to RFC 2181. I think the reference to RFC 2181
is useful and necessary, but I hesitate to think that RFC 2181's use of
glue is a redefinition that is intended to apply outside of the RFC
itself. That is, I
On Mon, Apr 6, 2015 at 1:38 PM, Edward Lewis wrote:
> So, it's important to come to a common set of terminology which reflects
> how we understand the DNS to be built today, less important to rectify this
> with the past documents.
>
...except we're referencing those documents heavily to build t
On Sat, Apr 4, 2015 at 12:37 AM, Andrew Sullivan
wrote:
> On Fri, Apr 03, 2015 at 02:23:52PM -0400, Casey Deccio wrote:
> > I've re-read the definitions of zone apex and delegation point in RFC
> 4033
> > (in conjunction with review of draft-hoffman-dns-terminology-02)
On Fri, Apr 3, 2015 at 3:32 PM, Edward Lewis wrote:
> Delegation Point: the collection of records at a name which owns an NS set
> that are visible in the parent zone.
>
Zone apex: the collection of records at a name which owns an NS set that
> are visible in the child zone.
>
> "Visible" is a no
On Fri, Apr 3, 2015 at 2:52 PM, Edward Lewis wrote:
> IMHO, the original text in 4033 is correct as it is for the first proposed
> errata. The notion that zone cuts are between nodes was blown away by the
> DS record, and when I've ever white-boarded a DNS hierarchy, the cut goes
> through the n
I've re-read the definitions of zone apex and delegation point in RFC 4033
(in conjunction with review of draft-hoffman-dns-terminology-02) and it
seems to me that they are not consistent with RFC 1034 notions.
Additionally, there appears to be some misusage of the terms in the
document itself. An
On Thu, Apr 2, 2015 at 4:06 PM, Patrik Fältström wrote:
>
> > On 2 apr 2015, at 21:51, Paul Hoffman wrote:
> >
> > Given this thread, I propose the following for the draft:
>
> Well, I would change things around so that it is more clear primary and
> secondary are the terms to use today, like:
>
On Fri, Mar 13, 2015 at 7:00 PM, Paul Hoffman wrote:
> Casey noticing the updated, wider definition in 2181 kinda throws a wrench
> into the "what is not glue" discussion. Here is a proposed update to the
> draft that includes both definitions and discusses the ramifications of the
> update.
>
>
On Fri, Mar 13, 2015 at 5:32 PM, Tony Finch wrote:
> Casey Deccio wrote:
> >
> > It seems like a reference to delegation NS records is also in order,
> based
> > on previous discussion:
> >
> > From:
> > "... the authoritative delegation (NS)...&qu
On Fri, Mar 13, 2015 at 12:55 PM, Paul Hoffman
wrote:
> On Mar 13, 2015, at 9:33 AM, Evan Hunt wrote:
> > Given the amount of discussion this topic has generated, and the number
> of
> > ways I've seen the word used in the past (and, in fact, have used it
> myself
> > when speaking imprecisely),
On Thu, Mar 12, 2015 at 2:10 PM, Paul Hoffman wrote:
> On Mar 12, 2015, at 10:59 AM, Tony Finch wrote:
> >
> > Patrik Wallström wrote:
> >>
> >> Glue Name Records are defined as all NS records pertaining to the child
> >> domain that are delivered by the nameservers for the parent domain.
> >>
On Mon, Jul 28, 2014 at 10:05 AM, David Conrad wrote:
> Hi,
>
> On Jul 28, 2014, at 5:48 AM, Nicholas Weaver
> wrote:
> > The IPv6 net has decreed “No, really, FRAGMENTS DO NOT WORK”.
>
> This could be a bit of an issue when the DNSSEC root key is rolled. Could
> someone point me to a writeup an
21 matches
Mail list logo
