On Tue, Dec 23, 2014 at 3:19 PM, Ben Campbell <[email protected]> wrote:
> > > 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. > > I see your point. Taken together, REQ1 and REQ2 state there should be support for both non-configured and configured modes of operation in use case C. Hopefully it will be clear that these modes are mutually exclusive. Regards, -K- > > > HTH, -K- > > > >
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
