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

[Ben Campbell <[e-mail]>]

> 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.

> 
> HTH, -K-
>