| Hello, Many LC comments were about the stale reference to RSSAC001. This RSSAC001 has been posted in december, which shall solve many issues raised. Moreover, a new version of the draft (-02) http://datatracker.ietf.org/doc/draft-iab-2870bis/ has been posted based on the comments. Below is a summary of LC comments and actions taken. Regards, Marc. http://www.ietf.org/id/draft-iab-2870bis-02.txt Marc. ===== Summary of IETF LC comments on draft-iab-2870bis A) mainly 2 individuals do not agree with the document approach, such as: - IETF should not specify what root servers do - should not be a BCP - should not be split into 2 documents - should only put historic to 2870bis However, 6 individuals responded to those comments with supporting the document and its approach. We still believe that this document is the right approach and have achieve rough concensus. B) Comment: RFC2119 language is not appropriate for a BCP. We believe that, while not a protocol specification, it provides recommendations to an implementation of the root service therefore we think it is appropriate to use this language. C) Comment: Add text on fragmentation and MTU. We believe that this is more of operational nature and therefore should not be part of this document. D) Some noted that some root servers are not supporting IPv6 at the moment. We note that we are not talking about specific root servers but the root service. Some followup comments have replied to that effect. Therefore, we think this is ok as it is. E) Comment: .arpa is not really part of the root zone. Moreover, the MAY does not do anything. We agree and removed that requirement. F) some (non-substantive) text fixes were suggested that we agreed and implemented in the new version of the document. G) a suggestion to add that "IANA has a responsibility to publish [ROOTZONE], update the root hints, and ensure the root zone trust anchor is published ». We agree on the idea, but believe this is more on IANA role than root service and therefore enlarge the intended scope of the document, therefore we did not change the document, unless the AD thinks we should. H) a suggestion to state that a root service may not answer queries in the presence of operational events such as DDOS or else. We agree on the idea, however, we believe this is an example of operational issues that should not be discussed in this document, since it would require all kind of operational qualifications and text.. I) Many comments were reflecting the absence of RSSAC001 publication at the time of the IETF LC. The RSSAC01 document has now been published by RSSAC and it has a stable reference. The reference has been updated accordingly in the document. This should solve those many comments.
|