Re: [dnssd] dnssd Digest, Vol 99, Issue 4

[Martin Turon <[e-mail]>]

RE: Last call review of
https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp

Hi DNSSD Team,

I have reviewed the latest version of this document (draft-ietf-dnssd-srp-14)
and believe it is ready to publish.

Some optional editorial comments:

   - First instance of RR acronym could be expanded for clarity: `RR
   (Resource Record)`
   - References to RFC2136 do not appear as links in html as refs to other
   RFCs do.
   - References to RFC7942 in section 9 have no links in html.
   - Reference to RFC2782 in section 2.2.5.4
   <https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-14.html#section-2.2.5.4>
   "Compression in SRV" records
   <https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-14.html#name-compression-in-srv-records>
has
   no link in html.

Some general technical clarification questions:

   - 2.2.4.1 First-Come-First-Serve: "As long as the registration service
   remembers the name and the key used to register that name, no other server
   can add or update the information associated with that." -- this implies
   records are held forever and doesn't mention any requirement to refresh or
   expire the record.  It may be good to adjust the wording slightly to add
   some summary or forward reference to "2.2.5.3.
   <https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-14.html#section-2.2.5.3>Record
   Lifetimes
   <https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-14.html#name-record-lifetimes>"
   so it is clear the FCFS will expire dormant record claims.
   - 2.2.5.1 "The requestor generates a public/private key pair." When I
   read this I immediately ask myself what is the algorithm used (ECC, RSA,
   etc) to generate these pub/priv keys and what are the key sizes?  I
   couldn't find answers to this in the section.  A forward reference to "
   5.3.
   <https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-14.html#section-5.3>Required
   Signature Algorithm
   <https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-14.html#name-required-signature-algorith>"
   would help.
   - 2.2.5.4.
   <https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-14.html#section-2.2.5.4>Compression
   in SRV records
   <https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-14.html#name-compression-in-srv-records>
    "an SRP requestor SHOULD compress the target in the SRV record."  The
   method of compression to be used isn't referenced directly, thus assumes a
   reader very familiar with the suite of DNS protocol RFCs.  Also, the
   supporting rational text in this section implies that compression can be
   mandatory for SRP.  If so, why not make this a MUST?  Is it to maximize
   interoperability with some potentially older implementations?
   - 2.3.6.
   <https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-14.html#section-2.3.6>Optional
   Behavior
   <https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-14.html#name-optional-behavior>
mentions
   the concept of "Reverse Mapping" without any reference or details as to
   what it is or where it is specified.  I'm assuming it is referring to
   adding records to map from IP address back to service, but some added
   reference would be helpful.

Regards,
Martin
_____________________________
Martin Turon  |  Google


On Mon, Aug 8, 2022 at 3:45 PM David Schinazi <[e-mail]>
> wrote:
>
>> Hi DNSSD enthusiasts,
>>
>> As promised during our meeting at IETF 114 two weeks ago, we are issuing
>> a second Working Group Last Call (WGLC) for draft-ietf-dnssd-srp. To remind
>> folks of the timeline, we had our first WGLC for this document in July
>> 2021. That WGLC was successful in establishing WG consensus in publishing
>> this document, but did expose some issues that needed to be resolved before
>> publication. The authors then did a first round of addressing comments in
>> October 2021 and another in July 2022. The authors now think that all
>> comments received during the original WGLC have now been addressed. Since
>> so much time has passed, we're having a full second WGLC to give everyone
>> an opportunity to read the document with fresh eyes. This WGLC will last
>> for two weeks until 2022-08-22 at 23:59 UTC. Please let us know if you have
>> any remaining concerns with this document, especially if you had commented
>> on the previous WGLC with concerns that you wanted to see resolved.
>>
>> The latest draft is available on the datatracker:
>> https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/
>>
>> Please send responses to the DNSSD list as replies to this email.
>>
>> Thanks,
>> David and Chris
>> _______________________________________________
>> dnssd mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnssd
>
>