Hi John,
Thank you for re-raising this! We've been waiting for it :)
On 3/5/25 03:24, John Scudder via Datatracker wrote:
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
Thanks for this document. While my knowledge of the subject area is limited, it
seems clear and well-written.
I have one point to DISCUSS. Actually, we already are discussing it, in my
follow-up to Roman's ballot,
https://mailarchive.ietf.org/arch/msg/dnsop/0T2AHx1K8M8U0tc7Ec0AIoEphoo/ et
seq. (we wandered off of the public mailing list archive after that one
though). The reason I'm capturing this as a DISCUSS point is that I think, as
we discussed, what's in 07 isn't OK -- either there needs to be some kind of
guidance to the Designated Expert(s), or the policy needs to be changed to one
that doesn't require such guidance. I don't mind what solution is chosen, as
long as there is one.
The authors opted for adding more useful guidance for experts. We now have:
NEW
[...] Expert reviewers should take into consideration the
following points, but are being designated as experts for a reason,
so they should be given substantial latitude:
* Point squatting should be discouraged. Reviewers are encouraged
to get sufficient information for registration requests to ensure
that the usage is not going to duplicate one that is already
registered and that the point is likely to be used in deployments.
The code points tagged as "Private Use" are intended for testing
purposes and closed environments. Code points in other ranges
should not be assigned for testing.
* A specification of a scheme is desirable, but early assignment
before a specification is available is also possible. When
specifications are not provided, the description provided needs to
have sufficient information to identify what the point is being
used for.
* Experts should take into account that field values are fit for
purpose. For example, the mnemonic should be indicative and and
have a plausible connection to the scheme's notification
mechanism.
If this looks OK to you, we'll submit a new revision with it once the
submission cut-off is over. Meanwhile, here's the diff:
https://author-tools.ietf.org/api/iddiff?url_1=https://peterthomassen.github.io/draft-ietf-dnsop-generalized-notify/20250305_dnsdir/draft-ietf-dnsop-generalized-notify.txt&url_2=https://peterthomassen.github.io/draft-ietf-dnsop-generalized-notify/20250306_iesg/draft-ietf-dnsop-generalized-notify.txt
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
I have only one other point to raise -- In Section 4.3 you have "NOTIFY(CDS)
messages carrying notification payloads (records) for several child zones MUST
be discarded, as sending them is an error." Shouldn't that be "more than one
child zone" instead of "several" (which my dictionary defines as "more than two
but not many")?
Yes, probably; shall fix. (TIL!)
Best,
Peter + co-authors
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
