Toerless Eckert asked me for feedback on draft-ietf-anima-brski-discovery-09.
I will confess that I did not read the whole thing thoroughly from start to
finish. I did skim the parts related to DNS-SD as Toerless requested. As
somebody who is not thoroughly immersed in this work, I found the document
quite difficult reading. Just beginning with the abstract, it leaps into lots
of acronyms that I don’t know:
This document specifies how to make BRSKI communications
autoconfiguring, extensible and resilient in the face of simultaneous
use of different variations of the BRSKI protocol (BRSKI, BRSKI-AE,
BRSKI-PRM, constrained BRSKI, stateless constrained BRSKI proxies).
It would be helpful for people new to this work if the abstract at least began
it with a sentence explaining what BRSKI is for and what it does.
Reducing use of reference-as-noun would also help readability. If a reader
doesn’t already know what all the references are, the use of unknown references
as substitutes for English words makes reading the document feel like reading
Clockwork Orange where you have to keep guessing what the mystery words mean.
To anyone who doesn’t know the secret code, the text reads like this:
In this document, a role is functionality performed by a BRSKI entity
either as an initiator or responder. [SomeDocument] defines the roles
of pledge, Join Proxy, registrar, MASA. [SomeDocument] adds the role
Registrar-Agent. Trust anchor is a dependent role required by BRSKI,
provided through [SomeDocument] or other protocols in [SomeDocument].
I suggest running the document through an AI proofreading tool, or at least a
spell-checker. The first paragraph of the Overview has three mistakes in two
sentences:
BRKI was designed to support multi-vendor deployments ideally with
zero additional provisioning in the network just to support BRSKI.
In recent years, multiple variations of the BRSKI protocol *where*
specified, *sich* as [BRSKI-PRM], [BRSKI-AE], [cBRSKI] and [cPROXY];
within these documents *that* are multiple options that need to be
supported by all BRSKI entities involved in a BRSKI enrollment, such
as pledge, proxy and registrar.
where -> were
sich -> such
that -> there
There seems to be some unnecessary editorializing about why simply using
DNS-Based Service Discovery would not work:
Because of the different options of how to run DNS-SD, the
requirements in this document do not guarantee interoperability when
using DNS-SD. One side could use unicast DNS-SD, the other mDNS, and
there may be no mapping between the two.
...
Hence, a
mandatory to implement (MTI) profile is not feasible because of the
wide range of variations to deploy DNS-SD.
This is inventing problems that don’t really exist. For devices on Ethernet or
Wi-Fi, simply use DNS-SD over Multicast DNS, and everything will work. For
devices on Thread, use unicast DNS using Service Registration Protocol (SRP).
Work is underway for defining zero-configuration SRP for Ethernet and Wi-Fi,
with forward/backward-compatibility so that new devices use SRP when it is
available while still working with older devices that only support Multicast
DNS. Thread is new, so it avoided the backward-compatibility issue by just
going straight to using unicast SRP for everything (multicast capacity is
especially scarce with the limited throughput on Thread networks). In any case,
these details are out of scope for this document. Just use DNS-SD as defined
for the interface hardware the device has, and as DNS-SD evolves and develops
new capabilities for various link types, devices using DNS-SD will inherit
those improvements transparently as they become available.
Variation Strings from the IANA registry Table 8 are encoded as DNS-
SD Keys with a value of 1 in the DNS-SD service instances TXT RR
using the shortened encoding of "key" instead of "key=1". In result,
the value of the TXT RR is a sequence of zero terminated strings,
each one indicating a single supported variation type choice.
A variation may have the option of being represented by the empty
string "". This is not allowed in the DNS-SD encoding, and instead
the alternative variation string MUST always be used for DNS-SD.
Variation strings in DNS-SD are case insensitive as required by DNS-
SD. It is RECOMMENDED to only announce lowercase variation strings
in DNS-SD.
The use of variation strings can easily break the DNS-SD rule that
they keys should be no more than 9 characters long. This is
justified by the absence of value fields to keep the total length of
the TXT RR reasonably short.
This seems confused. I don’t know what “value of 1” means. It sounds like you
are just defining boolean attributes. Why are your strings zero terminated? Why
do you choose to not allow empty strings? If you choose to break the DNS-SD
rule that keys should be no more than 9 characters long then this is not
DNS-SD. You should expect that client libraries for DNS-SD might define a
ten-character array as a stack variable to hold the key name as a C string, and
any key names that don’t fit in this are rightly ignored as invalid. This is
the whole point of defining limits in protocol specifications -- so that
implementers know what they have to support.
If you want to express a list of supported variation strings, I suggest you
define a key “vars” where the value is a comma-separated list of supported
variation strings, similar to how printers express their list of supported page
description languages as a comma-separated list of MIME types:
pdl=image/urf,image/jpeg,
application/octet-stream,application/pdf,application/postscript,
application/PCLm,application/vnd.hp-PCL,application/vnd.hp-PCLXL
In several places in the document lines exceed the 72-character maximum width
for text-format RFCs.
Stuart Cheshire
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
