> On Dec 23, 2014, at 1:45 PM, Kerry Lynn <[email protected]> wrote: > > On Mon, Dec 22, 2014 at 6:40 PM, Ben Campbell <[email protected]> wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-dnssd-requirements-04 > Reviewer: Ben Campbell > Review Date: 2014-12-22 > IETF LC End Date: 2015-01-07 > IESG Telechat date: (if known) > > Summary: This draft is basically ready for publication as an informational > RFC. Its well written and easy to understand. > > Thanks. > > Major issues: > > None > > Minor issues: > > The acronym is a bit unfortunate. I suspect that much of the target audience > already knows SSD as "solid-state drive" Of course, I don't really expect you > to change it at this point in the process. :-) > > This is really just a mnemonic device within this draft to eliminate the need > for us to spell out "Scalable > DNS-SD" everywhere. SSD, to the extent that it satisfies the requirements > enumerated in this draft, is > the end goal of the WG. I doubt it will ever be used outside of that context.
No problem. I mainly found it amusing that I did a double take when I ran into SSD later in the document, and had to go back to where it was defined. I really don't expect a change. > > Nits/editorial comments: > > -- IDNits reports a couple of out-of-date references. > > What is the proper way to handle this issue at this stage? There were no > nits when I submitted -04, > but the beat goes on. Should we just wait until AUTH48 to resolve any out of > date references, or > should I generate a -05 now? I would check with your AD and/or shepherd. (This could also be done in the form of notes to the RFC editor.) > > -- REQ2: > > Am I correct in assuming that this would not apply to case C when used in > zero configuration mode? > > I think you are not correct. My reading of REQ2 is that some configuration > mechanism must be provided > in use case C to *allow* the end user to configure topologically-independent > zones if s/he so chooses. > In the event the end user a) chooses not to use the mechanism (Zero > Configuration mode) and b) there > are multiple zones, my opinion is that these will almost certainly be > topologically-dependent. I don't think that's far off from what I meant. I just wanted to make sure there was no contradiction between the requirement that C allow a zero-conf mode, and the requirement for C to allow configuration. As long as there are not contradicting assumptions that both be used at the same time, I think it's fine. > > HTH, -K- > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
