Re: [DNSOP] WGLC rfc8499bis for revised lame delegation definition
Hi kc, On 17/07/2023 21:41, k claffy wrote: I agree it would greatly help to include the more precise terms. Note that Scott's current EPP draft is still using this term, citing the definition in 1912. Should the term be removed from Scott's draft, or acknowledged that it is now historic? If Scott replaces it with another more precise term, can we get that term in this document so that future uses can cite this document? Alternatively, instead of deprecating, the last sentence of that paragraph could be "Because...and now is not specific or clear as to the intended meaning, sufficient context may be required to remove undesired ambiguity." ( similar to 'validating resolver'? ) Thank you for your remarks. The chairs acknowledge that more precise terms are useful and desirable. For progress, we decided not to include newer terms of different types of broken delegation in the current rfc8499bis. More discussion on these terms is required, and the chairs and authors of the document feel that this should be written down in another draft. We would like to invite you or other DNSOP participants to put your thoughts in a new draft to discuss with the WG and to come to more precise definitions of various broken delegations. This new draft (RFC) can later be referenced by the DNS Terminology document. Best regards, -- Benno ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC rfc8499bis for revised lame delegation definition
Dear WG, Thank you for your thoughtful feedback during the WGLC for the revised lame delegation definition. With this email, we close the WGLC for rfc8499bis. With the discussion and feedback during the interim and with the WGLC on the mailing list, the chairs have determined there is rough consensus on the proposed wording on lame delegation, and as it is now included in the latest revision of rfc8499bis on datatracker. After the document shepherd write-up, the document is sent to the IESG as the next step. Best regards, -- Benno On 18/07/2023 08:17, Havard Eidnes wrote: Note that Scott's current EPP draft is still using this term, citing the definition in 1912. Should the term be removed from Scott's draft, or acknowledged that it is now historic? If Scott replaces it with another more precise term, can we get that term in this document so that future uses can cite this document? [SAH] My draft uses the term in only one place where it describes practices that can "introduce risks of lame delegation". I'm inclined to change that sentence to something like "introduce risks of invalid DNS delegation" to avoid the term completely if it eliminates the need for a normative reference that doesn't yet exist. Don't take this the wrong way -- I'm not picking on you presonally... But I think this illustrates one of the problems with coming up with "specific and clear" alternatives to the "lame delegation" characterization which is also brief, precise, and doesn't have too wide difference to normal-language usage. Because... Even though my first language is not English, I would have thought that it ought to be possible to distinguish between a "valid" and an "invalid" delegation without querying for the actual current operational state wrt. to the given zone, i.e. there has to be some evident "rule violation" involved. Quoting the Merriam-Webster dictionary: invalid : not valid: a : being without foundation or force in fact, truth, or law | an invalid assumption | declared the will invalid b : logically inconsequent The most relevant part here would be "without foundation in ... law", if we consider the RFCs "law" within this area, which isn't too far- fetched. E.g. it would IMHO be "invalid" to use an NS record with a name server name which contains "_" in its name, because there is at least a deep- seated convention (if not a rule from ... rfc 952?) that host names, i.e. names which resolve to A and/or records (and therefore, by extension, name server names), should not contain "_" in their owner name (by default enforced by BIND to this day, when loading an authoritative zone), i.e. "it explicitly goes against the rules". (And, yes, I know that not everyone agrees with this rule...) I would claim the flavour is distinctly different, and that "invalid delegation" is not a good substitute for "lame delegation". Regards, - Håvard ___ 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] WGLC rfc8499bis for revised lame delegation definition
>> Note that Scott's current EPP draft is still using this term, >> citing the definition in 1912. Should the term be removed >> from Scott's draft, or acknowledged that it is now historic? >> If Scott replaces it with another more precise term, can we >> get that term in this document so that future uses can cite >> this document? > > [SAH] My draft uses the term in only one place where it describes > practices that can "introduce risks of lame delegation". I'm > inclined to change that sentence to something like "introduce risks > of invalid DNS delegation" to avoid the term completely if it > eliminates the need for a normative reference that doesn't yet > exist. Don't take this the wrong way -- I'm not picking on you presonally... But I think this illustrates one of the problems with coming up with "specific and clear" alternatives to the "lame delegation" characterization which is also brief, precise, and doesn't have too wide difference to normal-language usage. Because... Even though my first language is not English, I would have thought that it ought to be possible to distinguish between a "valid" and an "invalid" delegation without querying for the actual current operational state wrt. to the given zone, i.e. there has to be some evident "rule violation" involved. Quoting the Merriam-Webster dictionary: invalid : not valid: a : being without foundation or force in fact, truth, or law | an invalid assumption | declared the will invalid b : logically inconsequent The most relevant part here would be "without foundation in ... law", if we consider the RFCs "law" within this area, which isn't too far- fetched. E.g. it would IMHO be "invalid" to use an NS record with a name server name which contains "_" in its name, because there is at least a deep- seated convention (if not a rule from ... rfc 952?) that host names, i.e. names which resolve to A and/or records (and therefore, by extension, name server names), should not contain "_" in their owner name (by default enforced by BIND to this day, when loading an authoritative zone), i.e. "it explicitly goes against the rules". (And, yes, I know that not everyone agrees with this rule...) I would claim the flavour is distinctly different, and that "invalid delegation" is not a good substitute for "lame delegation". Regards, - Håvard ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC rfc8499bis for revised lame delegation definition
> With the DNSOP interim meeting last June, we reworded the definition > of "lame delegation". This new definition of "lame delegation" has > been shared on the mailing list and included by the document authors > in the latest revision of the rfc8499bis draft, > https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-rfc8499bis-08. Yes, I noticed that earlier suggestion, and at the time I did not raise my voice (or use my keyboard...). That doesn't mean I'm not disappointed. What was the specific reasons given at the DNSOP interim meeting in June (where I did not attend)? Any notes to share? It is my humble opinion that the definition of "lame delegation" from rfc1912 is "fine", and is consistent with what I perceive to be the correct use of the term: A delegation to a name server which does not serve the zone in question. I also concur with the others who have commented on this part: it should be considered historic, and avoided in favor of terms that are specific and clear. that this is sort of a "cop-out", in that the document doesn't actually suggest "terms that are specific and clear" to be used in preference. As such, I suspect this suggestion will be quite ineffective in eradicating the term's use. Old habits die hard, especially when no "specific and clear" alternatives are presented. Best regards, - Håvard ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC rfc8499bis for revised lame delegation definition
> -Original Message- > From: DNSOP On Behalf Of k claffy > Sent: Tuesday, July 18, 2023 12:41 AM > To: George Michaelson > Cc: Benno Overeinder ; DNSOP Working Group > ; DNSOP Chairs > Subject: [EXTERNAL] Re: [DNSOP] WGLC rfc8499bis for revised lame > delegation definition > > Caution: This email originated from outside the organization. Do not click > links > or open attachments unless you recognize the sender and know the content > is safe. > > > I agree it would greatly help to include the more precise terms. > > Note that Scott's current EPP draft is still using this term, citing the > definition > in 1912. Should the term be removed from Scott's draft, or acknowledged > that it is now historic? > If Scott replaces it with another more precise term, can we get that term in > this document so that future uses can cite this document? [SAH] My draft uses the term in only one place where it describes practices that can "introduce risks of lame delegation". I'm inclined to change that sentence to something like "introduce risks of invalid DNS delegation" to avoid the term completely if it eliminates the need for a normative reference that doesn't yet exist. Scott ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC rfc8499bis for revised lame delegation definition
I agree it would greatly help to include the more precise terms. Note that Scott's current EPP draft is still using this term, citing the definition in 1912. Should the term be removed from Scott's draft, or acknowledged that it is now historic? If Scott replaces it with another more precise term, can we get that term in this document so that future uses can cite this document? Alternatively, instead of deprecating, the last sentence of that paragraph could be "Because...and now is not specific or clear as to the intended meaning, sufficient context may be required to remove undesired ambiguity." ( similar to 'validating resolver'? ) thanks for impressive document, k On Tue, Jul 18, 2023 at 11:37:44AM +1000, George Michaelson wrote: > To the definition and future use of lame, I think this is reasonable > editorial. > > I think the draft could use some linkage to the "better terms" so it's > clear what terms are now held to refer to what we formerly called > "lame" -But that would be connective, not substantive to the > definition of what lame "is" (or rather "was" since we're deprecating > it) > > cheers, and thanks for the work on this everyone concerned. > > -G > > On Tue, Jul 18, 2023 at 8:40???AM Benno Overeinder > wrote: > > > > Dear WG, > > > > With the DNSOP interim meeting last June, we reworded the definition of > > "lame delegation". This new definition of "lame delegation" has been > > shared on the mailing list and included by the document authors in the > > latest revision of the rfc8499bis draft, > > https://author-tools.ietf.org/iddiff?url2=draft- ietf-dnsop-rfc8499bis-08. > > > > This one-week Working Group Last Call is only about the definition of > > "lame delegation". As mentioned above, the wording is the result of the > > interim meeting, where it was identified that the original definition of > > "lame delegation" does not cover current operational issues and that > > more precise terms are preferred. > > > > We believe the current wording reflects the views shared on the mailing > > list over the past two months, and we ask for confirmation. If there > > are strong objections to the current definition in revision -08, we > > return to the original rfc8499 definition. Regardless of the outcome, > > after this WGLC the document will be forwarded to the IESG for publication. > > > > This WGLC will end on Monday, 24 July. > > > > Best regards, > > > > Benno > > for the DNSOP co-chairs > > > > ___ > > 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC rfc8499bis for revised lame delegation definition
To the definition and future use of lame, I think this is reasonable editorial. I think the draft could use some linkage to the "better terms" so it's clear what terms are now held to refer to what we formerly called "lame" -But that would be connective, not substantive to the definition of what lame "is" (or rather "was" since we're deprecating it) cheers, and thanks for the work on this everyone concerned. -G On Tue, Jul 18, 2023 at 8:40 AM Benno Overeinder wrote: > > Dear WG, > > With the DNSOP interim meeting last June, we reworded the definition of > "lame delegation". This new definition of "lame delegation" has been > shared on the mailing list and included by the document authors in the > latest revision of the rfc8499bis draft, > https://author-tools.ietf.org/iddiff?url2=draft- ietf-dnsop-rfc8499bis-08. > > This one-week Working Group Last Call is only about the definition of > "lame delegation". As mentioned above, the wording is the result of the > interim meeting, where it was identified that the original definition of > "lame delegation" does not cover current operational issues and that > more precise terms are preferred. > > We believe the current wording reflects the views shared on the mailing > list over the past two months, and we ask for confirmation. If there > are strong objections to the current definition in revision -08, we > return to the original rfc8499 definition. Regardless of the outcome, > after this WGLC the document will be forwarded to the IESG for publication. > > This WGLC will end on Monday, 24 July. > > Best regards, > > Benno > for the DNSOP co-chairs > > ___ > 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
[DNSOP] WGLC rfc8499bis for revised lame delegation definition
Dear WG, With the DNSOP interim meeting last June, we reworded the definition of "lame delegation". This new definition of "lame delegation" has been shared on the mailing list and included by the document authors in the latest revision of the rfc8499bis draft, https://author-tools.ietf.org/iddiff?url2=draft- ietf-dnsop-rfc8499bis-08. This one-week Working Group Last Call is only about the definition of "lame delegation". As mentioned above, the wording is the result of the interim meeting, where it was identified that the original definition of "lame delegation" does not cover current operational issues and that more precise terms are preferred. We believe the current wording reflects the views shared on the mailing list over the past two months, and we ask for confirmation. If there are strong objections to the current definition in revision -08, we return to the original rfc8499 definition. Regardless of the outcome, after this WGLC the document will be forwarded to the IESG for publication. This WGLC will end on Monday, 24 July. Best regards, Benno for the DNSOP co-chairs ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
