Hi JINMEI, Thanks again for your comments.
> For a higher level points, it looks like we simply have to agree to disagree. I > have no particular incentive to convince you on my view (and you don't > necessarily have to convince me to get the proposal adopted), so I'll only > answer specific points of the draft content: My job here is to accept most useful comments that can improve the draft and I welcome them. As I understand from your last messages, you concerns about the cases that this proposal does not support IPv4. Now it does.. but I only need to re-organize the draft and include it. http://www.ietf.org/proceedings/89/slides/slides-89-dnsop-2.pdf This might help until I submit the revised version. > > IMHO, this is a mechanism or an approach to update a zone file. What I > > meant in the document is to update a zone file and not different what > > mechanism is in use either the node wants to use incremental update or > > the other approach. This is why I used "update" word and not [AI]XFR. > > IF DNS people thinks it is better to use that word, then I just follow. > > > > Any thought? > > At least "update" is very confusing to me as it can be easily confused with > dynamic DNS updates. It doesn't have to be "[AI]XFR", but at least I'd avoid the > word "update" in this context. Ok, if you think it is confusing, in parenthesis I will add "[AI]XFR" > > The types section is not encrypted. Only the content of each section > > are encrypted. > > So for instance > > Type|length|reserve| no encryption but other parts encrypted except > > additional section > > I'm afraid I don't understand this. I don't even understand what "types > section" means. Maybe a detailed format of the message to be decrypted in > Section 11.4 will help. I will add picture to upcoming version. This might help. Thanks, Best, Hosnieh _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
