On Fri, Nov 11, 2016 at 01:49:31AM +0900, [email protected] wrote: > 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/
As a matter of policy, software patents are almost dead. Should we still care? https://en.wikipedia.org/wiki/Software_patents_under_United_States_patent_law#Post-Alice_period "Few software patents have survived this analysis since the Alice decision largely because they are written in purely functional language to claim a result rather than describe a structure for accomplishing a result." "In short, such patents, although frequently dressed up in the argot of invention, simply describe a problem, announce purely functional steps that purport to solve the problem, and recite standard computer operations to perform some of those steps. The principal flaw in these patents is that they do not contain an “inventive concept” that solves practical problems and ensures that the patent is directed to something “significantly more than” the ineligible abstract idea itself." This matches the 7769826 patent exactly. There is nothing more technical in there than "perhaps use a hash and multiple data structures". Also, should we work with companies attempting to hinder progress by clinging to patents which are no longer enforceable? Bert > > 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: 神明達哉 <[email protected]> > > - 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 <[email protected]> > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
