Re: [Gen-art] Gen-ART LC Review of draft-ietf-dnssd-requirements-04

[Kerry Lynn <[e-mail]>]

On Tue, Dec 23, 2014 at 3:19 PM, Ben Campbell <[e-mail]> wrote:

>
> > On Dec 23, 2014, at 1:45 PM, Kerry Lynn <[e-mail]> wrote:
> >
> > On Mon, Dec 22, 2014 at 6:40 PM, Ben Campbell <[e-mail]> 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-
> >
>
>