On 11/13/16 6:16 AM, Edward Lewis wrote: > I read through the document and had a lot of comments, so maybe I need to > "back up a bit." > > I'm conflicted over documents that define good operational practices over top > of a standard protocol. There's much evidence we need this, for example, > just to pick one, the number of TLD zones with very large DNSKEY sets. On > the other hand, confusing operations and protocol can impair efforts to > improve the protocol, such as how round-robin made DNSSEC more difficult in > needing to define a canonical order of the resource records within an RR set. > > I'd support this document but it has to state up front that it has a limited > scope, which needs to be properly defined.
traditionally we would call that an applicability statement. I think that's quite useful particularly if there are cases where it should not be be employed. > The origin of my comment is section 2.1 which says that a delegations' name > must be a hostname (a'la RFC 1123) and further that registered names are > generally good for this. I know that there's no need for a delegation's name > to be "printable" in general, the only delegation I can't make work (with > DNSSEC) is '*'. > > E.g., there's no reason I can't have "\007.mylab.mydept.myorg.example" in my > zone. Of course, that would not be very easy to access via a web browser > location bar. > > Contrary to that, I had few "problems" with section 3 because it states up > front "the public Internet DNS hierarchy" as the application domain. Section > 2 and earlier didn't scope the work. > > What I can't find is a definition for, what is called in section 8, a "fully > functional" delegation. Again, that is tied to the lack of scope. > > And, (as this dives deeper than I intended to mention), in section 8.2 there > is this: > > "Any DNSKEY algorithm number used for in a zone MUST be assigned by IANA." > > Does that include PRIVATEDNS (253)? (To pick nits, it's not DNSKEY algorithm > number, it's the registry of DNS Security Algorithm Numbers.) If someone > uses that "IANA assigned" number they won't be "fully functional" for some > interpretation of "fully functional." And ... I think IANA "assigned" is the > wrong verbage, perhaps IANA registered. By now I've gone far into the weeds. > > I'd like to see the document state or define what kind of delegations it is > covering. I think it is fine to define a kind of something more generic and > apply rules to that. Much in the same way that IDNA defines rules for > IDNA-aware applications while not altering the basic protocol definition. > > Bottom line - there ought to be a way to provide operational guidance to > participants on the global public Internet while allowing for continued > permission-less innovation. Guidance is needed but don't give it in a way > that can be used to stop anyone from trying other things in their sandboxes. sure > > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
