Hi Jay, Apologies for the late response. Thanks for your attention and feedback.
> I've read this draft now and my feedback is: > > 1. the linkage to domain names is defined by the briefest of paragraphs, to > quote: > > > For example, there is a clause used to specify the "example.com" zone > > that the name server needs to support, and the mechanism of zone > > transfer for this zone is AXFR. Then the NAME of a CZ for this > > clause is "example.com", the CLASS of this kind of CZs can be defined > > as "Zone", the type of a CR for the mechanism of zone transfer can be > > defined as "zone_transfer", and the RDATA will contain the following > > characters "AXFR"." > > This needs a clear and unambiguous definition. > > it also needs a definition of a) how the name matching is meant to work and b) > how the service is to be located. The 01 version of this draft definitely needs a further improvement. I'm planning to update this draft before IETF 80, and I'm sure to make these paragraphs more clear. > 2. the use of DNS as a transport is not thought through and does not work as > specified. DNS is a binary format and yet some key fields of this proposal are > text based and no transformation to the binary format is given. For example, > the doc says: > > > TYPE: A type of the requested CR. This fields are represented as > > a sequence of labels, where each label consists of a length octet > > followed by that number of octets. > > but in DNS this is a two octet field. A new OpCode is required by this draft to identify a queries or responses message of the automated synchronization mechanism for the configuration data of multiple DNS name servers. The format of Configuration Record is based on the section 3.2.1 of [RFC1035], with some fields (such as TYPE field) redefined by this draft. > 3. If a two octet type code was defined for TYPE, then either this is chosen > without regard to DNS RRtypes, and so the same set of data sent over the wire > (i.e. a DNS packet using a particular RR and a packet in this protocol using the > same two octet identifier as that RR) can only be understood when the context > of where that data was used in known. Or if the two octet code is defined > with regard to DNS RRtypes to avoid conflict, then this is creating RRs by a > backdoor. A new OpCode is used, so I think there won't be any confusion you mentioned. > 4. I don't agree with the principle implicit in this draft that DNS can be used > to hold configuration data for nameservers that is not related to DNS. For > example this could theoretically include telling the nameserver to restart or > turn on logging, which is a fundamental change of use of DNS and one to > which it is unsuited. This draft only focuses on providing an automated synchronization mechanism for configuration data of DNS name servers. What kinds of configuration data needed to be synchronized should be decided by others (such as DNS administrators or DNS experts of DNSOP WG). Actually, the principle implicit in this draft is that DNS can be used to hold configuration data for nameservers that is related to DNS name servers (not related to DNS). IMO, turning on logging within your example is one configuration item for DNS name servers, so it might be supported by this automated synchronization mechanism. But I think restarting of DNS name servers within your example belongs to Control not to Configuration. As you know, management operations are divided into four categories by the requirement draft [draft-ietf-dnsop-name-server-management-reqs-05]. These are control, configuration, monitoring and alarms. So far, this draft only focuses on solving the problems belong to the second category (Configuration category). > 5. The approach of leaving others to define the CRs renders this unusable. > The feature set of nameservers is well known and any protocol must attempt > to enumerate those and provide a well thought out framework for > representing them to provide minimum usable functionality and to prevent > inconsistencies appearing later. +1. I definitely agree with you at this point. I think the 01 version of this draft is still in a very early stage. A lot of further work needs to be done in future. Cheers, Ning _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
