kaiserd
commented
4 years ago I pushed an update to this PR. What do you think?
Closed huitema closed 4 years ago
kaiserd
commented
4 years ago I pushed an update to this PR. What do you think?
huitema
commented
4 years ago On 1/27/2020 7:32 AM, Daniel Kaiser wrote:
I pushed an update to this PR. What do you think?
Yes, these are good changes, they are in the PR now. If you have no additional issue, please change your review from "change requested" to "approve", and I will submit the new draft.
-- Christian Huitema
evyncke
commented
4 years ago Christian and Daniel,
All changes look good to me as well. Up to you the authors to upload this revised I-D and I will proceed with the publication process.
taking Eric's review into consideration:
Main point:
I have a fundamental issue with this document on the process side... DNSSD charter is explicitly about multi-link networks and the privacy issues described in section 3.1 are on the mDNS / multicast / single layer-2 domain... The abstract should also refrain from using a sheer mDNS example.
I have removed the MDNS reference form the abstract and added a reference to server based DNS-SD in the first paragraph of the introduction.
Some comments:
Terminology and RFC 2119. I find it weird to use this terminology in an informational document (esp when never used). Also RFC 8174 should then be used. And those are normative references if kept.
I removed the terminology section and the reference to RFC 2119. I also rewrote the imperative requirements in section 4, and use descriptive text instead.
Section 3.2, is “legal person” well defined in this context?
Changed to "entity" to avoid long discussions.
Section 3.2.2 perhaps worth mentioning briefly that the space in the service instance names are just for readers’ sake and are not really supported by BIND & co without escaping them
Done, with reference to section 4.1 of RFC 6763
Section 3.4.1 please add reference to <Ethernet "Magic Packet">
Hard one, there is no authoritative reference for that, just a bunch of industry documents probably under NDA. I removed the mention of Magic Packet, and added a weaselly reference to RFC 6762 which has veiled references to Apple's "sleep proxy".
Section 3.4.3 errs on the ‘solutions’ side while the title of this document is about ‘requirements’. Should it be removed and be the basis of another document?
Rewrote and shortened, keeping the references but changing the tone.
Section 4.1 numbered list appears as broken
Not broken when going through https://xml2rfc.tools.ietf.org/. I wondered what caused the glitch.
Should common elements of sections 4.1 and 4.2 be in a ‘common’ section?
Leaving as is for now. We might discuss removing the entire section 4, as it is a recap of the requirements expressed in section 3. Made sense when we added the normative language, but not so useful now.
Section 4.3 contains a list with a single element. Consider removing the list
Fixed. Two elements now.
A couple of typos: entitiy, identiy, ...
Fixed.