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

From: Ben Campbell <[email-masked]>
Date: Mon, 22 Dec 2014 17:40:02 -0600

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.

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

Nits/editorial comments:

-- IDNits reports a couple of out-of-date references.

-- REQ2:

Am I correct in assuming that this would not apply to case C when used in zero configuration mode?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 22 Dec 2014 22:41:20 -0500

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

You are the first person to point this out!   Hm.   Differentiated Neutronium Solid State Disks?

Thanks for the review.   I will let the authors respond.   (Authors, please respond!)

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 23 Dec 2014 14:45:36 -0500

On Mon, Dec 22, 2014 at 6:40 PM, Ben Campbell <[email-masked]> wrote:

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

Nits/editorial comments:
> 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 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.

HTH, -K-

---

From: Ben Campbell <[email-masked]>
Date: Tue, 23 Dec 2014 14:19:17 -0600

> On Dec 23, 2014, at 1:45 PM, Kerry Lynn <[email-masked]> wrote:
> 
> 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.

> 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

I would check with your AD and/or shepherd. (This could also be done in the form of notes to the RFC editor.)

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

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 23 Dec 2014 16:24:56 -0500

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

> > 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:
> >
> > DNS-SD" everywhere.  SSD, to the extent that it satisfies the
> requirements enumerated in this draft, is
> 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:
> >
> 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-

---

From: Ted Lemon <[email-masked]>
Date: Tue, 23 Dec 2014 22:03:34 -0500

On Dec 23, 2014, at 4:24 PM, Kerry Lynn <[email-masked]> wrote:
> 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

Why not update the document to say so explicitly, and fix the idnits while you're at it?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 23 Dec 2014 22:04:02 -0500

> Why not update the document to say so explicitly, and fix the idnits while you're at it?

(Although you should probably hold off on the update until the last call has expired.)