Folks,
Widespread diverse restrictions in devices/implementations/applications
with an expected residual lifetime in the order of a another decade
_are_ technical restrictions, not policy.
All work on DNS I have followed in the recent years always was under
the umbrella of conserving compatibility with deployed systems,
and the costs for doing that indeed sometimes were really high.
This was justified.
Robustness has to remain the guiding principle when "tuning" the DNS.
One of the obligations we have in the IETF is, IMHO, to take care
of transparency, to avoid introducing fragility that hampers
communication between users all over the world.
That's an engineering aspect, and hence a technical aspect, not policy.
We are faced with a scenario where some few voices want to open the
doors wide to challenge the force of storms.
Isn't is better engineering practice to keep the door almost closed,
open it only a small slot wide -- just so much as current needs have
been identified --, and observe what happens, before undertaking the
next step?
If the storm breathes in and destroys your ... (here: ability for all
to communicate using all assigned domain names), you likely won't be
able to close the door back far enough to restitute something
resembling the "status quo ante"!
Andrew Sullivan spoke:
> I think Joe's pragmatic approach is the right one: document right now
> that whatever the restrictions might historically have been, we are
> quite explicitly going to permit at the very least one class of
> labels.
+1
> If people feel strongly that in fact the TLD label restriction never
> was there and should not be, then once this document is published you
> all can go out and write the draft, "TLD label character restrictions
> considered harmful", and pursue the publication of that as an RFC. In
> the meantime, we have at least a technical document that makes clear
> that certain things are permitted.
+1
Looking through another pair of glasses, this seems to be a simple
application of the robustness principle:
- be conservative in what you send
(frequently: "MUST set to 0, unless future specs say otherwise",
and here: be conservative in what labels are allowed to be
placed in the public DNS), but
- be liberal in what you accept
(frequently: "MUST ignore the value, to allow for future
extensions",
and here: educate implementers that they should get rid of
restrictions that prohibit future extension of the set of
possible labels to be expected)
If you want to define an extension later for the 'originating' side,
it is prudent to check for adherence to the "be liberal" principle
on the 'consumer' side before you do it.
Kind regards,
Alfred.
--
+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: a...@tr-sys.de |
+------------------------+--------------------------------------------+
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
