Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03
On 7/16/15 6:44 AM, Warren Kumari wrote: On Thu, Jul 16, 2015 at 2:23 PM, Andrew Sullivan a...@anvilwalrusden.com wrote: On Thu, Jul 16, 2015 at 01:30:03PM +0200, Warren Kumari wrote: We shouldn't be figuring out how useful a WG is by the number of documents published, but I don't think DNSOP is still where documents go to die... Agreed, but I also don't want to return to that bleak past where we could never get anything published because it wasn't perfect, and then the number of recycles got high enough that nobody would review, so the draft wasn't perfect, and so on. good enough is a substantiallly different bar then good. If there are things that folks really cannot live with I think that's really what I want to know about. +very many much lots. I just wanted to acknowledge the fact that our chairs are now getting documents pushed through W The editors will put their heads together once more on the basis of the most recent comments. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03
On 16 Jul 2015, at 03:15, Paul Hoffman paul.hoff...@vpnc.org mailto:paul.hoff...@vpnc.org wrote: On 15 Jul 2015, at 17:33, Andrew Sullivan wrote: Just on this issue, and speaking only for myself (but as one of the people behind this document), my view is that this WG has historically been one of the places where documents go to die, and I am unwilling to go through the exercise of proving again how great an enemy of the good the perfect can be. I'd be much more inclined to remove the contentious definitions and publish that document than to try to get things perfect. Firstly to say that I think this is a very worthy effort and the document will be of great value to the DNS community. It should be published and I support the proposal that removing contentious definitions to get the draft published is the a best way to proceed. I agree and acknowledge that there remain some definitions in there that are contentious. Not only do you agree and acknowledge that, *so does the document*. I have to disagree that the document goes that far - the first sentence of the third paragraph in the introduction states: “The definitions here are believed to be the consensus definition of the DNS community, both protocol developers and operators.” and paragraph 5 “In this document, where the consensus definition is the same as the one in an RFC, that RFC is quoted. Where the consensus definition has changed somewhat, the RFC is mentioned but the new stand-alone definition is given. so I don’t believe any definitions that are considered contentious should be in the document if this wording is to be retained. Based on the contention and lack of consensus for some of the definitions, the Introduction now says: During the development of this document, it became clear that some DNS-related terms are interpreted quite differently by different DNS experts. Further, some terms that are defined in early DNS RFCs now have definitions that are generally agreed to that are different from the original definitions. Therefore, the authors intend to follow this document with a substantial revision in the not-distant future. That revision will probably have more in-depth discussion of some terms as well as new terms; it will also update some of the RFCs with new definitions. Since this paragraph appears after the first statement about consensus I read it as indicating the bis is likely to refine and extend the original document (fine) but not that readers should expect some definitions presented here to substantially change in a later revision. Sara. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03
All, On Wed, 15 Jul 2015 20:33:59 -0400 Andrew Sullivan a...@anvilwalrusden.com wrote: On Tue, Jul 14, 2015 at 03:43:12PM -0400, Casey Deccio wrote: I am also concerned about the apparent urgency to get the initial document out with points that admittedly remain contentious and/or where there isn't WG consensus. I don't think it needs perfection, but it seems unnecessary to get the document published without further explicitly identifying and considering the standing issues. We've haven't had this document before--I'm not sure what the rush is now. Just on this issue, and speaking only for myself (but as one of the people behind this document), my view is that this WG has historically been one of the places where documents go to die, and I am unwilling to go through the exercise of proving again how great an enemy of the good the perfect can be. I'd be much more inclined to remove the contentious definitions and publish that document than to try to get things perfect. I totally agree, on all counts. Cheers, -- Shane ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03
On Thu, Jul 16, 2015 at 2:23 PM, Andrew Sullivan a...@anvilwalrusden.com wrote: On Thu, Jul 16, 2015 at 01:30:03PM +0200, Warren Kumari wrote: We shouldn't be figuring out how useful a WG is by the number of documents published, but I don't think DNSOP is still where documents go to die... Agreed, but I also don't want to return to that bleak past where we could never get anything published because it wasn't perfect, and then the number of recycles got high enough that nobody would review, so the draft wasn't perfect, and so on. +very many much lots. I just wanted to acknowledge the fact that our chairs are now getting documents pushed through W The editors will put their heads together once more on the basis of the most recent comments. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03
On 16 Jul 2015, at 14:14, Suzanne Woolf suzworldw...@gmail.com wrote: We have been through extensive review and a Working Group Last Call on this draft. The next revision should go ahead to the IESG. +1 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03
Hi, This is a good time to remind ourselves of how we got here. This draft came into the WG as an individual submission, with the authors seeking comment but not asking for it to be a WG work item. We eventually adopted it in the expectation that handling it as a WG draft would lead to higher quality review and higher credibility for the resulting document. There has seemed consistently to be very strong support that this document is needed. The chairs were in full understanding of the editors' views on the purpose of the document, and thought the WG was too: the intention was to get a good reference out in the field where people who aren’t necessarily as sophisticated as DNSOP regulars can use it, and then tackle the more difficult issues— where definitions aren’t fully consistent within the standard, or implementers and operators have diverged from the standard, or the standard is silent on some important aspect of the protocol. At this stage, I don’t think it’s a good use of the WG’s time to revisit the basis for adopting the draft. Nor do I think we’re going to resolve all possible contentions, no matter how much more time or how many more review cycles we insist on. Some will be noted as part of this document; some will be removed to wait for the next one. Not speaking for the editors, it does seem to me that it would be helpful for reviews to separate critiques of the form “I don’t think this accurately captures the definition of this term in existing documents” or “I think documentation and implementation/practice have diverged” from critiques of the form “I don’t like this definition or this aspect of the protocol.” We have been through extensive review and a Working Group Last Call on this draft. The next revision should go ahead to the IESG. best, Suzanne On Jul 16, 2015, at 8:23 AM, Andrew Sullivan a...@anvilwalrusden.com wrote: On Thu, Jul 16, 2015 at 01:30:03PM +0200, Warren Kumari wrote: We shouldn't be figuring out how useful a WG is by the number of documents published, but I don't think DNSOP is still where documents go to die... Agreed, but I also don't want to return to that bleak past where we could never get anything published because it wasn't perfect, and then the number of recycles got high enough that nobody would review, so the draft wasn't perfect, and so on. The editors will put their heads together once more on the basis of the most recent comments. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03
On Thu, Jul 16, 2015 at 11:15 AM, Shane Kerr sh...@time-travellers.org wrote: All, On Wed, 15 Jul 2015 20:33:59 -0400 Andrew Sullivan a...@anvilwalrusden.com wrote: On Tue, Jul 14, 2015 at 03:43:12PM -0400, Casey Deccio wrote: I am also concerned about the apparent urgency to get the initial document out with points that admittedly remain contentious and/or where there isn't WG consensus. I don't think it needs perfection, but it seems unnecessary to get the document published without further explicitly identifying and considering the standing issues. We've haven't had this document before--I'm not sure what the rush is now. Just on this issue, and speaking only for myself (but as one of the people behind this document), my view is that this WG has historically been one of the places where documents go to die, and I am unwilling to go through the exercise of proving again how great an enemy of the good the perfect can be. I'd be much more inclined to remove the contentious definitions and publish that document than to try to get things perfect. I totally agree, on all counts. +1 on getting it published. I should point out that the emphasis should be on the historically in WG has historically been one of the places where documents go to die. Recently this working group has been munching though and getting documents published. 2012: 1 RFC 2013: 1 RFC 2014: 1 RFC 2015: 3 RFC, 4 documents are with the IESG / RFC Ed. We shouldn't be figuring out how useful a WG is by the number of documents published, but I don't think DNSOP is still where documents go to die... W Cheers, -- Shane ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03
On Thu, Jul 16, 2015 at 01:30:03PM +0200, Warren Kumari wrote: We shouldn't be figuring out how useful a WG is by the number of documents published, but I don't think DNSOP is still where documents go to die... Agreed, but I also don't want to return to that bleak past where we could never get anything published because it wasn't perfect, and then the number of recycles got high enough that nobody would review, so the draft wasn't perfect, and so on. The editors will put their heads together once more on the basis of the most recent comments. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03
On 15 Jul 2015, at 17:33, Andrew Sullivan wrote: Hi, On Tue, Jul 14, 2015 at 03:43:12PM -0400, Casey Deccio wrote: I am also concerned about the apparent urgency to get the initial document out with points that admittedly remain contentious and/or where there isn't WG consensus. I don't think it needs perfection, but it seems unnecessary to get the document published without further explicitly identifying and considering the standing issues. We've haven't had this document before--I'm not sure what the rush is now. Just on this issue, and speaking only for myself (but as one of the people behind this document), my view is that this WG has historically been one of the places where documents go to die, and I am unwilling to go through the exercise of proving again how great an enemy of the good the perfect can be. I'd be much more inclined to remove the contentious definitions and publish that document than to try to get things perfect. I agree and acknowledge that there remain some definitions in there that are contentious. Not only do you agree and acknowledge that, *so does the document*. Based on the contention and lack of consensus for some of the definitions, the Introduction now says: During the development of this document, it became clear that some DNS-related terms are interpreted quite differently by different DNS experts. Further, some terms that are defined in early DNS RFCs now have definitions that are generally agreed to that are different from the original definitions. Therefore, the authors intend to follow this document with a substantial revision in the not-distant future. That revision will probably have more in-depth discussion of some terms as well as new terms; it will also update some of the RFCs with new definitions. If there is something more that can be said in the document, by all means let us know. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03
On 7/15/15 10:15 PM, Paul Hoffman wrote: Not only do you agree and acknowledge that, *so does the document*. Based on the contention and lack of consensus for some of the definitions, the Introduction now says: During the development of this document, it became clear that some DNS-related terms are interpreted quite differently by different DNS experts. Further, some terms that are defined in early DNS RFCs now have definitions that are generally agreed to that are different from the original definitions. Therefore, the authors intend to follow this document with a substantial revision in the not-distant future. That revision will probably have more in-depth discussion of some terms as well as new terms; it will also update some of the RFCs with new definitions. If there is something more that can be said in the document, by all means let us know. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop Also, the document took the approach early on of documenting what existing RFCs said in one place. When it became clear that what the RFCs say may not be how people currently use the term, the consensus in the working group was to document the existing definition, and flag it as in disagreement. Once this document was pushed out, *then* the revised draft could actually update old RFCs. As chair, I also felt that once this draft is published (and all contention removed), it would become something that would be part of the document shepherding process - to make sure new RFCs actually used accurate terminology. But that may be a pipe dream. I do think the authors have done an impressive job considering the scope of the document and the depth and breath of comments. tim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03
Sorry for the top-post. As I understand things, this is more than a choice. RFC 2181 requires it, I think, no? -- Andrew Sullivan Please excuse my clumbsy thums. On Jul 15, 2015, at 06:00, John Dickinson j...@sinodun.com wrote: On 14/07/2015 17:26, Casey Deccio wrote: On Tue, Jul 14, 2015 at 12:00 PM, Paul Hoffman paul.hoff...@vpnc.org mailto:paul.hoff...@vpnc.org wrote: On 13 Jul 2015, at 14:20, Casey Deccio wrote: 4. In the definition of RRset, the bit about TTLs needing to be the same seems out of place for this terminology document. That is an operational requirement. Disagree. To some people, TTLs are operational, to others they are part of the master file format. For the latter, this sameness applies to the definition. No, the zone file can contain different TTLs. As far as I know most implementations choose to reduce the TTLs for all RRs in an RRSet to the lowest value. What I am saying is that whether the TTLs are the same (correct) or the TTLs are different (incorrect), it doesn't change the definition of RRset, which is the set of RRs with the same name/class/type. Therefore the requirement that the TTL be the same is not a useful statement for the definitions doc, whether it's operational or standards-based. I agree. John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03
On 14/07/2015 18:15, Tim Wicinski wrote: On 7/14/15 12:26 PM, Tony Finch wrote: Paul Hoffman paul.hoff...@vpnc.org wrote: This is still contentious, and I think it really should be deferred to the -bis document for longer discussion and hopefully consensus. As far as I can tell from the last few months there is a fairly clear consensus that the current draft is not good enough. Brushing off suggestions by saying that we'll publish a turkey then fix it up later is not a good way to encourage people to contribute. Tony. Tony I would have to disagree with you on the consensus. There was many comments on the draft, and the authors did an admirable job addressing them and attempting to find common ground. The decision was made to first document all existing terminology in one place, regardless of how accurate it is to the world today; and then take time to generate a revised document where many definitions would be updated, and other documents partially obsoleted. But I would not call it a turkey. Tim, After a quick read of -03 I would saay the draft is in much better shape than last time I read it. I wouldn't call it a turkey, but I do agree with Tony that deferring anything contentious to a -bis is a bad way forward, especially for a draft that is only 3 months old (since the -00). regards John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03
Hi, On Tue, Jul 14, 2015 at 03:43:12PM -0400, Casey Deccio wrote: I am also concerned about the apparent urgency to get the initial document out with points that admittedly remain contentious and/or where there isn't WG consensus. I don't think it needs perfection, but it seems unnecessary to get the document published without further explicitly identifying and considering the standing issues. We've haven't had this document before--I'm not sure what the rush is now. Just on this issue, and speaking only for myself (but as one of the people behind this document), my view is that this WG has historically been one of the places where documents go to die, and I am unwilling to go through the exercise of proving again how great an enemy of the good the perfect can be. I'd be much more inclined to remove the contentious definitions and publish that document than to try to get things perfect. I agree and acknowledge that there remain some definitions in there that are contentious. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03
On Wed, Jul 15, 2015 at 10:55:19AM +0100, John Dickinson j...@sinodun.com wrote a message of 47 lines which said: I wouldn't call it a turkey, but I do agree with Tony that deferring anything contentious to a -bis is a bad way forward, It's harsh to say that everything contentious have been deferred. A lot of complicated issues (with strong disagreements) were solved in this working group and I would sadly regret that we lose this work because other issues are not yet solved. especially for a draft that is only 3 months old (since the -00). 7.5 months (since draft-hoffman-dns-terminology-00) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03
On Jul 13 2015, Casey Deccio wrote: I have a few comments on the latest draft-ietf-dnsop-dns-terminology (-03). There will be more; I'm part way through a review. [snip] 3. The current text for referral is incomprehensible. I suggest the following: [snip again] Historically, many authoritative servers answered with a referral to the root zone when queried for a name for which they were not authoritative, but this practice has declined. [I know this part was copied from the existing draft, but ...] Surely this should be for a name for which they were not authoritative, nor for any of its ancestors ? Also, as such a response is undoubtedly still legal, maybe this ought to mention what the common(er) practice now is - presumably REFUSED. -- Chris Thompson Email: c...@cam.ac.uk ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03
On 13 Jul 2015, at 14:20, Casey Deccio wrote: 1. (stylistic) There are a number of definitions that quote terminology and then parenthetically state quoted from. It seems more intuitive, precise, and consistent to mark quoted text using quotation marks instead, as in other definitions. Some examples (there are probably more): - Canonical name - CNAME - NODATA - Resolver Yes, the document does not use a consistent style to say what is quoted. I did this to make it more readable. In specific, I think using quotation marks will make it less readable. If there are specific places where the style makes it unclear what is quoted, we should correct that, but trying to be completely consistent will make some parts harder to read. 2. For the public suffix definition, I suggest the following: A domain that is controlled by a public registry (RFC 6265, 5.3). For security reasons many user agents are configured to reject Domain attributes that correspond to 'public suffixes' (RFC 6265, section 4.1.2.3). I like using the direct definition; I don't like discussing things outside HTTP (such as web browsers) unless it is really needed. There is nothing inherent in a domain name to indicate whether or not it is a public suffix; that can only be determined by outside means. One resource for identifying public suffixes is the Public Suffix List (PSL) maintained by Mozilla (http://publicsuffix.org/). I kinda like the idea of adding the reference to the Mozilla list as one resource. Do others agree? (optional) The IETF DBOUND Working Group was chartered to solve the more general issue of identifying or repudiating relationships between domain names, outside of the DNS namespace itself, which could change the role of a public suffix. 3. The current text for referral is incomprehensible. I suggest the following: A response generated using local data which contains no answer but rather includes name servers which have zones which are closer ancestors to the name than the server sending the reply (RFC 1034, sections 4.1 and 4.3.1). These name servers take the form of NS records in the authority section of the response and come from the NS RRs marking cuts along the bottom of a zone when a match would take us out of the authoritative data (RFC 1034, section 4.3.2). Referrals are only associated with non-recursive (i.e., iterative) queries (RFC 1034 section 4.3.1). In general, a referral is a way for a server to send an answer saying that the server does not know the answer, but knows where the resolver should direct its query should be directed in order to eventually get an answer. Historically, many authoritative servers answered with a referral to the root zone when queried for a name for which they were not authoritative, but this practice has declined. See also Glue Records. This is still contentious, and I think it really should be deferred to the -bis document for longer discussion and hopefully consensus. 4. In the definition of RRset, the bit about TTLs needing to be the same seems out of place for this terminology document. That is an operational requirement. Disagree. To some people, TTLs are operational, to others they are part of the master file format. For the latter, this sameness applies to the definition. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03
On Tue, Jul 14, 2015 at 12:00 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: On 13 Jul 2015, at 14:20, Casey Deccio wrote: 1. (stylistic) There are a number of definitions that quote terminology and then parenthetically state quoted from. It seems more intuitive, precise, and consistent to mark quoted text using quotation marks instead, as in other definitions. Some examples (there are probably more): - Canonical name - CNAME - NODATA - Resolver Yes, the document does not use a consistent style to say what is quoted. I did this to make it more readable. In specific, I think using quotation marks will make it less readable. If there are specific places where the style makes it unclear what is quoted, we should correct that, but trying to be completely consistent will make some parts harder to read. I'm not sure how adding quotation marks makes things less readable. If we're saying that we're quoting text, I'd really like to know what the text is that we're quoting. If we're paraphrasing, no quotation marks are necessary. This is a fairly standard practice. 3. The current text for referral is incomprehensible. I suggest the following: A response generated using local data which contains no answer but rather includes name servers which have zones which are closer ancestors to the name than the server sending the reply (RFC 1034, sections 4.1 and 4.3.1). These name servers take the form of NS records in the authority section of the response and come from the NS RRs marking cuts along the bottom of a zone when a match would take us out of the authoritative data (RFC 1034, section 4.3.2). Referrals are only associated with non-recursive (i.e., iterative) queries (RFC 1034 section 4.3.1). In general, a referral is a way for a server to send an answer saying that the server does not know the answer, but knows where the resolver should direct its query should be directed in order to eventually get an answer. Historically, many authoritative servers answered with a referral to the root zone when queried for a name for which they were not authoritative, but this practice has declined. See also Glue Records. This is still contentious, and I think it really should be deferred to the -bis document for longer discussion and hopefully consensus. Could you help me understand which parts of the (reworded) paragraph are contentious? Independent of the current intended definitions for referral, the current text really is unreadable and (in my opinion) unsuitable for an initial document. 4. In the definition of RRset, the bit about TTLs needing to be the same seems out of place for this terminology document. That is an operational requirement. Disagree. To some people, TTLs are operational, to others they are part of the master file format. For the latter, this sameness applies to the definition. What I am saying is that whether the TTLs are the same (correct) or the TTLs are different (incorrect), it doesn't change the definition of RRset, which is the set of RRs with the same name/class/type. Therefore the requirement that the TTL be the same is not a useful statement for the definitions doc, whether it's operational or standards-based. Regards, Casey ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03
Paul Hoffman paul.hoff...@vpnc.org wrote: This is still contentious, and I think it really should be deferred to the -bis document for longer discussion and hopefully consensus. As far as I can tell from the last few months there is a fairly clear consensus that the current draft is not good enough. Brushing off suggestions by saying that we'll publish a turkey then fix it up later is not a good way to encourage people to contribute. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Southeast Fitzroy: Northerly 5 to 7. Moderate, occasionally rough in south. Fair. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03
On 7/14/15 12:26 PM, Tony Finch wrote: Paul Hoffman paul.hoff...@vpnc.org wrote: This is still contentious, and I think it really should be deferred to the -bis document for longer discussion and hopefully consensus. As far as I can tell from the last few months there is a fairly clear consensus that the current draft is not good enough. Brushing off suggestions by saying that we'll publish a turkey then fix it up later is not a good way to encourage people to contribute. Tony. Tony I would have to disagree with you on the consensus. There was many comments on the draft, and the authors did an admirable job addressing them and attempting to find common ground. The decision was made to first document all existing terminology in one place, regardless of how accurate it is to the world today; and then take time to generate a revised document where many definitions would be updated, and other documents partially obsoleted. But I would not call it a turkey. tim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03
On Tue, Jul 14, 2015 at 1:15 PM, Tim Wicinski tjw.i...@gmail.com wrote: On 7/14/15 12:26 PM, Tony Finch wrote: Paul Hoffman paul.hoff...@vpnc.org wrote: This is still contentious, and I think it really should be deferred to the -bis document for longer discussion and hopefully consensus. As far as I can tell from the last few months there is a fairly clear consensus that the current draft is not good enough. Brushing off suggestions by saying that we'll publish a turkey then fix it up later is not a good way to encourage people to contribute. I would have to disagree with you on the consensus. There was many comments on the draft, and the authors did an admirable job addressing them and attempting to find common ground. Hi Tim, You'll excuse my lack of familiarity with the process, but what is the current status of this draft (not a -bis version), in terms of opportunities for continued feedback and modification by the WG? I realize that it has been in the WG for a while, has been sent to the AD, and WG comments have tapered off some. But your wording sounds somewhat definite. I do understand that the authors have done a great job addressing comments and attempting to get consensus and common ground. That being said, this document covers a lot of ground, and it has been noted that there are points on which there is not consensus--even points that are contentious. Perhaps what would be helpful is to identify which definitions in the document don't have consensus--and (if possible) even which parts of those definitions are problematic. Focusing on those points, rather than the document as a whole, will allow the WG to determine whether consensus can be found on those definitions or whether they should be minimized sufficiently to avoid the contention and fleshed out at a later time (i.e., in a -bis document). I feel like there is a difference between settling on what's there and settling on something minimal. The decision was made to first document all existing terminology in one place, regardless of how accurate it is to the world today; and then take time to generate a revised document where many definitions would be updated, and other documents partially obsoleted. But I would not call it a turkey. I am also concerned about the apparent urgency to get the initial document out with points that admittedly remain contentious and/or where there isn't WG consensus. I don't think it needs perfection, but it seems unnecessary to get the document published without further explicitly identifying and considering the standing issues. We've haven't had this document before--I'm not sure what the rush is now. Best regards, Casey ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
