> On Jul 28, 2018, at 2:30 AM, Tim Wicinski <tjw.i...@gmail.com> wrote: > > (these are just my comments alone. So take it as such)
Thanks Tim, I don't think these questions are already answered, so thank you for bringing them up. > > The draft states in the Motivation section: > "The motivation and design of this protocol enhancement is tied to the DNS > root zone [InterNIC]." > > Your Design Overview states that this will work for zones that are > "relatively stable and have infrequent updates". I think some descriptive > text about the type of zone this RR type attempts to address should be more > clearly spelled out in your Abstract. Noted. > > For the ZONEMD RR Type, where in the registry do the authors think it should > go? While some of that falls on the Expert Review process, I think the > document authors should capture their rationale in the document. If the > proposed RR Type is greater than 256 (which I think it does), it does not > appear to require a Standards Track document, just Expert Review. Thanks. Is there a proper way to word such a request? Looking at RFC6895 I'm not seeing a real difference in the way that ranges "<=127" and ">=256" are described. > > I ask this since the document is listed as "Standards Track" and the document > is narrowly scoped to focus on the Root Zone. Additionally the document > states: "This specification is OPTIONAL to implement by both publishers and > consumers of zone file data." This appears to be contradictory to me, but > hopefully someone can illuminate me. > > I ask all of this because we have seen the working group start to push back > on similarly scoped Proposed Standards (kskroll-sentinel). > > Though I do find it amusing that you use "The Camel" as the excuse for such a > limited scope use case, even while requesting a Proposed Standard! I can accept that Standards Track is the wrong choice here. Chalk it up to my naïveté. I suppose Experimental would be more appropriate? DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
