Jinmei-san, thanks very much for your detailed comments. I also received IPR claim from Nominum.
https://datatracker.ietf.org/ipr/2907/ https://patents.google.com/patent/US7769826B2/ I {will,need to} remove detailed algorithm {,to avoid IPR}. Then, I will change the main contents to focus on problem collection and proposal of requirements. > From: 神明達哉 <jin...@wide.ad.jp> > - general: the title and file name seem to be too generic for the > actual content. I suggest making them more specific, focusing on > the subject of this draft. Agree. (I will submit next version to remove detailed algorithm to avoid IPR problem.) > - Section 1 > > [...] And it may break requirements of resolvers' > answers described in Section 3.2. > > I don't get it. Specifically which requirement does this refer to? > And, specifically how this override break that requirement? Ok, I will add more text... > - Section 3.1 > > As described above, parent side NS RRSet makes a new zone. Parent > side NS RRSet (referral) and glue records are all the information to > access servers for the child zone. > > That is, resolvers SHOULD NOT use child side NS RRSet to iterate > zones. > > There seems to be a logical leap between the first and second > paragraph; I don't get why we SHOULD NOT use the child side NS > RRset for subsequent iteration simply because the parent NS RRset is > used for the iteration first time (which I guess the first para > tries to say). In fact, the child side NS RRset might be a more > complete, accurate and up to date set of the NS, while some part of > the parent NS RRset may be unusable. This is related to the high > level comment I made in my previous message - I see and support the > seeming background motivation of this requirement, but I believe we > need more careful considerations and probably a much less drastic > update. I agree that we need more careful consideration. > - Section 4 > > However, people sets different NS RRSets with mistakes, or > intentionally. > > Specifically what kind of intent does this "intentionally" mean? I considered "intentionally means "malicious idea". next version will relfect your excellent comment. Regards, -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
