Re: [dbound] Fw: New Version Notification for draft-yao-dbound-dns-solution-00.txt

[Casey Deccio <[e-mail]>]

On Tue, Sep 29, 2015 at 5:06 AM, Jiankang Yao <[e-mail]> wrote:

>        I submit a draft about dbound solution.
>        any comments are welcome.
>
> Thanks for the submission.  I have read the draft and provide comments
below.

General - One of the challenges I have in following this is with lack of
use cases, including how this mechanism applies to those cases.  Several
concrete uses of the PSL are documented elsewhere, and those would be a
starting point.  It is hard to tell what this adds without those cases.

Expiration/Inception - as others have expressed, this is entirely
unnecessary and simply adds complexity.  Expiration and inception in DNSSEC
are to prevent replay, but in this context, the issue seems to be more
about convenience.  The records could just be added and removed at the
desired time to have the same effect.

Relation - draft-deccio-dbound-name-relationships-00 (referenced) does
indeed mention two types of relationships, but the point of that
distinction was to divide the problem space, not to indicate that those
relationship types needed to be identified explicitly in a solution.  In
fact, ancestral relationships are identified simply by comparing two
names--that exists inherently in the DNS (and it is noted in the referenced
relationships draft).  The policy relationship is what is undefined,
whether two names are already ancestrally related or not. This field
therefore is unnecessary and potentially problematic.  How would you
anticipate it being used?

Target names - the PSL is used as an example for a service location example
of the Target Name field.  I'm not sure exactly what that means.  The PSL
only indicates boundaries, not relationships.  That is, it cannot confirm
relationships, only repudiate them.  It seems to me that perhaps this was
an attempt to leverage an existing technology for backwards compatibility,
but the PSL simply doesn't provide the same type of service as what I think
you are trying to provide otherwise.

Administrative boundary - the term "administrative boundary" seems to take
the place of "relationship" later in the text.  There subtle distinctions
between boundaries and relationships.  For example, there is a reference on
page to knowing "whether two names A and B share the same administrative
boundary".  I suppose I'm still thinking of boundaries in the namespace
here, in which case two names might be "policy-related", but they might not
"share" boundaries.   In any case it is not clear what is being
referenced.  Examples would be very helpful for clarity.

Regards,
Casey