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 <be...@nlnetlabs.nl>
> 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
